Fedora 14 Schedule Retrospective

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Could Have Been Better)
(Could Have Been Better)
Line 102: Line 102:
 
* Don't let updates with dependency issues into stable.
 
* Don't let updates with dependency issues into stable.
 
|-
 
|-
|| Notify mirrors || 2010-08-23 ||
+
|| Notify mirrors about new release content || 2010-08-23 ||
 
* https://fedorahosted.org/rel-eng/ticket/3862
 
* https://fedorahosted.org/rel-eng/ticket/3862
 
* No SOP exists for this particular rel-eng task.
 
* No SOP exists for this particular rel-eng task.
Line 110: Line 110:
 
* Include the actual procedure in the automatically filed rel-eng Trac ticket for releases.
 
* Include the actual procedure in the automatically filed rel-eng Trac ticket for releases.
 
|-
 
|-
|| Web content || 2010-08-24 ||
+
|| Web content change for F14 Alpha || 2010-08-24 ||
 
* Links in web content didn't match the actual mirror content (web links started with ''F14-'' whereas actual content starts with ''Fedora-''
 
* Links in web content didn't match the actual mirror content (web links started with ''F14-'' whereas actual content starts with ''Fedora-''
 
||
 
||

Revision as of 14:56, 24 August 2010

Background

Largely inspired by the success Fedora 13 QA Retrospecitve and the benefit of capturing data from ideas and events when they happen, this page is for tracking Fedora 14 schedule successes and mis-steps. It's goal is iteratively track and refine our process of testing and releasing Fedora 14 on time.

Any Fedora team member or community observer is welcome to add information here.

Successes

Task Date What was successful? How to Repeat It?
Pre-Alpha Rawhide Acceptance Test Plan #1 2010-07-12 Anaconda traces back on install. The success here is that we discovered this problem four weeks before the Alpha Compose Keep doing what we are doing
Pre-Alpha blocker bug meetings 2010-07-24 Meetings are happening each week and people are referencing the release criteria in the bugs--this is helping to save time at the review meetings
  • Continue to encourage people to become familiar with the release criteria and refer to it
Compose Alpha Release Candidate 2010-08-05
  • All blocker bugs were barely resolved in time.
  • Compose was completed on time---Dennis Gilmore filled in for Jesse Keating
  • Continue to build out SOP documentation so that others can rotate in
  • Hound blocker bug owners and keep requesting status
  • When there are no comments in the bug and maintainers are not responding, query Bodhi and Koji to see if new packages have been built
Tracking release blockers 2010-08-05
  • Continue tracking specific bugs and packages that are out of band of the stable branch and need to be manually included by recording them in the Trac ticket.
  • This provides transparency to all the people working on the process and lessens the chance of something being missed.
  • Save time having to recompose if if something is missed.

Could Have Been Better

Task Date What Happened? What To Do Differently Next Time?
Create Installable Images for QA testing #1 2010-07-08
  • Not ready until 2010-07-12
  • Installer lead was out during week, backup built anaconda-14.10-1.fc14 and pykickstart-1.76-1.fc14 in rawhide on 2010-07-08
  • Release Engineering lead was on out on 2010-07-09
  • Koji Outage 2010-07-10 to 2010-07-11
  • Verify that desired anaconda version is available the day before compose
  • Coordinate with installer lead several weeks prior
  • Create a checklist of reminders and dependencies that should be confirmed prior to the compose date?
  • Send a reminder to devel-announce to have packages in rawhide for upcoming compose
  • Build up the Release Engineering team so that alternate team members can compose releases
Create Installable Images for QA testing #3 2010-07-22
  • Not ready until 2010-07-23
  • glibc change for minimal kernel delayed getting rawhide composed
  • Urge the glibc folks to communicate better when they are going to make disruptive changes like requiring a much newer kernel.
  • Enhance QA and Release Engineering tools to automatically discover breakages like this in advance--prior to the actual compose.
Fedora 14 Blocker Meetings are already taking a minimum of an hour 2010-07-24
  • We are averaging 10 minutes of discussion per bug--this will be a problem as the number of blockers grows
  • Not getting timely feedback needed from bug assignee (package maintainer)
  • In the absence of information from the maintainer the meeting is held up while various people try to research the problem and group discussion attempts to fill in information gaps--many times this works, but it is incredibly inefficient without the package maintainer present.
  • IRC communication can be laggy and disorganized
  • Review and hound maintainers for information about bugs in the comments of proposed and approved blocker bugs as soon as they come in--don't wait for Friday's meeting
  • Use Fedora Talk (conferencing system) to speed up discussion and keep meeting more focused
    • stream audio to the web
    • people without the ability to connect to Fedora Talk can listen to web stream and respond in IRC
Branch Fedora 14 2010-07-27
  • Completed on 2010-07-29
  • New boost package landed on 2010-07-27
  • Python rebuild to 2.7 took longer than expected
  • Change from CVS to Git
  • Assume that branching takes more than one day?
Fedora 14 Alpha Test Compose 2010-07-29
  • Test Compose #1 produced on 2010-08-01. Does not boot because of bug 602274
  • Test Compose #2 produced on 2010-08-03. Cannot install because of bug 620900
  • Gave up on Test Compose #3 and moved to preparing for the Release Candidate
  • Smash less major changes together at the same time: python 2.7, changing SCM, systemd
  • Could we do any sanity testing before publishing images to make sure they boot to save bandwidth and turn around time? In the case of Test Compose #1 it fell over right way.
  • Kevin Kofler suggests it may ultimately have worked out better simply to delay the Alpha freeze and leave dist-f14 tag open until the major problems were resolved
Feature Submission Deadline 2010-07-13
  • It isn't obvious that spins are included in this item, and hence are due before this date.
  • Seems that spin deadline could be later, there is so much other stuff eg even the main Fedora gnome/kde spins to test. (The current spins wrangler disagrees.)
  • Concentrate on one spin successful booting
  • Set a slightly or much later spin completion date
Nightly Spin composes 2010-07-*
  • soname bumps broke a number of the spins that made it difficult to test spins and that cascaded into discovering several bugs very close to the alpha freeze and a lot of scrambling to solve then in a short period of time.
  • Get features that impact lots of other packages (or testing thereof) in well before the deadline.
Nightly Spin ISOs for Alpha 2010-08-24
  • Overlapping issues with broken dependencies have resulted in the Games Spin not composing since July 27th at which point the Splash Screen bug (617115) still existed in livecd-tools. So the Games Spin ISO that exists at the Alpha release will be unusable.
  • Don't let updates with dependency issues into stable.
Notify mirrors about new release content 2010-08-23
  • https://fedorahosted.org/rel-eng/ticket/3862
  • No SOP exists for this particular rel-eng task.
  • Mirrors may have gotten word late about the F14 Alpha content availability, compared to previous releases. A notice was sent 24 hours ahead (subscriber only link). Only about 50% of the mirrors included F14 Alpha content by 1400 UTC 2010-08-24, which may have been related. Usually the mirror list is notified the Friday before the release.
  • Include a task on the schedule going forward to include making this announcement.
  • Include the actual procedure in the automatically filed rel-eng Trac ticket for releases.
Web content change for F14 Alpha 2010-08-24
  • Links in web content didn't match the actual mirror content (web links started with F14- whereas actual content starts with Fedora-
  • Website content changes for each release need an SOP, which in part points to the Release Engineering SOP for creating the ISOs we ship
  • Release Engineering needs an SOP for creating the content (including standard naming)