FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 12-11-2008, 07:54 PM
Michael Schwendt
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Thu, 11 Dec 2008 16:40:46 +0100, Ralf wrote:

> On Thu, 2008-12-11 at 09:27 -0600, Rex Dieter wrote:
> > Matej Cepl wrote:
> >
> > > On 2008-12-09, 12:03 GMT, Sven Lankes wrote:
> > >> We should try to get the bohdi-karma-mechanism more popular.
> > >
> > > IMNSHO we should get rid of it
>
> +1. It's superfluous.

The positive votes are superfluous. This voting method only draws the
attention of users who want to speed up the release of updates, because
they can't get enough. Fedora without hundreds of updates every week
seems to be boring.

The pkgdb "list of open bugs" feature is superior anyway:

http://bugz.fedoraproject.org/SOURCE_RPM_NAME_HERE

All we need is a convenient way to tag update tickets in bodhi with
bugzilla ticket numbers. Else packagers continue to ignore problem
reports in bugzilla and push pending updates to stable.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 03:20 AM
Ralf Corsepius
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Thu, 2008-12-11 at 18:41 +0100, Christoph Wickert wrote:
> Am Donnerstag, den 11.12.2008, 17:52 +0100 schrieb Ralf Corsepius:
> > On Thu, 2008-12-11 at 17:08 +0100, Sven Lankes wrote:
> > > On Wed, Dec 10, 2008 at 11:58:51AM +0100, Matej Cepl wrote:
> > >
> > > >> We should try to get the bohdi-karma-mechanism more popular.
> > >
> > > > IMNSHO we should get rid of it -- there is already one very good
> > > > mechanism for registering bugs in the software and it is
> > > > bugzilla.
> > >
> > > Which can cater for negative feedback. I don't think most people would
> > > be too happy with bz-entries created just containing 'works for me'.
> > But this is exactly what is happening.
> >
> > Cf. https://bugzilla.redhat.com/show_bug.cgi?id=475943
> > for a real world case.
>
> Huh? This does not look like positive feedback to me but like a normal
> bug report.

Note the "works for me"s: It's the normal way users who report bugs
through bugzilla provide feedback on proposed fixes.


Note how the package maintainer pointed reporters to "fix-candidate"
packages: He directed users to packages in koji and not to packages in
*-testing.


Both observations are symptomatic for situations in which "non-trivial"
package bugs are being addressed. Neither *testing nor the karma stuff
are being applied.

BTW: IMO this raises the next questions: Why don't successful koji
builds not automatically land in testing?

Ralf



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 10:14 AM
Michael Schwendt
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Fri, 12 Dec 2008 05:20:59 +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, ...].
Automatic pushes to updates-testing would only lead to cases where
somebody forgets to withdraw a build and also forgets to enter release
notes.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 10:20 AM
Ralf Corsepius
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Fri, 2008-12-12 at 12:14 +0100, Michael Schwendt wrote:
> On Fri, 12 Dec 2008 05:20:59 +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).

=> Without this karma crap, this, so far mere bureaucratic step can be
avoided.

Ralf



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 11:38 AM
Michael Schwendt
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

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,
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. On
the contrary, as we know, bugzilla spam overwhelmes the package
maintainers.

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 12:10 PM
Ralf Corsepius
 
Default Fedora QA ? - 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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-12-2008, 02:04 PM
Michael Schwendt
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Fri, 12 Dec 2008 14:10:38 +0100, Ralf wrote:

> > 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.

Sure, but it wouldn't matter. Yum only chooses the most recent one
available anyway (and fails in case of missing Obsoletes and broken deps).
Any test-update which would be published immediately after a successful
build could be installed by users before you build the next one. If you
did several builds before you got it right (perhaps that doesn't apply to
you, but one can observe how other packagers do that), some users with
quick mirrors would get several test updates and would need to deal with
.rpmsave/.rpmnew issues and temporarily missing features (e.g. not every
configure script fails if something isn't detected).

In other words:

I would not want the publishing of builds to be automatic.

Rather introduce a "make build-update" as an optional alternative to
"make build". Perhaps adda a guard, so it needs an explicit opt-in
(e.g. an environment variable) before it becomes available to experienced
packagers.

I'm a fan of automation, too, but it leads to problems where it does
things magically and requires even more documentation, so packagers are
aware of what happens "in the background". I talk to packagers regularly,
and often they are surprised already by what rpmbuild does automatically.
"Oh, I didn't know that" is the phrase seen most often. Pushing builds
automatically is something we ought to be very careful with, even if
pushing only to updates-testing. We cannot affort to annoy any testers,
who are willing to help.

> 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.

That's a quite short-sighted view, IMHO. It may match your personal
perspective, but doesn't seem to apply to many updates in Fedora.

There are lots of updates, which simply say "update to x.y.z", where even
the maintainer did not sum up what changes come with this minor [not
major] version bump. Is it a bug-fix release? Is it for feature additions?
Is it a mix thereof? No BZ references either. Is it safe to install it?
Many users want to know that. The release notes for that update are empty,
as it's a simple "sync with upstream" update. [Major upgrades are a
completely different beast.] All (!) the burden is put onto the shoulders
of the potential testers. And that's bad.

How do you know that none of your users is affected by a change
which is supposed to fix an issue known upstream? A fix that may work
for upstream can break for other users. You need to give the users
time to evaluate the update. Not rush and mark it stable after 2-3
days already.

> 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.

As I said, you consider "make build" and "make update" as not convenient
enough.

That is independent from bashing the karma system or the necessity to
give the community a chance to evaluate test updates.

>
> => A vote in bodhi is mostly meaningless.

We won't agree here, at least not fully. In +1 votes I see too much potential
for abuse (and I know several cases of sloppy testing, too), but the feature
is nice to have and helpful. Currently there is no alternative that is connected
as close to update package sets.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-13-2008, 01:54 PM
Thorsten Leemhuis
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On 13.12.2008 15:33, Robert Scheck wrote:
>

The reporting should be always possible, as it maybe turns later out if an
update was broken or not. And how a about yum? If it's PackageKit-only it
is not really an advantage, given that unexperienced users won't rate such
updates anyway usually (at least from my point of view).


BTW, was "automatic feedback from the clients to bodhi" discussed
already somewhere in this thread? E.g. if the package maintainer could
see in bodhi "2500 users installed and ran this testin-update for at
least three days, no negative karma reported, no new bugs" then it
should be quite save to move the package.


Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-14-2008, 01:47 AM
Seth Vidal
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Sat, 13 Dec 2008, Chuck Anderson wrote:



PK already has features that yum does not--it shows metadata about
updates that yum doesn't, for example.



It does? what metadata would that be? Considering all the info PK has
about packages it gets FROM yum I don't see how that's possible.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-14-2008, 03:53 PM
Seth Vidal
 
Default Fedora QA ? - What Fedora makes sucking for me - or why I am NOT Fedora

On Sun, 14 Dec 2008, Chuck Anderson wrote:


On Sat, Dec 13, 2008 at 09:47:57PM -0500, Seth Vidal wrote:

On Sat, 13 Dec 2008, Chuck Anderson wrote:

PK already has features that yum does not--it shows metadata about
updates that yum doesn't, for example.


It does? what metadata would that be? Considering all the info PK has
about packages it gets FROM yum I don't see how that's possible.


Yum doesn't show the user the type of the update: security vs. bugfix
vs. enhancement. It also doesn't show the user the update comments,
nor any suggested logout/login or reboot actions after the updates are
applied. I believe the data comes from updateinfo.xml.gz in the repo.



yum install yum-security

Description:
This plugin adds the options --security, --cve, --bz and --advisory
flags to yum and the list-security and info-security
commands. The options make it possible to limit list/upgrade of packages to

specific security relevant ones. The commands give you the security information.


-sv



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 10:40 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org