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

[Stefan van der Eijk]

Comments in-line:

Richard

-----Original Message-----
From: Stefan van der Eijk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:34 AM
To: [EMAIL PROTECTED]; cooker
Subject: Re: [Cooker] the line between cooker and contrib.

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).

** And I am sure that there are many other locations of programs
** that are a part of all this, but who knows all the locations?

Hmmm... someone on the zarb.org machine has a list of urpmi repositories... Forgot the exact URL though.

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.

** Oh, I agree, and the standards do not seem to be the same
** for each of the different areas. It would be nice to have a ** more concise and consistent front to Mandrake.

Anyone disagree?

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)

** Heh, I am sure that we could really start a long dialogue
** on this, but this is a good start.  Now if only someone
** from Mandrake could pick this up since in theory they do
** OWN all of this.

Yup... there is so much they can leverage, if they just manage it in the right way...

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.

** There can be a reason to have different levels of trust in a ** package and to ensure that a minimum amount of requirements and
** testing are met. I can easily see the need for at least a two level
** environment, if not three, but not any more than that.

But do are seperate urpmi repositories / development environments needed? Or can they be managed in one?

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.

** I agree that everything should be pointing to a single goal which
** is the creation of a more robust and stable Linux platform that
** we can all enjoy. But, since Mandrake has been having a few ** problems managing this process and maintaining a sufficient workforce
** for the amount of effort that is required, some of this will have ** to be delegated to those that can help with the work for the good
** of all of us.

I hope they work on getting this process implemented, instead of wasting their resources trying to do it by themselves...

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).

** While the voting is nice, I am not really sure about the accuracy of
** what is being voted upon. Each person gets so many votes per week
** and with having to vote in 9.1 AND 9.0, or any other version the
** concept gets pretty washed out. It would almost be better for each
** member to have a vote per package, and be able to give a grade 1-10.
** This would then allow each person to decide how important a
** particular package may be.

** For example, there are many packages that I will never use, and ** standardly delete from EVERY install that I have. Anyway, I am not
** sure of the validity of the current voting system, and not sure I ** have a good suggestion for a replacement at this time.


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.

** These are great ideas, and perhaps someone with some MDK authority
** can help us move to something like this.

I suggested it to them back in September 2001. The time wasn't right then... Maybe it is now. I think we (the community) should work out these ideas into something more solid, get more people to support it and then present it to mdk management.

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.

** And this point is something that I would really like to see. Why
** not rebuild often? Instead of having a 9.1b2, you could have a
** 9.1-01-28-03 or something like that.

:-) No daily iso's though --> cost too much BW.

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.

** Exactly.

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?

** How about someone from MDK to step in here with the discussion?

Any mdk managers reading this?

Stefan

smime.p7s
Description: S/MIME Cryptographic Signature