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
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 /tmp
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
Alexander Viro writes:
> On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> > Yes, for the stuff discussed on lkml patch dependencies should be
> > pretty minimal. However, if I were discussing something on linux-m68k
> > it would be common to say "kernel is 2.5.18 + m68k-native-patch-2.5.18 +
> > m
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 bi
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 convenient
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 r
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 t
} 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 diff
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 uns
> 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
On Thu, Sep 14, 2000 at 10:56:17PM +0100, Alan Cox wrote:
> [security audit]
> One by people other than the authors
That's OK by me, nobody is stopping anyone from doing that. I'd welcome it.
> [non-free tools means Linux is not free]
>
> It affects peoples ability to contribute. Those who cho
> > 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 aud
> > 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
On Thu, Sep 14, 2000 at 04:46:30PM +0100, Alan Cox wrote:
> That isnt the problem. Its what is in the source data you have to worry about.
> CVS also uses SSH happily. That doesn't stop attacks on either by feeding the
> server/input side bogus metadata
True, but ssh checks for an authent
Theodore Y. Ts'o wrote:
>From: [EMAIL PROTECTED] (Rogier Wolff)
>So under a "good" patch maintenance system, I'd have liked to generate
>the patch, and have it wait until I approve it.
>
> We talked about doing something like that, but at that point you need
> PGP signatures of the
> 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
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/
> 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 t
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.
> hav
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 y
-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 pat
Daniel Quinlan wrote:
> 4. If the robot likes the patch, it will create a unique identifier
>(i.e. "KP7562") and prepend a log entry to the body of the patch:
>
> --- linux/Documentation/patch-log Tue Aug 29 17:24:37 2000
> +++ linux/Documentation/patch-log Tue Aug 29 17:24:44
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 fo
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/fixe
> 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
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 ev
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 Lin
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 o
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
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 easi
On Wed, Sep 13, 2000 at 02:15:58AM -0700, Daniel Quinlan wrote:
> Here is a proposal to improve the kernel development process.
Nice proposal. But I have one question:
Where do the current subsystem maintainers fall into this system?
Do people still submit patches to them, and then do the main
> 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 to
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 Lin
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 dis
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 + FOO42
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 t
> 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
> understand.
> 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 versi
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,
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
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 wo
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
an
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
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_ pendi
Date:Wed, 13 Sep 2000 02:15:58 -0700
From: Daniel Quinlan <[EMAIL PROTECTED]>
Here is a proposal to improve the kernel development process.
This sounds like a really nice idea. If this helps Linus handle the
load better and makes the process more smooth, I'm all for it.
Howeve
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 da
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.
Descr
62 matches
Mail list logo
