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? >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. >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. >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. 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. 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. 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. 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? Stefan
