Re: F13 Schedule Proposal--please RESPOND - 'test compose'
by James Laska
On Wed, 2009-11-11 at 18:31 -0800, John Poelstra wrote:
> On 11/06/2009 12:53 PM, Bill Nottingham wrote:
> > Sorry about the delay - been drowning in F12 final hair-on-fire
stuff.
> >
> > John Poelstra (poelstra(a)redhat.com) said:
> >>>> I'm not sure what period
> >>>> you believe should be a month. Can you be more specific?
> >>>
> >>> The alpha/beta interim time; i.e., the time between corresponding
> >>> alpha and beta milestones.
> >>
> >> Which alpha and beta milestones--Start/End of Alpha freeze? Alpha
> >> Public Release? Beta Freeze? Beta Public Release? Specific date
> >> comparisons would be helpful.
> >
> > The interim period between the alpha and beta public release is the
> > one that was most obvious to me. In every prior release except F-12
> > (because F-12 slipped), it's been right around a month. In your
schedule,
> > it's set at 6 weeks. Hence my query as if you were just
incorporating
> > the F-12 slip time.
>
> The duration between public alpha and beta has been all over and I'm
> unsure of its significance (if I understand you correctly below,
you're
> suggesting that measuring the time between milestones is meaningless):
> (in days)
> F8 - 21
> F9 - 23
> F10 - 35
> F11 - 28
> F12 - 56
>
> F13 - 42 (original proposal)
>
> I think a better way to break this down is to be more specific about
the
> tasks in between because saying "one month in between" is too vague.
To
> make it four weeks we'd have to set:
>
> Alpha Public Release Available
> 2 weeks
> --followed by--
> Beta Freeze
> 2 weeks
> --followed by--
> Beta Public Release Available
>
> I'd propose making the Alpha Public Release three weeks--the original
> proposal was four.
>
> For the past couple of releases there was been two weeks between the
> freeze date and the public release date. We need two weeks to include
a
> "Test Compose"--granted I don't believe we were able to create any of
> the Test Composes on time (something we should examine when creating
the
> F13 schedule).
That is something I'd like to wiggle into the RC process for F-13. For
each of the F-12 milestones, we had the following quality milestones:
* Pre-RC installation verification (non-media, rawhide-based)
* Test compose verification (media provided by rel-eng)
* Release candidate verification (media provided by rel-eng)
We *informally* did this for the RC phase. But this was adhoc and I
think we could improve our coverage if we can plan to this milestone.
Can we add a 'test compose' to the release candidate phase?
> > If that's adjusted down to 4 weeks, the other related dates move a
> > similar amount. Alpha Release -> 2/23, Alpha Freeze -> 2/9,
Feature
> > Freeze -> 2/1, Feature submission -> 1/19.
> >
> > (As a random practical note, feature submission right after New
> > Years may not be best.)
>
> I agree. I was following the methodology set forth by FESCo that the
> submission deadline should be two weeks before Feature freeze. I'll
> keep it in mind as other dates move around.
>
> <cut>
>
> >> concern around being eaten by raptors. Hopefully it can also
reduce
> >> the amount of discussion about future schedules because after 12
> >> releases we've finally figured out a few things that work best.
> >>
> >> I am concerned that the Release Engineering team is not growing and
> >> new people do not come to our meetings or look for ways to get
> >> involved and help. I thought it would help to create a better
trail
> >> of documentation about our repeatable processes so that others can
> >> know how and why we do what we do.
> >
> > No, more documentation is good; it just surprised me that it was all
> > in one place as a methodology, as that's not the sort of thing I'm
> > going to go randomly looking for if it's not pointed out.
> >
> > One note as to the methodology as denoted on the spreadsheet - we
> > *do* need to define whether we are time-based with specific target
> > dates, or time-based with a specific length of cycle. If we are
>
> Good distinction. You are right, we can't be both :)
>
> > time-based with specific target dates (May 1/Nov 1), tracking
> > 'start -> <foo> milestone' durations, with 'start' being the
actual
> > release date of the prior release, is meaningless to creating the
> > next schedule. If we're time based with 'a 6 month cycle, however
> > it lands', then those 'start -> milestone' durations become a
> > meaningful thing to track again.
> >
>
> Meaning can be found in how long it actually takes us to complete
> certain tasks and the overall durations of our schedules. Because
when
> we estimate these things wrong or don't meet the originally planned
> schedule we slip (ship late). If we find that certain tasks are
usually
> complete on time or within an acceptable variance we know they they
are
> good durations to use in the next schedule.
>
> Whether we target a specific GA date or say we are a '6 month cycle'
we
> still have to make decisions about how long each of the tasks can
take
> within the overall alloted time period. This results in trade-offs
and
> decisions about what parts of the schedule should remain the same for
> each release and which parts can change without adversely affecting
our
> ability to meet the scheduled GA date.
>
> We've generally found that we need a certain amount of time between
> freeze and public release (2 weeks). We've also found that for a
public
> release to be worth creating it needs to be available for a period of
> time before creating a new one. With these task durations less
flexible
> the schedule has to give somewhere. In the past several releases
we've
> been taking that off the development time (start to first freeze).
>
> >>> 'work all done' is the RC freeze. Not all work is equal, though;
there's
> >>> UI changes that affect collateral, rebases of fringe leaf node
packages,
> >>>
> >>
> >> It would seem to me that this isn't really working for us. We
> >> haven't been able to compose an RC on time for the Alpha, Beta or
> >> Final.
> >
> > Part of this is a more strict handling of RCs. Before, we'd just
> > compose anyway, and not track the blocker list with such severity.
> > Now that we're actually treating the blocker list with a little more
> > process, we're slipping more.
>
> Interesting observation. I hadn't considered it this way. Are you
> suggesting that we should handle blockers differently? Is this is a
> good or bad thing to you?
Great thing imo! I think this results in improved quality, improved
communication between all parties, and rewards testers for finding high
severity/impact issues that the group feels should be blockers.
That said ... Adam and I have been discussing some ideas on how we can
improve the blocker process to make for meetings that aren't as
intensive. Expect more from QA on this soon.
> >> Is there any substance to the idea that if the "work"
> >> stopped just a little earlier (5-7 days) there might be more time
> >> for the developers to focus on the blockers so the RCs could be
> >> built in time and it wouldn't be such a last minute scramble?
> >
> > That would just be moving the freeze date, wouldn't it? As a
> > counter-example, here in F-12 we've been frozen and just taking
> > fixes, and we still had blockers when it came time to compose the
> > RC. I'm not sure that more freeze time would help here. Part of
> > me thinks that what would help the most is more attention to
blockers
> > *throughout* the process.
> >
>
> We reviewed the blocker list every Friday starting at least two weeks
> before every freeze until release. What would you suggest as an
> additional or alternate way to focus on blockers?
For me ... see above. There is room for improving the process of
proposing blockers to reduce the average time spent per bug in meeting.
Thanks,
James
14 years, 6 months
#3149: Block rhpl from dist-f13
by Fedora Release Engineering
#3149: Block rhpl from dist-f13
---------------------+------------------------------------------------------
Reporter: clumens | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
---------------------+------------------------------------------------------
rhpl is now a dead package, as was announced way back on June 30 (508951).
The only package still using it is system-config-kdump, and the maintainer
has had patches he's been sitting on for months. With F13 opening up now,
we should kill it early on and be done with it.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3149>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months
#3143: Tag request xfce4-settings-4.6.3-2.fc12 for dist-f12
by Fedora Release Engineering
#3143: Tag request xfce4-settings-4.6.3-2.fc12 for dist-f12
----------------------+-----------------------------------------------------
Reporter: cwickert | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Component: koji |
----------------------+-----------------------------------------------------
{{{
This update makes xfce4-mouse-settings work with libXi 1.3. It is
extreemly important for the Xfce Spin, without it, we wont have any
mouse configuration. Tested to work by nirik and me, sorry for the last
minute request.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3143>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months
#3145: Tag request for F-12 for gtkmm24
by Fedora Release Engineering
#3145: Tag request for F-12 for gtkmm24
-----------------------------+----------------------------------------------
Reporter: denis | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 12 Final | Component: koji
Keywords: |
-----------------------------+----------------------------------------------
Apparently there is a ABI breakage with gtkmm24 2.18.1 (which is the
current version for F-12 final). See
https://bugzilla.redhat.com/show_bug.cgi?id=533638 (filed by gnote
developper Hubert Figuiere).
Most of the gtkmm-using apps in F-12 were not compiled against 2.18.1, but
seem stable nonetheless, based on my own testing and from the lack of bugs
filed.
So the question is: do we leave things as they are now and push 2.18.2
directly to stable after F-12 is released, or do we take preemptive action
and tag 2.18.2 for F-12 final. I realize it may be too late for this
anyway. However I'm pretty nervous about shipping a known ABI-breaking lib
into F-12 final as you can imagine...
Gtkmm24 2.18.2 build :
http://koji.fedoraproject.org/koji/buildinfo?buildID=138076
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3145>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months
#3139: Untag request, delete updates
by Fedora Release Engineering
#3139: Untag request, delete updates
-----------------------------+----------------------------------------------
Reporter: hubbitus | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 12 Final | Component: cvs
Keywords: |
-----------------------------+----------------------------------------------
Hello.
Incidentally I made a mistake in version enumeration of gloox (please see
https://bugzilla.redhat.com/show_bug.cgi?id=528696 ) then Peter Lemenkov
point me and I fix that. But updates was made.
So, please untag/delete updates (sorry, I don't known how it procedure
named, I don't found it in wiki):
gloox-1_0rc3-0_8_SVNr4204_fc13:devel:hubbitus:1255902890
gloox-1_0rc3-0_8_SVNr4204_fc10:F-10:hubbitus:1255903574
gloox-1_0rc3-0_8_SVNr4204_fc11:F-11:hubbitus:1255929213
gloox-1_0rc3-0_8_SVNr4204_fc12:F-12:hubbitus:1255929890
Or say what I can correct error in this situation?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3139>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months
#3128: Tag request xdg-user-dirs-0.12-1.fc12 for dist-f12
by Fedora Release Engineering
#3128: Tag request xdg-user-dirs-0.12-1.fc12 for dist-f12
-------------------+--------------------------------------------------------
Reporter: alexl | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Component: koji |
-------------------+--------------------------------------------------------
{{{
This update adds a few more translations of the "Downloads"
default folder for xdg-user-dirs. Its important to get this in
because if anyone logs in with the old version they will get the
non-translated directory name which will not be updated if the
update is later installed.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3128>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months
#3137: openoffice.org-3.1.1-19.16.fc12 for F-12
by Fedora Release Engineering
#3137: openoffice.org-3.1.1-19.16.fc12 for F-12
---------------------+------------------------------------------------------
Reporter: caolanm | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
---------------------+------------------------------------------------------
* How important is this?
* rhbz#533146 calc notes go missing on save to native format, which is a
real biggy
* ooo#106523 df/A export on x86_64 generates broken pdf, which is a biggy
* rhbz#532330 openoffice impress doesn't recognise .ogv files as video
* ooo#106497 language marked as providing spellchecking when unavailable
* How much have you tested it?
* confirmed that notes in calc reappear after export
* confirmed that acroread doesn't crash on new pdf output
* confirmed insert->movie contains ogv
* confirmed that language list doesn't include non-existing dictionaries
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3137>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
14 years, 6 months