On Fri, 2008-12-12 at 13:38 +0100, Michael Schwendt wrote:
> On Fri, 12 Dec 2008 12:20:07 +0100, Ralf wrote:
>
> > > > BTW: IMO this raises the next questions: Why don't successful koji
> > > > builds not automatically land in testing?
> > >
> > > A build being successful does not imply that it is ready for release.
> > > It could still do something wrong [in the .spec, at run-time, ...].
> >
> > Right, but ...
> > > Automatic pushes to updates-testing would only lead to cases where
> > > somebody forgets to withdraw a build and also forgets to enter release
> > > notes.
> >
> > Pushing packages to "stable" still requires approval by a human
> > (normally the maintainer).
>
> The problem Fedora has is that updates-testing is not popular enough.
> It is counter-productive to flood that repo with builds automatically,
Then make sure that only one version at of a package (with NEVR >
version in stable) is inside. Could likely be automated without much
effort.
> without somebody raising a green flag and declaring a build as an update.
>
> A compromise would be to make this optional via a pkg cvs make target with
> bodhi-client (see "make update"), but without the need to fill in forms.
> The update could still be edited inside bodhi web.
>
> > => Without this karma crap, this, so far mere bureaucratic step can be
> > avoided.
>
> It's not "karma crap", but some +1 voters have shown more than once that
> they haven't tested packages painstakingly.
> The possibility to vote -1 and leave a comment is quite good actually,
> because this feedback is tied directly to the actual update request.
In almost all cases, updates
* address a specific problem, which typically is BZ'ed, with the
relevant tester audience listening to this BZ
=> a vote in bodhi is redundant to feedback in bugzilla
or
* are "upstream updates" addressing unspecific issues ("Upstreams says
package fixes issue XYZ").
=> Nobody but the maintainer is waiting to test this update, hardly
anybody will have a test case.
or
* are package maintainers addressing so far unpublished issues
(maintainer often extensive use a package and are likely more familiar
with a package than many other users).
=> Nobody but the maintainer is waiting to test this update.
=> A vote in bodhi is mostly meaningless.
> On
> the contrary, as we know, bugzilla spam overwhelmes the package
> maintainers.
True, but the bureaucracy introduced by bodhi and the testing repos is
much worse - As far as my packages are concerned, it's at least one
magitude (factor 10) higher - Truely nagging!
> Whenever someone says "Fedora is community-driven" I'd really like to see
> that it means "update pkg foo passed the testing done by a group of
> power-users" and not just "Fedora provides a system where a single package
> maintainer is free to unleash a pkg and burden the community with breakage".
> Not only do we need to give interested parts of the community the
> opportunity to contribute testing, we need to request it actively. "You
> want updates, then help with testing to make sure the stuff remains
> usable." Let it stay in updates-testing for several weeks, if need be.
> Six months pass so quickly, the next Fedora will be released soon
> enough if the community shows no interest in updating the older dist
> releases.
/me thinks you are mis-understanding what I am aiming at:
I don't want to get rid of "testing", I want to get rid of the hidden
"package has been built but maintainer hasn't gotten around to push a
package to testing" package queue and the interactions with it.
It's the interactive step maintainers are required to perform in bodhi
to push a package to testing, which adding to this bureaucratic bloat
maintainers in Fedora are confronted with.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
