On Saturday 08 November 2003 07:21 pm, Warren Togami wrote: > On Sat, 2003-11-08 at 12:12, Ingo T. Storm wrote: > > I think it all comes down to D, which is rather about opinion and > > directions than technical fact and touches an important question: How > > much _Fedora.us_ is in _FedoraLegacy_? To me it looks like it's rather > > the "Fedora.us" core people would like to stay on a successful track > > (same rpm for everyone), > 2) I never advocated upgrading to the same version of rpm, rpm-4.2 was > mentioned. I mentioned that the latest upgrade to the latest versions > rpm-4.2.1, rpm-4.1.1 and rpm-4.0.5 at rpm.org. For what it's worth, on a purely technical point, Red Hat already did this in the past. It is not unreasonable to get everyone up to the same spec file behavior so that the updated RPMs can be more easily maintained. I have had to maintain specs that build on more than one RPM version. I even had to once do this with as old an RPM version as 2.5. So, Ingo, there are valid technical reasons to desire the same RPM version across the board, if it's not technically unfeasible to do so. Now, if it is technically unfeasible, then that's a different issue. But there's no politics involved from my view: not that there isn't from others; I can only vouch for my own opinion. As to the the politics, I have only two words to the 'opposing factions' involved. "Grow Up!" Fedora Legacy won't involve third party repositories, fancy release tags, or any such. There is strong precedent in the package naming of previous errata; this precedent should continue to be followed so that upgrades don't break from a up2date 7.3 to Fedora Core (or even to RHL9, for that matter). So the issues here are much fewer than the current maelstrom over on the Fedora lists. The issues here are not the same as even the old fedora.us issues, so the same guidelines don't necessarily need to apply. If anything, the guidelines might need to be stricter. I see: 1.) A package needs a maintainer. This is not a small task for some packages: for instance, if a security alert happens for PostgreSQL, the erratum needs to be for the same major version as shipped with that supported Red Hat release. (I pick on PostgreSQL since I maintain the postgresql.org RPMset). This task for PostgreSQL may mean a major backpatching effort (which happened not long ago for multiple releases where the upstream developers were not wont to backpatch). This would have to be up to the maintainer to do, though. The maintainer must be able to exercise some authority over the owned package; rely on the maintainer's possessiveness to keep things right and tight, within guidelines. This is not unlike how Red Hat works internally, from what I've gathered in four years of beta testing. 2.) Guidelines for how to go about the above. When does it become unreasonable to stay with the same major version, backpatching security fixes? Red Hat did this; this is very resource intensive and is expensive, which is why we are in the whole Fedora Legacy situation in the first place. 3.) There needs to be a good way to get the updates out to users. This implies a trust infrastructure between developers, as well as a mirror structure and secure uploading mechanisms. A simple way to do this is with scp using RSA authentication. The upload needs to be source only -- the buildfarm needs to build and sign with the Fedora Legacy key in an automated (or semi automated for a little extra security -- I have some ideas how to make this secure and not exploitable -- the biggest thing is that the actual build farm must not be directly connected to the Internet) fashion. This simplifies the trust relationship somewhat, since the binaries are all signed with a single key (or at least a few keys, instead of one for each maintainer). This boils down to the question 'How seriously is Fedora Legacy going to take itself?' -- that is, is FL going to be a volunteer business with a security reputation equal to Red Hat's (I personally think this is unreasonable: the only way I'm going to use community-built errata is by rebuilding from source RPM!). (although I break my own rules with the Aurora project, but that's about to change...) Or to put it much more bluntly: I wouldn't even install the PostgreSQL binaries that I myself upload on my production machines. And it has nothing to do with the fact that they are not signed. 4.) There needs to be some governance. I propose a steering committee based on merit: if you put up the bandwidth, you get a say in the governance, etc. This is the way the PostgreSQL steering committee works. Membership is by invitation of the existing steering committee. Those who do the work get a say in how the work is done, basically. This would be the way rogue maintainers would be reigned in. (revoke their RSA auth keys, no login). There must be checks and balances all the way around. A dictatorship is worse than anarchy, but neither are very productive. 5.) If FL is to be taken seriously by people like me (IT Directors), then the petty squabbling must stop. Now. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
