Re: Proposal for a team of admins

[Julien Bect]

Le 10/01/2017 à 15:21, Julien Bect a écrit :

Le 10/01/2017 à 14:58, Julien Bect a écrit :

I am co-maintainer of the (externally hosted !) stk package, and (more or less implicitely) the maintainer of the generate_html and gsl packages.

I vote for option 2.1.

OF is already, and should remain IMHO, a mix of self- and externally hosted packages (with a set of rules to maintain coordination of the OF package ecosystem as a whole).

More on this in a separate thread.

I take this opportunity to propose myself as one member of an "admin team" that would continue and expand the work that was done by Carnë.

I give below some details about my view of OF, and especially the "controversial" (quoting Olaf) issue of externally-hosted packages.  [....]

I will continue here a discussion started with Philip on the other (voting) thread:

Julien Bect-2 wrote

Le 10/01/2017 à 23:31, PhilipNienhuis a écrit :

I have a very slight (55 % vs 45 %) preference for 2.2, because of the extra work involved with 2.1. However if that extra work can be shifted towards the maintainers of those independent packages I think 2.1 my preference will change into 2.1.

Hi Philip, Can you explain what this extra work is, exactly ?

Not exactly, but I'm thinking of e.g., maintaining the infrastructure on octave.sf.net and in Octave itself (pkg -forge) needed for those external packages, keeping repos sync'ed, that sort of things. All of it depending on how exactly "external packages" can be integrated with Octave-Forge and core Octave.

The way I see it there is not much additional work for OF admins:

* When the EHP [1] is created, we have of course to create its OF-repo by cloning its main repo.  But for other packages, we also have to create an OF-repo [-> no additional work].

* Keeping repo sync'ed is, in my mind, entirely of the package maintainer's responsibility [-> no additional work].

* Checking that repos are sync'ed when making a release.  The way I see it, this is done by checking that the release tarball can be reproduced from source (on the OF repo).  This is easily scriptable and, if the test fails, it is the responsibility of the package maintainer to make things right.  Moreover, I think that this must be done for OFHP [2] as well: even an experienced OF maintainer can sometimes forget to push some changes ;-) [-> no additional work].


[1] Externally Hosted Package... we're discussing some much these days, I thought that a shortcut might come in handy.

[2] OctaveForge Hosted Packages