[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora QA ? - Re: What Fedora makes sucking for me - or why I am NOT Fedora



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]