Testing Fedora - small (?) suggestion.

[Jeff Spaleta]

On 11/10/06, Gilboa Davara <gilboad at gmail.com> wrote:
> A. Create more mile-stone releases. Once the tree reaches build
> integrity (no missing packages), spin a test release. (Fixes P1, P2)

Logic fault... we dont have enough testers right now... more
mile-stone releases will actually mean even fewer people will be
testing each of those releases.  We don't magically gain more manhours
of testing by having 14 individual isosets in the wild.

> B. Change the terms that are being used to describe each test release.
> Whether we like it or not, people are used to the "Alpha", "Beta" and
> "RC" terms, and tend to consider "Test release" as "Alpha release". I
> understand that the term "Test" was used to differentiate the
> ever-rolling Fedora from the release-based RHEL, but Fedora has aged
> enough to be viewed as an entity by itself and we can drop the "Test"
> term.

Complete redherring. Changing the naming scheme...again... will only
cause additional confusion because it will require yet another change
in things such as mirror url locations and updating available
documentation on the procecss.  This is a pointless change for the
sake of change simply because its an easy thing to do, without
quantifiable metrics as to the importance of this particular issue.  I
decree this is completely not important.

I'm not even sure how valuable technical feedback is from people who
are confused by the naming scheme. At best I expect "those" people to
bitch about colorschemes, font glyphs and other stylist aspects which
are not of an important technical nature.

> C. Once Fedora hits RC, only bug fixes go into the tree. No last minute
> 2.6.39 kernel that break Anaconda, SCSI, and USB two days before the
> release. Nada. New features can always enter the tree as updates once
> the release ISOs have been sent.

Easier said than done... and in fact against the very nature of how
kernel updates are done once is a release is out.  Say it with me...
Upstream  Upstream Upstream!  I think you underestimate the amount of
work and time it would require to hand pick individual patches and
backport them instead of lifting the next upstream kernel which
includes a superset of issues identified in Fedora based testing.

The current kernel maintainer may want to comment on this particular
issue in more detail, but in an effort to save him his valuable time,
I would strongly suggest that you take a look back through the history
of fedora-devel mailinglist for kernel maintainer comments concerning
the overall goal of reducing the amount of patches being applied to
fedora kernels and to stay as close to upstream as is reasonable.  I
don't think what you are suggesting here as a remedy to the kernel in
particular is realistically possible.

>
> Here's a mock Fedora release schedule:
> T-4 Months: Alpha1
> T-X Months: AlphaX
> T-1 Months: Beta
> T-3 weeks: RC1 - Tree go into lock mode.
> T-1.5 weeks: RC2
> T+n weeks: unexpected RC3.
> T: release. Part time.

Forget for a second the substantial additional burden on the release
engineering team associated with the scheduling associated with all
the new self-consistent isos you want to see spun up.  Or the fact
that you have to institute additional freeze deadlines which make it
more difficult for individual maintainers to get new tech into the
tree at all.  Do you really expect a significant number of testers to
install even half of these images and do the due dilligence associated
with testing of the installer looking for regressions?  And if a
significant number of people aren't going to be doing the regression
testing..then you haven't solved the problem you were aiming to solve.


-jef"Every single iso image deadline in that mock up that you expect
to pass through release engineering will slip by a week..garunteed.
You want a to see 8 milestone isos.. that 2 months of delay associated
with any strawman schedule. Hold your breath."spaleta