On Fri, 2007-11-02 at 14:45 +0100, Michael Schwendt wrote:
On Fri, 02 Nov 2007 13:42:55 +0100, Ralf Corsepius wrote:
> C'mon, you are once more trying to push people to adopt your (IMO:
> broken) vision.
Ridiculous.
Thanks, actually that's what I think about your and Kevin's
rationale.
All you are doing is trying to supress and force the community to use
ONE single scheme: your truth.
Actually, it's the opposite. I'm not the one who's
fighting the use of
scripts like upgradecheck, just because some of its (not even daily)
mails are considered an annoyance by a few package maintainers.
Yes, e.g. by me.
This upgradecheck does neither reflect my way of
packaging nor does it produce correct results.
E.g. atm 90% of all complaints currently are against FC-6 and F-8.
Cause: Fc-6 automatically getting pushed, F-8 being in deep freeze.
Take a
deep breath, mash warns about broken deps in rawhide every day, even
when a packager can only wait for another packager to fix something
first.
I tell you what: I push them to /dev/null, because in 95% of all cases
these messages are "false alarms" or alarms caused by rel-engs
work-flow.
> - If a package is being pushed from testing to updates (currenly
not
> possible due to bodhi's design),
?? What do you mean? How have the many packagers done it?
Withdrawing a package
from testing and then repushing to stable is the
only way I found.
Marking a
test update "stable" does work, doesn't it?
Well, it didn't do
yesterday.
Do you see a pattern in
the way you criticise achievements?
Yes, there is a pattern: I don't see bodhi
nor the current release flow
to be achievements to be proud of.
> Example: "Package X works in FC-8 but doesn't work in
FC-7".
If it works, why isn't it put into F-8 (or devel)?
I can answer that for you.
Case 1) The usual procedure is that the packager still focuses on F-7
and does not use F-8/rawhide yet. The update is prepared for F-7 only,
neglecting F-8/rawhide completely.
You've got it conversely.
Look at what I wrote: F-8 works, but the same package for F-7 has shown
to be broken (after release!)
Such things happen, e.g. because
* the infrastructure underneath is different
* a "presumed to be harmless update" triggers something on F-7, but
doesn't trigger the same issue (e.g. because this bug had been fixed in
F-8 and F-8 is using a newer version) on F-8.
...
One approach being applied by maintainers would be:
"Trial and error" on "updates-testing".
Case 2) The usual %{?dist} and "make tag" breakage. Wrong
release
bumps as the cause of broken upgrade paths.
That's not what I am talking about.
I am talking about packages in testing.
Case 3) You refer to an already released pkg in F-7 and F-8, which
is
reported as being broken in F-7 only.
Right, that's the case I am talking
about.
Let's assume you prepare a
version upgrade as a test update for F-7, not testing the same code
for F-8 or devel. You try to cherry-pick your target audience by
releasing an exclusive test upgrade for an old(er) dist, neglecting to
test the same stuff for the newer dists. What is so wrong about
warning about the broken upgrade path? Especially when you learn
that the test update works for F-7, you need to bring F-8 and devel
on par with F-7 anyway.
You are presuming the cause for the bug to be inside of the package
exposing the issue. In such cases propagating a fix to F-8 would be
appropriate, but in many cases, this is not the case.
Ralf