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