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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
