Fedora Rel-Eng Meeting Recap 2007-JUN-11
John Poelstra
poelstra at redhat.com
Tue Jun 12 14:13:49 UTC 2007
Recap and full IRC transcript found here:
http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2007-jun-11
Please make corrections and clarifications to the wiki page.
== Buildroot contents for updates ==
* The buildroot used for fedora 7 updates building is not self
updating. It only contains things from f7-gold, and stable released
updates. This means that one update candidate cannot be built against
another update candidate without rel-eng interaction. We haven't been
very vocal about this yet, and it isn't documented anywhere.
* Do we want to adjust things or leave them be?
* See IRC log for discussion points
Decision: Talk to lmacken about modifying Bodhi to do a sanity check on
published buildroot contents before allowing an update be pushed. After
that we will make the dist-fc7-build buildroot auto-update with
-candidate builds and see what happens.
== Expand Standard Operating Procedures (SOPs) ==
* f13
* rel-eng has more and more people helping out so we want to make
sure that things are well documented
* Infrastructure team started doing SOP/ pages (Standard Operating
Procedure) and they are proving very useful. I'd like to start doing
them for Release Engineering too
* thinking of ReleaseEngineering/SOP/<task> as the layout, the SOP
page itself could be a list of pages and info on how to add an SOP
* Proposal: As a release engineer, as you do tasks for Fedora, check
to see if there is an SOP/<task> page. If there isn't, create one and
poke rel-eng folks for review.
* This is more of a mandate than a vote item.
== Early Torrent Release - Rahul Sundaram ==
* explore possibility of doing early torrent releases.
* See IRC log for discussion of pros and cons and affect on mirrors
Decision: Investigate with Infrastructure team ways of getting more
mirrors to participate in seeding the torrent (early?). Do not release
torrent to general public before the agreed upon coordinated release
date/time.
== Upgrade path enforcement - Rahul Sundaram ==
* Discussion surrounding policy that upgrade path should not break
from a particular point on, for example, after Test1 or Test2--enforced
by Release Engineering.
* See IRC log for discussion details
Decision: Recommend to FESCo policy that upgrade path never be
compromised either by removing builds or NEVR regressions. File RFE in
Koji to enforce rule at build time
More information about the fedora-devel-list
mailing list