Fwd: No Frozen Rawhide Meeting Summary

Tue Nov 24 09:12:43 CET 2009

Forwarding this here, just to make sure everybody sees it, as I guess we
have to simply follow Fedoras lead here and lay our repos out in a
similar fashion to make sure users of rawhide and "current release +1"
get everything they need and test our stuff.

CU
knurd

-------- Original-Nachricht --------
Betreff: No Frozen Rawhide Meeting Summary
Datum: Mon, 23 Nov 2009 11:37:27 -0800
Von: Jesse Keating <jkeating at redhat.com>
Antwort an: Development discussions related to Fedora
<fedora-devel-list at redhat.com>
Organisation: Red Hat
An: Development discussions related to Fedora <fedora-devel-list at redhat.com>

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

-------------- next part --------------
-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list