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

[Oliver Heimlich]

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?

Nobody has voted for option 1 yet, so I see a problem that we are
missing the new package database (meta repository), which is required to
get away from 2.1. Maybe we can build on top of some existing software
(like a tailored version of the FSF free software directory).

Best
Oliver

signature.asc
Description: OpenPGP digital signature