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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
