On Sep 20, 2011, at 8:45 AM, Doug Ledford wrote: > > Instead, I think we ought to revamp the process like this: > > Maintainer A builds new package B > Maintainer A files a bodhi ticket for package B > In that ticket, the maintainer is responsible for list each item of change > from the previous package already in the compose tree. For example, did the > upstream source get bumped, did any new patches get applied, did any old > patches stop being applied, are the changes verified bug fixes as tested in > rawhide, are the changes isolated or are there feature additions as well, > will this update create dependency problems from things such as an soname > bump, will other packages need to be rebuilt. > Finally, the bodhi update should be reviewed by people from release > engineering, and if the ticket meets the requirements of a reasonable change > at this late stage of the game, the ticket should be approved and the package > pushed to stable. > > The point of this process is that when stabilizing the product for GA, we > want to minimize unnecessary or risky churn, and that doesn't need testing, > that needs a human to make a judgement call. Then, once the judgement call > is made, we need as much testing as possible to make the release as good as > possible. Holding things up in updates-testing and then releasing them later > throws away untold instances of testing, wasting those resources on a package > that may never be on the final product. We need to make that judgement call, > put the package in if we are going to, test the hell out of it, and fix any > breakage we find. We need this iterative "test, report breakage, fix, > retest" process to be as fast as possible, and our current process moves at > the speed of a salt coated slug. > > That's my proposed process for our early branched release. Thoughts?
This is essentially what we had a while ago, only with trac tickets instead of bodhi requests. There were a couple of problems with this. 1) Nowhere near enough releng folks to properly review all the tickets. 2) 9 times out of 10 there was very little data put into the ticket. 3) releng folks were often not the best people to decide whether a change was "too risky" 4) There was no easy way to get at the package and assess its stability. I think there were more issues, but those come to mind first. We decided it was best instead to make a repository out of proposed changes, and let your packaging peers decide whether or not the update was safe enough to go into the release, thus we have bodhi and updates-testing as a gateway to get into the release. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
