<br><br><div class="gmail_quote">2009/8/6 Adam Williamson <span dir="ltr"><<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, 2009-08-05 at 17:23 -0700, Christopher Stone wrote:<br>
> On Wed, Aug 5, 2009 at 4:59 PM, Adam Williamson<<a href="mailto:awilliam@redhat.com">awilliam@redhat.com</a>> wrote:<br>
> > On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:<br>
> >> On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:<br>
> >> ><br>
> >> > Well, I think it's really the same issue. The problem is one of<br>
> >> > expectation: we have two similar components, GNOME and KDE, in the same<br>
> >> > distribution, following different update polices - GNOME favours stable,<br>
> >> > KDE favours adventurous. This confounds expectation.<br>
> >><br>
> >> I don't know that this is really the case.  KDE is rolling up a bugfix<br>
> >> release.  Gnome does bugfix releases.  Other than a difference in how<br>
> >> they number them, is there really that big of a difference in what they<br>
> >> are doing?<br>
> ><br>
> > It's not a bugfix release, it's a bit ingenuous to describe it as one.<br>
><br>
> Except for the fact that it fixes *over 10,000 bugs*. [1]<br>
><br>
> And I believe the word you are looking for is *dis*ingenuous.<br>
><br>
> It's hard to believe KDE 4.2 had that many bugs...<br>
><br>
> [1] <a href="http://kde.org/announcements/4.3/index.php" target="_blank">http://kde.org/announcements/4.3/index.php</a><br>
<br>
</div>I was actually reaching for another word entirely, but you're right that<br>
ingenuous makes no sense. :)<br>
<br>
A release that fixes bugs is not necessarily a bug fix release. A bug<br>
fix release is a release that _exclusively_ fixes bugs. So any bug fix<br>
release must fix bugs, but not any release that fixes bugs must be a bug<br>
fix release.<br>
<div class="im"></div></blockquote><div><br><br>It's unlikely a project has no open bugs, so any update should fix a bunch of<br>them; on the other hand it's rare to have software enhancement stopped just<br>to close bugs, in particular in big projects, if you want that you want backporting.<br>
By the way, i dont even think its safe to measure stability or completness counting<br>bugfix releases or with release numbers, as you will find projects which get <br>released with major versions X.0 in an incomplete and unstable state, while others<br>
trying to accomplish the opposite.<br><br>That said, in this scenery:<br>F-x<br>- bugfix rel<br>- enhance rel<br>F-x+1 released<br>- bugfix rel<br>with no backporting and the aim to be leading edge, what's the point to skip <br>
update 2? In the worst case, your Frel will hit (Flatest - 2) in about 12 months<br>and you will need to upgrade nonetheless<br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
--<br>
Adam Williamson<br>
Fedora QA Community Monkey<br>
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org<br>
<a href="http://www.happyassassin.net" target="_blank">http://www.happyassassin.net</a><br>
<br>
--<br>
</div><div><div></div><div class="h5">fedora-devel-list mailing list<br>
<a href="mailto:fedora-devel-list@redhat.com">fedora-devel-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-devel-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-devel-list</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Guido Grazioli <<a href="mailto:guido.grazioli@gmail.com">guido.grazioli@gmail.com</a>><br>Via Parri 11 48011 - Alfonsine (RA)<br>Mobile: +39 347 1017202 (10-18)<br>
Key FP = 7040 F398 0DED A737 7337  DAE1 12DC A698 5E81 2278<br>Linked in: <a href="http://www.linkedin.com/in/guidograzioli">http://www.linkedin.com/in/guidograzioli</a><br>