On 11/10/06, Gilboa Davara <gilboad@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
