Last week we had a Fedora Talk meeting regarding the No Frozen Rawhide proposal. This meeting was to quickly get everybody back up to speed on the proposal, walk through a typical release cycle, and identify the parts of the proposal that still need work. We then outlined what the blocking items were, and not-so-blocking with available workarounds, and who would be responsible for getting the blockers done and the schedule for completion. There was a gobby session open at the time too, and notes were taken from the meeting. They can be found at the bottom of this message. The high level plan is as follows: - Continue to produce rawhide as a repo of packages without install images. - At feature freeze, branch CVS for F-13 - devel/ now builds for F-14, reflect that in fedora-release and koji - F-13 builds are published to pub/fedora/linux/releases/13/Everything/ nightly - Potential F-13 builds are published to pub/fedora/linux/updates/testing/13/ either nightly or as part of standard updates pushes. - Bodhi will be used for managing builds from F-13. Push to testing goes to the updates-testing location. Push to stable goes to the Everything/ path. - Install images created in the Everything/ path. - Packages in the critical path will require positive karma from releng or qa before allowed to go stable. Packages outside the critical path will be managed just as updates are now. - At F13 Release Candidate stage, pushes to "stable" will go to pub/fedora/linux/updates/13/ instead of the Everything/ path. Release blocking fixes will be pulled into Everything/ There are lots of other details to the above, but that's a good overview. There are some major obstacles to getting this done, the two biggest being bodhi and the compose infrastructure. Bodhi is currently being rewritten, partly to enable us to add the functionality we need. I have an action item to sync up with Luke Macken to make sure he is aware of our needs and will be able to implement them in time for F13 Feature Freeze. If not, we have a fallback to using trac for tag requests, but very non-optimal. The compose infrastructure needs some improvement to be able to handle making multiple trees each day, as well as additional updates repos. Bill Nottingham is taking the lead on this work and will be investigating various ways to speed up our processes. This is the one true blocker to this effort, if we simply do not have the resources to compose a never ending rawhide plus a pending release, we will have to postpone these changes until such resources are obtained. We will continue to talk about no frozen rawhide and get updates from the various tasks being worked on in our weekly release engineering meeting (Mondays at 1800 UTC), and I suspect we'll be talking about it quite a lot at FUDCon in Toronto. Please feel free to contact me on IRC, or post to fedora-devel-list if you have any questions regarding this proposal and how Fedora development will operate in the future. Below you'll find the gobby notes from our meeting: Attendees: John Poelstra, Bill Nottingham, Jesse Keating, Dennis Gilmore, James Laska, Warren Togami, Steven M. Parrish, <add yourself> https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal (aka NFR :) Right now: - rawhide is pulling from F-13 - rawhide does not have images At some point: - rawhide will pull from F-14 - we will branch everything in CVS, and start a second F-13 tree - we create the F-13 version in bugzilla (and any other associated things in our normal process) - we do 'something' in fedora-release and mirrormanager to put people on the right repos -- where does this tree go. releases/13/Everything? +1+1 -- testing updates to go updates/testing/13/ --- make sure this path is OK with mirrors Possible Alternatives - at feature freeze? +1+1+1+1 - at beta freeze? How it works for developers, after branch: - tag - build - 'make update' Tool changes/scope: * koji/release engineering ** need autosigning *** Assignee: Jesse * releng scripts ** need to be able to build a second nightly tree *** Assignee: Jesse, Bill * mash ** needs to be able to build trees faster. HOW? *** Split packages into subdirs (Seth's idea) *** Use multiple compose boxes *** (kill multilib?) *** (kill deltas?) (updates only?) *** Assignee: Bill, Jesse * Bodhi ** need to have 'pre-release' updates that go into an updates-testing, have a process on tagging them ** critical path requires releng/QE signoff; other packages can be promoted by maintainer, or by karma ** how does this work with buildroot overrides? Badly. *** can we have bodhi control buildroot overrides ** Needs to have this behavior 'switch' to pushing updates to the normal areas *** at RC stage? *** at gold stage? ** Need to confirm availability of Luke Macken to make required changes otherwise this section can't happen (after we scope out all the changes that need to happen here) *** Assignee: Luke * Automated testing (AutoQA) ** Watcher/hook support for monitoring for test events (post-bodhi-update) ** https://fedorahosted.org/autoqa/milestone/autoqa%20depcheck ** Defining package-level tests needed for bodhi acceptance (deps, conflicts etc...)? ** How will tests publish results into bodhi? (autoqa web interface, links from bodhi and koji? to autoqa) ** Not a requirement for go forward with NFR, but would make a lot of other things better * Documentation ** document, document, document. Warn users as to what they need to do; inform them if they're not doing it. ** This *will* cause confusion for developers at first. ** need to be very very loud as we make these changes *** Create some scripts to discover people who don't realize the issues NEXT STEPS 1) put gobby results into wiki and clarify plan of action on proposal page (Jesse) 2) Pull in Luke to brief on plans and confirm timeline (Jesse) 3) Work the mash issues (Bill) 4) Next meetings will take place at Monday Release Engineering meetings FALLBACK PLAN: *Branch at Feature freeze * freeze using f13-alpha tag * use trac to manage tag requests * freeze using f13-beta tag ** rinse and repeat till release is done -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
