Re: OF package maintainers please vote: Scope of OF?

[PhilipNienhuis]

Oliver Heimlich wrote
> On 10.01.2017 13:51, Olaf Till wrote:
>> Dear all,
>> 
>> there is no new person authorized to initialize a vote on Octave
>> Forge, but maybe you see the need for it, although I'm not the right
>> person to start it.
>> 
>> After a controversial discussion in the thread "...looking for a new
>> leader..." and a similarly controversial off-list discussion
>> initalized by Julien with Oliver and me, I think the first principal
>> issue to decide on is the following:
>> 
>> There are two different main concepts proposed for OF:
>> 
>> 1. Simply maintain a list of packages, hosted elsewhere.
>> 
>> 2. Continue to execercise some central control onto contained
>>    packages, making the package maintainers potentially bound to some
>>    majority- or admin-decisions.
>> 
>> For 2., two subvariants have been proposed:
>> 
>> 2.1. In addition to the controled packages, maintain a list of
>>      independent packages, checked only for some formal structural
>>      conformance, which are primarily hosted elsewhere. OF contains
>>      'copies' of the external repositories, synchronized at least at
>>      release time. The package maintainer has exclusive control, if OF
>>      decides to fork the package, a different package name must be
>>      used.
>> 
>> 2.2. Only the controled packages are contained in OF.
>> 
> 
> I maintain the following OF packages: interval, strings, and vibes. The
> last-mentioned is developed (and released) externally.
> 
> My opinion is that we should target on concept 2.2 for OF. Reasoning: I
> want to keep the concept of commonly developed packages, helping each
> other to make high quality releases, and stay in touch with Octave core
> during development, which lowers the entry barrier for people like me. I
> gave several reasons for this in my mail dated January 9 (01:39 CET).
> 
> As a consequence, we have to “get rid” of externally developed packages
> on OF. It's a matter of respect to developers who wish to be free to
> make releases on their own. We should support this, but should not burn
> out ourselves doing so. Also I believe we have no right to restrict
> others who don't want to agree with the rules dictated by OF.
> 
> Dropping externally developed packages from OF immediately would be a
> bad service to the community. So I suggest the following plan:
> 
> - Keep status quo (concept 2.1) for today with a new leader (and
> possibly team of admins) for OF.
> - Develop a package database, where registered users may enter
> meta-information about their just released external packages (cf.
> concept 1). It shall be possible to enter OF packages into this
> database, and OF packages might get flagged (“seal of quality”).
> - The database shall be free for anyone to enter their packages with a
> minimum amount of criteria to be fulfilled (complete meta-data including
> maintainer contact information, download URL and documentation URL, no
> duplicate package names). Any quality checks (if any at all) shall be
> automated and there shall be no need for approval of uploads (though the
> admin team might take down dangerous/illegal entries once they get to
> know them). The database should not be hosted on OF and be maintained by
> a different team. The database shall contain only meta information, in
> particular no file hosting or repository hosting will be included and
> must be set up by the package maintainers elsewhere (Github, Bitbucket,
> Savannah.nongnu.org, SourceForge).
> - Once the database is up and running, Octave core should get a “pkg
> install -fancynewdatabase 
> <packagename>
> ” switch, lookup the URL of the
> package tarball, download the package from an external URL and try to
> install the package.
> - Then we can deprecate any externally developed packages on OF and no
> longer accept releases for them until the maintainer decides to put her
> package under control of OF again.
> - Improve the package database with automated checking tools and more
> features. A lot of these might come as a byproduct from a fresh team for
> OF (see first bullet), who have to agree on some rules and can formalize
> these in formal checks.
> 
> AFAIC we have at least Olaf, me, and maybe Philip(?) and CdF(?) would
> support this plan and take care of OF with concept 2.2. Who else?

To me it looks like something between 2.1 and 2.2.

I like the idea that there are more or less "official" OF packages that (1)
feature some quality control, (2) to the outside world suggest that they
belong, or relate closely, to Octave, and (3) feature, or suggest, some sort
of continuity: if the maintainer goes AWOL some other maintainer can easily
take over (at least in theory).  
So OF packages have the aura of being closer tied to Octave than to its
creator / its maintainer du jour.

Such packages should (IMO) at least have a repo on OF (to guarantee the
continuity).  Where the actual development takes place is irrelevant, as
long as there's an OF repo synced with the external repo.

I have no strong opinions further than that..

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/OF-package-maintainers-please-vote-Scope-of-OF-tp4681358p4681433.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.