All good points. It's hard to criticise a volunteer effort, particularly since I haven't found a way to be useful yet (though not from lack of offering,) but I have to get fixes out a *lot* quicker than I've seen them appear here. Now, I have the advantage of an internal QA process that backstops my work, but those guys have procedures they follow, and they get the job done reasonably quickly. How can I help in addressing some of Michael's criticisms? My expertise is in analyzing and integrating patches. But it seems that what is needed is some minimal amount of formalism and process. I say "minimal" because projects can get bogged down in discussions over that sort of thing. I vote for a bare-bones release process that can be effective. Off the top of my head: 1 Vulnerabilty Analysis. Watch the lists, the vendor patches and other sources. Determine quickly if a particular problem applies to the relevant distros. That part of the process doesn't seem to be broken, though it's informal. 2 Remediation. Leverage the vendors. State schedules. Publish status. As Michael notes, this will become increasingly difficult as the supported distributions drift farther from the mainstream. That's unavoidable, but the critical thing is frequent status updates so that others can see where help is needed. 3 QA. This seems to be where the most trouble is. Is the problem due to lack of testers? What are the criterea for calling QA adequate? Where is the status pubished? If we don't have testers for a particular distribution, perhaps we should consider dropping support for that distro. That's harsh, but if folks don't like it, they can pitch in. Or can they? 4 Release. What are the criterea? Are there infrastructure issues? What's the schedule? Apologies if these questions are answered elsewhere. Also, I'm not unappreciative of the effort shown here. The triage has been very helpful to me, and I'm grateful. I'd like to offer help where I can, but I'm concerned that it could be wasted without a bit more formal approach. On Mon, 17 May 2004, Michael Schwendt wrote: > After having slept on it, for me it's time to unsubscribe and discontinue > any Fedora Legacy activities. Hence I wave "Good bye!" to the few people > involved so far. > > If I were enough of a geek and found myself interesting enough to run my > own blog, I would bitch about it in there. But I'm not. And so I post a > few impressions here. > > It just doesn't work, when even trivial fixes or patches ripped off of Red > Hat Enterprise Linux errata don't receive proper attention and the update > packages sit in the queue for months without anyone posting clearsigned > reviews or approvals, respectively. > > Future fixes won't be as easy as taking patches from RHEL without > modification and applying them to Red Hat Linux 7.3. It may be necessary > to do real backporting and prepare and test upgrades as a last resort. > > No, it's not that updates are prioritized and more important updates > occupy all available resources. It's not hardware and server maintenance > induced delays either, because the bugzilla system is available and the > packages can be prepared meanwhile independently of mirror/server > logistics. > > It's that the Fedora Legacy community has not decided on publish criteria > and minimal formalism on how to review and approve packages (in particular > the good bits of the fedora.us policies and guidelines). Therefore, > neither packagers or reviewers know what exactly is required to get a > package published _in time_. > > It's not even known how to get a package into "updates-testing" and how > long it will be kept in there. Additionally, non-existing updates for less > popular distributions (e.g. rh80) hold up reviewed and approved updates > for popular distributions, e.g. rh73. A developer, who looks into security > advisories and patches today, doesn't want to repeat the same work 2-3 > months later -- when finally it's decided the time has come to push out > another update which has been neglected for several weeks or when the next > weakness must be dealt with and the fix for the previous one has not been > approved yet. Developers and reviewers want to finish something and move on. > > The early support for rh73 has been an opportunity to practice doing > legacy updates, in particular with official patches from RHEL which make > that a lot easier. This chance has not been taken. > > So long, > Michael > > -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo@xxxxxxxxx +1-650-218-2216 just sit there." - Will Rogers -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
