Mailing List Archive

Accountability
Hi,
Sorry to post while Linus is on holidays, but life goes on.
Is there a good reason, or indeed any reason, why epckpt isn't in the kernel
right now?
For those of you who don't know, it's a checkpoint/restart utility, it's quite
good, its functionality can't be duplicated in user space, and it has some
quite useful applications.
Here's a mirror URL:
http://www.cs.rochester.edu/~edpin/epckpt/
I'll wait for replies before I suggest a kernel fork.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Wed, Sep 15, 1999 at 01:58:02AM +1000, Colin McCormack wrote:
> I looked at the patch, it didn't look unstable, unclean or insubstantial. It
> looked like a fairly straight-forward and elegant mod, to me.
>
> I note that there have been 4 released versions of the patch, going back to
> 2.0.29. One would have thought it was in a reasonable position to go into
> 2.2.1.
>
> Although I am not the author of the work in question, if it was me, I'd be
> looking for some reasoned feedback as to why it's not in the kernel already,
> otherwise I'd become rapidly disenchanted, discouraged and demotivated.
>
> I doubt that's good for Linux.
>
> Colin.
I think your taking this a little too far. Things don't just magically
appear in the kernel. The author needs to submit it in a suitable fashion
for inclusion. So the answer might be as simple as "The author never tried
to get it included", have you even asked the author about this and does
s/he even _want_ it in the kernel?
Ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> For those of you who don't know, it's a checkpoint/restart utility, it's quite
> good, its functionality can't be duplicated in user space, and it has some
> quite useful applications.
>
> Here's a mirror URL:
> http://www.cs.rochester.edu/~edpin/epckpt/
>
> I'll wait for replies before I suggest a kernel fork.
I would suggest the first thing you want to do is to port it to 2.3.x and
make it work on 2.3.x. If you can get it stable, clean and solid when 2.4.x
appears then it is both a good add on patch and its positioned nicely to
go into 2.5.x . I plan to do the same with the extremely useful swsuspend
patch for example.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
>> Here's a mirror URL:
>> http://www.cs.rochester.edu/~edpin/epckpt/
>>
>> I'll wait for replies before I suggest a kernel fork.
>
> I would suggest the first thing you want to do is to port it to 2.3.x and
> make it work on 2.3.x. If you can get it stable, clean and solid when 2.4.x
> appears then it is both a good add on patch and its positioned nicely to
> go into 2.5.x . I plan to do the same with the extremely useful swsuspend
> patch for example.
I looked at the patch, it didn't look unstable, unclean or insubstantial. It
looked like a fairly straight-forward and elegant mod, to me.
I note that there have been 4 released versions of the patch, going back to
2.0.29. One would have thought it was in a reasonable position to go into
2.2.1.
Although I am not the author of the work in question, if it was me, I'd be
looking for some reasoned feedback as to why it's not in the kernel already,
otherwise I'd become rapidly disenchanted, discouraged and demotivated.
I doubt that's good for Linux.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
Colin McCormack wrote:
> Is there a good reason, or indeed any reason, why epckpt isn't in the kernel
> right now?
"Feature freeze".
Wait until 2.5 unless your feature will really change the life of
millions.
> I'll wait for replies before I suggest a kernel fork.
Keeping the patch up to date with developing kernels is always a nice
thing to do.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> Colin McCormack wrote:
>>Is there a good reason, or indeed any reason, why epckpt isn't in the kernel
>> right now?
>
> "Feature freeze".
Since version 2.2.1 ?
> Wait until 2.5 unless your feature will really change the life of
> millions.
The patch, a relatively simple one, has been around since 2.0.36. That's a
year at least. 2.4 is scheduled for release at the end of this year, it may
slip.
Is two years lead time really what you'd expect from a Bazaar development
system?
>> I'll wait for replies before I suggest a kernel fork.
>
> Keeping the patch up to date with developing kernels is always a nice
> thing to do.
That's some feedback. Thanks.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> On Wed, Sep 15, 1999 at 01:58:02AM +1000, Colin McCormack wrote:
>> Although I am not the author of the work in question, if it was me, I'd be
>> looking for some reasoned feedback as to why it's not in the kernel
already,
>> otherwise I'd become rapidly disenchanted, discouraged and demotivated.
>
>> I doubt that's good for Linux.
>>
> I think your taking this a little too far. Things don't just magically
> appear in the kernel. The author needs to submit it in a suitable fashion
> for inclusion.
I don't think I was implicitly relying upon magic to get it into the kernel.
Let's look at what `suitable fashion' might mean, in this context:
1) We know it can't be a .bz file, because
http://kernelnotes.org/lnxlists/linux-kernel/lk_9908_05/msg00250.html
2) We know that it can't be picked from a CVS archive, or packaged as a
release from an archive, because
http://kt.linuxcare.com/kt19990819_31.html#9
3) We know that it can't be sent any time in the next two weeks, because
http://kernelnotes.org/lnxlists/linux-kernel/lk_9909_02/msg00460.html
I just don't see much there to do with the stability, cleanliness and solidity
criteria Alan mentioned a couple of posts back. In fact, these reasons have
nothing to do with why people use Linux, and an N-year delay in a minor patch
is a pretty clear sign that something's awry.
I'm reminded of when Andrew Tanenbaum discouraged Bruce Evans and me from
working on a multi-threaded file system for Minix because it'd reduce the
pedagogic value of Minix.
We know what happened then.
> So the answer might be as simple as "The author never tried
> to get it included", have you even asked the author about this and does
> s/he even _want_ it in the kernel?
Yes, I asked. Yes, the author has posted patches. He's probably too polite.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> I don't think I was implicitly relying upon magic to get it into the kernel.
> Let's look at what `suitable fashion' might mean, in this context:
A suitable fashion means someone submits it to Linus and promises to maintain
it and fix it.
> I'm reminded of when Andrew Tanenbaum discouraged Bruce Evans and me from
> working on a multi-threaded file system for Minix because it'd reduce the
> pedagogic value of Minix.
>
> We know what happened then.
Yes. His OS stayed a teaching OS has he deeply believed it should.
> > So the answer might be as simple as "The author never tried
> > to get it included", have you even asked the author about this and does
> > s/he even _want_ it in the kernel?
>
> Yes, I asked. Yes, the author has posted patches. He's probably too polite.
Feel free to be his marketing front man. I do however think you are 4 weeks
late for 2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> Although I am not the author of the work in question, if it was me, I'd be
> looking for some reasoned feedback as to why it's not in the kernel already,
> otherwise I'd become rapidly disenchanted, discouraged and demotivated.
>
> I doubt that's good for Linux.
Everything you add pushes back the release time for the next stable release.
So to help a few people using that feature you delay stuff all benefit from.
The suspend patch is also not going to make 2.4. Its as simple, useful to
more people and the same applies. I'm just going to make sure its polished
and ready for 2.5
ALan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> > I don't think I was implicitly relying upon magic to get it into the kernel.
> > Let's look at what `suitable fashion' might mean, in this context:
>
> A suitable fashion means someone submits it to Linus and promises to maintain
> it and fix it.
Is this documented somewhere?
> > I'm reminded of when Andrew Tanenbaum discouraged Bruce Evans and me from
> > working on a multi-threaded file system for Minix because it'd reduce the
> > pedagogic value of Minix.
> >
> > We know what happened then.
>
> Yes. His OS stayed a teaching OS has he deeply believed it should.
Yes, but meanwhile it forked, producing a better OS: Minix.
Now there's Hurd on the horizon, Eros looking like reviving the `debate' about
microkernels, and no reasonable facsimile of a version control or patch
submission system for Linux.
>>> So the answer might be as simple as "The author never tried
>>> to get it included", have you even asked the author about this and does
>>> s/he even _want_ it in the kernel?
>>
>> Yes, I asked. Yes, the author has posted patches. He's probably too
polite.
>
> Feel free to be his marketing front man. I do however think you are 4 weeks
> late for 2.4
From one marketing front man to another: I respect your desire to keep the
brand name pure, but what's in a number? Something for real marketing front
men to put on a press release? What's it got to do with the *other* use to
which one might put Linux ... experimenting with new features?
What'd be really nice would be a system where people could directly submit
branch material, others could selectively check out branches, and still others
could (if they wished) re-join the branches.
Linus could bless branches, so could you, but people should be able to roll
their own to a much greater extent, if Linux is to maintain any kind of
growing edge.
Another lesson from history is the gcc/egcs development. I'd say Linux's in
the balance now, but if I were intimately involved with the kernel, I'd be
open-sourcing it as quickly as possible.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> > A suitable fashion means someone submits it to Linus and promises to maintain
> > it and fix it.
>
> Is this documented somewhere?
5 years of tradition
> Another lesson from history is the gcc/egcs development. I'd say Linux's in
> the balance now, but if I were intimately involved with the kernel, I'd be
> open-sourcing it as quickly as possible.
Free software projects without good input filtering of ideas turn into bloated
sludge. Egcs has good filtering (you should hear some of the things people say
about the Cygnus guys after they get told "no" a few times ;)) so it works.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
>>>A suitable fashion means someone submits it to Linus and promises to
maintain
>>> it and fix it.
>>
>> Is this documented somewhere?
>
> 5 years of tradition
I take that to mean `no'.
>> Another lesson from history is the gcc/egcs development. I'd say Linux's
in
>> the balance now, but if I were intimately involved with the kernel, I'd be
>> open-sourcing it as quickly as possible.
> Free software projects without good input filtering of ideas turn into bloated
> sludge. Egcs has good filtering (you should hear some of the things people say
> about the Cygnus guys after they get told "no" a few times ;)) so it works.
Good input filtering? I've never seen anyone be told `no' because their
patches were too large (in fact, as far as I can see, large slabs of egcs are
farmed out to largely independent groups, as has effectively happened with
ISDN under Linux), nor because one of the developers' machines doesn't have
bz2.
As far as it goes, `good' input filtering for Linux would be able to be done
by tossing a coin, so long as people were able to select which branches they
wanted to continue to work on, submit and check out.
Additionally, coins don't get stuck on `no' for things like GGI.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> Additionally, coins don't get stuck on `no' for things like GGI.
Which is a fine example why tossing coins doesnt work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> > Additionally, coins don't get stuck on `no' for things like GGI.
>
> Which is a fine example why tossing coins doesnt work
Empirically, we won't know if excluding GGI `works', because it'll always be
excluded.
Similarly, we'll never know if Minix fs could have been made multithreaded.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
In article <cistron.19990914160259Z156135-15266+621@vger.rutgers.edu>,
Colin McCormack <colin@field.medicine.adelaide.edu.au> wrote:
>I looked at the patch, it didn't look unstable, unclean or insubstantial. It
>looked like a fairly straight-forward and elegant mod, to me.
>
>I note that there have been 4 released versions of the patch, going back to
>2.0.29. One would have thought it was in a reasonable position to go into
>2.2.1.
>
>Although I am not the author of the work in question, if it was me, I'd be
>looking for some reasoned feedback as to why it's not in the kernel already,
>otherwise I'd become rapidly disenchanted, discouraged and demotivated.
Kernel patches need to be announced on linux-kernel. Then you get a few
people to test it. Then you send it to the subsystem maintainer, or
directly to Linus. These people are very busy; if you sent a patch
for 2.3.15 and in the main time 2.3.18 has appeared on which it doesn't
patch cleanly you won't get an answer. Also if you don't document _very
well_ what the patch does and why it won't get applied either.
If Linus or the subsystem maintainer doesn't reply assume your patch
was not good enough. You can send another email to ask for an explanation,
and you'll usually get one.
To get a patch in the kernel, you need to be very persistent. OTOH, as
soon as a you get a driver or filesystem or other subsystem into the
kernel of which you are clearly the author/maintainer, patches will
usually be applied with no questions asked.
Mike.
--
... somehow I have a feeling the hurting hasn't even begun yet
-- Bill, "The Terrible Thunderlizards"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Wed, 15 Sep 1999, Colin McCormack wrote:
>> > I don't think I was implicitly relying upon magic to get it into the kernel.
>> > Let's look at what `suitable fashion' might mean, in this context:
>>
>> A suitable fashion means someone submits it to Linus and promises to maintain
>> it and fix it.
>
>Is this documented somewhere?
linux/MAINTAINERS
>Another lesson from history is the gcc/egcs development. I'd say Linux's in
>the balance now, but if I were intimately involved with the kernel, I'd be
>open-sourcing it as quickly as possible.
And it isn't open-source currently? That's the idea of the MAINTAINERS
file at least, division of labor and a nice flow of patches in.
-George Greer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Wed, 15 Sep 1999, Colin McCormack wrote:
> As far as it goes, `good' input filtering for Linux would be able to
> be done by tossing a coin, so long as people were able to select which
> branches they wanted to continue to work on, submit and check out.
Feel free to implement this idea _on_your_own_server_.
It would certainly be "interesting" to see anyone try to
come up with a better working plan than filtering by a
number of skilled people.
"good input filtering done by tossing a coin" ???
Just don't expect me to lend you any coins...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
work at: http://www.reseau.nl/
home at: http://www.nl.linux.org/~riel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Wed, 15 Sep 1999, Colin McCormack wrote:
>>>>A suitable fashion means someone submits it to Linus and promises to
>maintain
>>>> it and fix it.
>>>
>>> Is this documented somewhere?
>>
>> 5 years of tradition
>
>I take that to mean `no'.
I take that to mean you haven't read linux-kernel.
>Good input filtering? I've never seen anyone be told `no' because their
>patches were too large (in fact, as far as I can see, large slabs of egcs
>are farmed out to largely independent groups, as has effectively happened
>with ISDN under Linux), nor because one of the developers' machines
>doesn't have bz2.
Input filtering isn't by size, it's content.
>Additionally, coins don't get stuck on `no' for things like GGI.
They seem to be doing just fine.
You have that air of contemptuousness about your posts...
-George Greer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
Colin, please take this elsewhere. you have no clue about linux-kernel,
how it works, and appear fuzzy even on _that_ it works. if you want to
implement a patch/version control system, and can get the Cabal to use it,
you'll do a service to the community. whining is a disservice.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Tue, Sep 14, 1999 at 06:02:47PM +0200, Jamie Lokier wrote:
> > Is there a good reason, or indeed any reason, why epckpt isn't in the kernel
> > right now?
>
> "Feature freeze".
>
> Wait until 2.5 unless your feature will really change the life of
> millions.
If it changes the life of millions, it should definitely wait until 2.5.x <g>
<mode type="david parsons">
Change isn't always good..
</mode>
--
The church is near but the road is icy; the bar is far away but I will
walk carefully.
-- Russian Proverb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
> > I think your taking this a little too far. Things don't just magically
> > appear in the kernel. The author needs to submit it in a suitable fashion
> > for inclusion.
>
> I don't think I was implicitly relying upon magic to get it into the kernel.
>
> Let's look at what `suitable fashion' might mean, in this context:
>
> 1) We know it can't be a .bz file, because
> http://kernelnotes.org/lnxlists/linux-kernel/lk_9908_05/msg00250.html
A restriction on file formats should not be a major hardship for getting
patches out. Submit it in a suitable format. It is clear that bz2 may not be
a suitable format, as there are some who do not support bz2. Come on, you've
got tar/gz...
That said, it may be appropriate to document this.
> 2) We know that it can't be picked from a CVS archive, or packaged as a
> release from an archive, because
> http://kt.linuxcare.com/kt19990819_31.html#9
This is a misrepresentation of Linus' comments on this subject. Linus was
commenting on the difficulties of incorporating infrequent, large snapshots.
Infrequent, large snapshots ARE inappropriate here, whereas small, frequent
incremental diffs are appropriate - they ease peer review, and they introduce
much less risk. Linus also acknowledged that large snapshots may be
appropriate for things (such as the ISDN functionality) being added to standard
kernels for the first time.
> 3) We know that it can't be sent any time in the next two weeks, because
> http://kernelnotes.org/lnxlists/linux-kernel/lk_9909_02/msg00460.html
Hey, go figure, Linus takes a couple weeks off. Core functionality and new
features need to go through him, and seeing as there's a feature freeze now,
need to be very well justified.
> I just don't see much there to do with the stability, cleanliness and solidity
> criteria Alan mentioned a couple of posts back. In fact, these reasons have
> nothing to do with why people use Linux, and an N-year delay in a minor patch
> is a pretty clear sign that something's awry.
A big delay is concerning. However, the reason Linus went off on the ISDN
group in your second link was to improve stability and solidity. Infrequent
large patches do not do anything positive for stability.
> Yes, I asked. Yes, the author has posted patches. He's probably too polite.
Where were the patches posted? When were the patches posted? How were the
patches posted?
PK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
Colin McCormack <colin@field.medicine.adelaide.edu.au> writes:
> I've never seen anyone be told `no' because their patches were too
> large
Then you haven't watched Jeff Law discuss some of HJ Lu's patches.
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
In article <linux.kernel.19990914162252Z156154-15264+596@vger.rutgers.edu>,
Colin McCormack <colin@field.medicine.adelaide.edu.au> wrote:
>> Colin McCormack wrote:
>>>Is there a good reason, or indeed any reason, why epckpt isn't in the kernel
>>> right now?
>>
>> "Feature freeze".
>
>Since version 2.2.1 ?
>
>> Wait until 2.5 unless your feature will really change the life of
>> millions.
>
>The patch, a relatively simple one, has been around since 2.0.36. That's a
>year at least. 2.4 is scheduled for release at the end of this year, it may
>slip.
>
>Is two years lead time really what you'd expect from a Bazaar development
>system?
It's not a bazaar. The distributions may be developed that way,
but to get into the mainline kernel you have to go through the
pope.
____
david parsons \bi/ Can't get much more cathedral-like than the Linux
\/ kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Tue, Sep 14, 1999 at 06:36:47PM +0000, Mark Hahn wrote:
> Colin, please take this elsewhere. you have no clue about linux-kernel,
> how it works, and appear fuzzy even on _that_ it works. if you want to
> implement a patch/version control system, and can get the Cabal to use it,
> you'll do a service to the community. whining is a disservice.
There is no Cabal.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Accountability [ In reply to ]
On Wed, Sep 15, 1999 at 03:11:56AM +1000, Colin McCormack wrote:
> > A suitable fashion means someone submits it to Linus and promises to maintain
> > it and fix it.
>
> Is this documented somewhere?
Not "formally". But every now and then Linus or someone else posts something
to linux-kernel that elaborates on what they like to see done. I dimly recall
that there may also be something in the FAQ about it - have you read it?
> From one marketing front man to another:
Assuming you addressed this to Alan, I certainly don't regard him as a
'marketing front man' particularly. I don't know whether he does, but I doubt
it somehow.
> I respect your desire to keep the
> brand name pure, but what's in a number?
Well, for starters, the patchlevel (middle number) tells you whether it's
a stable version or not. You generally won't get new core features (i.e.
something that affects other code) into a stable release.
> Something for real marketing front men to put on a press release?
I guess the main version number (left-most) is kind of like that.
> What'd be really nice would be a system where people could directly submit
> branch material
If you mean, "submit material for a non-standard branch", then just create
a mailing list for the non standard branch, get people interested in said
branch to join it, and bob's your unicorn.
>, others could selectively check out branches,
Nothing to stop people publishing non-standard branches. Alan does it, and I
think Andrea has periodically as well. And of course there are the ELKS people,
and so on.
> and still others could (if they wished) re-join the branches.
Anyone who's got the source to both branches can do this.
> Linus could bless branches, so could you, but people should be able to roll
> their own to a much greater extent, if Linux is to maintain any kind of
> growing edge.
The kernel's GPL'd. Anyone can roll their own branch, and distribute it. This
is in fact what the distribution vendors do. Admittedly they don't tend to
deviate much, but that's not really relevant.
> Another lesson from history is the gcc/egcs development. I'd say Linux's in
> the balance now, but if I were intimately involved with the kernel, I'd be
> open-sourcing it as quickly as possible.
It /is/ "open-sourced" (ugh); that is, it's GPL'd and as such complies with
the OSI's open source definition and the DFSG, which are pretty much the
de-facto standards for the definition of "open source".
Can we drop this now? Or at least go to email?
--
There are many intelligent species in the universe. They all own
cats.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

1 2  View All