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

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

 



On Wed, 2008-12-10 at 20:06 -0500, Josh Boyer wrote:
> On Thu, Dec 11, 2008 at 01:26:35AM +0100, Ralf Corsepius wrote:
> >On Wed, 2008-12-10 at 18:51 -0500, Josh Boyer wrote:
> >> On Wed, Dec 10, 2008 at 11:48:04PM +0100, Ralf Corsepius wrote:
> >> >On Wed, 2008-12-10 at 23:20 +0100, Nicolas Mailhot wrote:
> >> >> Le mercredi 10 décembre 2008 à 22:46 +0100, Ralf Corsepius a écrit :
> >> >> 
> >> >> > ... then wait until your immature and hardly tested "new code" from
> >> >> > "rawhide" automatically becomes the "release".
> >> >> > 
> >> >> > FC10 clearly demonstrates this effect.
> >> >> 
> >> >> I don't think this is fair to releng and the QA teams. 
> >> >Why is this not fair? The technical facts on FC10 speak for themselves: 
> >> >Rawhide and Fedora's release procedures as means for "Fedora release
> >> >preparation testing" don't work out.
> >> 
> >> Examples of this? 
> >
> >Some random examples, which I have been hit myself:
> >
> 
> <snip>
> 
> >To me, 
> >* the gnome-session, evolution and PackageKit examples are cases
> >demonstrating how "bugged SW", which should never have been made part of
> >a release, migrates from rawhide into releases.
> >* all 4 cases are demonstrating that rawhide as a release testing
> >platform doesn't work out.
> 
> I'd exclude the kernel bug from that summary. 
Having 70+ subscribers on a single BZ speaks a clear language, does it? 

... I have been facing this issue on 4 out of 5 (completely different)
machines I currently have FC10 installed ...

>  As for the others, I came
> to the startling realization that I don't use any of the other 3 packages
> at all because I generally either have no use for them or found them to
> be buggy in the past and gave up on them (like evolution).
Well, these had just been examples ... I could easily extend this
list :(

> Which is sort of an agreement with you in some regards.  However I also
> think one needs to keep in mind that for the majority of packages Fedora
> gets what upstream delivers.
Right, but blindly relying on upstreams is not of much help either.

Instead, package maintainers, testers and rel-engs can not avoid to
build up opinions of their own and to compromise. This may mean to skip
one or more upstream release, to modify it, or ... in extreme cases,
even to abandon a package.

The really problematic cases however are those in which developer and
user perception on a packager/upstream's quality diverge and those in
which political/economical motives or wishful thinking overrule obvious
facts.

>   Fortunately, most of the upstreams we have
> seem to be pretty good about fixing bugs as they are found.  QA can't find
> them all, and I think your efforts here show exactly _why_ we need people
> like you doing the bug reporting you are.
Hmm, all I actually do is to report what I stumble over when using the
OS or when working with components the OS consists of. This works fine,
as long as bugs are being fixed in reasonable time frames and not pushed
aside as "FIXEDRAWHIDE" or "UPSTREAM".

> >Wrt. rel-eng:
> >
> >Besides the numerous NEVR issues between Fedora release, which FC10 (as
> >usual) suffers from, this time another kind of repo screw up took place:
> 
> NEVR issues not getting caught are due to two things:  1) package maintainers
> not paying attention, and 2) the lack of dep and upgrade path checking in
> bodhi.
[snip]
> I don't know why that happened.  My best guess would be something like:
> "An update was staged and then something happened that caused a newer
> package to be pulled into the final release.  The maintainer forgot
> about the pending update."
> 
> Again, no real clue though.
My explanation: rel-eng has lost focus on the real issues.

Or more direct: Why haven't they developed a set of tools related to
detect packaging issues, such as NEVR conflicts, throughout all the
years Fedora is around?

> >>  Do you have bug report numbers, regression cases,
> >> or any sort of data saying things are getting worse from a release
> >> stability perspective?
> >> 
> >> I'm not saying you're wrong, but statements without facts are hard
> >> to swallow.  If we're sucking it up, point us to where and how so
> >> things can be fixed.  I have F10 on a number of machines and it's
> >> working fine, so my personal experience may be different than yours.
> >Let me put it this way: I have been running machines equipped with FC10
> >since ca. Beta2, and am busy filing bugs since then. I haven't been
> >bookkeeping, but it's in the order of 0.5-1 per day.
> 
> 0.5-1 per day after release, or as an average over the time since Beta2?
The later. It has been more or less a constant flow of 3-4 new BZs at
average per week. So far, without any tendency to decrease or increase.

> Also, across a subset of packages or just in random things as you hit
> them?
Most of them are "random things" I trip over when using/trying to us
packages as "ordinary user".

> I know you aren't keeping track, but data like that would be useful to
> indentify bug trends and problem packages. 
Well, with previous releases, I feel there had been a clear tendency: 
Initial releases (the CDs/DVDs) had been almost unusable. After ca. 4-8
weeks of lifetime, when most major packages in Fedora had at least been
replaced once, Fedora had matured into a shape one could recommend to
use it.

>  I'm not asking you to actually
> go answer those questions, but it's something the bug zappers could think
> about.
IMO, the bug zappers are a problem of their own, I should better not
comment on at this point in time.

Ralf



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux