On 10/10/2012 01:43 PM, David Cantrell wrote:
Rather than throw almost everything on the blocker list when it's early
>and get more rigorous later on, I'd rather we just be rigorous the whole
>time. The blocker list isn't a work list (using the blocker list as a
>'todo list' / reminder list is a tendency I've noticed in both RHEL and
>Fedora, and something I think we should fight), it is a list of bugs
>that must be fixed for the release to go out. No more, no less. If we
>wouldn't really block the release for a bug, it doesn't belong on the
>list at any point in time. I think we've been making a good effort to
>improve this in recent releases; it's not just an aspiration.
That's fine, but how is that not a to do list?
I think it's a "must-do" list, which isn't the entirety of a "to-do"
list. If we look at both the Blocker list /and/ the Nice to Have list
together, then it starts to look more like a "to do" list.
I think one of the problems here is the difference between RHEL process
and Fedora process. RHEL doesn't seem to have a "Nice to have" concept.
RHEL seems to be "throw everything on the blocker list, because we
would take a fix for this after a freeze, and we can remove it from the
blocker list later if we don't get it done". Fedora isn't like that.
We have two lists, a list of things we would truly delay the release
for, and a list of things we'd take after a freeze if they get fixed,
but won't otherwise delay the release.
>So if there are concrete cases where you think bugs have been accepted
>as blockers that you wouldn't be comfortable taking as blockers the day
>before release, that's_always a problem_, and please highlight those
>bugs to us. I don't think it's 'not a problem' if we accepted them as
>blockers a long time before release and they got fixed before any chance
>of causing a slip, it's still a problem. We should stick firmly to our
>tight, minimal definition of what constitutes a blocker, regardless of
>the point in the release schedule.
The big difference here and what we see on the RHEL side is that RHEL allows
for blocker bugs to be re-evaluated and booted if a later workaround or some
other acceptable solution besides a bug fix is found. It becomes a schedule
thing, which I am routinely told is very important for Fedora.
If something marked as a blocker early on is still not fixed through several
test releases, does it really matter anymore for the release? If not, why
not boot it off the blocker list?
What do you mean by test releases here? We've done multiple "test
composes" of an alpha or a beta leading up to a "release candidate". We
do these test composes, even with known blockers, because /some/ of the
things have been fixed and it's good to get testing on that. But
"release candidate" doesn't happen until all the blockers are met or
removed. Blockers are frequently removed from the list when re-evaluated.
> >We do want to make a good release and keep the users happy, but we need to
> >also remember that developers are people too and not just meat grinders for
> >bug reports.
>
>Sure, hence the need to keep the criteria realistic.
>
> >1) Adjustments to the blocker acceptance criteria that I explained.
> >2) Acknowledgement that concurrent releases are always in play for the
> > installer team. Generally two RHEL releases and one Fedora release.
> > RHEL gets priority.
>
>I would prefer to phrase 2) the way I already did: Fedora should ensure
>its release requirements are realistic in the context of the resources
>available. If the 'resources available' are to an extent defined by
>other commitments on the part of the anaconda team, then so be it, but
>I'd rather consider it in that context, rather than haul RHEL
>specifically into a Fedora context.
Call it want you want, but we all know it's RHEL.
> >What I'm asking for is blocker acceptance criteria changes that are more
> >realistic given remaining time and other commitments. Or dump the
> >time/schedule requirement and just say we'll call it done when it's done.
>
>The schedule / blocker process balance is a bit of a delicate one, yeah.
>In practice we start getting a lot of pressure if the blocker process
>results in delays of several weeks. I think I'd like to look at this
>way, though: any time that following the release validation process
>properly results in a long slip,_that means something is wrong_. It
>usually means either that the release criteria are excessive, or it
>means that something went wrong in the feature process. I believe the
>feature process as it stands is not adequate in ensuring proposed
>features are really viable on the Fedora release schedule, and FESCo has
>also not always been assertive enough in dropping or delaying features
>that are clearly not meeting the schedule; I think sometimes problems
>are due to that, rather than to over-ambitious release requirements.
I'll agree with that. I've had that complaint for a long time, ever since
we merged Core and Extras.
As we have both already stated and agreed on, the installer is unique. Our
development process is so very much tied to the Fedora release schedule.
There is no easy way for us to develop something large like a new installer
and not have it tied to a release. This became harder for us when we
stopped doing rawhide nightly composes many years ago (and I have no idea if
those are happening again these days). People don't go and download a new
installer to try it out. You download a release of something and try
installing it. Our only way to get that to users is to follow the Fedora
release schedule, unless we want to start making our own distribution.
I know what you're getting at and it's that newui was a huge feature and
that's made our lives hard. Unfortunately, the Fedora release schedule is
such that work like this is always painful for us.
So the no images in rawhide thing was kinda my doing. It came from a
meeting a few years ago with release engineering, QA, installer team,
and others, where we looked at how our development process was going and
where all the painful points where.
One of the major pain points identified was how frequently rawhide
wasn't installable, and how it would turn people away. After talking
with folks it seemed like a better idea was to /not/ present a broken
set of images each night to people when we had no idea of they would
work. Instead what we wanted to do was keep rawhide as just a
repository of packages. We would then create "known good" images that
people could use as a starting point to get on rawhide, from that point
it was just yum update every day.
Where this may have failed is in the creation of the known good images.
Of course to know they're good, they must be created first, then
tested. There was schedule points for creating composes to smoke test,
with the hopes of identifying a compose that was "good enough" to be
promoted as a last known good. I think we're probably missing some
infrastructure here, and some cooperation between installer devs and qa
and releng.
The happy world I envisioned was an installer team able to work on their
own on large changes, not bothered by people constantly telling them
that rawhide was broken, again. When the team thought they'd reached
some milestone and wanted to start getting testing, they would work with
QA and releng to get some images produced and ran through smoke tests.
If good, promoted, if not fix it and try again, iterate. If this happy
world isn't something we think can be managed, then we really should
re-evaluate the no images in rawhide thing again.
--
Jesse Keating
Fedora -- Freedom² is a feature!
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
