I just became aware of the discussion on the contrib repo on
sw-porters-discuss through a cross-post, it does not seem to have
received attention there. The thread started here:
http://mail.opensolaris.org/pipermail/sw-porters-discuss/2008-November/000027.html
The proposal can be read here:
http://www.genunix.org/wiki/index.php/ContribRepo

As this is about the future of OpenSolaris I'm posting my
thoughts on indiana-discuss.
With the current proposal the contrib repository becomes IMHO a
dumping ground for packages which have been built by someone
somehow. I consider a non-reproducible build, that is how, with
what patches, compiler options etc. the package was built,
problematic for a number of reasons:

* The first is security, if the package is built by some unknown
  submitter, a review of the binary package only cannot easily
  enforce quality and make sure no backdoors are injected etc.
* If the original submitter abandons his package, people willing
  to take over might have to start all over again.
* Similarly, if there are a security issues with the package and
  the original submitter is unresponsive it might not be easily
  patched.
* If the way how a package is built is not public, it is
  impossible for someone to easily tweak it to his needs and
  recompile it.
* Lastly, it is problematic with some FOSS licenses such as the
  GPL which require a distributor of binary packages to make
  available the _corresponding_ source, simply providing a URL to
  external sources (as proposed) is not sufficient.

All of these problems could be avoided if both hosting of sources
and build recipes on opensolaris.org was *enforced* (the proposal
only mentions it possibly being a "target repository for software
generated packages") and packages were also built on
opensolaris.org. The simplest and most intuitive way to implement
this would be a public source code repository with build recipes
like JDS or SFE from which periodic builds are made which could,
after some QA, be put into the contrib package repository. This
does not exclude the possibility to package closed-source
software (the number of redistributable closed-source software
should be very small compared to the huge number of FOSS
available). This would have the additional benefit that build
recipes could be more easily integrated into JDS or SFW,
similarly to how SFE specs are often imported into JDS.

There are further aspects of the process which IMHO are
problematic. First there appears to be no real maintainership
concept, everybody can just dump a package in contrib and
everybody can approve it with a +1. There should be some
hierarchy, e.g. "approved" maintainers or sponsors which have the
right to move packages from pending to contrib and regular
maintainers (everybody else) which have proven themselves after
being mentored for some more time become "approved"
maintainers/sponsors as well.

The restrictions excluding Sun employees is just ridiculous
considering that they make up the vast majority of the community.
Do SFE maintainers who are employed by Sun have to find non-Sun
sponsors or are they completely excluded? Either way this cuts
severely into resources.

Cutting red tape is certainly appreciated but going from one
extreme to the other does not seem to be an improvement to me.
Please look at proven procedures of how similar projects operate,
e.g. Redhat/Fedora, Debian non-main, Ubuntu universe, FreeBSD
Ports, pkgsrc.
-- 
Guido Berhoerster
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss

Reply via email to