[DRE-maint] Bug#807169: README.Debian / advice about plugins

[Marc Dequènes (duck)]

Quack,

First, sorry you did not get a reply at the time and thanks for your 
input. I think this is still relevant so I will reply.

On Sun, 06 Dec 2015 13:42:33 +0100 Daniel Pocock wrote:

> It seems that a lot of functionality (e.g. tagging, iCalendar support)
> is not in Redmine itself and this has to be added using plugins.

There were a few additions but it's still the case for several classical 
features like tags:
  http://www.redmine.org/issues/1448

> Could you add some notes about this to README.Debian, the wiki[1] or 
> both?

I inherited the redmine maintenance and did not know we had a wiki page. 
It's not in a bad shape but still would need some love, adding to the 
todolist.
Since 3.0 the README.Debian was improved and we'll continue doing so.

> - README.Debian already describes setting X_DEBIAN_SITEID for rake
> commands. The installation instructions for many plugins (example[2])
> recommend running a rake command. Should X_DEBIAN_SITEID be set for
> those rake commands and does the rake command need to be run for each
> instance? Or is a plugin installation shared between multiple 
> instances?

You're right, plugins installation was not documented at all. I added a 
chapter for 4.0.4-3.

> - README.Debian gives an example rake command using sudo www-data.
> Should plugin installation be run as www-data or as root?

Antonio make a great jobs at modernizing the installation procedure and 
it now uses triggers, so plugin installation does not require to run 
rake commands manually anymore. This is not covered in the new chapter.

> - Can you comment on best practices for packaging plugins? As part of
> my project, I'm likely to use at least 2 or 3 plugins and would 
> probably
> like to upload them to Debian.

So with the new system and use of triggers you just need to drop files 
in the plugins/ directory, nothing else.

We've had quite some work around the main package and I still did not 
get time to work on the few packaged plugins. When I get to it I guess I 
could write a few lines in README.Debian about it.

> - Can you comment on selection of plugins (and their suitability for
> being in Debian)? I notice that many of them appear to be for specific
> Redmine versions and discussions in the issue trackers frequently
> indicate plugins breaking with newer versions of Redmine or Rails. Is
> this likely to be troublesome for supporting packages of the plugins?

Well, in my personal experience with plugins, they do not often survive 
a Debian release time. I guess that's why previous maintainers did not 
packaged many.

The tags absence is not solved in the core and the one you were using 
has not been updated for two years. There is a PR about supporting Rails 
4 and we're already using 5. So I guess it's a good example that even 
when there's a real demand for a feature there's no certitude it's going 
to be maintained.

Currently my only plan is to see if we can have the recaptcha plugin 
back. I don't think this is sustainable to commit to maintain 
non-critical plugins.

> - I could also imagine that if some plugin becomes part of core then
> people using one of the alternative plugins (e.g. there are several
> plugins for tagging right now) might have trouble during a package
> upgrade to the version of Redmine where it is part of core. Has anybody
> with more experience with Redmine dealt with such situations already 
> and
> can anybody comment on the impact for people who may contemplate
> uploading plugin packages to Debian?

I think upstream is unwilling to add too many big feature to core, so it 
does not seem likely.
Currently the only plugins you cannot remove easily from core are 
gravatar and open_id_authentication.
I've been using Redmine for many years with a handful of plugins and 
never encountered this situation.

> - Some other families of packages (e.g. Drupal) have scripts for
> automatically creating packages of their plugins (e.g.
> dh-make-drupal[3]). Is anybody already working on something like that
> for Redmine plugins?

No, but since with the new system there's nothing to do but installing 
files in the right directory, I don't think this is needed anymore.

> - If a dh-make-redmine tool was created, it could be interesting to
> automatically build an unofficial apt repository of all official 
> Redmine
> plugins

Not sure. Manual installation is pretty easy in the new system 
(documented in the new chapter too). Also all advertized plugins are not 
in a usable state.


I'll keep this bug open to remind us to add a note about plugin 
packaging and to update the wiki page.

Thanks for your input.
\_o<

-- 
Marc Dequènes