Mailing List Archive

Colin McCormack wrote:
> > "Feature freeze".
>
> Since version 2.2.1 ?
Linus warned about the feature freeze weeks in advance. Now it's too
late for 2.4. There are simply more important things to get working.
-- 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/

On Wed, 15 Sep 1999, Colin McCormack wrote:
> >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.
Hrm, sounds like a mailing list might be in order. Maybe we could call
it 'linux-kernel'...
Stephen
-
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/

On Wed, 15 Sep 1999, Colin McCormack wrote:
>> 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?
Alan is hardly a marketing front man for anything in here. I
don't know why you'd make such a comment. Alan is a very
important part of kernel development and maintenance. Pot shots
at him over such a trivial issue are pointless indeed.
>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.
Feel free to design such a system. I'm sure the developers would
love to use it, and would very much appreciate your efforts to
give back into the Linux community for all it has given you.
>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.
Just let us know when your system is ready, I'd be glad to beta
test it for you. As it stands right now, people can roll their
own kernel to EVERY extent. Patches are freely available
wherever their authors put them up for download. Alan Cox
integrates several patches into his AC series of kernels, as well
as arca kernels being available and a number of others. Andre
Hedrick has IDE patches available, and many others have patches
available as well.
Some people take many of the patches that are out there and
integrate them into a big mother-patch. You can download these
and try them as well.
I believe Riley Williams, or someone on this list with a name
starting with "R" has collected the entire Linux kernel source
tarballs all into a huge CVS tree and made it available online,
and on CDR as well. You could likely easily integrate other
patches into this tree too.
>Another lesson from history is the gcc/egcs development.
I don't see how gcc stagnation and egcs takeover pertains to
Linux at all.
>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.
Open-sourcing? How much more "open source" can you GET? The
linux kernel is probably the largest open source project that has
ever existed with such magnitude, and open development. This
mailing list is proof of that. Every kernel is released for
everyone to view, as are the prereleases in between ALL kernel
versions such as 2.2.x-pre1, pre2, etc... In addition, most if
not all patches that are included in the pre patches, as well as
tonnes of others that don't get included for some reason or
another, are also posted to the list, and a lot of those are also
made available for download via web/ftp.
I can't see any reason why you think linux isn't as open
source as it gets - other than the possibility that you just have
not taken the time to open your eyes and research it thouroughly
before going off...
Another $0.02.
Linux IMHO _IS_ the true definition of open source.
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
Ya dee buckity, rum ting tee toooo, mi - mi - mi, yaaooooooo....
(King Otto)
-
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/

In reading Steve Dodd's post, among others, a few key realizations occurred,
for me.
1) The mailing list linux-kernel *is* the change repository.
This is precisely how comp.sources.minix worked, all those years ago: if you
followed the newsgroup you knew everything there was to know about Minix, if
you didn't you knew nothing.
2) Only patches to unstable kernels will ever be considered for inclusion in a
kernel.
Not unreasonable, when you think about it, but not obvious either, unless you
read this mailing list.
3) The patch submission process is ad-hoc and informal.
Or, perhaps, it seems that way to someone who's not actually primarily focused
on the kernel. Over time rules of thumb have arisen such as whom not to
flame, what format to submit patches in, which ideas are `hot' and which will
languish.
You can predict a lot from this and a few subsidiary observations.
First: only kernel-centric patches will flourish, because only people who
follow the group will be able to negotiate the caucus, and only people who are
primarily focused on the kernel will bother.
Second: any kernel functionality which forms a sufficiently large and modular
chunk will have to spin off and use its own resources, as has happened with MM
and with ISDN. The traffic flow in the main list will swamp anything that's
not primarily focused on the kernel.
Third: the kernel list won't ever see a real pressing need for a CVS because
they're comfortable with the list's use as a patch repository.
Colin.
> 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/

On Wed, Sep 15, 1999 at 09:44:52AM +1000, Colin McCormack wrote:
> 1) The mailing list linux-kernel *is* the change repository.
>
> This is precisely how comp.sources.minix worked, all those years ago: if you
> followed the newsgroup you knew everything there was to know about Minix, if
> you didn't you knew nothing.
I'd disagree. We have a load of stuff in linux/Documentation/*. What's there
is pretty good, the problem is the stuff that's missing. I'm sure patches from
you to add stuff to that directory would be welcomed.
> 2) Only patches to unstable kernels will ever be considered for inclusion in a
> kernel.
>
> Not unreasonable, when you think about it, but not obvious either, unless you
> read this mailing list.
Well, yes, pretty obvious to most people I think. I've actually dug up the
linux-kernel FAQ, and it does define what a 'production kernel' is. Of course,
if your patch fixes a bug in the stable kernel, then I'm sure it would be
considered.
> 3) The patch submission process is ad-hoc and informal.
>
> Or, perhaps, it seems that way to someone who's not actually primarily focused
> on the kernel. Over time rules of thumb have arisen such as whom not to
> flame, what format to submit patches in, which ideas are `hot' and which will
> languish.
Ish. The prefered format for patches is mentioned in the (ancient) copy of
the lkml FAQ I'm looking at. The "MAINTAINERS" file in the root of the source
tarball describes pretty accurately a good process for creating, testing and
submitting patches.
> First: only kernel-centric patches will flourish, because only people who
> follow the group will be able to negotiate the caucus, and only people who are
> primarily focused on the kernel will bother.
I'm not sure what you mean by "kernel-centric". This is the kernel mailing
list, of course patches are going to focused on the kernel, we don't do
anything else here..
> Second: any kernel functionality which forms a sufficiently large and modular
> chunk will have to spin off and use its own resources, as has happened with MM
> and with ISDN.
To a certain extent, yes, in as far as those areas create their own mailing
lists and web pages. Is that a problem?
> The traffic flow in the main list will swamp anything that's
> not primarily focused on the kernel.
Anything that's not focused on the kernel is off-topic. Hence the name of
the list..
> Third: the kernel list won't ever see a real pressing need for a CVS because
> they're comfortable with the list's use as a patch repository.
A lot of people use some sort of source control privately though. And Larry
McVoy has been working very hard to produce a distributed source control
system that meets Linus' requirements. Anybody's free to use CVS to keep
the kernel source code, and I believe DaveM and the Sparc people do so. Linus'
won't because he doesn't want to. I don't see anyone has the right to tell him
how he should manage his tree.
--
Horses are forbidden to eat fire hydrants in Marshalltown, Iowa.
-
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/

> On Wed, Sep 15, 1999 at 09:44:52AM +1000, Colin McCormack wrote:
>
>> 1) The mailing list linux-kernel *is* the change repository.
>>
>> This is precisely how comp.sources.minix worked, all those years ago: if
you
>> followed the newsgroup you knew everything there was to know about Minix,
if
>> you didn't you knew nothing.
>
> I'd disagree. We have a load of stuff in linux/Documentation/*. What's there
> is pretty good, the problem is the stuff that's missing. I'm sure patches from
> you to add stuff to that directory would be welcomed.
I'm thinking of a `what you really need to know to get a patch considered' web
page.
>>2) Only patches to unstable kernels will ever be considered for inclusion in
a
>> kernel.
>>
>> Not unreasonable, when you think about it, but not obvious either, unless
you
>> read this mailing list.
>
> Well, yes, pretty obvious to most people I think. I've actually dug up the
> linux-kernel FAQ, and it does define what a 'production kernel' is. Of course,
> if your patch fixes a bug in the stable kernel, then I'm sure it would be
> considered.
I wonder if my epckpt author knew it? Somehow I doubt it.
What we end up with is this: anyone who needs (as distinct from `wants', in a
linux-kernel mailing list way) to add functionality to the kernel would like
to add it to the stable kernel.
1) because they're doing something else that depends on the patch, and they
don't need extra worries from the (presumed) instability of the development
kernels.
2) because they'd like to be working with somewhat more stable versions of
internal data structures (to the extent they need to dick with them.)
3) because their consumers are likely to be running a stable kernel, that's
their target.
It's not at all immediately obvious to someone who wants to do something that,
perforce, relies upon kernel mods, that the development kernel is the place to
start looking.
Whether the requirement of patching the development kernel's a good or bad
thing, I have no opinion. I merely make the point that it's not clear to
someone who's only *secondarily* interested in patching the kernel, and
primarily interested in providing functionality which properly or necessarily
belongs in the kernel.
This conversation's cleared it up for me.
>> 3) The patch submission process is ad-hoc and informal.
>>
>> Or, perhaps, it seems that way to someone who's not actually primarily
focused
>> on the kernel. Over time rules of thumb have arisen such as whom not to
>> flame, what format to submit patches in, which ideas are `hot' and which
will
>> languish.
>
> Ish. The prefered format for patches is mentioned in the (ancient) copy of
> the lkml FAQ I'm looking at. The "MAINTAINERS" file in the root of the source
> tarball describes pretty accurately a good process for creating, testing and
> submitting patches.
I'll have a look.
>> First: only kernel-centric patches will flourish, because only people who
>> follow the group will be able to negotiate the caucus, and only people who
are
>> primarily focused on the kernel will bother.
>
>I'm not sure what you mean by "kernel-centric". This is the kernel mailing
>list, of course patches are going to focused on the kernel, we don't do
>anything else here..
I think I mean patches motivated by a desire to extend the kernel, or improve
the kernel for its own sake, rather than patches intended to add functionality
to userland for which kernel space mods is considered necessary.
I'm not speaking authoritatively in this, but it seems to me that e.g. GGI
were aiming to solve a user problem, and were rejected because they offended
some ethos in kernel-land. The frustration and bitterness arose, I would say,
because of a difference in the primacy of values. GGI: We want this
functionality, it must be in kernel space to work. Kernal: it makes the
kernel ugly and bloated, or vaporous, or not crispy enough, or whatever you
guys use as the unit of niceness.
As someone who doesn't admire monolithic kernel `crispiness', I'm pretty well
on the GGI guys' side, because the utility offered exceeds the (nominal)
disutility of code which doesn't conform to a standard I don't value.
My point is: there's useful userland functionality going begging because the
kernel group values it lower than some fad gadget tweak. If the userland
functionality makes a difference, that's a centrifugal force.
>> Second: any kernel functionality which forms a sufficiently large and
modular
>> chunk will have to spin off and use its own resources, as has happened with
MM
>> and with ISDN.
>
> To a certain extent, yes, in as far as those areas create their own mailing
> lists and web pages. Is that a problem?
It's only a problem when they try to synch the mods back in, apparently, or
when then claim they're doing their own QA and ask that it be valued.
>> The traffic flow in the main list will swamp anything that's
>> not primarily focused on the kernel.
>
> Anything that's not focused on the kernel is off-topic. Hence the name of
> the list..
I'll rephrase: anything not primarily motivated by a desire to hack the
kernel.
>>Third: the kernel list won't ever see a real pressing need for a CVS because
>>they're comfortable with the list's use as a patch repository.
>
> A lot of people use some sort of source control privately though. And Larry
> McVoy has been working very hard to produce a distributed source control
> system that meets Linus' requirements. Anybody's free to use CVS to keep
> the kernel source code, and I believe DaveM and the Sparc people do so.
Sure. It comes down to perceived cost/benefit, I guess. All strength to
Larry McVoy in his quest. It'd be very useful.
> Linus'
> won't because he doesn't want to. I don't see anyone has the right to tell him
> how he should manage his tree.
Wouldn't matter if they had the right. They don't have the ability. Which's
why I found the treatment of the ISDN people heavy handed, uncooperative,
peremptory, arrogant, unconstructive. (pick your adjective.)
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/

On 14-Sep-99 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.
Hm, it looks machine-dependent, incomplete, fragile and not ported to 2.3.
There's no way this is 2.2 material, and there's a fair amount of work before
its ready for the mainstream. Its not obvious that the author even wants it in
the mainstream kernel (which may be a huge liability for him, since it looks
like its part of a research project).
Anyway, since its currently a fairly self-contained patch, if you really need
it for 2.2 there shouldn't be a problem with applying it yourself?
J
-
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/

Colin McCormack wrote:
>
> What we end up with is this: anyone who needs (as distinct from `wants', in a
> linux-kernel mailing list way) to add functionality to the kernel would like
> to add it to the stable kernel.
>
<delurk>
There's nothing stopping you from adding that functionality to the kernel
_you_ use. That doesn't mean you should expect Linus to accept patches that
are relatively untested to the stable kernel. You can use the patch with
your stable kernel and at the same time port it to the latest development
kernel and hope it gets accepted in time for the next stable release.
It seems as if this is getting even easier now that people are working to
shorten the development cycle.
Kjartan Maraas
</delurk>
-
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/

On Wed, Sep 15, 1999 at 09:44:52AM +1000, Colin McCormack wrote:
> In reading Steve Dodd's post, among others, a few key realizations occurred,
> for me.
>
> 1) The mailing list linux-kernel *is* the change repository.
>
> This is precisely how comp.sources.minix worked, all those years ago: if you
> followed the newsgroup you knew everything there was to know about Minix, if
> you didn't you knew nothing.
Quelle suprise. If I want to know about 'Hamlet' then I have to read
'Hamlet'. If I want to know about the ongoing linux kernel
development, then I have to read the linux-kernel development list.
There are books, articles, commentaries in abundance about both
things, but there's no substitute for the real thing.

> 2) Only patches to unstable kernels will ever be considered for inclusion in a
> kernel.
>
> Not unreasonable, when you think about it, but not obvious either, unless you
> read this mailing list.
Also not true. Features go into unstable kernels, patches for
bugfixes can go against either kernel series. Its in the FAQ.

> 3) The patch submission process is ad-hoc and informal.
>
> Or, perhaps, it seems that way to someone who's not actually primarily focused
> on the kernel. Over time rules of thumb have arisen such as whom not to
> flame, what format to submit patches in, which ideas are `hot' and which will
> languish.
You really should try reading the FAQ before you post this kind of
stuff. The fact is, that it is documented and you just haven't
bothered to take the trouble to read it. "How to submit a patch" at
http://www.tux.org/lkml/#s4-1 might be a good place to start in this
instance. You could supplement that with a look through the mail list
archives.
>
> You can predict a lot from this and a few subsidiary observations.
>
> First: only kernel-centric patches will flourish, because only people who
> follow the group will be able to negotiate the caucus, and only people who are
> primarily focused on the kernel will bother.
Explain, breifly, what a non-kernel-centric patch to the linux kernel
might be.
Its also probably a good thing that only kernel-focussed people
contribute to the kernel. Kernel programming is a pretty tricky
business. If I'm flying, I'd rather have the plane serviced by
someone airplane-centric. If you want a reliable kernel, patches have
to be submitted by people who know what they're doing. Following the
kernel list is a good way to start to know and understand the kernel.
You also see what the really knowlegable guys have to say about
various things. This is useful to determine what kinds of things will
get accepted and so on.
> Second: any kernel functionality which forms a sufficiently large and modular
> chunk will have to spin off and use its own resources, as has happened with MM
> and with ISDN. The traffic flow in the main list will swamp anything that's
> not primarily focused on the kernel.
Hmm. A lot of these so-called spin-offs have spun off for a long
time. Furthermore, people regularly discuss memory management etc on
the main list. Lastly, these spinoffs have to feed something back to
Linus and/or Alan if they want it in the official kernel.
> Third: the kernel list won't ever see a real pressing need for a CVS because
> they're comfortable with the list's use as a patch repository.
CVS was tried, and proved unusable for Linus. IIRC he felt the deltas
became too large for him to personally check all the code, and it was
difficult to maintain quality. There was a pretty big falling out
over this issue. Part of the problem is that many teamworking tools
are built for use in small teams, and really don't scale to
contributions from thousands of developers very well. Larry Mc Voy is
working on a major new revision system called BitKeeper, which he has
tailored to Linus et al's preferences on the way. It is waiting in
the wings to be used.
The question about scalability of development tools is also why
patches have to be submitted in the right format and to the right
people. Recieving 1000's of emails every day makes Linus and Alan
pretty quick with the ol "delete" key. If they go away, their inboxes
get swamped. For these reasons they work on the assumption that
people will resend patches until they get included or discussed. The
FAQ (and many other things) more eloquently than I. Its URL is on the
bottom of every submission to the list.
Sean
-
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/

On Wed, 15 Sep 1999, Colin McCormack wrote:
> >>2) Only patches to unstable kernels will ever be considered for inclusion in
> >> a kernel.
> >>
> >> Not unreasonable, when you think about it, but not obvious either, unless
> >> you read this mailing list.
> >
> > Well, yes, pretty obvious to most people I think. I've actually dug up the
> > linux-kernel FAQ, and it does define what a 'production kernel' is. Of course,
> > if your patch fixes a bug in the stable kernel, then I'm sure it would be
> > considered.
>
> I wonder if my epckpt author knew it? Somehow I doubt it.
>
> What we end up with is this: anyone who needs (as distinct from `wants', in a
> linux-kernel mailing list way) to add functionality to the kernel would like
> to add it to the stable kernel.
[. snip list of reasons that people like to work against the stable kernel ]
So, in essence what you're saying is that you'd like (by proxy - I note
that you're not offering to implement anything) to work against a kernel
which isn't changing much.
For this to happen, you have to assume that nobody else is working on the
stable kernel. Exactly one patch, then, can be developed against the
stable kernel. Why the hell should it be yours?
And then, once your checkpointing patch has been folded into 2.even, you
have to get it put into 2.odd as well, or it disappears under the next
stable kernel.
> Whether the requirement of patching the development kernel's a good or
> bad thing, I have no opinion. I merely make the point that it's not
> clear to someone who's only *secondarily* interested in patching the
> kernel, and primarily interested in providing functionality which
> properly or necessarily belongs in the kernel.
Firstly, get it into an acceptable form. If the author isn't prepared to
do it, offer him money, do it yourself, or convince somebody else to do
it (offer me money, for example).
You can't get away from this. Why should Linus/Alan/other kernel patch
hoovers have to merge an old patch without the help of its author?
Secondly, since it does touch on core code and functionality, collect
evidence that it works. Get the maintainers of the subsystems which it
affects to OK it.
Third, at an appropriate time (ie. not during feature/code freeze) offer
it up to Linus. Again, for a non-trivial patch which affects core
functionality, show evidence (or at least claim) that it will be
maintained and fixed in a responsible and timely manner.
There's nothing particularly complicated about this. IMO, only someone
who has never worked on a non-trivial piece of software could think that
this process is opaque.
Matthew.
-
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/

Hi!
> 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.
I know mj has checkpoint/restart utility _working_ in user
space. Little bit hacky. What exactly can not be done userspace?
Pavel
--
I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
-
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/

> On Wed, 15 Sep 1999, Colin McCormack wrote:
>> What we end up with is this: anyone who needs (as distinct from `wants',
>> in a linux-kernel mailing list way) to add functionality to the kernel
>> would like to add it to the stable kernel.
> [. snip list of reasons that people like to work against the stable kernel ]
> So, in essence what you're saying is that you'd like (by proxy - I note
> that you're not offering to implement anything) to work against a kernel
> which isn't changing much.
Yes, in effect I think I'm saying unit testing is easier against a stable
backdrop.
I'm not offering to implement anything, correct. The code in question's been
implemented. I leave wheel reinvention to others.
> For this to happen, you have to assume that nobody else is working on the
> stable kernel. Exactly one patch, then, can be developed against the
> stable kernel. Why the hell should it be yours?
This really doesn't follow. Not all modifications are global in their impact,
and therefore many patches could coexist simultaneously without interference.
Additionally, if the kernel version control tools extended beyond majordomo,
sendmail and an editor, it would even be conceivable for people to check out
those branches they decided were suitable for their application.
> And then, once your checkpointing patch has been folded into 2.even, you
> have to get it put into 2.odd as well, or it disappears under the next
> stable kernel.
Or you regenerate it for the next 2.even, as this may be less effort.
>> Whether the requirement of patching the development kernel's a good or
>> bad thing, I have no opinion. I merely make the point that it's not
>> clear to someone who's only *secondarily* interested in patching the
>> kernel, and primarily interested in providing functionality which
>> properly or necessarily belongs in the kernel.
>
> Firstly, get it into an acceptable form. If the author isn't prepared to
> do it, offer him money, do it yourself, or convince somebody else to do
> it (offer me money, for example).
What's acceptable is purely subjective. Another good reason for a
post-distribution distribution. Many of us do it anyway, for significant and
useful functionality which hasn't found its way through the `input filtering'.
> You can't get away from this. Why should Linus/Alan/other kernel patch
> hoovers have to merge an old patch without the help of its author?
That's not what's being suggested. The question posed was more like: why are
authors expected to operate with no feedback in generating new patches.
> Secondly, since it does touch on core code and functionality, collect
> evidence that it works. Get the maintainers of the subsystems which it
> affects to OK it.
Forget it. There's a point beyond which it's not worth arguing, but easier to
get off and do it.
> Third, at an appropriate time (ie. not during feature/code freeze) offer
> it up to Linus. Again, for a non-trivial patch which affects core
> functionality, show evidence (or at least claim) that it will be
> maintained and fixed in a responsible and timely manner.
If you took the time to read the posts in this thread, you'd see that the
patch has apparently been `offered up to Linus' on several occasions, without
what was apparently effective feedback.
At the moment it seems to me that people just abandon the process in despair.
If nothing else, my part in this conversation is to suggest that a
non-despairing alternative might be needed, possible, and even feasible.
> There's nothing particularly complicated about this. IMO, only someone
> who has never worked on a non-trivial piece of software could think that
> this process is opaque.
Of course the process is opaque, in parts. Its opacity has nothing to do with its complexity, but with some subjective and non-transparent aspects of the process.
I'll give you an example: GGI. Nobody seems to know quite what happened to it. Not even people arguing on your side can articulate the reasons clearly. That's reasonable evidence of non-transparency.
The author of the piece of code I am interested in has no idea why the code didn't get incorporated. That's not a transparent process. If, in fact, it's because the patches were against 2.even, then a simple email to that effect may have saved him time, and may have given us useful functionality.
I asked a simple question in my initial post: `Is there a good reason, or indeed any reason, why epckpt isn't in the kernel right now?'
I still haven't got a clear answer to it. I don't know, you don't know, Alan Cox doesn't say (who knows if he knows, or ever knew) ... nobody knows. It's not a transparent process.
At least we can be clear about *that*.
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/

Date: Wed, 15 Sep 1999 21:52:52 +1000
From: Colin McCormack <colin@field.medicine.adelaide.edu.au>
What's acceptable is purely subjective. Another good reason for a
post-distribution distribution. Many of us do it anyway, for
significant and useful functionality which hasn't found its way
through the `input filtering'.
Well, that's your (and each patch author's) choice. You can choose not
to submit it to Linus and through the kernel modification process, and
simply integrate the patch after each stable release. However, this
takes time, and effort, since the kernel is changing and improving.
The avoidance of this effort, plus the altruistic desire to get the
improvement used by a larger number of people, is what encourages people
to do the extra work to get the patch into the development kernel.
I think one of the things which you don't appreciate that a lot of what
the input filtering is for is to get rid of bogus patches. Sturgeon's
law of 99% of what's out there is crap really applies here. Yes, I'm
sure *you* think your particular patch you're championing is pure gold,
and everything else is pure dross --- but that's what everybody else
thinks, too.
If it weren't for the input filtering, we would end up with something
like NT/Windows 2000 --- a huge, bloated kernel, that blue screens
constantly.
> You can't get away from this. Why should Linus/Alan/other kernel patch
> hoovers have to merge an old patch without the help of its author?
That's not what's being suggested. The question posed was more like:
why are authors expected to operate with no feedback in generating
new patches.
If you wait until you have a huge monolithic patch, and then ask for
feedback, you're already too late. What you should do is post your
design to the linux-kernel list first, and solicit input. Once people
are generally agreed that you have a good design, *then* you implement
it, preferably in stages and with close contact with the maintainers of
the subsystems you are affecting (if your pet change requires touching
large number of other people's code).
If you post a design to the linux-kernel list, you will generally get
feedback.
I'll give you an example: GGI. Nobody seems to know quite what
happened to it. Not even people arguing on your side can articulate
the reasons clearly. That's reasonable evidence of non-transparency.
The original design had far too much functionality stuffed into the
kernel, and the folks trying to implement were told that. But instead
of working with folks, they were overly antagonistic, and as a result
they couldn't present their ideas well. Over time, their design
changed, and more stuff was moved out of the kernel compared to their
original design, but I never heard anyone say ("you were right, and
we've made the following changes in response to your constructive
criticism").
In the end, the fbcon patches did get accepted into the kernel, and
implemented a lot of what the kernel pieces of GGI was supposed to do.
The difference is that the fbcon people were willing to work within the
system, and the GGI folks weren't. Being an Angry Young Man thrusting
your fist into the air isn't going to impress many people in this
community.
The author of the piece of code I am interested in has no idea why
the code didn't get incorporated. That's not a transparent process.
If you're not willing to learn about the process, or work within the
system, I have news for you --- no system is transparent. There are
books written about the Linux kernel, there are FAQ's, there are web
pages. If you don't like any of them, you're free to write down and
document the process better. If you're not quite so arrogrant and
abrasive, people might even help you.
I asked a simple question in my initial post: `Is there a good
reason, or indeed any reason, why epckpt isn't in the kernel right
now?'
I think it's fairly simple. Both the author of epckpt and you don't
seem to have any clue about how the Linux kernel development process
works, and didn't submit it to the 2.3 kernel before the feature
freeze. New features aren't as a rule accepted into stable kernel
series. (That rule has been bent before, and usually it's universally
acknowledged that doing so was a serious mistake.)
Just as you can't blame the C language if you can't be bothered to learn
about C before writing a program which then is crap, you can't blame the
linux kernel development process if you can't be bothered to learn about
it before trying to get a patch submitted to it. And you certainly
won't get any sympathy if you can't be bothered to learn about it before
starting to flame about it.
- Ted
-
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/

On Wed, 15 Sep 1999, Colin McCormack wrote:
> > There's nothing particularly complicated about this. IMO, only someone
> > who has never worked on a non-trivial piece of software could think that
> > this process is opaque.
>
> Of course the process is opaque, in parts. Its opacity has nothing to
> do with its complexity, but with some subjective and non-transparent
> aspects of the process.
>
> I'll give you an example: GGI.
Fine, we'll take your example. Apologies if this looks like I'm dis'ing
or misrepresenting the GGI people.
> Nobody seems to know quite what happened to it.
Unless something has changed since I last looked at GGI a couple of months
back, they are not claiming that their code is ready for kernel inclusion.
> Not even people arguing on your side can articulate the reasons
> clearly.
Here's a selection:
* they never produced a useful, stable kernel addition
* (to the best of my knowledge) they never submitted complete patches to
Linus
* they took so long in doing this, that a bunch of other guys beat them
to it
* their sources are packaged in such a way that I need to patch a
non-current kernel, _and_ fight their quirky build system
> That's reasonable evidence of non-transparency.
Maybe on Monday you had a good reason for claiming non-transparency, but
the very first response to your post was from Alan Cox, who explained
exactly what to do to get the patch integrated.
> I asked a simple question in my initial post: `Is there a good reason,
> or indeed any reason, why epckpt isn't in the kernel right now?'
OK, I'll bite. "Probably."
It "probably" comitted one or more of the following sins:
a) was formatted in an ugly manner
b) was encoded inconveniently
c) was submitted against a stable branch, or during a feature or code
freeze
d) was submitted as a patch against an obsolete kernel and didn't merge
trivially with the current one
e) affects core code (and thus potentially both performance and
reliability) and
+ made it look ugly
+ was not able to be configured out
+ was a portability disaster
f) looked like crappy code
g) looked hacky
h) was not considered a useful, desirable or worthwhile feature
i) was not submitted at all
(I just need one more for a full 10 Commandments)
From my brief inspection of the 2.2.1 release, I suspect it to be guilty
of b,c,e and maybe even d. It probably didn't do a and i. The rest (f,
g and h) I don't know/haven't read enough to comment on, but nobody who
has been following Linux kernel development would claim that it looked in
a worthwhile state for Linus' approval if it violated nearly half of
these.
> I still haven't got a clear answer to it. I don't know, you don't
> know, Alan Cox doesn't say (who knows if he knows, or ever knew) ...
> nobody knows. It's not a transparent process.
The development of epckpt is rather opaque to us. Most of us haven't used
it, many of us haven't even heard of it. Why should Alan throw a few
hundred k of new code into a stable branch when the maintainer won't even
provide a patch let alone one against a stable kernel?
If "edpin" won't merge Linus' patches, why should Linus merge his?
Matthew.
-
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/

On Wed, 15 Sep 1999, Colin McCormack wrote:
> On Wed, 15 Sep 1999, Matthew Kirkwood wrote:
> > On Wed, 15 Sep 1999, Colin McCormack wrote:
> >> What we end up with is this: anyone who needs (as distinct from
`wants',
> >> in a linux-kernel mailing list way) to add functionality to the
kernel
> >> would like to add it to the stable kernel.
> > [. snip list of reasons that people like to work against the stable
kernel ]
> > So, in essence what you're saying is that you'd like (by proxy - I
note
> > that you're not offering to implement anything) to work against a
kernel
> > which isn't changing much.
> Yes, in effect I think I'm saying unit testing is easier against a
stable
> backdrop.
There is no reason why one cannot do initial development against a stable
kernel. However, once the patch works to the developer's satisfaction, it
is incumbent upon him to port it to the development series if patches
to it are being accepted or to wait for the next one.
For example, if a patch for a new or enhanced feature were developed
against 2.2.0 through 2.2.7, it would be necessary to wait for the
release of 2.2.8/2.3.1 so that the patch could be submitted against 2.3.1.
If the patch were developed against 2.2.8 through 2.2.11, it should have
been ported to 2.3.x for submission. With 2.2.12, it is now too late, as
Linus has declared a (long expected and arguably overdue) feature freeze
with 2.3.18, so any new features must wait for 2.5.1. So the right thing
to do with a feature patch such as the one you are advocating is to port
it to 2.3.18 and maintain it until 2.5.1 is released. Then submit it. In
the meantime, see if the maintainer of the relevent section of the kernel
will provide you feedback on it. Just don't expect it to be accepted until
2.5.1.
Of course, none of the above applies to bug fixes.
M Carling
-
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/

In article <linux.kernel.199909151240.IAA04464@tsx-prime.mit.edu>,
Theodore Y. Ts'o <tytso@mit.edu> wrote:
>If it weren't for the input filtering, we would end up with something
>like NT/Windows 2000 --- a huge, bloated kernel, that blue screens
>constantly.
Well, as someone who has to administer a whole bunch of NT machines,
I regret to inform you that NT does _not_ bluescreen constantly at
either of the sites I administer.
I wish it did, for then I could replace it with Linux or xBSD, and
make the users use StarOffice instead of MS-Office.
Is the NT kernel that much larger than Linux? Sure, it takes three
disks to bootstrap it, but a large part of that is drivers and the
stage-1 installer, which is, in my experience, the thing that bloats
up a Linux bootstrap to the point where you either have to use a
compressed root filesystem or (shudder) multiple floppies to
bootstrap.
____
david parsons \bi/ Certainly if I used every ethernet, SCSI, and CD-rom
\/ driver for the bootstrap I'd be pushing two (compressed)
loppies instead of one.
-
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/

> On Wed, 15 Sep 1999, Colin McCormack wrote:
> > On Wed, 15 Sep 1999, Matthew Kirkwood wrote:
> > > On Wed, 15 Sep 1999, Colin McCormack wrote:
> > >> What we end up with is this: anyone who needs (as distinct from
> `wants',
> > >> in a linux-kernel mailing list way) to add functionality to the
> kernel
> > >> would like to add it to the stable kernel.
> > > [. snip list of reasons that people like to work against the stable
> kernel ]
>
> > > So, in essence what you're saying is that you'd like (by proxy - I
> note
> > > that you're not offering to implement anything) to work against a
> kernel
> > > which isn't changing much.
>
> > Yes, in effect I think I'm saying unit testing is easier against a
> stable
> > backdrop.
>
> There is no reason why one cannot do initial development against a stable
> kernel. However, once the patch works to the developer's satisfaction, it
> is incumbent upon him to port it to the development series if patches
> to it are being accepted or to wait for the next one.
>
> For example, if a patch for a new or enhanced feature were developed
> against 2.2.0 through 2.2.7, it would be necessary to wait for the
> release of 2.2.8/2.3.1 so that the patch could be submitted against 2.3.1.
> If the patch were developed against 2.2.8 through 2.2.11, it should have
> been ported to 2.3.x for submission. With 2.2.12, it is now too late, as
> Linus has declared a (long expected and arguably overdue) feature freeze
> with 2.3.18, so any new features must wait for 2.5.1. So the right thing
> to do with a feature patch such as the one you are advocating is to port
> it to 2.3.18 and maintain it until 2.5.1 is released. Then submit it. In
> the meantime, see if the maintainer of the relevent section of the kernel
> will provide you feedback on it. Just don't expect it to be accepted until
> 2.5.1.
It is important to understand _WHY_ a stable kernel is _always_ under feature
freeze. From his previous posts, I don't believe Colin understands this. The
reason that a development kernel is often unstable is that there are no
features going into it. Stable kernels are stable because there are no new
features going in.
New features add risk. Bug fixes decrease risk. It is untenable to say that
we should be increasing risk on a stable kernel. Thus it is untenable to say
that we should be adding features to stable kernels.
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/

<pkobly@calgary.crosswinds.net> said:
[...]
> New features add risk. Bug fixes decrease risk. It is untenable to say
> that we should be increasing risk on a stable kernel. Thus it is
> untenable to say that we should be adding features to stable kernels.
No, we should keep the kernel stable just so this character can get _his_
favorite patch in. That this means that development stands still isn't an
issue, as he sees this as a way to _speed up_ development. Plus splinter
the develoment into a thousand branches, so everybody has his own, and get
Linus to bless some of them. But blessing only some, not all, is probably
not transparent enough, so... And the head hackers also have to do the work
to join all these gratuituous branches, and go hunting for worthwhile
pieces to integrate!
Add the arrogance to talk about "accountability", as if the Linux community
at large owes him something.
I think this is just a very well done troll.
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616
-
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/

On Wed, 15 Sep 1999 pkobly@calgary.crosswinds.net wrote:
> New features add risk. Bug fixes decrease risk.
To be pedantic bug fixes *increase* risk because they might
introduce new bugs. However they do, or should, *reduce*
the number of known failure modes.
Mike
--
Failure isn't an option - it's built in to Windows
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 2 Markham Mews, Broad Street | Telephone: +44 118 989 0403 |
| Wokingham ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
-
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/

On Wed, 15 Sep 1999, David Parsons wrote:
> > So to get back to the MAIN topic, we DON'T want Linux ever being developed like
> > an MS product where with each service pack comes New and Improved bugs (and
> > security holes).
>
> You might as well give up on Linux now, because we already have
> patches going out that introduce new and improved bugs. That's
> life, and you're going to have to deal with it.
I think what he means is: with NT, you get a service pack once every 6
months or so, that attempts to both introduce new features and fix bugs.
Which at that latter it fails at.
With Linux, you get new features in the development kernels, then you get
a feature freeze, and finally you get a code freeze where all of the bugs
are ironed out. And if even that is not good enough for you, you can al-
ways use the stable series where even more bugs get fixed.
If you don't want new features, but you want stability instead, stick with
the stable kernels.
Chipzz AKA
Jan Van Buggenhout
--------------------------------------------------------------------------
UNIX isn't dead - It just smells funny
Xp@Ace.ULYSSIS.Student.KULeuven.Ac.Be
--------------------------------------------------------------------------
-
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/

On Thu, Sep 16, 1999 at 10:46:10AM +0200, Chipzz wrote:
> On Wed, 15 Sep 1999, David Parsons wrote:
> > You might as well give up on Linux now, because we already have
> > patches going out that introduce new and improved bugs. That's
> > life, and you're going to have to deal with it.
[snip]
> With Linux, you get new features in the development kernels, then you get
> a feature freeze, and finally you get a code freeze where all of the bugs
> are ironed out. And if even that is not good enough for you, you can al-
> ways use the stable series where even more bugs get fixed.
Yes, 'stable' kernels aren't perhaps always as stable as they might be, but
this seems to be pretty rare.
The big plus point is that you have the source kicking around. So if you decide
that 1.2.x was your ideal kernel, and you don't want any of the features that
later versions add, you can continue to maintain it, backport drivers, fix
bugs, etc.
--
"Friends help you move. Real friends help you move bodies."
-
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/

> I know mj has checkpoint/restart utility _working_ in user space.
One day I wrote ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/linux/freezer-0.0-pre2.tar.gz
which is a simple checkpoint/restart utility completely in userspace, but it
lacks several important features like saving/restoring of FPU registers
and signal handler.
Some weeks later Ondrej Filip <feela@ipex.cz> has filled in the missing
bits. His version is available at ftp://ftp.ipex.cz/pub/local/feela/src/freezer.tgz.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"First law of socio-genetics: Celibacy is not hereditary."
-
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/