In article <[EMAIL PROTECTED]>,
Eli Carter <[EMAIL PROTECTED]> wrote:
>Mitchell Blank Jr wrote:
>> Daniel Quinlan wrote:
>> > "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
>> > The web page will list valid version strings.
>> Ideally this should
In article <[EMAIL PROTECTED]>,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>When I sent Linus ten or twenty patches, that means I'm filling in ten
>to twenty e-mail templates, yum :)
Presumably that part of the process can be automated:
$ cd /usr/src/linux
$ ./scripts/submit-patch /tmp/patch-1
On Fri, 15 Sep 2000, Russell King wrote:
> Mitchell Blank Jr writes:
> > If they're able to create a patch, hopefully they'd be able to fill in
> > a simple email template (and I've seen some pretty dim folks manage to
> > register domains with InterNIC, so email templates aren't that hard :-)
>
> "cort" == Cort Dougan <[EMAIL PROTECTED]> writes:
Hi
cort> } Now multiply my experience by the several hundred kernel developers out
^
cort> } there, and you can easily see how the kernel development community could
Russell King writes:
> Richard Gooch writes:
> > in a patch, then an email is sent to stating that a patch with
> > ID has been applied. This would allow for automatic notification
> > of the patch author when their patch has been applied. All that is
> > needed is for Linus to update his patch
Russell King writes:
> Mitchell Blank Jr writes:
> > If they're able to create a patch, hopefully they'd be able to fill in
> > a simple email template (and I've seen some pretty dim folks manage to
> > register domains with InterNIC, so email templates aren't that hard :-)
> >
> > We could even
Mitchell Blank Jr writes:
> If they're able to create a patch, hopefully they'd be able to fill in
> a simple email template (and I've seen some pretty dim folks manage to
> register domains with InterNIC, so email templates aren't that hard :-)
>
> We could even have a simple web page where you
Richard Gooch writes:
> in a patch, then an email is sent to stating that a patch with
> ID has been applied. This would allow for automatic notification
> of the patch author when their patch has been applied. All that is
> needed is for Linus to update his patch binary.
Why would the patch
Russell King writes:
Mitchell Blank Jr writes:
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage to
register domains with InterNIC, so email templates aren't that hard :-)
We could even have a
"cort" == Cort Dougan [EMAIL PROTECTED] writes:
Hi
cort } Now multiply my experience by the several hundred kernel developers out
^
cort } there, and you can easily see how the kernel development community could
cort }
In article [EMAIL PROTECTED],
Jeff Garzik [EMAIL PROTECTED] wrote:
When I sent Linus ten or twenty patches, that means I'm filling in ten
to twenty e-mail templates, yum :)
Presumably that part of the process can be automated:
$ cd /usr/src/linux
$ ./scripts/submit-patch /tmp/patch-1
In article [EMAIL PROTECTED],
Eli Carter [EMAIL PROTECTED] wrote:
Mitchell Blank Jr wrote:
Daniel Quinlan wrote:
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
Ideally this should be overridable
I trimmed the CC list a bit, it was getting large. I just left
linux-kernel since I believe everyone is on that list.
} It's this critical mass which is missing; otherwise, my custom scripts
} which use RCS and where I only check in those files which I modify are
} quite frankly, more
Date: Thu, 14 Sep 2000 15:45:24 -0700
From: Larry McVoy <[EMAIL PROTECTED]>
I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work
Date: Thu, 14 Sep 2000 15:28:48 -0700 (PDT)
From: <[EMAIL PROTECTED]>
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
> "Fixes" - followed by one or more bug numbers (tracked by tytso
> for now). For example, "T0001" might be tytso bug
> number
>Isn't this "new" patch maintenance system much like bitkeeper?
>
> Heh. I'm surprised Larry hasn't jumped into this discussion by now.
Hi, here I am. I hadn't resubscribed to the list after it switched from
rutgers. Sheesh, I leave you guys alone for five minutes and you go off
and
On Thu, Sep 14, 2000 at 11:12:28PM +0100, Alan Cox wrote:
> > protecting your rights. Did you know that if BitMover goes out of
> > business BK becomes GPLed? Did you know if we stop maintaining the
> > openlogging servers, BK becomes GPLed? Did you know that single user
>
> Did you remember
} Second, I doubt very much that Linus would require BitKeeper only. It's
} trivial for BK to export patches which are bit for bit identical to the
} traditional "diff -Nur" output. BKweb does that on the fly, go look at
}
} http://www.bitmover.com:[EMAIL PROTECTED]
In fact, we do
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
> "Fixes" - followed by one or more bug numbers (tracked by tytso
> for now). For example, "T0001" might be tytso bug
> number 0001.
bugzilla. or something else automated to track bugs and assign numbers.
-
To
> protecting your rights. Did you know that if BitMover goes out of
> business BK becomes GPLed? Did you know if we stop maintaining the
> openlogging servers, BK becomes GPLed? Did you know that single user
Did you remember that I'm the person who went through the license and did
things like
> > that bitkeeper has. The problem with bitkeeper is that it's **so**
> > different from CVS that it takes time to learn --- I spent a day getting
> > my head wrapped around it, and I still wouldn't call myself an expert;
>
> Another problem is that bitkeeper has not been through a security
> > Another problem is that bitkeeper has not been through a security audit.
>
> What sort of audit did you have in mind? It has been through several
> internal audits, so I'm not sure why you are claiming that it hasn't.
One by people other than the authors
> First of all, that "Linux
> On Wed, Sep 13, 2000 at 11:50:58PM +0100, Alan Cox wrote:
> > Another problem is that bitkeeper has not been through a security audit.
>
> Maybe, but i like the fact that BitKeeper uses ssh by default for
> transmitting data.
That isnt the problem. Its what is in the source data you
On Wed, Sep 13, 2000 at 11:50:58PM +0100, Alan Cox wrote:
> Another problem is that bitkeeper has not been through a security audit.
Maybe, but i like the fact that BitKeeper uses ssh by default for
transmitting data.
--
Nathan Paul Simons, Programmer for FSMLabs
> tracking/fixing. The big issue really is the drivers, and it's simply
> because several of the maintainers of drivers are lackadasical about
> doing their job and chasing people down when bug reports are submitted
> against them.
Most drivers dont have formal maintainers people fix them when
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
"Fixes" - followed by one or more bug numbers (tracked by tytso
for now). For example, "T0001" might be tytso bug
number 0001.
bugzilla. or something else automated to track bugs and assign numbers.
-
To
Date: Thu, 14 Sep 2000 15:28:48 -0700 (PDT)
From: [EMAIL PROTECTED]
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
"Fixes" - followed by one or more bug numbers (tracked by tytso
for now). For example, "T0001" might be tytso bug
number
I trimmed the CC list a bit, it was getting large. I just left
linux-kernel since I believe everyone is on that list.
} It's this critical mass which is missing; otherwise, my custom scripts
} which use RCS and where I only check in those files which I modify are
} quite frankly, more
tracking/fixing. The big issue really is the drivers, and it's simply
because several of the maintainers of drivers are lackadasical about
doing their job and chasing people down when bug reports are submitted
against them.
Most drivers dont have formal maintainers people fix them when they
On Wed, Sep 13, 2000 at 11:50:58PM +0100, Alan Cox wrote:
Another problem is that bitkeeper has not been through a security audit.
Maybe, but i like the fact that BitKeeper uses ssh by default for
transmitting data.
That isnt the problem. Its what is in the source data you have to
On Wed, Sep 13, 2000 at 11:50:58PM +0100, Alan Cox wrote:
Another problem is that bitkeeper has not been through a security audit.
Maybe, but i like the fact that BitKeeper uses ssh by default for
transmitting data.
--
Nathan Paul Simons, Programmer for FSMLabs
http://www.fsmlabs.com/
that bitkeeper has. The problem with bitkeeper is that it's **so**
different from CVS that it takes time to learn --- I spent a day getting
my head wrapped around it, and I still wouldn't call myself an expert;
Another problem is that bitkeeper has not been through a security audit.
Another problem is that bitkeeper has not been through a security audit.
What sort of audit did you have in mind? It has been through several
internal audits, so I'm not sure why you are claiming that it hasn't.
One by people other than the authors
First of all, that "Linux ceases to
Date: Thu, 14 Sep 2000 15:45:24 -0700
From: Larry McVoy [EMAIL PROTECTED]
I'm going to have to respectfully disagree. First of all, having a flag
day where everyone switches to BK just isn't a realistic expectation,
even if the license wasn't an issue. Things just don't work
protecting your rights. Did you know that if BitMover goes out of
business BK becomes GPLed? Did you know if we stop maintaining the
openlogging servers, BK becomes GPLed? Did you know that single user
Did you remember that I'm the person who went through the license and did
things like
} Second, I doubt very much that Linus would require BitKeeper only. It's
} trivial for BK to export patches which are bit for bit identical to the
} traditional "diff -Nur" output. BKweb does that on the fly, go look at
}
} http://www.bitmover.com:[EMAIL PROTECTED]
In fact, we do
On Thu, Sep 14, 2000 at 11:12:28PM +0100, Alan Cox wrote:
protecting your rights. Did you know that if BitMover goes out of
business BK becomes GPLed? Did you know if we stop maintaining the
openlogging servers, BK becomes GPLed? Did you know that single user
Did you remember that I'm
Date: Wed, 13 Sep 2000 10:32:03 -0400
From: "Theodore Y. Ts'o" <[EMAIL PROTECTED]>
In the long run, it will make your life easier, to the extent that
having an up-to-date bug list is easier, and because then I won't
have to continually pester people about whether certain bugs have
> that bitkeeper has. The problem with bitkeeper is that it's **so**
> different from CVS that it takes time to learn --- I spent a day getting
> my head wrapped around it, and I still wouldn't call myself an expert;
Another problem is that bitkeeper has not been through a security audit.
>
Mitchell Blank Jr wrote:
>
> Alan Cox wrote:
> > Humans will generally get a weird report from sending Linus a message wonder
> > what all this field stuff is and mail someone else instead.
>
> If they're able to create a patch, hopefully they'd be able to fill in
> a simple email template (and
From: "Dunlap, Randy" <[EMAIL PROTECTED]>
Date: Wed, 13 Sep 2000 09:17:55 -0700
I appreciate Alan and you doing the kernel Status/TODO lists,
but I think that you ought to simplify it for yourself at
least (not that this would help Linus) by having maintainers
do it instead of
-BEGIN PGP SIGNED MESSAGE-
I had the same thought.
have you considered doing this as a front-end for bitkeeper?
something along the lines of it will accept bitkeeper changesets, or if it
receives a patch as you describe (and it applies cleanly) it creates a
bitkeeper changeset for it.
Date: Wed, 13 Sep 2000 17:14:57 +0200 (MEST)
From: [EMAIL PROTECTED] (Rogier Wolff)
Today we fixed a problem in a driver we maintain here. We should've
gone ahead and generate the patch and queued it for Linus. However,
in reality we'd like the complaining customer to test the
On Wed Sep 13, 2000 at 02:49:01AM -0700, David S. Miller wrote:
>From: Daniel Quinlan <[EMAIL PROTECTED]>
>Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT)
>
>> Very simply, (drumroll please) I want to run diff. :-)
>
>I think this is an orthogonal problem. Realtime diffs are good
Theodore Y. Ts'o writes:
>Date: Wed, 13 Sep 2000 03:30:39 -0700
>From: "David S. Miller" <[EMAIL PROTECTED]>
>
> From: Daniel Quinlan <[EMAIL PROTECTED]>
> Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
>
> How exactly does a system to tracking patches and
> From: Theodore Y. Ts'o [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 13, 2000 7:32 AM
>
>
> How can we simplify things? Part of the design of this new
> proposal was
> to change as little as possible from the existing setup
> (people's habits
> are hard to change), and yet to
Date:Wed, 13 Sep 2000 12:56:22 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> suggest a unique identifier for your patch? Humans are usually better
> at picking sensible names than a machine, and in discussions, it is
> better to refer to 'ide-foobar-fix3' than KP7562
Date:Wed, 13 Sep 2000 02:27:07 -0700
From: "David S. Miller" <[EMAIL PROTECTED]>
rsync [EMAIL PROTECTED]:/home/torvalds/src/linux \
ftp.kernel.org:/pub/linux/kernel/LIVE/linux
would be the real helper for people like me whose only real issue
now is bothering
Hi !
This is a very interesting idea, but I think we will
quickly need two more types of information from the
patch sender :
- type of patch (fix, new feature, performance boost,
cleanup ...)
- the degree of reliability known to the sender :
- some patches are hand-coded (often proposals
Date: Wed, 13 Sep 2000 15:29:04 +0100 (BST)
From: Alan Cox <[EMAIL PROTECTED]>
> Like any tracking system, the suceess or failure of its rollout depends
> completely on whether Linus et al will be steadfast enough to refuse
> to look at any patch that hasn't gone through the
Theodore Y. Ts'o wrote:
> How can we simplify things? Part of the design of this new proposal was
> to change as little as possible from the existing setup (people's habits
> are hard to change), and yet to make my life and Linus's life much
> easier. In the long run, it will make your life
> Like any tracking system, the suceess or failure of its rollout depends
> completely on whether Linus et al will be steadfast enough to refuse
> to look at any patch that hasn't gone through the system.
If that attitude is taken the large numbers of patches will never make 2.4
proper.
Alan
-
Mitchell Blank Jr wrote:
>
> Daniel Quinlan wrote:
> > "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> > The web page will list valid version strings.
>
> Ideally this should be overridable for patches marked experimental, since
> they might be
Date:Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" <[EMAIL PROTECTED]>
From: Daniel Quinlan <[EMAIL PROTECTED]>
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> Alexander Viro wrote:
> > BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
> > " will be cheerfully flushed down the toilet here,
> > no matter what system of dependencies is going to be in place.
>
> Yes, for the stuff
Alexander Viro wrote:
> BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
> " will be cheerfully flushed down the toilet here,
> no matter what system of dependencies is going to be in place.
Yes, for the stuff discussed on lkml patch dependencies should be
pretty minimal.
Alan Cox wrote:
> Humans will generally get a weird report from sending Linus a message wonder
> what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage
On Wed, 13 Sep 2000, Alan Cox wrote:
> Also the requires stuff isnt going to be easy because you can't tell who
> beat you to a patch and your patch _might_ still apply with wrong results so
> that can't be totally automated either.
BTW, any bug reports starting with "kernel is x.y.z +
Hi Dan,
nice proposal.
One comment:
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
>Linus wants the body of patches to be in text format and not
>MIME-encoded or uuencoded.
[...]
> Future features?
>
> - PGP signing of patches
> - conversion of uuencoded patches to
> suggest a unique identifier for your patch? Humans are usually better
> at picking sensible names than a machine, and in discussions, it is
> better to refer to 'ide-foobar-fix3' than KP7562 even if the latter is
> better for machines. It also makes the Requires: header easier to
>
> Here is a proposal to improve the kernel development process. It was
> co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and
> myself. We are posting the proposal here for public review and
> comment. Seb is the guy writing on the software; he's nearly done the
> initial
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
> Proposal:
>
> 1. Developers submit all Linux kernel patches to [EMAIL PROTECTED]
>(not in place yet, so don't start sending patches).
@vger.kernel.org
> 2. Each patch will conform to a standardized, but simple, text
From: Daniel Quinlan <[EMAIL PROTECTED]>
Date:Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping Linus and Ted) not help developers?
It has the potential to make more work for those of us who do our
Daniel Quinlan wrote:
> "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some modified kernel. Of course you
David S. Miller writes:
> Ok, so lets be clear.
>
> Who is this facility really meant for? Linus (to decrease his
> workload), Ted (to assist him in keeping the todo/bug lists uptodate),
> or developers (who cares :-)?
>
> From the description, my take was that this thing is meant to help all
From: Daniel Quinlan <[EMAIL PROTECTED]>
Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT)
> Very simply, (drumroll please) I want to run diff. :-)
I think this is an orthogonal problem. Realtime diffs are good for
developers, not as useful for someone trying to track bug reports
David S. Miller writes:
> [...] I don't want to sift through a log file on some web site
> etc. to find out what he's applied.
The log file is primarily for Ted (eventually a more automated
bug/TODO system).
> Very simply, (drumroll please) I want to run diff. :-)
I think this is an
Alexander Viro writes:
> Sigh... You know, some stuff is security-sensitive. Dunno about
> other folks, but in such situations I prefer to send the patches OOB
> to relevant maintainers. And they often go through several rewrites
> before they go into the tree. Having descriptions of _all_
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
>Required tags:
>
> "Version" - the base kernel version. For example, "2.4.0-test8-pre1".
> The web page will list valid version strings.
>
> "Description" - a detailed description of the patch.
>
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
>Good patches are sent to the linux-kernel mailing list which is
>also where additional discussion about these patches can take
>place. All patches (good and bad) will be logged and there will be
>a web interface to access the patch
Here is a proposal to improve the kernel development process. It was
co-written by Sebastian Kuzminsky, Linus Torvalds, Theodore Ts'o, and
myself. We are posting the proposal here for public review and
comment. Seb is the guy writing on the software; he's nearly done the
initial version.
On Wed, 13 Sep 2000, Daniel Quinlan wrote:
Good patches are sent to the linux-kernel mailing list which is
also where additional discussion about these patches can take
place. All patches (good and bad) will be logged and there will be
a web interface to access the patch
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
Required tags:
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
"Description" - a detailed description of the patch.
Alexander Viro writes:
Sigh... You know, some stuff is security-sensitive. Dunno about
other folks, but in such situations I prefer to send the patches OOB
to relevant maintainers. And they often go through several rewrites
before they go into the tree. Having descriptions of _all_ pending
Daniel Quinlan wrote:
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some modified kernel. Of course you
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
Proposal:
1. Developers submit all Linux kernel patches to [EMAIL PROTECTED]
(not in place yet, so don't start sending patches).
@vger.kernel.org
2. Each patch will conform to a standardized, but simple, text format,
Hi Dan,
nice proposal.
One comment:
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
Linus wants the body of patches to be in text format and not
MIME-encoded or uuencoded.
[...]
Future features?
- PGP signing of patches
- conversion of uuencoded patches to text
On Wed, 13 Sep 2000, Alan Cox wrote:
Also the requires stuff isnt going to be easy because you can't tell who
beat you to a patch and your patch _might_ still apply with wrong results so
that can't be totally automated either.
nods
BTW, any bug reports starting with "kernel is x.y.z +
Alan Cox wrote:
Humans will generally get a weird report from sending Linus a message wonder
what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've seen some pretty dim folks manage
Alexander Viro wrote:
BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
long list of patches" will be cheerfully flushed down the toilet here,
no matter what system of dependencies is going to be in place.
Yes, for the stuff discussed on lkml patch dependencies should be
On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
Alexander Viro wrote:
BTW, any bug reports starting with "kernel is x.y.z + FOO42069 + K314 +
long list of patches" will be cheerfully flushed down the toilet here,
no matter what system of dependencies is going to be in place.
Yes, for
Mitchell Blank Jr wrote:
Daniel Quinlan wrote:
"Version" - the base kernel version. For example, "2.4.0-test8-pre1".
The web page will list valid version strings.
Ideally this should be overridable for patches marked experimental, since
they might be to some
Like any tracking system, the suceess or failure of its rollout depends
completely on whether Linus et al will be steadfast enough to refuse
to look at any patch that hasn't gone through the system.
If that attitude is taken the large numbers of patches will never make 2.4
proper.
Alan
-
To
Date: Wed, 13 Sep 2000 15:29:04 +0100 (BST)
From: Alan Cox [EMAIL PROTECTED]
Like any tracking system, the suceess or failure of its rollout depends
completely on whether Linus et al will be steadfast enough to refuse
to look at any patch that hasn't gone through the system.
Hi !
This is a very interesting idea, but I think we will
quickly need two more types of information from the
patch sender :
- type of patch (fix, new feature, performance boost,
cleanup ...)
- the degree of reliability known to the sender :
- some patches are hand-coded (often proposals
Mitchell Blank Jr wrote:
Alan Cox wrote:
Humans will generally get a weird report from sending Linus a message wonder
what all this field stuff is and mail someone else instead.
If they're able to create a patch, hopefully they'd be able to fill in
a simple email template (and I've
David S. Miller writes:
[...] I don't want to sift through a log file on some web site
etc. to find out what he's applied.
The log file is primarily for Ted (eventually a more automated
bug/TODO system).
Very simply, (drumroll please) I want to run diff. :-)
I think this is an orthogonal
From: Daniel Quinlan [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT)
Very simply, (drumroll please) I want to run diff. :-)
I think this is an orthogonal problem. Realtime diffs are good for
developers, not as useful for someone trying to track bug reports
and
David S. Miller writes:
Ok, so lets be clear.
Who is this facility really meant for? Linus (to decrease his
workload), Ted (to assist him in keeping the todo/bug lists uptodate),
or developers (who cares :-)?
From the description, my take was that this thing is meant to help all
three
From: Daniel Quinlan [EMAIL PROTECTED]
Date:Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping Linus and Ted) not help developers?
It has the potential to make more work for those of us who do our
patch
Theodore Y. Ts'o wrote:
How can we simplify things? Part of the design of this new proposal was
to change as little as possible from the existing setup (people's habits
are hard to change), and yet to make my life and Linus's life much
easier. In the long run, it will make your life easier,
Date:Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" [EMAIL PROTECTED]
From: Daniel Quinlan [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
mention helping Linus
From: Theodore Y. Ts'o [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 13, 2000 7:32 AM
How can we simplify things? Part of the design of this new
proposal was
to change as little as possible from the existing setup
(people's habits
are hard to change), and yet to make my life
Theodore Y. Ts'o writes:
Date: Wed, 13 Sep 2000 03:30:39 -0700
From: "David S. Miller" [EMAIL PROTECTED]
From: Daniel Quinlan [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 03:18:14 -0700 (PDT)
How exactly does a system to tracking patches and bugs/fixes (not to
On Wed Sep 13, 2000 at 02:49:01AM -0700, David S. Miller wrote:
From: Daniel Quinlan [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT)
Very simply, (drumroll please) I want to run diff. :-)
I think this is an orthogonal problem. Realtime diffs are good for
Date:Wed, 13 Sep 2000 02:27:07 -0700
From: "David S. Miller" [EMAIL PROTECTED]
rsync [EMAIL PROTECTED]:/home/torvalds/src/linux \
ftp.kernel.org:/pub/linux/kernel/LIVE/linux
would be the real helper for people like me whose only real issue
now is bothering
-BEGIN PGP SIGNED MESSAGE-
I had the same thought.
have you considered doing this as a front-end for bitkeeper?
something along the lines of it will accept bitkeeper changesets, or if it
receives a patch as you describe (and it applies cleanly) it creates a
bitkeeper changeset for it.
From: "Dunlap, Randy" [EMAIL PROTECTED]
Date: Wed, 13 Sep 2000 09:17:55 -0700
I appreciate Alan and you doing the kernel Status/TODO lists,
but I think that you ought to simplify it for yourself at
least (not that this would help Linus) by having maintainers
do it instead of
that bitkeeper has. The problem with bitkeeper is that it's **so**
different from CVS that it takes time to learn --- I spent a day getting
my head wrapped around it, and I still wouldn't call myself an expert;
Another problem is that bitkeeper has not been through a security audit.
have
Date: Wed, 13 Sep 2000 10:32:03 -0400
From: "Theodore Y. Ts'o" [EMAIL PROTECTED]
In the long run, it will make your life easier, to the extent that
having an up-to-date bug list is easier, and because then I won't
have to continually pester people about whether certain bugs have
100 matches
Mail list logo
