On Thu, 2005-03-03 at 21:30 -0800, Andrew Morton wrote:
> You cannot have it both ways. Either the kernel needs testers, or it is
> "stable". See how these are opposites?
I don't see a contradiction. You need testers for release candidates to
make them stable. The problem is that Linux release c
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > It won't help that at all. None of these proposals will increase testing
> > of tip-of-tree. In fact the 2.6.x proposal may decrease that level of
> > that testing, although probably not much.
>
> Giving humans a well-known
Andrew James Wade wrote:
> I've just done a bit of looking for scripts to automate the process of
> installing a new kernel, and I haven't come up with much of much. So
> right now I'm writing my own. If there are tools to help automate this
> they need to be more prominent on www.kernel.org and
>
Andrew Morton wrote:
It won't help that at all. None of these proposals will increase testing
of tip-of-tree. In fact the 2.6.x proposal may decrease that level of
that testing, although probably not much.
Giving humans a well-known point where bugfixes-only mode starts would
help. Such as the
> You cannot have it both ways. Either the kernel needs
> testers, or it is "stable". See how these are opposites?
I think one of the fundamental problems is "either the kernel needs more
features, or it needs stablization". You cannot have it both ways. With the
current model, the kernel deve
Jochen Striepe <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On 03 Mar 2005, Andrew Morton wrote:
> > 2.6.x is making good progress but there have been a handful of prominent
> > regressions which seem to be making people think that the whole process is
> > bust. I don't believe that this has been p
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > Am I right? All we're proposing here is a tree which has small fixups for
> > reasonably serious problems. Almost without exception it would consist of
> > backports.
>
> "thru-ports": commit to linux-2.6.x.y and get Linus to pull.
This means th
On Thu, 2005-03-03 at 16:03 -0800, Andrew Morton wrote:
> Or, to put it another way, we're getting a small number of irritating
> regressions, mainly in device drivers which is giving the whole thing a bad
> rep. Is there some way in which we can fix that problem without
> reinventing the whole wo
On Thu, 3 Mar 2005, Thomas Gleixner wrote:
>
> It still does not solve the problem of "untested" releases. Users will
> still ignore the linus-tree-rcX kernels.
.. and maybe that problem is unsolvable. People certainly argued
vehemently that anything we do to try to make test releases (renami
On Fri, Mar 04, 2005 at 12:44:16PM +1100, CaT wrote:
> The problems were weird. The fs I was copying from decided it was
> corrupt. Unmounting the partition and trying an fsck reported that it
> couldn't find the partition. After a reboot all was well and a fsck
> reported no problems.
Similar stu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/03/2005 07:21 AM, Linus Torvalds wrote:
> Comments?
before you do this, we have to make -rc's real rc's. Seriously how can
it be that there is a diff between the last rc and the "vanilla"
release. Thats a no-goer in my opinion. Even if it is sm
On March 2, 2005 09:14 pm, Gene Heskett wrote:
> One doesn't have to be a code monkey to do this 'canary' scene as long
> as a bash script can be hacked up to do the majority of the work, I
> have a couple of them that basicly make a new kernel install a no
> brainer. Often under 30 minutes to
On Thu, 3 Mar 2005, Hua Zhong wrote:
>
> Do you consider having a real stable release maintainer again?
No, this really is a different thing.
This is not a "truly separate" parallell track, exactly because it would
not actually get a life of its own. For it to make sense, it would not do
any
On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote:
> This only attacks part of the problem.
It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels.
So we move the real -rcX phase after the so called stable release.
Doing -rcX from the
Linus Torvalds wrote:
On Thu, 3 Mar 2005, Horst von Brand wrote:
[I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
the kind of tester you are looking for... haven't seen any of the
showstopper bugs everybody is talking about, or I'd have screamed.]
Yeah, I wish eve
On Thu, 3 Mar 2005, Steven Rostedt wrote:
On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:
I don't think you are understanding the proposal
You're probably right. :-)
2.6.11.y will be released as 2.6.12 is being developed.
once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a
Hi,
On 03 Mar 2005, Andrew Morton wrote:
> 2.6.x is making good progress but there have been a handful of prominent
> regressions which seem to be making people think that the whole process is
> bust. I don't believe that this has been proven yet.
Sorry -- what you (with the vision of a kern
On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
> compile time regressions we should be able to nail down fairly easily.
> (someone from OSDL is already doing compile stats and such on each release
> [too bad they're mostly incomprehensible to the casual viewer])
Dave, I'm the "someone from
On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote:
> On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
>
> > compile time regressions we should be able to nail down fairly easily.
> > (someone from OSDL is already doing compile stats and such on each release
> > [too bad they're
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > That is all inappropriate activity for a 2.6.x.y tree as it is being
> > proposed.
> >
> > Am I right? All we're proposing here is a tree which has small fixups for
> > reasonably serious problems. Almost without exception it would consist of
> >
Hua Zhong wrote:
The reason that I think it's important for some other person to do this job
independently is that you are not bothered by bugfixes, which you never did
well. :) You move on to each release as you do today, with different
criteria, and someone else who can do the job better do so to
On Thursday 03 March 2005 16:07, Jeff Garzik wrote:
>As a further elaboration...
>
>The problem with the current 2.6-rc setup is a _human_
> _communications_ problem.
>
>Users have been trained in a metaphor that is applied uniformly
> across all software projects that use the metaphor:
>
> test re
Andrew Morton wrote:
Alan Cox <[EMAIL PROTECTED]> wrote:
On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
development skills - it's just patchmonkeying the things which maintainers
send him.
I would disagree, and I suspect anyone
On Iau, 2005-03-03 at 03:10, Christoph Hellwig wrote:
> The point is that it's happening anyway. See Andres' -as tree which
> is the basis for the Debian vendor kernel. Getting that up to an
> official status as 2.6.x.y would be very nice (and having it on
> linux.bkbits.net)
IMHO it is nowhere
On Thu, Mar 03, 2005 at 05:32:03PM -0500, Jeff Garzik wrote:
> On Thu, Mar 03, 2005 at 10:15:46PM +, Alan Cox wrote:
> > We still need 2.6.x.y updates on a more official footing and with more
> > than one person as the "2.6.x.y" maintainer. I think that is actually
> > more important.
>
> That
On Thu, Mar 03, 2005 at 08:41:02PM +0100, Krzysztof Halasa wrote:
> > 2) After 2.6.11 release is out, there is no established process for
> > "oh shit, 2.6.11 users will really want that fixed."
>
> We can do 2.6.11.x scheme. For the last stable kernel, of course
> (i.e., one additional small patc
Alan Cox <[EMAIL PROTECTED]> wrote:
>
> On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
> > Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
> > development skills - it's just patchmonkeying the things which maintainers
> > send him.
>
> I would disagree, and I suspect anyone
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
> > That's the only way it _can_ work. The maintainer of 2.6.x.y shouldn't be
>
> Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
> we risk the magic 2.7 number to
On Thu, 2005-03-03 at 15:28 -0800, Andrew Morton wrote:
> Subject: [Bugme-new] [Bug 4282] New: ALSA driver in Linux 2.6.11 causes a
> kernel panic when loading the EMU10K1 driver
Um... this one is highly suspect. Myself and others have been doing a
lot of work on this driver lately, and have unl
On Iau, 2005-03-03 at 23:17, Andrew Morton wrote:
> Ideally, the 2.6.x.y maintainer wouldn't need any particular kernel
> development skills - it's just patchmonkeying the things which maintainers
> send him.
I would disagree, and I suspect anyone else who has maintained a distro
stable kernel wou
On Fri, Mar 04, 2005 at 12:44:04AM +, Alan Cox wrote:
> On Gwe, 2005-03-04 at 00:19, CaT wrote:
> > Working IDE locking? Does this mean if I have 2 promise cards, a HD
> > on each card and I copy from one to the other it wont all blow up in my
> > face?
>
> Depends on your PCI bus and also if
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Now, I haven't actually gotten any complaints about 2.6.11 (apart from
> "gcc4 still has problems" with fairly trivial solutions)
There have been quite a few. Mainly driver stuff again:
Subject: Re: [BUG] 2.4.27 - 2.4.29 tar: /dev/nst0: Warning: Can
On Mar 03, 2005, at 14:35, Sean wrote:
Wait a second though, this tree will be branched from the development
mainline. So it will contain many patches that entered with less
testing. What will be the policy for dealing with regressions
relative
to the previous $sucker release caused by huge pa
On Gwe, 2005-03-04 at 00:19, CaT wrote:
> Working IDE locking? Does this mean if I have 2 promise cards, a HD
> on each card and I copy from one to the other it wont all blow up in my
> face?
Depends on your PCI bus and also if the are on the same IRQ. In the same
IRQ case you may find 2.6.11 is a
Dave Jones ([EMAIL PROTECTED]) said:
> > [*] I don't know any details of the /proc incompatibility which davej
> > mentions, and I'd like to. That sounds like a screw-up.
>
> We changed the format of /proc/slabinfo. Running slabtop threw up
> an error message complaining that the format h
On Thu, Mar 03, 2005 at 11:51:42PM +, Alan Cox wrote:
> -ac is essentially base security fixes + working IDE locking + pwc +
> fixes for the bugs everyone hit that needed fixing urgently. I consider
> working locking on my storage essential because I like my data to still
> be there.
Working I
On Iau, 2005-03-03 at 16:59, Greg KH wrote:
> On Thu, Mar 03, 2005 at 10:55:13AM -0600, Chris Friesen wrote:
> > Linus Torvalds wrote:
> >
> > >I'll tell you what the problem is: I don't think you'll find anybody to do
> > >the parallell "only trivial patches" tree.
> >
> > Isn't this what -ac an
On Thu, Mar 03, 2005 at 03:17:52PM -0800, Andrew Morton wrote:
> That's the only way it _can_ work. The maintainer of 2.6.x.y shouldn't be
Andrew, what about my suggestion of shifting left x.y of 8 bits? ;) Do
we risk the magic 2.7 number to get us stuck in unstable mode for 2
years instead of 2
Greg KH <[EMAIL PROTECTED]> wrote:
>
> > It's perfectly workable from a BK standpoint to do
> >
> > -> linux-2.6 commit
> > -> cpcset into linux-2.6.X.Y [see Documentation/BK-usage/cpcset]
> > -> pull from linux-2.6.X.Y into linux-2.6 [dups cset, but no
> >real code change]
>
On Thu, 2005-03-03 at 13:53 -0800, David Lang wrote:
> > Actually, the >5 was pretty pointless anyway. What I got
> > from talking to people is that they wanted a release that only got fixes
> > that would crash the machine, or cause a root exploit. That's what I
> > thought Linus was trying to s
On Thu, 3 Mar 2005, Hua Zhong wrote:
>
> Indeed. What I have in mind (and suggested in the past) is that we have a
> real 2.6 stable release maintainer. The only difference is that he starts
> from a random 2.6.x release he picks, and releases 2.6.x.y until he thinks
> stable enough, and he move
On Thu, Mar 03, 2005 at 04:28:52PM -0500, Jeff Garzik wrote:
> Bill Rugolsky Jr. wrote:
> >I've watched you periodically announce "hey, I'm doing an update for
> >FC3/FC2, please test" on the mail list, and a handful of people go test.
> >If we could convince many of the the less risk-averse but la
On Iau, 2005-03-03 at 00:32, Dave Jones wrote:
> On Wed, Mar 02, 2005 at 03:44:58PM -0800, Linus Torvalds wrote:
> The only thing that would make a difference afaics, would be you putting
> your foot down and just ignoring such submissions ?
ROTFL. You've not watched Linus for a long time have you
On Thu, Mar 03, 2005 at 10:15:46PM +, Alan Cox wrote:
> We still need 2.6.x.y updates on a more official footing and with more
> than one person as the "2.6.x.y" maintainer. I think that is actually
> more important.
That appears to be the consensus conclusion we've arrived at.
Jeff
On Iau, 2005-03-03 at 01:27, Dave Jones wrote:
> In an ideal world, we'd see a single 'y' release of 2.6.x.y, but if x+1 takes
> too long to be released, bits of x+1 should also appear in x.y+1
> The only question in my mind is 'how critical does a bug have to be to
> justify a .y release. Once a
On Mer, 2005-03-02 at 22:21, Linus Torvalds wrote:
> - 2.6.: still a stable kernel, but accept bigger changes leading up
>to it (timeframe: a month or two).
> - 2..x: aim for big changes that may destabilize the kernel for
>several releases (timeframe: a year or two)
> - .x.x: Linus we
On Thu, 2005-03-03 at 13:38 -0800, Stephen Hemminger wrote:
> In all this discussion, I see a couple of underlying problems. The first
> is what is the definition of stability. To many (mostly kernel developers)
> the definition of stability "S" depends on number of bug reports "B":
>
> S(i
On Thu, 2005-03-03 at 16:52 -0500, Dave Jones wrote:
> On Thu, Mar 03, 2005 at 01:49:50PM -0800, John Cherry wrote:
> > On Thu, 2005-03-03 at 00:21 -0500, Dave Jones wrote:
> >
> > > compile time regressions we should be able to nail down fairly easily.
> > > (someone from OSDL is already doin
> In other words, I'm really talking about something different
> from what you seem to envision.
Indeed. What I have in mind (and suggested in the past) is that we have a
real 2.6 stable release maintainer. The only difference is that he starts
from a random 2.6.x release he picks, and releases
On Thu, 2005-03-03 at 13:24 -0800, David Lang wrote:
> I don't think you are understanding the proposal
>
You're probably right. :-)
> 2.6.11.y will be released as 2.6.12 is being developed.
>
> once 2.6.12 is released (or shortly after that if 2.6.12 ends up being a
> _real_ mess) 2.6.11.y wi
In all this discussion, I see a couple of underlying problems. The first
is what is the definition of stability. To many (mostly kernel developers)
the definition of stability "S" depends on number of bug reports "B":
S(infinite) = B(0)
S(X) > S(Y) iff B(X) < B(Y)
The problem is
Bill Rugolsky Jr. wrote:
I've watched you periodically announce "hey, I'm doing an update for
FC3/FC2, please test" on the mail list, and a handful of people go test.
If we could convince many of the the less risk-averse but lazy users to
grab kernels automatically from updates/3/testing/ or update
Dave Jones wrote:
Other failures have been somewhat more dramatic.
I know ipsec-tools, and alsa-lib have both caused pain
on at least one occasion after the last 2-3 kernel updates.
alsa-lib is a special case.
alsa-lib exists so that it can mitigate changes between the kernel and
userland. If th
On Thu, 3 Mar 2005, Steven Rostedt wrote:
A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
to several people about the stability of the 2.6 kernel. Every one I
talked to seemed to be nervous about using it. Some did, and some did
not and stayed with 2.4. But each one had a
On Thu, Mar 03, 2005 at 01:09:01PM -0800, Andrew Morton wrote:
> [*] I don't know any details of the /proc incompatibility which davej
> mentions, and I'd like to. That sounds like a screw-up.
We changed the format of /proc/slabinfo. Running slabtop threw up
an error message complaining t
As a further elaboration...
The problem with the current 2.6-rc setup is a _human_ _communications_
problem.
Users have been trained in a metaphor that is applied uniformly across
all software projects that use the metaphor:
test release: a useful merge/testing point
r
Andries Brouwer <[EMAIL PROTECTED]> wrote:
>
> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
> the guarantee that user-visible APIs do not change. That goal
> has disappeared, meaning that anything might break when one
> upgrades from 2.6.14 to 2.6.16.
> This is one of the big
A couple of weeks ago I was at LinuxWorldExpo in Boston and was talking
to several people about the stability of the 2.6 kernel. Every one I
talked to seemed to be nervous about using it. Some did, and some did
not and stayed with 2.4. But each one had a different level of faith in
which kernel
Linus Torvalds <[EMAIL PROTECTED]> said:
> On Thu, 3 Mar 2005, Horst von Brand wrote:
> > [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
> > the kind of tester you are looking for... haven't seen any of the
> > showstopper bugs everybody is talking about, or I'd have
El Thu, 3 Mar 2005 00:21:01 -0500,
Dave Jones <[EMAIL PROTECTED]> escribió:
> bunch of IBM thinkpads. As it turns out there are quite a lot of these
> out there, so when I released a 2.6.10 update for Fedora, bugzilla lit
> up like a christmas tree with "Hey, where'd my sound go?" reports.
> (It w
On Thu, Mar 03, 2005 at 02:33:58PM -0500, Dave Jones wrote:
> If you accelerate the merging process, you're lowering the review process.
> The only answer to get regressions fixed up as quickly as possible
> (because prevention is nigh on impossible at the current rate, so
> any faster is just abs
On Thu, 3 Mar 2005, Sean wrote:
>
> Wait a second though, this tree will be branched from the development
> mainline. So it will contain many patches that entered with less
> testing.
Well, since I'd pull basically all the time, all the patches _do_ get
testing the the -rc kernels.
But the
On Thu, 2005-03-03 at 14:52 -0500, Jeff Garzik wrote:
> I disagree it's unsolvable:
>
> 1) At some point in the -rc cycle, you put your foot down and say
> "nothing but bugfixes."
Release candidates are supposed to be bugfix only from -rc1. Everything
else can only be called the "ridiculous coun
Chris Wright <[EMAIL PROTECTED]> writes:
> I like this definition. The only remaining question is what determines
> a 2.6.x.y release? One patch? Sure if it's critical enough.
Sure. Or a patch for 1-2 days, will less critical things.
And probably no .tar* balls for them. Just a patch agains
Thomas Gleixner wrote:
On Thu, 2005-03-03 at 18:08 +0100, Adrian Bunk wrote:
This only attacks part of the problem.
It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels.
So we move the real -rcX phase after the so called stable release.
On Thu, Mar 03, 2005 at 02:35:29PM -0500, Sean wrote:
> On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> > On Thu, 3 Mar 2005, Jens Axboe wrote:
> >>
> >> Why should there be one? One of the things I like about this concept is
> >> that it's just a moving tree. There could be daily snapshots
On Thu, 2005-03-03 at 14:42 -0500, Jeff Garzik wrote:
> 1) Release maintainers need to avoid merging non-bugfixes. Lately, the
> key penguins _have_ been doing their job here. This manifested in
> 2.6.11-rc4, 2.6.11-rc5.
True, but the confidence of users in -rc is gone already. So testing
happ
David S. Miller wrote:
On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
I disagree it's unsolvable:
1) At some point in the -rc cycle, you put your foot down and say
"nothing but bugfixes."
Linus actually did, as Andrew showed you, and it was actually followed
quite well
Jeff Garzik <[EMAIL PROTECTED]> writes:
> 1) There is no clear, CONSISTENT point where "bugfixes only"
> begins. Right now, it could be -rc2, -rc3, -rc4... who knows.
>
> We need to send a clear signal to users "this is when you can really
> start hammering it." A signal that does not change from
On Thu, 03 Mar 2005 14:52:21 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> I disagree it's unsolvable:
>
> 1) At some point in the -rc cycle, you put your foot down and say
> "nothing but bugfixes."
Linus actually did, as Andrew showed you, and it was actually followed
quite well.
You keep ig
Andries Brouwer <[EMAIL PROTECTED]> writes:
> API stability: Stable series like 2.0, 2.2, 2.4 try to maintain
> the guarantee that user-visible APIs do not change. That goal
> has disappeared, meaning that anything might break when one
> upgrades from 2.6.14 to 2.6.16.
Both 2.4 and 2.6 are IMHO s
On Thu, 2005-03-03 at 11:37 -0800, Linus Torvalds wrote:
> > It still does not solve the problem of "untested" releases. Users will
> > still ignore the linus-tree-rcX kernels.
>
> .. and maybe that problem is unsolvable. People certainly argued
> vehemently that anything we do to try to make te
Linus Torvalds wrote:
On Thu, 3 Mar 2005, Thomas Gleixner wrote:
It still does not solve the problem of "untested" releases. Users will
still ignore the linus-tree-rcX kernels.
.. and maybe that problem is unsolvable. People certainly argued
vehemently that anything we do to try to make test rel
On Thu, March 3, 2005 12:53 pm, Linus Torvalds said:
> On Thu, 3 Mar 2005, Jens Axboe wrote:
>>
>> Why should there be one? One of the things I like about this concept is
>> that it's just a moving tree. There could be daily snapshots like the
>> -bkX "releases" of Linus's tree, if there are change
On Thu, Mar 03, 2005 at 12:07:59PM -0500, Bill Rugolsky Jr. wrote:
> IMHO, Jeff Garzik has made two very useful points in this thread:
>
> 1. The number of changesets flowing towards the Linus kernel is accelerating,
>so the kernel developers should be trying to accelerate the merging
>
> In fact, if somebody maintained that kind of tree, especially
> in BK, it would be trivial for me to just pull from it every once in a
> while (like ever _day_ if necessary). But for that to work, then that
> tree would have to be about so _obviously_ not wild patches that
> it's a no-brainer
Linus Torvalds wrote:
I'll tell you what the problem is: I don't think you'll find anybody to do
the parallell "only trivial patches" tree.
Isn't this what -ac and -as effectively already are?
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
>...
> But look at how to solve it. The _logical_ solution is to have a third
> line of defense: we have the -mm trees (wild and wacky patches), and we
> have my tree (hopefully not wacky any more), and it would be good to have
> a thi
On Thu, 3 Mar 2005, Jeff Garzik wrote:
>
> The only problem I see with this -- and its a minor problem -- is that
> some patches that belong in the 2.6.X.Y tree go straight to you/Andrew,
> rather than to $sucker.
Yes. I think people will have to be taught, and get used to the new world
order
On Thu, Mar 03, 2005 at 12:52:52PM -0500, Daniel Barkalow wrote:
> On Thu, 3 Mar 2005, Linus Torvalds wrote:
>
> > - some very _technical_ and objective rules on patches. And they should
> >limit the patches severely, so that people can never blame the sucker
> >who does the job. For ex
On Thu, Mar 03, 2005 at 01:04:49PM -0500, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >In fact, if somebody maintained that kind of tree, especially in BK, it
> >would be trivial for me to just pull from it every once in a while (like
> >ever _day_ if necessary). But for that to work, then that
Linus Torvalds wrote:
In fact, if somebody maintained that kind of tree, especially in BK, it
would be trivial for me to just pull from it every once in a while (like
ever _day_ if necessary). But for that to work, then that tree would have
to be about so _obviously_ not wild patches that it's a
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> On Thu, 3 Mar 2005, Jens Axboe wrote:
> >
> > Why should there be one? One of the things I like about this concept is
> > that it's just a moving tree. There could be daily snapshots like the
> > -bkX "releases" of Linus's tree, if there are changes fr
On Thu, 3 Mar 2005, Greg KH wrote:
>
> Then either the patch author splits out the bug if they want to, or we
> punt and say "wait for 2.6.12". Distros can then decide if they want to
> take the whole $big_patch in their releases, if they are near a release
> cycle.
Yes. Exactly.
We're not ai
On Thu, 3 Mar 2005 11:48:39 + (GMT)
Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> On Thu, 3 Mar 2005, Jeff Garzik wrote:
> > Anton Altaparmakov wrote:
> > > I think the .EVEN and .ODD proposal would work a lot better than -rc ever
> > > would/could.
> >
> > ...until people find out the "sec
On Thu, 3 Mar 2005, Neil Brown wrote:
On Wednesday March 2, [EMAIL PROTECTED] wrote:
On Wed, 02 Mar 2005 23:46:22 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote:
If Linus/DaveM really don't like -pre/-rc naming, I think 2.6.x.y is
preferable to even/odd.
All of these arguments are circular. If people
On Thu, 3 Mar 2005, Jens Axboe wrote:
>
> Why should there be one? One of the things I like about this concept is
> that it's just a moving tree. There could be daily snapshots like the
> -bkX "releases" of Linus's tree, if there are changes from the day
> before. It means (hopefully) that no on
On Thu, 3 Mar 2005, Linus Torvalds wrote:
> - some very _technical_ and objective rules on patches. And they should
>limit the patches severely, so that people can never blame the sucker
>who does the job. For example, I would suggest that "size" be one hard
>technical rule. If the
On Thu, 3 Mar 2005, Chris Friesen wrote:
>
> Linus Torvalds wrote:
>
> > I'll tell you what the problem is: I don't think you'll find anybody to do
> > the parallell "only trivial patches" tree.
>
> Isn't this what -ac and -as effectively already are?
No. They both end up doing a lot of much f
On Wed, 2 Mar 2005 14:21:38 -0800 (PST), Linus Torvalds wrote:
> The reason I put a shorter timeframe on the "all-even" kernel is because I
> don't want developers to be too itchy and sitting on stuff for too long if
> they did something slightly bigger. In theory, the longer the better
> there, b
On Thu, Mar 03, 2005 at 12:00:39PM -0500, Theodore Ts'o wrote:
> On Thu, Mar 03, 2005 at 08:43:53AM -0800, Greg KH wrote:
> > On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> > >
> > > So what's the problem with this approach? It would seem to make everybody
> > > happy: it would
On Thu, Mar 03, 2005 at 09:04:43AM -0800, Eric Gaumer wrote:
> Greg KH wrote:
> >On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> >
> >>So what's the problem with this approach? It would seem to make everybody
> >>happy: it would reduce my load, it would give people the alternate "
On Thu, Mar 03, 2005 at 06:08:08PM +0100, Adrian Bunk wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> >...
> > But look at how to solve it. The _logical_ solution is to have a third
> > line of defense: we have the -mm trees (wild and wacky patches), and we
> > have my tr
Greg KH wrote:
On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
So what's the problem with this approach? It would seem to make everybody
happy: it would reduce my load, it would give people the alternate "2.6.x
base kernel plus fixes only" parallell track, and it would _not_ have th
On Thu, Mar 03, 2005 at 02:15:06AM -0800, Andrew Morton wrote:
> If we were to get serious with maintenance of 2.6.x.y streams then that is
> a 100% productisation activity. It's a very useful activity, and there is
> demand for it. But it is a very different activity. And a lot of this
> discus
On Thu, Mar 03, 2005 at 06:03:36PM +0100, Jens Axboe wrote:
> On Thu, Mar 03 2005, Chris Wright wrote:
> > > - Finally: this tree never has any history past the "last release". When
> > >a new kernel comes, the tree is frozen, and never to be touched again.
> >
> > I like this definition. Th
On Thu, Mar 03, 2005 at 10:55:13AM -0600, Chris Friesen wrote:
> Linus Torvalds wrote:
>
> >I'll tell you what the problem is: I don't think you'll find anybody to do
> >the parallell "only trivial patches" tree.
>
> Isn't this what -ac and -as effectively already are?
Based on the patches in th
On Thu, Mar 03 2005, Chris Wright wrote:
> > - Finally: this tree never has any history past the "last release". When
> >a new kernel comes, the tree is frozen, and never to be touched again.
>
> I like this definition. The only remaining question is what determines
> a 2.6.x.y release? One
On Thu, Mar 03, 2005 at 08:43:53AM -0800, Greg KH wrote:
> On Thu, Mar 03, 2005 at 08:23:39AM -0800, Linus Torvalds wrote:
> >
> > So what's the problem with this approach? It would seem to make everybody
> > happy: it would reduce my load, it would give people the alternate "2.6.x
> > base kernel
On Thu, 3 Mar 2005, Horst von Brand wrote:
>
> [I'm pulling bk daily, and have it mixed with the ipw tree too, so I'm just
> the kind of tester you are looking for... haven't seen any of the
> showstopper bugs everybody is talking about, or I'd have screamed.]
Yeah, I wish everybody was like
101 - 200 of 346 matches
Mail list logo
