On Wed, 2008-12-10 at 08:36 -0800, Jesse Keating wrote: > On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote: > > One way or another, if I were building a distribution that wanted to > > simultaneously claim that it is both new code and 'tested and working', > > I'd try to plan in a way that it wasn't a flip of the coin on every > > machine which you'll get today. > > Now here's a crazy idea, that nobody seems to want to follow: > > Treat rawhide as your 'new code' land, leave the release trees as your > 'testing and working' code. That is don't be so goddamn eager to push > new packages and new upstream releases to every freaking branch in > existence. > > Of course, when I make suggestions like these, I become extremely > unpopular. With some people, I guess, although as long as I've been reading f-d-l there has been repeated calls for the updates to slow down. There are two problems here: 1. Sometimes updates have significant bug fixes, as well as a couple of new features (and are fairly well testing, although sometimes even the bugfixes have bugs). I would put most of the yum updates that have been released for non-rawhide versions in this category. 2. Prisoners dilemma, if there are 100M of updates a week then it becomes very easy to say "Well my 100k update isn't that big, and has XYZ feature which is really nice ... so I'll update it too". ...if you are just asking nicely then #1 and #2 create a feedback loop which perpetuates the current updates firehose, if we want to do this we need to start forcing updates to not happen (ie. policy saying that updates _won't_ happen unless they qualify under XYZ). Maybe we could introduce this with usable KOPERS, so people can put their updates/non-critical-fixes into those repos. And as a Fedora user, an upstream developer and a Fedora packager ... I would welcome a policy to that effect. -- James Antill <james@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
