Re: [Cooker] the line between cooker and contrib.

[Stefan van der Eijk]

In thinking of this some more, I realized that I only
added to the mass of confusion and complaints. So, I will try to be more clear with the issues, and a possible
set of solutions.

Go for it!

There are three distribution and contribution points.  These
are the cooker, the contrib., and the club.

don't forget the PLF, and all the other bits an peices people having lying around because they can't get it uploaded into a "main" distro (cooker / contrib / club / plf).

There does not
seem to be a clear definition of the difference between these
or what the relationship should be.

The fact that much is undocumented at mdk is causing a lot of confusing and frustration. Put things on paper, make a descision! And keep the papers up2date.

A second set of issues is around the contributions themselves.
Where should something be contributed, and who has permission, and if access is needed, who can grant that access.

and:

   * what kind of access do they need (https upload, shell?)
   * who checks what is uploaded (QA, etc)

So, here is a recommended solution for this:

The contrib. are should allow anyone to upload suggested packages
that they have constructed. These would be considered the
lowest level of contribution. To be allowed to move to the
second level, and include a binary RPM, they must be mentored
by someone.  This gets them to the club level.  Once again, they
should be able to upload packages as they are able.  To post
something for cooker, they once again must be mentored.  When they
are able to produce packages that meet a well-documented set
of requirements, then they will be elevated to cooker level.

Good idea. But personally I'd change a few things:
make one big repository. I don't see the value of added confusion of having multiple repositories. The difference of between cooker / contrib / plf (plf is difficult due to legal issues) / club is the status which a package has, it shouldn't be the physical location it is in.

A package which is now in cooker(= an important package) is, and will be maintained by a mdk employee only. The other packages can be maintained by anyone who feels like it. The objective is to keep the large distro working together as one unit as it is being developped, in the end cooker, contrib and club packages are going to be installed on one system and will need to work together, right? When the time comes that the distro needs to be made, the packages will be sorted out and put onto different CD's. The first one containing core OS (basesystem, X, kde, gnome), and the last one the least important stuff. OS dependancies and a voting system will determin which packages go onto which CD.

As times change certain software becomes popular and other software goes out of fashion. Same is the case at mdk. The voting system will help to show which package is needed and which one can be lost. Contributors (non mdk employees) should be able to "adopt" a package and be able to maintain it by themselves. If they don't maintain the package, it goes to a package orphanage, if nobody adopt it there, it dies (such is life).

The package maintainer will need to register himself and click through a EULA (just to get the legal things clear). He'll get a certificate + password that he can use to upload packages. Uploading packages will go through https (you don't want people to have shell access). Only the src.rpm will be uploaded --> there is too little control (security --> trojans, etc) to allow binary uploads. A mdk employee OK's the upload (checks through the diffs of the patches and .spec file) and the src.rpm proceeds to the build robot. where the binaries will be built (multi-arch?) and uploaded to the dsitro. New sources (when a version is bumped up) are retrieved from the URL specified in the .spec file --> don't trust the tar.bz2 a contributor puts in the src.rpm. If the build fails or there are rpmlint errors, the maintainer will be notified, with the resulting errors outputs.

Every 2 weeks the complete distro should be rebuilt (but not uploaded) to make sure that everything still builds. When a build fails, the maintainer is notified.

The advantages of this model are:

1. the community has more say in what goes in and what is not worth
the effort
2. the community can maintain packages by themselves, without
depending on mdk employees or priviledged users who have shell acces.
3. more controll for mdk over what goes into the distro --> tar.bz2
downloaded, mdk OK's patches and .spec file changes
4. less frustration with the contributors :-)
5. less effort for mdk to maintain the distro
6. the distro always works due to extensive build testing

Now, to really make this work, each of the mentor levels must
have the capability to increase access to the next level.  If
this is not done, the process no matter which one is followed
will NEVER scale and we will miss out on a lot of opportunity.

The system must scale, and the effort that mdk needs to put into it to let it scale must go down. Their role should be more along the lines of controlling the process instead of doing everything by themselves. Leverage the community.

While I realize this may not be the best possible fit, it is
however a suggested route that could ease the burden on the few
that control all the access and make this more a larger project
and potential success for all of us.

Very true.

Anybody want to start a project to discuss and outline ideas as presented above?

Stefan

smime.p7s
Description: S/MIME Cryptographic Signature