On Wed, 2007-05-16 at 09:11 -0400, Jesse Keating wrote: > On Wednesday 16 May 2007 03:19:08 Ralf Corsepius wrote: > > Update 40 packages at once and you'll probably notice why I consider > > this to be a crack ridden work-flow. 2 steps more per package and one > > form per package demonstrates the flaws of this workflow. > > Given that the tool allows you to release multiple packages with the same > announcement / reasons / bugs / etc it is quite easy to prepare a stack of > packages for update, say a flaw in a library is discovered, you have to build > a new version of library, and a bunch of downstream packages against said > library, you can release the entire stack under a single web form, and now > all your updates have context, and it can even autoupdate a bug once it is > pushed to the world. Where is this documented? URL? > > 0) maintainer tests package's functionality. > > > > > 1) Maintainer checks changes into CVS branch. > > > 2) Maintainer builds. > > > 3) Maintainer tests that build. > > > 4) Maintainer fills out the form with the N-V-R, optional security > > > (yes/no), optional Bug numbers fixed, and some fills in some details of > > > what the update is about, then chooses updates or updates-testing. > > > 5) Submit, where security and/or rel-eng team pushes it through. > > > > Now where in this scheme is Will Woods? I don't see him testing > > anything. All I see is more bureaucracy and more manual steps than > > before. > > Perhaps this is where we're not communicating clearly enough. Will isn't > going to be doing (all) the testing himself. However Will is going to be > driving a QA team and anybody else who is interested to make use of the > public updates-testing repo. I still fail to understand what he does and how a community package is supposed to profit from this. What does he do, what a "package consistency checker" can't and what can't be achieved by having a repo containing packages? > The testing will be the wider audience of those > that use updates-testing and who may have configurations or situations beyond > what you as the maintainer could test yourself before releasing the updates. > It gives you a chance to land the update on more people's machines for wider > testing before just lobbing it over the wall at our general user base. And > if the update isn't quite right, well it was in updates-testing so no harm, > no foul. If the update wasn't quite right and you pushed it into -final > updates and everybody's machine now you've just given not only yourself a bad > name as a maintainer, but you've given Fedora a bad name as a distro too. > (yes yes, we all know you consider Fedora to be a horrible distro already, > but many of us don't.) This impression is wrong. I don't consider Fedora to be a horrible distro - at least technically, otherwise I wasn't using it? Truth is - and this likely won't taste you - I consider * its infrastructure having been introduced with the merger to be a series of horrible mistakes, the new workflow to be largely bureaucratic, and the shape this all currently is in to be a shame. * this all to be a symptom of Fedora leadership to have failed at a large extend. * RH to have betrayed opensource and measuring "openness of SW" by selfish double standards, by having allowed "non-modifiable" firmware in Fedora while banning other "non-OSI-compliant" SW. Truth also is: So far, I feel the negative effects of the merger to outweigh the positive effects. More pragmatically: Over all these years Fedora exists, it has ever been a major problem to me to maintain ca. 45 packages over 3-5 versions/distros in FE. Now it is - In short: a regression. Ralf -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
