On 03/02/2010 08:55 PM, Matthew Woehlke wrote: > Jesse Keating wrote: >> On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: >>> You and everyone else, please stop proposing Rawhide as the solution for me >>> and people who want the same "update everything that doesn't break things" >>> policy, it does NOT fit our usecase at all! >> >> If you don't like rawhide for that use case, find another operating >> system. I'm tired of our stable releases getting tonnes of updates. >> I'm tired of what F11 shipped like being completely different today. >> I'm tired of waiting for many many hours while we try to compose out the >> 3444 individual updates in F11 stable. (that's right, 3444 srpms worth >> of updates. F11 only had 7446 srpms to begin with!!). This is not the >> style of distribution I wish to produce or consume. If this is the >> style of distribution you wish to produce or consume, then I encourage >> you to go find another distribution or start your own. > > Okay, I have to ask: why are you right and Kevin is wrong? What makes > your vision of Fedora more worthy than his? (Especially when his is the > apparent incumbent?)
And especially given that he cited as many things as he did in Fedora
docs about doing things the way he does. Unfortunately, there are
people on both sides of this fence and making Fedora a one size fits all
distribution will necessarily piss off one group or the other. Which is
why I said in a previous email that I would prefer the
bugfixes/backports split that Mandriva has because that allows you to
satisfy both sides of the fence. I saw this train a comin'. We might
could compromise along the lines of what I wrote in that email in terms
of splitting which packages are update happy and which are considered
stable among some line that would satisfy the majority of people, but I
really think you need two update streams to fully satisfy people.
That or we would have to go with another alternative entirely. People
have (well, to be fair mainly James, but he's right I think) pointed
Kevin at rawhide time and time again. And Kevin has pointed out (also
rightly) that rawhide isn't really consumable. So, we fix that. We
make rawhide consumable, you make rawhide the thing that people track if
they want continuous rolling updates, and you make the actual releases
more stable.
How would you make rawhide consumable you ask? Ah, well, I'll make the
following, totally out of my ass and probably not feasible proposal:
Along the lines of "no frozen rawhide", a new rawhide-testing repo is
created. By default, all builds from devel go into rawhide (gothca
didn't I, you thought I was going to send them to rawhide-testing but
I'm not ;-). However, we have a set of automated tools that check for
things like dependency breakage, API changes, etc. (maybe using rpmdiff
or the like). If those tests trip positive, then the package is moved
from rawhide to rawhide-testing. Alternatively, a developer can build
directly into rawhide-testing for known disruptive changes like soname
bumps and the like. That way rawhide-testing becomes a staging area.
We both encourage maintainers pushing changes they know to be disruptive
to build there, plus we have tools that will catch some classes of
disruption and move them there. Once a package gets caught up in
rawhide-testing, the way to get back out and into rawhide is to fix the
disruptive change. If the change was an sobump, then in addition to the
package itself, we would need rebuilds of all the dependent packages in
rawhide-testing so that they can be pushed en masse. The solution would
be dependent on the type of breakage the package was found to cause, but
the general idea is to stage the changes here until they are ready to
hit rawhide all at once and in a way that doesn't break the
consumability of rawhide. I would maintain nightly pushes of rawhide
packages, but might make the rawhide-testing -> rawhide thing only
happen on an as-needed basis (and hopefully that won't be too often,
maybe no more than once a week on the high side I would guess, but that
number's totally out of my ass).
Then there are the releases. You wean back the updates in stable
releases to things that are actually necessary. I admit I have filed
updates myself that weren't really necessary except they helped me keep
everything straight in my head. So, what does actually necessary mean?
I guess that's up to discussion, but I would throw in my points:
1) Bug fixes and security updates (no one would argue these shouldn't be
sent out)
2) Enhancements? Dunno...are people requesting the enhancement, or are
you just throwing it in to keep F-11/F-12/F-13 the same so you don't
have to think about what's different between them like I sometimes do?
I think there's a bit of wiggle room here. Some things I could see
saying yes to, others no.
3) Wholesale upstream updates? Dunno, see #2.
> Some of us like Fedora just fine the way it is, and don't want to see it
> change to match your vision.
Fair enough, and I don't really like the constant stream of updates.
There are obviously people on both side of this fence, and I would hope
that we might be able to find a solution that doesn't require one group
or the other to walk away from Fedora. Which is why I've outlined what
I did above.
The only two ways I can see to satisfy both groups are:
1) Make a rolling rawhide consumable and move anyone that wants constant
rolling updates there while making point releases stable
and
2) Have two independent update streams for each release similar to the
bugfix/backport streams Mandriva has
An option that doesn't satisfy both groups is to put things to a vote
and whoever wins buys the loser a box of chocolates and a card that
reads "Too bad, enjoy the rest of your week".
If things aren't so bad as to require immediate action though, then the
head in sand, live with status quo option is the one most often taken.
I'm not qualified to speak as to whether things are actually bad enough
to push people to opt for a different option.
Well, if either group doesn't hold at least a reasonable number of
members though, it might not be worth it to do any sort of technical
solution to the issue as the benefit might not cover the implementation
costs. In that case, do the vote and let the little, itty bitty group,
whichever that may be, cry in their beers while they eat their
consolation chocolates. (Sorry, as heartless as it might be, it is still
an accurate bean counter truth)
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
