On Wed, Oct 10, 2012 at 02:25:37PM -0700, Jesse Keating wrote: > 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. Yeah, that's a fair assessment. > 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. At least from my point of view, RHEL does have a nice to have concept, but it's at devel discretion and closes off much earlier I think than Fedora does. But to me that's just one of the differences between slow-moving RHEL and fast-moving Fedora. > >>>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. I was specifically referring to the Alpha and Beta releases, not the additional test composes we do. Apologies for the vocabulary confusion. My example was really just, "if something filed before Alpha as a blocker still hasn't been closed by RC and no one has complained, should we really care about it for this release?" > >>>> >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. I remember when all that went down and I think it made sense at the time. The name 'rawhide' has certain expectations associated with it that we will probably never be able to change. At the time I found it frustrating because we relied on the nightly composes to do installer development. But I understand that since it was publicly available, we needed to stop the constant "nightlies are broken" reports from users. > 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. Known good rawhide composes would be a nice thing to have. > 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. I think this is possible. We need to work against rawhide, so as long as we have a regular compose process building images from that for us, we can work this way. But it sort of only gets us so far. The more large changes we do outside of official repos, the more integration work we stack up for ourselves later. -- David Cantrell <dcantrell@xxxxxxxxxx> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
