Re: Proposal: Linux Kernel Patch Management System
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 for patches marked experimental, since >> they might be to some modified kernel. Of course you wouldn't do an >> test for applyability :-) > >Yes you can. Use the "Requires" identifier to add all the previous >patches first. But if the patch for the prerequisite modification isn't >available, what is the point of submitting the patch? If both patches are submitted at near the same time, the prerequisite patch may not arrive until after its dependents; in that case, you'd want the patch tracking system to hold on to the dependents until the prerequisite showed up. Consider the following scenario: developer A makes a patch P. developer A sends a copy of P to the patch tracking system. developer A CC's a copy of P to developer B in the same email. the copy of P for the patch tracking system enters a Microsoft Exchange email server during a Visual Basic Scripting Host virus incident, and is delayed by 48 hours. developer B fixes a bug in P, making patch Q. developer B submits Q to patch tracking system with "Requires: P" (assuming B has some identifier for P; see below for ideas on how to do this). the patch tracking system receives Q from B. To cope with the scenario outlined above, in addition to a numeric ID assigned by the patch server, the server should support reference to a patch by the MD5 hash of the patch text, or by message-IDs in email headers when patches are submitted. When the patch server can unambiguously translate one of those into a locally unique ID for the patch, it should do so, but leave the original specification in its internal database so that the patch can be meaningfully exported again. I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch text (i.e. the stuff you actually input to 'patch') as the actual patch identifier, and make the other ID forms search queries that ultimately resolve the MD5 hash. This has the advantage of allowing for a single globally unique identifier for all patches even if there are multiple kernel patch servers operated by different groups. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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/patch-2 /tmp/patch3... The first time you'd run this hypothetical script, it would ask for template field values and offer to remember the ones that don't change often, such as the architecture you're working on. Presumably it would work in batch mode, too, if you had several related patches. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 :-) > > > > We could even have a simple web page where you check a few boxes and > > fill in "URL to patch" and hit submit. > > You reckon? Its hard enough with mailing lists - I've seen people send > email subscription requests to majordomo@list to subscribe to a mailman > list, along with sending subscription requests to the mailing list address > etc. What makes you think that if humanity can't handle mailing lists > that humanity will handle an email template or a simple web page? >_ > |_| - ---+---+- > | | Russell King[EMAIL PROTECTED] --- --- > | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | > | +-+-+ --- -+- > / | THE developer of ARM Linux |+| /|\ > / | | | --- | > +-+-+ - /\\\ | Remember? This is not humanity. We're a community made of one Great Penguin (you guess who), few smaller penguins (kernel developers), and many many little rabbits (tring to learn something, with or without a debugger)... what has Mankind to do with us? B-) B-) B-) Anyway, you mean that one could: 1) read l-k, 2) choose an item from some TODO list, 3) download the kernel tarball and correctly untar it, 4) fire the editor of choice, 5) read the Source, 6) understand the Source, 7) contemplate It, 8) even dare to modify It, 9) produce a patch file with correct diff options, 10) find out the correct address to send the patch to, 11) launch the browser, and successfully open the form page, and after that stop for not being able to fill the template? You *really* believe this is a likely scenario? .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> "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> } easily have to invest a man-year or more learning how to use BK. But cort> If it takes a man-year to learn BK, that person shouldn't be doing kernel cort> work. It's beyond them. Putting shoes on would be a monumental effort of cort> mental power for them. I think ted means that it takes a man-year for the kernel comunity, not for a single person :) Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 binary. > > Why would the patch binary have to be touched? Do it the Unix > way(tm) and have a wrapper around patch which detects the relevent > line in the patch. (Note that patch will ignore any non-patch lines > automagically). Well, the patch programme doesn't have to specifically support the Notify: lines. But it would be good to be able to pass unrecognised lines to a separate file (or programme). It would allow other hacks like this in a robust way. But sure, we could just go for a simple script. Linus: would you use it? All you need do is: % cd `where patch` % mv patch patch.exe % mv ~/patch.wrapper patch and you'll never need to worry about it again. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 simple web page where you check a few boxes and > > fill in "URL to patch" and hit submit. > > You reckon? Its hard enough with mailing lists - I've seen people > send email subscription requests to majordomo@list to subscribe to a > mailman list, along with sending subscription requests to the > mailing list address etc. What makes you think that if humanity > can't handle mailing lists that humanity will handle an email > template or a simple web page? Humanity can't handle patching kernels either. And with the Darwinist development model, those who can't fill in the template have their patches go to /dev/null ;-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 check a few boxes and > fill in "URL to patch" and hit submit. You reckon? Its hard enough with mailing lists - I've seen people send email subscription requests to majordomo@list to subscribe to a mailman list, along with sending subscription requests to the mailing list address etc. What makes you think that if humanity can't handle mailing lists that humanity will handle an email template or a simple web page? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 binary have to be touched? Do it the Unix way(tm) and have a wrapper around patch which detects the relevent line in the patch. (Note that patch will ignore any non-patch lines automagically). _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 simple web page where you check a few boxes and fill in "URL to patch" and hit submit. You reckon? Its hard enough with mailing lists - I've seen people send email subscription requests to majordomo@list to subscribe to a mailman list, along with sending subscription requests to the mailing list address etc. What makes you think that if humanity can't handle mailing lists that humanity will handle an email template or a simple web page? Humanity can't handle patching kernels either. And with the Darwinist development model, those who can't fill in the template have their patches go to /dev/null ;-) Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
"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 } easily have to invest a man-year or more learning how to use BK. But cort If it takes a man-year to learn BK, that person shouldn't be doing kernel cort work. It's beyond them. Putting shoes on would be a monumental effort of cort mental power for them. I think ted means that it takes a man-year for the kernel comunity, not for a single person :) Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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/patch-2 /tmp/patch3... The first time you'd run this hypothetical script, it would ask for template field values and offer to remember the ones that don't change often, such as the architecture you're working on. Presumably it would work in batch mode, too, if you had several related patches. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 for patches marked experimental, since they might be to some modified kernel. Of course you wouldn't do an test for applyability :-) Yes you can. Use the "Requires" identifier to add all the previous patches first. But if the patch for the prerequisite modification isn't available, what is the point of submitting the patch? If both patches are submitted at near the same time, the prerequisite patch may not arrive until after its dependents; in that case, you'd want the patch tracking system to hold on to the dependents until the prerequisite showed up. Consider the following scenario: developer A makes a patch P. developer A sends a copy of P to the patch tracking system. developer A CC's a copy of P to developer B in the same email. the copy of P for the patch tracking system enters a Microsoft Exchange email server during a Visual Basic Scripting Host virus incident, and is delayed by 48 hours. developer B fixes a bug in P, making patch Q. developer B submits Q to patch tracking system with "Requires: P" (assuming B has some identifier for P; see below for ideas on how to do this). the patch tracking system receives Q from B. To cope with the scenario outlined above, in addition to a numeric ID assigned by the patch server, the server should support reference to a patch by the MD5 hash of the patch text, or by message-IDs in email headers when patches are submitted. When the patch server can unambiguously translate one of those into a locally unique ID for the patch, it should do so, but leave the original specification in its internal database so that the patch can be meaningfully exported again. I'd recommend using the MD5 hash (ok, SHA-1 if you insist) of the patch text (i.e. the stuff you actually input to 'patch') as the actual patch identifier, and make the other ID forms search queries that ultimately resolve the MD5 hash. This has the advantage of allowing for a single globally unique identifier for all patches even if there are multiple kernel patch servers operated by different groups. -- Opinions expressed are my own, I don't speak for my employer, and all that. Encrypted email preferred. Go ahead, you know you want to. ;-) OpenPGP at work: 3528 A66A A62D 7ACE 7258 E561 E665 AA6F 263D 2C3D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 right now. BK makes me have to think too } hard, where as CVS and RCS are more intuitively obvious what's going } on. That comes from familiarity and long experience, and I have no } doubt that if I were using BK a lot, I'd get familiar with it too. The above tells me you haven't tried BK and stayed with it very long. It's been intuitive for doing simple things and almost the same is true for complicated things. CVS for the kernel is a nightmare compared to BK. I've had to go back to CVS for some linux/mips work (linux/mips is managed mostly through CVS, not my choice) and it's been a mess. Why don't you send me some private email with exactly what you want BK to do that's not intuitive and I'll walk you through how I do it. I think you'll see the difference right off. I'm a big fan of BK. I've been managing the PPC trees, our RTLinux trees and it's helped out a LOT. } The problem though is time. I took a full day's worth of my time trying } to play with BK. That was a significant investment on my part, since I } could have done a lot of other things with that time. And in order for } me to get really familiar with it, I'll have to spend more time. But in } the mean time, for the projects where I was using it, I was pretty much } a solo developer, and if that's all I'm doing BK has no real advantage } of using CVS with a local repository. (Which is why it was very astute } of you to give solo developers the option of using BK without openlogin } if they so desired.) } } Now multiply my experience by the several hundred kernel developers out } there, and you can easily see how the kernel development community could } easily have to invest a man-year or more learning how to use BK. But If it takes a man-year to learn BK, that person shouldn't be doing kernel work. It's beyond them. Putting shoes on would be a monumental effort of mental power for them. BK isn't CVS, RCS or any other revision control software. It aims to do things differently - and better. There is some learning, but it is far far from a year. It took me 2 hours to get to the point where I was competently creating trees and giving other people access to our trees. That includes merging in Linus' patch with the _weird_ pre-patch format - that's not such an easy thing. My experience isn't unique. All of our PPC guys have caught up to speed very very quickly. } there's catch-22, in that if we don't have a critical mass of people } using it, then the value of BK is seriously diluted. So when I invested } a day of my time learning how to use BK, that was a decision that made } economic sense only if I thought eventually that a lot of other people } would use it. Unfortunately, the bug-a-boo with the license, and the } fact that some people (and I respect their right to feel that way) don't } feel comfortable with the BK license, means that I may have made a bad } choice economically when I made my decision to learn more about BK. (Of } course, there were other reasons other than pure selfish economic ones;I } was curious, and I think Larry's a good guy, and they both weighed in my } decision to spend time learning more about BK.) } } I recall the old story of penguins lined up at the ice floe's edge, each } nudging each other to see who would be the first one to jump. } Eventually one would get pushed in, and if he/she wasn't eaten by a } shark, they would all jump in and they would all get fat and happy. } There seems to be nice parallel to this situation. I hate mixing metaphors on the kernel list since they tend to degrade into discussions of social-Darwinism, bunnies, bazookas and wolfs with IT-manager claws (check out the kgdb thread). So I'll avoid the penguin jumping in metaphor. I did take the leap to BK, and took the PPC and RTLinux guys with me. We plowed the path for Linux work with BK already. We've several pitfalls, influenced BK enough to remove some problems (Larry has been really accommodating) and I'd recommend it to nearly anyone. Linux BK doesn't depend on Linus using it. If it did, I wouldn't be using it. We've been tracking Linus for nearly a year, merging with him, taking patches from BK and non-BK users and it does work. You don't even need to track Linus yourself. You don't have to create a tree, either. Just clone the tree we've been maintaining to track Linus (2.2 or 2.4/2.3) and you have your own area to work in. I'm serious about sending me the troubles you have so I can help. I bet you'll like it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 that way and you are saying, I think, that BK is only useful if everyone switches. I don't think that people who are using BK would agree with that statement. You can use BK to track what Linus releases easily and nicely. In fact, the trees at BitMover, made by the FSMlab crew (Cort and PPC friends), are just that. Cort worked up some scripts to deal with the fact that pre-patches are different from release patches, but other than that, tracking the Linus releases has been trivial. Yes, but that's no different from http://lksr.org, which uses CVS, and which does something similar. The real value for bitkeeper comes when I start getting patches from *other* people as changesets, all derived from the same BK "root" repository. Then I can much more easily merge changes, and do all of the things which makes BK so nice. 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 right now. BK makes me have to think too hard, where as CVS and RCS are more intuitively obvious what's going on. That comes from familiarity and long experience, and I have no doubt that if I were using BK a lot, I'd get familiar with it too. The problem though is time. I took a full day's worth of my time trying to play with BK. That was a significant investment on my part, since I could have done a lot of other things with that time. And in order for me to get really familiar with it, I'll have to spend more time. But in the mean time, for the projects where I was using it, I was pretty much a solo developer, and if that's all I'm doing BK has no real advantage of using CVS with a local repository. (Which is why it was very astute of you to give solo developers the option of using BK without openlogin if they so desired.) Now multiply my experience by the several hundred kernel developers out there, and you can easily see how the kernel development community could easily have to invest a man-year or more learning how to use BK. But there's catch-22, in that if we don't have a critical mass of people using it, then the value of BK is seriously diluted. So when I invested a day of my time learning how to use BK, that was a decision that made economic sense only if I thought eventually that a lot of other people would use it. Unfortunately, the bug-a-boo with the license, and the fact that some people (and I respect their right to feel that way) don't feel comfortable with the BK license, means that I may have made a bad choice economically when I made my decision to learn more about BK. (Of course, there were other reasons other than pure selfish economic ones;I was curious, and I think Larry's a good guy, and they both weighed in my decision to spend time learning more about BK.) I recall the old story of penguins lined up at the ice floe's edge, each nudging each other to see who would be the first one to jump. Eventually one would get pushed in, and if he/she wasn't eaten by a shark, they would all jump in and they would all get fat and happy. There seems to be nice parallel to this situation. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 0001. bugzilla. or something else automated to track bugs and assign numbers. It's an open question whether it's less work for me to read through all of linux-kernel, looking for bug reports, and filing them myself, OR run something like bugzilla, and then have to winnow out all of the bogus/bullshit patches which people submit --- and then have to scan l-k anyway, since a lot of people won't bother to use the formal web submission tool. If everyone used it, and it was integrated into a full software development process that included a software control system, sure; that's what bugzilla was designed around, and it's not bad at doing what it was designed to do. But given the somewhat chaotic development process used by the kernel, simply throwing in bugzilla without putting in the rest of the changes necessary to really make it work well is probably a bad idea. And I don't think we have the mandate from the developers and from Linus to make that kind of major change to how the Linux kernel is developed. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
>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 rewrite BitKeeper. I should give you all jobs :-) [...] > why it's so nice. I like that part, can I just quote you on that part? > The problem, though, is that bitkeeper is only useful > if a large number of other developers use it, and given its non-OSS > license, it's not clear it will get that critical mass. Personally, I > have no problem with the license. But if there are enough other people > who are license fanatics who do have a problem with it, then bitkeeper > loses a lot of value for me. If Linus were willing to dictate from high > that we were going to use bitkeeper, and that all patches had to come in > as bitkeeper changelogs, then that might get us critical mass. 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 that way and you are saying, I think, that BK is only useful if everyone switches. I don't think that people who are using BK would agree with that statement. You can use BK to track what Linus releases easily and nicely. In fact, the trees at BitMover, made by the FSMlab crew (Cort and PPC friends), are just that. Cort worked up some scripts to deal with the fact that pre-patches are different from release patches, but other than that, tracking the Linus releases has been trivial. Putting stuff back from BK into Linus' tree is another matter. It would be a lot easier if Linus maintained a BK tree and generated the traditional patches and/or release tarballs from that tree. There are some issues with file creates that BK doesn't handle well which would go away if there was a definitive BK tree that Linus used. We hope that that will happen, but even if it does, you don't have to use BK if you don't like it, or the license, or you just think I'm a big boogerhead. If Linus had a BK tree, he can just export the patches from it, each changeset is in essence a patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 the person who went through the license and did > things like pointing out the issue with having a third party go after the > openlogging servers ? Yes, and I recall that was a long time ago. The license hasn't stood still, it's evolved as a direct result of your (and other's) feedback. If you are going to make strong statements about it in a public forum where your word carries substantial weight, isn't it reasonable to ask that you are up to date? -- --- Larry McVoy[EMAIL PROTECTED] http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
} 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 -uNr patches nightly at ftp://www.fsmlabs.com/pub/linuxppc/ as well as exports to a rsync tree. } for example. I wouldn't expect Linus to require you to use BitKeeper, and } I wouldn't want you to be using BitKeeper because of that, I'd want you using } it because it saves you time and effort. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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 pointing out the issue with having a third party go after the openlogging servers ? Jeez Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> > 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. 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. > > have no problem with the license. But if there are enough other people > > who are license fanatics who do have a problem with it, then bitkeeper > > loses a lot of value for me. If Linus were willing to dictate from high > > that we were going to use bitkeeper, and that all patches had to come in > > If Linus requires bitkeeper only then there will be two kernel trees. Linux > ceases to be free software when you require nonfree software to contribute it. First of all, that "Linux ceases to be free software..." is a false statement, what tools you use to hack Linux in no way effect to license under which you get Linux, and I think you know that, Alan. 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] for example. I wouldn't expect Linus to require you to use BitKeeper, and I wouldn't want you to be using BitKeeper because of that, I'd want you using it because it saves you time and effort. > Note: I think the BK license is fair, I understand Larry's problem and I support > his right to use whatever license he likes. I also happen to support my right > to decline to use his software I just have one question: can you tell me if you have actually read the BKL or are you just making up your mind that it is free or non free based on something else? For those who haven't read it, it says that you get source, you can wack the source and redistribute it, that subsections of the system such as the memory checker, the mmap based DMB library, and the installer, are all also licensed under the GPL. You can read it here: http://www.bitkeeper.com/license.html The points that I believe Alan doesn't like is that you have to pass our regression tests and you have to respect the openlogging requirement -- if you modify the source and want to redistribute it. I hear that you'd like something 100% free of such restrictions, and wouldn't we all, but BK was way too expensive to develop for us to just give it away free. We have no other source of income. It is our intent, and the license reflects that, that if you are doing work out in the open, on open source or anything else, that you can use it free of any monetary payment. It's somewhat interesting to note that if you put your data on sourceforge, you give up more rights than BK asks from you. They expect you to make the entire project source code available on sourceforge, not just the changelogs. All the BKL says is that you have to make the changelogs available. If you are truly concerned with your freedom, you shouldn't be putting anything on sourceforge. Yet people do it all the time, because sourceforge provides a useful service. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> > 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 be free software..." is a false statement, > what tools you use to hack Linux in no way effect to license under which you > get Linux, and I think you know that, Alan. It affects peoples ability to contribute. Those who choose only to use free software (such as the debian project) would be unable to contribute if that was the only tool available. > Second, I doubt very much that Linus would require BitKeeper only. It's Im sure he wouldnt. And I really don't mind (and its none of my business either) what he uses internally. > I just have one question: can you tell me if you have actually read > the BKL or are you just making up your mind that it is free or non free > based on something else? DFSG. Which nowdays seems to be the reference Its nearly free software and as I've said, I understand the compromises you made and why you needed to make them - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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 worry about. CVS also uses SSH happily. That doesn't stop attacks on either by feeding the server/input side bogus metadata - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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 break and then go off and do other things. A lot of driver problems occur in the field and so we get a lot of fixes from folks whose primary business in life is making their site stable so they can sleep at night. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 0001. bugzilla. or something else automated to track bugs and assign numbers. It's an open question whether it's less work for me to read through all of linux-kernel, looking for bug reports, and filing them myself, OR run something like bugzilla, and then have to winnow out all of the bogus/bullshit patches which people submit --- and then have to scan l-k anyway, since a lot of people won't bother to use the formal web submission tool. If everyone used it, and it was integrated into a full software development process that included a software control system, sure; that's what bugzilla was designed around, and it's not bad at doing what it was designed to do. But given the somewhat chaotic development process used by the kernel, simply throwing in bugzilla without putting in the rest of the changes necessary to really make it work well is probably a bad idea. And I don't think we have the mandate from the developers and from Linus to make that kind of major change to how the Linux kernel is developed. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 right now. BK makes me have to think too } hard, where as CVS and RCS are more intuitively obvious what's going } on. That comes from familiarity and long experience, and I have no } doubt that if I were using BK a lot, I'd get familiar with it too. The above tells me you haven't tried BK and stayed with it very long. It's been intuitive for doing simple things and almost the same is true for complicated things. CVS for the kernel is a nightmare compared to BK. I've had to go back to CVS for some linux/mips work (linux/mips is managed mostly through CVS, not my choice) and it's been a mess. Why don't you send me some private email with exactly what you want BK to do that's not intuitive and I'll walk you through how I do it. I think you'll see the difference right off. I'm a big fan of BK. I've been managing the PPC trees, our RTLinux trees and it's helped out a LOT. } The problem though is time. I took a full day's worth of my time trying } to play with BK. That was a significant investment on my part, since I } could have done a lot of other things with that time. And in order for } me to get really familiar with it, I'll have to spend more time. But in } the mean time, for the projects where I was using it, I was pretty much } a solo developer, and if that's all I'm doing BK has no real advantage } of using CVS with a local repository. (Which is why it was very astute } of you to give solo developers the option of using BK without openlogin } if they so desired.) } } Now multiply my experience by the several hundred kernel developers out } there, and you can easily see how the kernel development community could } easily have to invest a man-year or more learning how to use BK. But If it takes a man-year to learn BK, that person shouldn't be doing kernel work. It's beyond them. Putting shoes on would be a monumental effort of mental power for them. BK isn't CVS, RCS or any other revision control software. It aims to do things differently - and better. There is some learning, but it is far far from a year. It took me 2 hours to get to the point where I was competently creating trees and giving other people access to our trees. That includes merging in Linus' patch with the _weird_ pre-patch format - that's not such an easy thing. My experience isn't unique. All of our PPC guys have caught up to speed very very quickly. } there's catch-22, in that if we don't have a critical mass of people } using it, then the value of BK is seriously diluted. So when I invested } a day of my time learning how to use BK, that was a decision that made } economic sense only if I thought eventually that a lot of other people } would use it. Unfortunately, the bug-a-boo with the license, and the } fact that some people (and I respect their right to feel that way) don't } feel comfortable with the BK license, means that I may have made a bad } choice economically when I made my decision to learn more about BK. (Of } course, there were other reasons other than pure selfish economic ones;I } was curious, and I think Larry's a good guy, and they both weighed in my } decision to spend time learning more about BK.) } } I recall the old story of penguins lined up at the ice floe's edge, each } nudging each other to see who would be the first one to jump. } Eventually one would get pushed in, and if he/she wasn't eaten by a } shark, they would all jump in and they would all get fat and happy. } There seems to be nice parallel to this situation. I hate mixing metaphors on the kernel list since they tend to degrade into discussions of social-Darwinism, bunnies, bazookas and wolfs with IT-manager claws (check out the kgdb thread). So I'll avoid the penguin jumping in metaphor. I did take the leap to BK, and took the PPC and RTLinux guys with me. We plowed the path for Linux work with BK already. We've several pitfalls, influenced BK enough to remove some problems (Larry has been really accommodating) and I'd recommend it to nearly anyone. Linux BK doesn't depend on Linus using it. If it did, I wouldn't be using it. We've been tracking Linus for nearly a year, merging with him, taking patches from BK and non-BK users and it does work. You don't even need to track Linus yourself. You don't have to create a tree, either. Just clone the tree we've been maintaining to track Linus (2.2 or 2.4/2.3) and you have your own area to work in. I'm serious about sending me the troubles you have so I can help. I bet you'll like it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 break and then go off and do other things. A lot of driver problems occur in the field and so we get a lot of fixes from folks whose primary business in life is making their site stable so they can sleep at night. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 worry about. CVS also uses SSH happily. That doesn't stop attacks on either by feeding the server/input side bogus metadata - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. 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. have no problem with the license. But if there are enough other people who are license fanatics who do have a problem with it, then bitkeeper loses a lot of value for me. If Linus were willing to dictate from high that we were going to use bitkeeper, and that all patches had to come in If Linus requires bitkeeper only then there will be two kernel trees. Linux ceases to be free software when you require nonfree software to contribute it. First of all, that "Linux ceases to be free software..." is a false statement, what tools you use to hack Linux in no way effect to license under which you get Linux, and I think you know that, Alan. 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] for example. I wouldn't expect Linus to require you to use BitKeeper, and I wouldn't want you to be using BitKeeper because of that, I'd want you using it because it saves you time and effort. Note: I think the BK license is fair, I understand Larry's problem and I support his right to use whatever license he likes. I also happen to support my right to decline to use his software I just have one question: can you tell me if you have actually read the BKL or are you just making up your mind that it is free or non free based on something else? For those who haven't read it, it says that you get source, you can wack the source and redistribute it, that subsections of the system such as the memory checker, the mmap based DMB library, and the installer, are all also licensed under the GPL. You can read it here: http://www.bitkeeper.com/license.html The points that I believe Alan doesn't like is that you have to pass our regression tests and you have to respect the openlogging requirement -- if you modify the source and want to redistribute it. I hear that you'd like something 100% free of such restrictions, and wouldn't we all, but BK was way too expensive to develop for us to just give it away free. We have no other source of income. It is our intent, and the license reflects that, that if you are doing work out in the open, on open source or anything else, that you can use it free of any monetary payment. It's somewhat interesting to note that if you put your data on sourceforge, you give up more rights than BK asks from you. They expect you to make the entire project source code available on sourceforge, not just the changelogs. All the BKL says is that you have to make the changelogs available. If you are truly concerned with your freedom, you shouldn't be putting anything on sourceforge. Yet people do it all the time, because sourceforge provides a useful service. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 be free software..." is a false statement, what tools you use to hack Linux in no way effect to license under which you get Linux, and I think you know that, Alan. It affects peoples ability to contribute. Those who choose only to use free software (such as the debian project) would be unable to contribute if that was the only tool available. Second, I doubt very much that Linus would require BitKeeper only. It's Im sure he wouldnt. And I really don't mind (and its none of my business either) what he uses internally. I just have one question: can you tell me if you have actually read the BKL or are you just making up your mind that it is free or non free based on something else? DFSG. Which nowdays seems to be the reference Its nearly free software and as I've said, I understand the compromises you made and why you needed to make them - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 that way and you are saying, I think, that BK is only useful if everyone switches. I don't think that people who are using BK would agree with that statement. You can use BK to track what Linus releases easily and nicely. In fact, the trees at BitMover, made by the FSMlab crew (Cort and PPC friends), are just that. Cort worked up some scripts to deal with the fact that pre-patches are different from release patches, but other than that, tracking the Linus releases has been trivial. Yes, but that's no different from http://lksr.org, which uses CVS, and which does something similar. The real value for bitkeeper comes when I start getting patches from *other* people as changesets, all derived from the same BK "root" repository. Then I can much more easily merge changes, and do all of the things which makes BK so nice. 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 right now. BK makes me have to think too hard, where as CVS and RCS are more intuitively obvious what's going on. That comes from familiarity and long experience, and I have no doubt that if I were using BK a lot, I'd get familiar with it too. The problem though is time. I took a full day's worth of my time trying to play with BK. That was a significant investment on my part, since I could have done a lot of other things with that time. And in order for me to get really familiar with it, I'll have to spend more time. But in the mean time, for the projects where I was using it, I was pretty much a solo developer, and if that's all I'm doing BK has no real advantage of using CVS with a local repository. (Which is why it was very astute of you to give solo developers the option of using BK without openlogin if they so desired.) Now multiply my experience by the several hundred kernel developers out there, and you can easily see how the kernel development community could easily have to invest a man-year or more learning how to use BK. But there's catch-22, in that if we don't have a critical mass of people using it, then the value of BK is seriously diluted. So when I invested a day of my time learning how to use BK, that was a decision that made economic sense only if I thought eventually that a lot of other people would use it. Unfortunately, the bug-a-boo with the license, and the fact that some people (and I respect their right to feel that way) don't feel comfortable with the BK license, means that I may have made a bad choice economically when I made my decision to learn more about BK. (Of course, there were other reasons other than pure selfish economic ones;I was curious, and I think Larry's a good guy, and they both weighed in my decision to spend time learning more about BK.) I recall the old story of penguins lined up at the ice floe's edge, each nudging each other to see who would be the first one to jump. Eventually one would get pushed in, and if he/she wasn't eaten by a shark, they would all jump in and they would all get fat and happy. There seems to be nice parallel to this situation. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 pointing out the issue with having a third party go after the openlogging servers ? Jeez Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
} 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 -uNr patches nightly at ftp://www.fsmlabs.com/pub/linuxppc/ as well as exports to a rsync tree. } for example. I wouldn't expect Linus to require you to use BitKeeper, and } I wouldn't want you to be using BitKeeper because of that, I'd want you using } it because it saves you time and effort. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 the person who went through the license and did things like pointing out the issue with having a third party go after the openlogging servers ? Yes, and I recall that was a long time ago. The license hasn't stood still, it's evolved as a direct result of your (and other's) feedback. If you are going to make strong statements about it in a public forum where your word carries substantial weight, isn't it reasonable to ask that you are up to date? -- --- Larry McVoy[EMAIL PROTECTED] http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 been fixed. Ok, I claim: 1) I always have an uptodate bug list for the things I maintain 2) I always notify you instantly when Linus puts up a pre-patch that closes bugs in areas I maintain. 3) By going over every diff by hand I (and others) spot bugs that would not be found easily by testing. It's free code review to keep going over relative diffs like this as new pre-patches come out. (I'd say there about 10 to 20 people who, like me, religiously read over and review the diffs between pre-patches as they are released. There is _real_ value in this. It won't all stop due to the patch robot, but you for one aparently will do it less often than you do now.) So changing the mechanism is going to make my life easier and better how? But still, Ted, I respect you enough that if you are so convinced this is going to make things better, I'm going to give it a try as is. No problem. However, I contend that some of us will feel that they are being punished for doing a good job thus far without this patch robot. I don't think the big problem is VFS, MM, or networking bug 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. If you agree with the previous paragraph, then my final argument is that forcing these driver "maintainers" to go through the patch robot system will not necessarily get them to look at the bug list and hunt people down to fix bugs. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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 no problem with the license. But if there are enough other people > who are license fanatics who do have a problem with it, then bitkeeper > loses a lot of value for me. If Linus were willing to dictate from high > that we were going to use bitkeeper, and that all patches had to come in If Linus requires bitkeeper only then there will be two kernel trees. Linux ceases to be free software when you require nonfree software to contribute it. Note: I think the BK license is fair, I understand Larry's problem and I support his right to use whatever license he likes. I also happen to support my right to decline to use his software - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 seen some pretty dim folks manage to > register domains with InterNIC, so email templates aren't that hard :-) When I sent Linus ten or twenty patches, that means I'm filling in ten to twenty e-mail templates, yum :) Jeff -- Jeff Garzik | Windows NT Performance, Building 1024| on the next "In Search Of" MandrakeSoft, Inc. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 you do it. I'm willing to do it for USB, but I'm not willing to duplicate your work if you continue to do it. I don't expect you to know/understand all of the filesystem or I/O subsystem or VM or process issues and be able to track them without asking lots of questions. (Maybe you do, but I don't think that should be a requirement of the status-bot.) Tell you what. If you're willing to handle USB bug reports, I'll segregate them into one area, and then have you send me updates every few days. The updates should hopefully include bug reports from users who post to linux-kernel. What I currently do is save those e-mail messages in a mail folder, and then include their names (but not e-mail address) in the bug list. You should roll up reports from maintainers for a summary kernel status report. If maintainers are willing to do a good job capturing bug reports, that's great. We can break those out into subsystems. The problem is that sometimes maintainers can get egos involved and not be willing to admit that something might be a bug, especially if the bug report doesn't contain full information. This works much better if the subsystem is maintained by a team, and one person of that team is responsible for the overal bug tracking for that subsystem. It sounds like the USB subsystem meets this criteria quite handily. PS: This is probably too good to be true and would require the assistance of lots of maintainers, but that's how it should be done IMO. Well, yes, and in a perfect world Linus would be using a bug tracking system. But we've managed quite well despite that not being the case. :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
-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. I guess this should wait until Larry makes a comment. David Lang >Isn't this "new" patch maintenance system much like bitkeeper? > > Heh. I'm surprised Larry hasn't jumped into this discussion by now. > > What we've implemented is a very small subset of the sort of features > 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; > that's what's necessary to really get a good feel for how it works and > why it's so nice. The problem, though, is that bitkeeper is only useful > if a large number of other developers use it, and given its non-OSS > license, it's not clear it will get that critical mass. Personally, I > have no problem with the license. But if there are enough other people > who are license fanatics who do have a problem with it, then bitkeeper > loses a lot of value for me. If Linus were willing to dictate from high > that we were going to use bitkeeper, and that all patches had to come in > as bitkeeper changelogs, then that might get us critical mass. If he > doesn't do that, though, my big concern is whether or not it'll be able > to garner enough critical mass for it to be worth the trouble for kernel > developers to want to spend time learning it. > > - Ted > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOb/Qvz7msCGEppcbAQEOAQf/e++B2UDp326KCg88YUvDvhvKzUBYPkKk Y6kqaDgQdfso7wtzIEtmxbboFCEndzsby8ccnF/OW1+7/OlZjaxNH2SOizZnND/K l2HquT8ptE94VV40IUqgjaOsy5+bx43iI+WD5eOvjtOGnkVYSro5b3IJLQ1q5rBV 1ae0coqsF0fCnL/5LjKkJoVIrB0jQU2X7703UKP2kex//45gnRokioQ7Yf2M3jIQ Dx7XL+hvAtmWmo5/dSMCwQWC/8QWghqQJ+JK5gzUrjvyn+JqV68+B1Ok6ykTLLy7 XTUiGg2VCmzjNjDfsiWpiOTHl/NrS/Ojo0v1lk3Er8SD37E+83TicQ== =UsJX -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 patch first. 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 developers, and it starts getting very complicated. Also, I was a bit concerned that if it was too "different" from what people were used to, they might not adopt it at all. A more gradual approach might work better. So eventually, yes, it might be nice to ahve some of the things that you're talking about. Another features that I REALLY REALLY would like in a patch maintenance system would be that it could try and automatically (re-)generate the patch against a different kernel version: Pushing a patch forward is generally relatively easy to code --- you'll either get something which will patch correctly, or you won't. You can even have something automated do a test build. However, that isn't enough to guarantee that the patch is still valid given other changes that have since happened. I personally find that regenering a patch against a newer kernel version is the trivial part of the exercise. It's retesting and revalidating the patch afterwards which is a pain, and which takes real human effort that I don't believe can be automatied. Isn't this "new" patch maintenance system much like bitkeeper? Heh. I'm surprised Larry hasn't jumped into this discussion by now. What we've implemented is a very small subset of the sort of features 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; that's what's necessary to really get a good feel for how it works and why it's so nice. The problem, though, is that bitkeeper is only useful if a large number of other developers use it, and given its non-OSS license, it's not clear it will get that critical mass. Personally, I have no problem with the license. But if there are enough other people who are license fanatics who do have a problem with it, then bitkeeper loses a lot of value for me. If Linus were willing to dictate from high that we were going to use bitkeeper, and that all patches had to come in as bitkeeper changelogs, then that might get us critical mass. If he doesn't do that, though, my big concern is whether or not it'll be able to garner enough critical mass for it to be worth the trouble for kernel developers to want to spend time learning it. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 >developers, not as useful for someone trying to track bug reports >and see what has been applied, from whom, descriptions, etc. > > Ok, so lets be clear. > > Who is this facility really meant for? Linus (to decrease his I suspect this new system is designed for the needs of lower-volume patch submitters like myself. For example, I had to submit my latest patch (a binary compatibility fix) to Linus about 8 times (without ever getting a response I might add) before it showed up in the latest kernel. Very inefficient. Furthermore, I had to make a couple of changes to the patch -- first a logic error then a spelling error. Each required a new patch cluttering poor Linus' Inbox. With a system in place where I could have updated a numbered patch, and had immediate feedback on its status, life would have simpler for me, and Linus would not have had his mailbox so cluttered -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 > mention helping Linus and Ted) not help developers? > >It has the potential to make more work for those of us who do our >patch submissions effectively already. > > 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, 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 been > fixed. > > Right now, having to paw through diff files to see when Linus has > applied a particular patch (add grumble about lack of a source code > control system) is really not fun. Alan did it for a while, and burned > out, and I can tell you, I can't really blame him --- it's a lot of > work. > > Is it really that hard to annotate the patch with a bit of information, > and then send it off to a different mailing address instead of sending > it directly to Linus and the l-k list? > > What can we do to make things simpler on developers? Certainly this > isn't going to work unless the developers use it, and that means we need > to keep things as easy as possible for the patch submitters. Something I've been planning on implementing for some time now is a small patch to patch, so that it recognises lines of the form: Notify: email,id 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. This way, I wouldn't have to sift through a diff to see if my patch has been applied. And it doesn't require any change in the way Linus works. An extension which does change the way he works would involve him running a patch --reject on a patch before hitting 'd'. And possibly also a patch --not-now. It also doesn't require developers to change their habits. It's entirely optional. Separately, making Linus' unpacked working trees available: ftp://ftp.??.kernel.org/pub/linux/kernel/v*/LIVE/ would make patch generation a lot easier. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Proposal: Linux Kernel Patch Management System
> 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 and Linus's life much > easier. 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 been > fixed. > > Right now, having to paw through diff files to see when Linus has > applied a particular patch (add grumble about lack of a source code > control system) is really not fun. Alan did it for a while, > and burned > out, and I can tell you, I can't really blame him --- it's a lot of > work. > > Is it really that hard to annotate the patch with a bit of > information, > and then send it off to a different mailing address instead of sending > it directly to Linus and the l-k list? > > What can we do to make things simpler on developers? Certainly this > isn't going to work unless the developers use it, and that > means we need > to keep things as easy as possible for the patch submitters. Ted, 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 you do it. I'm willing to do it for USB, but I'm not willing to duplicate your work if you continue to do it. I don't expect you to know/understand all of the filesystem or I/O subsystem or VM or process issues and be able to track them without asking lots of questions. (Maybe you do, but I don't think that should be a requirement of the status-bot.) You should roll up reports from maintainers for a summary kernel status report. ~Randy PS: This is probably too good to be true and would require the assistance of lots of maintainers, but that's how it should be done IMO. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 even if the latter is > better for machines. It also makes the Requires: header easier to > understand. Humans will generally get a weird report from sending Linus a message wonder what all this field stuff is and mail someone else instead. The thing that needs the most thinking about is how to handle patches that don't have all this id crap and stuff on them. This is why it makes more sense to let the system pick the patch number. That way the developers don't have to worry about it. (No, I don't think the dependency stuff will get much, if any use.) The only ID field which I'd ask for (and it's to make my job easier), is that if a patch is known to fix a bug in the 2.4 buglist, that you include that fact in the header. (i.e., this fixes problem T0012.) If people don't do this (it's optional), I'll try to intuit it from the patch subscription, but I'll occasionally get things wrong. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 Linus all the time to make pre-patches so I can send him known clean diffs. This is orthogonal to the patch management system, but I agree this would be highly useful. Would Linus be willing to have an hourly cron job that rsync'ed his live kernel sources to ftp.kernel.org? (I suspect a number of patch submitters would then have rsync jobs that would sync from kernel.org to their local directories. I know I would.) It would certainly make it easier to send clean patches to Linus. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management 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 on lkml) - some *will* break something (just for test purposes) - some are known to be buggy, but testers are needed - some patches are simply not tested - some are reported to work for a long time on a small amount of computers - some are reported to work, perhaps with small bugs (ie: raid, reiserfs, ide... mainly real projects) - some are known to involve absolutely no risk at all (mainly documentation patches). I personnaly would like to be able to classify the patches I sometimes send this way. I know that some of them are not good and I wouldn't like people to blindly rely on them. With such a method, it would be easy to select "reliable fixes" or "features that need to be fixed" on a search engine. Moreover, if a patch is finally reported to break something, it would be easy to change it reliability level afterwards. If we also add a field that tells if the patch is to be included, not to be included or simply proposed, it would be helpfull to include synthetic reports about the global reliability. Just my two cents here, Willy ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. If that attitude is taken the large numbers of patches will never make 2.4 proper. I've never asked for that attitude. If only 50% of the patches go through this system, my job will be made *much* easier. That being said, the existing system isn't perfect. I can tell you that there are a large number of "obvious" bug fixes which haven't been making it into 2.4 proper. I do try to keep track of patches, although in a much more informal way than actual bug reports. Some of them are very simple error checking fixes which got submitted a month or two ago, got ignored by Linus, and are pretty much forgotten. If the patch author doesn't aggressively submit (in my personal experience I've had to sometime retransmit three or more times), the patch can get dropped, even if an outside observer thinks that it's an obviously good patch. I have an RMAIL folder containing about 120 patches that fall in this category. Some of the patches may still require some fixing, and some of the patches may have since been applied (although every so often I sweep through the folder and try to eliminate those that have already been accepted). My guess is that percentage of "good patches" that haven't been accepted is probably 50-75%. If anyone would like to go through that list and retransmit some of the more obviously correct ones to Linus, let me know, and I'll send you that RMAIL folder. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management 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 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 been > fixed. OK. 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 patch first. So under a "good" patch maintenance system, I'd have liked to generate the patch, and have it wait until I approve it. That way, it might be available for "public" testing by others, while I can give the "goahead" to send to Linus or retract the patch if it doesn't work as advertized. Another features that I REALLY REALLY would like in a patch maintenance system would be that it could try and automatically (re-)generate the patch against a different kernel version: Suppose I make a patch against 2.4.0-test8 and then Linus releases a newer version (possibly even before I give the "goahead bug Linus") Then applying my patch to 2.4.0-test9 and generating a new patch against 2.4.0-test9-clean is one possibility. The other is to apply patch-2.4.0-test9 to my patched kernel. The results could be compared for consistency. Also, sometimes a backport of a patch is required. Automating that as far as possible is useful! (What Larry McVoy seems to miss is that "automated patch-port failed" is a valid answer, as long as it works in 99% of the cases). Isn't this "new" patch maintenance system much like bitkeeper? Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 modified kernel. Of course you wouldn't do an > test for applyability :-) Yes you can. Use the "Requires" identifier to add all the previous patches first. But if the patch for the prerequisite modification isn't available, what is the point of submitting the patch? Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 and Ted) not help developers? It has the potential to make more work for those of us who do our patch submissions effectively already. 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, 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 been fixed. Right now, having to paw through diff files to see when Linus has applied a particular patch (add grumble about lack of a source code control system) is really not fun. Alan did it for a while, and burned out, and I can tell you, I can't really blame him --- it's a lot of work. Is it really that hard to annotate the patch with a bit of information, and then send it off to a different mailing address instead of sending it directly to Linus and the l-k list? What can we do to make things simpler on developers? Certainly this isn't going to work unless the developers use it, and that means we need to keep things as easy as possible for the patch submitters. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 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 + > mac68k-patch-2.5.18" I'm less than sure that keeping architecture-specific development out of the main tree is a good thing. Usual scenario (seen that quite a few times): tree for architecture foo is based on mainstream version x.y.z, in x.y.z+5 change happens in the mainstream tree and in-tree variant of arch/foo/* is updated. In x.y.z+10 foo-specific stuff gets synced with the main tree and we are getting a huge mess, since repository for foo didn't get the updates back in x.y.z+5. Having all stuff in one place may help, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. 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 + mac68k-patch-2.5.18" -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 to register domains with InterNIC, so email templates aren't that hard :-) We could even have a simple web page where you check a few boxes and fill in "URL to patch" and hit submit. > The thing that needs the most thinking about is how to handle patches that > don't have all this id crap and stuff on them. 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. It's just like when you're converting a helpdesk to use a ticket tracking system. You need to teach the tech people that when they run into someone in the hallway that says "hey, my printer is broken, come fix it" they they need to reply "you must be mistaken - if your printer were broken you would have filed a trouble ticket... since I have no trouble ticket your printer must be fine". People catch on quick. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 + FOO42069 + K314 + " will be cheerfully flushed down the toilet here, no matter what system of dependencies is going to be in place. Even if dependencies will scale, testing/bug hunting won't. Anybody who has doubts about it really ought to recall the situation with Minix circa '91. IOW, don't go overboard with the dependencies - number of simultaneous patches translates into number of people that have to be involved in any work on patched kernel and _that_ will give a bottleneck. Extra generality is not going to do any good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 format for people with broken >mailers If you want to use PGP signatures, you need to allow MIME encoding. Otherwise non-7bit chars or even trailing spaces may lead to invalid PGP signatures. I've gone through that once. That's why I use this (admittedly ugly quoted-printable). Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
> 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. Humans will generally get a weird report from sending Linus a message wonder what all this field stuff is and mail someone else instead. The thing that needs the most thinking about is how to handle patches that don't have all this id crap and stuff on them. 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. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Proposal: Linux Kernel Patch Management System
> 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. What you are actually trying to do is to implement a feature-based software configuration management system. >Required tags: > > "Version" - the base kernel version. For example, "2.4.0-test8-pre1". > The web page will list valid version strings. Note that this could just as well be the first item on Requires tag. For example, each Linux kernel would need the one before it: linux-2.2.17 requires linux-2.2.16 which requires linux-2.2.15 etc. > "Requires" - followed by one or more kernel-patch identifiers. >For example, "KP7555". Rembember that the ordering of the Requires tag is quite important if there are multiple patches modifying the same files. Currently I'm working on a kernel which is based on linux-2.2.16 and also has the backport of the USB code from linux-2.4.something, a patch with a driver for a device, and yet another patch for something else. Most of these patches are not dependent on each other really, but a few of them touch the same files which makes things a bit complicated. It would be very nice if the creator of the patch could give the patch some kind of "base name", as it'll be Alexander S A Kjeldaas wrote, it's much easier to understand what "geode-irq-fixup-12" means than "KP3712". Maybe this should be called a "Feature" instead of base-name, because that's what it is, the patch implements a feature. A very nice tool to have would be an automatic patcher where I say "I want this patch, get everything it needs" and which then performs all the patching. Say that I'm working on an USB driver for the National Semiconductor Geode which is currently based on the following stuff: linux-2.2.14 usb-2.3.99-pre7-1-for-2.2.14 (requires linux-2.2.14) wingel-usb-12 (requires usb-2.3.99-pre7-1-for-2.2.14.diff) So if I say "I want the wingel-usb-12" version, it'll download and patch everything in order. (Actually, the wingel-usb-12 patch might even be empty, the only thing I'm using it for is to select which set of features/patches I want.) A few things to thing about here, what should happen if I upgrade the Linux kernel to 2.2.16? I should be able to patch it with the usb patch for 2.2.14 since the tool should be able to tell that linux-2.2.16 is a successor of linux-2.2.14, but at the same time it should tell me that I'm trying to do an imperfect patch (which might result in rejects) and not allow me to do this automatically. What I'd have to to is to apply the patch manually and create a new usb-2.3.99-pre7-1-for-2.2.16 patch instead. This will of course force me to create a new wingel-usb-13 patch too. linux-2.2.16 (obsoletes linux 2.2.14-15) wingel-usb-2.3.99-pre7-1-for-2.2.16 (requires linux-2.2.16 and obsoletes usb-2.3.99-pre7-1-for-2.2.14) wingel-usb-13 (requires usb-2.3.99-pre7-1-for-2.2.16 and obsoletes wingel-usb-12) Actually, the tools could have a few more goodies. While I've been waiting the guy doing the usb backport has released a new version which based on a newer 2.4 kernel and is relative to the 2.2.16 kernel, so what I'd really like is to use that patch instead. The tools would probably have to do some interesting backtracking to figure out that usb-2.4.0-for-2.1.16 is related to my wingel-usb-2.3.99-for-2.2.16 through a common ancestor usb-2.3.99-for-2.2.14. linux-2.2.16 usb-2.4.0-test2-pre2-for-2.2.16-v3 (requires linux-2.2.16 and obsoletes usb-2.3.99-pre7-1-for-2.2.14) wingel-usb-14 (requires usb-2.4.0-test2-pre2-for-2.2.16-v3 and obsoletes wingel-usb-13) I belive that linux-2.2.17 includes the usb-2.4 backport, so if I do that move I'll end up with: linux-2.2.17 wingel-usb-14 (requires linux-2.2.17) It would be nice if the tracking of the usb code doesn't disappear when it's incorporated into the kernel, since a new backport might be needed in the future, but I'm not sure if that is possible. I think I've written too much again, but I've been thinking and reading about the same thing for quite a while and just wanted to do a brain-dump of what I've been thinking of. Comments? /Christer -- "Just how much can I get away with and still go to heaven?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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, >which looks something like this (exact details to be determined): Add optional entry 'list', to send the patch only to a relevant list (for testing patch). ... > >Linus wants the body of patches to be in text format and not >MIME-encoded or uuencoded. kernel-paches should be capable to receive MIME and uuencoded mail. The robot will convert to the canonical text format. > > 3. A robot will process all patches for correctness (mostly, does it >apply?) and if it is a unified patch with the right base directory. >with the possibility of additional tests later such as >compilation tests, regression tests, etc. > 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: > ... > >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 database. > >We had some amount of discussion about whether a separate mailing >list would be a good idea, but we ruled the idea out because >fragmenting the kernel-related discussion would have negative >effects on development. If it becomes a problem, we can always >separate it later. IMHO we can already slit the lists in: linux-kernel : the normal developers list linux-bug (or linux-kernel-bug): for the "Alan Cox" tree (2.2 now) > 6. When and if Linus applies an entire patch, the patch-log will be >updated with a record of the changes. If Linus applies a partial >patch, then he will remove (or edit) the patch-log section of the >patch. 7. Testing. The people can test the patch and send a report. Thus it should be added the some happy/unhappy field somewhere on web. giacomo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 submissions effectively already. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 wouldn't do an
test for applyability :-)
>Linus wants the body of patches to be in text format and not
>MIME-encoded or uuencoded.
Well, since it'll be machine-parsed anyway, can't we just fix that up?
>Good patches are sent to the linux-kernel mailing list which is
>also where additional discussion about these patches can take
>place.
...and the patch-id should go in the Subject line i.e.
Subject: [PATCHID: KP3004] fix for video card catching fire
Then the web interface to the patch database could also have
the archived discussion available right there
Also there should be some flag to turn off the "automatic posting"
feature for the truly TRULY trivial patches ("i found a spelling
error in a comment") that just don't merit discussion
> - Linus should reject most out-of-band patches if this is to work.
Yes, but you should be able to select people other than Linus that
they want the patch sent to (and probably different mailing lists you
want the patch discussed on). That way this can scale to the various
maintainers. For instance if I haved a great new networking feature
I could have the system send it to davem (assuming that he signs
up for it - I'm just using him as an example) and discussion of it
on netdev. David decides that he likes the patch, and he sends
a (GPG/PGP signed) message to the server indicating this. Now the
patch goes into Linus's queue (and lkml) with a note indicating
that davem has blessed it.
Of course, other developers with public keys on file could also tag it
so that if a patch touches several different subsystems it can get
"signed off on" by the involved maintainers before Linus has to make
a call.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 entities. How exactly does a system to tracking patches and bugs/fixes (not to mention helping Linus and Ted) not help developers? In other words, it is meant to help all three entities. Anyway, I understand your request, but it's not my call. Obviously, it's better if patches successfully apply to the live tree the first time, but aside from that, it doesn't have much effect on the mechanics of the patch management system. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 see what has been applied, from whom, descriptions, etc. 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 entities. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 problem. Realtime diffs are good for developers, not as useful for someone trying to track bug reports and see what has been applied, from whom, descriptions, etc. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 > patches in publicly accessible place may become an interesting > problem. We could add a "security" or "private" flag that would do the right thing. I haven't asked Linus about how he wants security-sensitive stuff handled (OOB or with the kernel-patch system but not public). In terms of rewrites, that's why there is an "obsoletes" tag. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. > >Optional tags: > > "Fixes" - followed by one or more bug numbers (tracked by tytso > for now). For example, "T0001" might be tytso bug > number 0001. > > "Obsoletes" - followed by one or more kernel-patch identifiers. > > For example, "KP7555". > > "Requires" - followed by one or more kernel-patch identifiers. >For example, "KP7555". > > "Cc" - followed by one or more email addresses to be carbon-copied > on success. > > "Flags" - followed by one or more supported flags. > For example, "experimental" (that is, don't submit > anything to Linus). > >The tags are basically in RFC 822 format, but are placed in the body >of the email. (Additional lines are preceeded by whitespace, tags are >followed by a colon, etc.) > >Linus wants the body of patches to be in text format and not >MIME-encoded or uuencoded. > > 3. A robot will process all patches for correctness (mostly, does it >apply?) with the possibility of additional tests later such as >compilation tests, regression tests, etc. > > 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: > Would it be possible to have an optional Id: tag where you could 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. astor -- Alexander Kjeldaas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 database. 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 patches in publicly accessible place may become an interesting problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Proposal: Linux Kernel Patch Management System
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. Description of the problem: 1. There is no system that archives and tracks Linux kernel patches. 2. There isn't a good way of marking that a particular patch is believed to address a particular problem on the TODO list. (Patches should be tied to the TODO items.) 3. There is no archival system and no easy way to determine which patches have made it into the kernel. Proposal: 1. Developers submit all Linux kernel patches to [EMAIL PROTECTED] (not in place yet, so don't start sending patches). 2. Each patch will conform to a standardized, but simple, text format, which looks something like this (exact details to be determined): --- To: [EMAIL PROTECTED] Subject: this is a short description of the patch : : --- 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. Optional tags: "Fixes" - followed by one or more bug numbers (tracked by tytso for now). For example, "T0001" might be tytso bug number 0001. "Obsoletes" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Requires" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Cc" - followed by one or more email addresses to be carbon-copied on success. "Flags" - followed by one or more supported flags. For example, "experimental" (that is, don't submit anything to Linus). The tags are basically in RFC 822 format, but are placed in the body of the email. (Additional lines are preceeded by whitespace, tags are followed by a colon, etc.) Linus wants the body of patches to be in text format and not MIME-encoded or uuencoded. 3. A robot will process all patches for correctness (mostly, does it apply?) with the possibility of additional tests later such as compilation tests, regression tests, etc. 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 2000 @@ -1 +1,3 @@ +Applied patch KP7562 (2000/08/30) + Synopsis: () + (Yes, this prepend patch will always successfully apply.) 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 database. We had some amount of discussion about whether a separate mailing list would be a good idea, but we ruled the idea out because fragmenting the kernel-related discussion would have negative effects on development. If it becomes a problem, we can always separate it later. If the patch is long, the actual body of the patch won't be included in the email to the discussion mailing list, just a URL to the patch. Also, information about each applied patch can be retrieved from the patch web site (using the identifier). 5. If the robot doesn't like the patch, it will send the patch back to the submitter with a failure report. 6. When and if Linus applies an entire patch, the patch-log will be updated with a record of the changes. If Linus applies a partial patch, then he will remove (or edit) the patch-log section of the patch. Notes: - The web site will document version strings that will work with the server. Patches against unsupported versions will probably not work and should be rejected, sent to somewhere else, etc. - This system can be put into place quickly. - Linus should reject most out-of-band patches if this is to work. Future features? - PGP signing of patches - conversion of uuencoded patches to text format for people with broken mailers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 database. 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 patches in publicly accessible place may become an interesting problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. Optional tags: "Fixes" - followed by one or more bug numbers (tracked by tytso for now). For example, "T0001" might be tytso bug number 0001. "Obsoletes" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Requires" - followed by one or more kernel-patch identifiers. For example, "KP7555". "Cc" - followed by one or more email addresses to be carbon-copied on success. "Flags" - followed by one or more supported flags. For example, "experimental" (that is, don't submit anything to Linus). The tags are basically in RFC 822 format, but are placed in the body of the email. (Additional lines are preceeded by whitespace, tags are followed by a colon, etc.) Linus wants the body of patches to be in text format and not MIME-encoded or uuencoded. 3. A robot will process all patches for correctness (mostly, does it apply?) with the possibility of additional tests later such as compilation tests, regression tests, etc. 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: Would it be possible to have an optional Id: tag where you could 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. astor -- Alexander Kjeldaas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 patches in publicly accessible place may become an interesting problem. We could add a "security" or "private" flag that would do the right thing. I haven't asked Linus about how he wants security-sensitive stuff handled (OOB or with the kernel-patch system but not public). In terms of rewrites, that's why there is an "obsoletes" tag. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 wouldn't do an
test for applyability :-)
Linus wants the body of patches to be in text format and not
MIME-encoded or uuencoded.
Well, since it'll be machine-parsed anyway, can't we just fix that up?
Good patches are sent to the linux-kernel mailing list which is
also where additional discussion about these patches can take
place.
...and the patch-id should go in the Subject line i.e.
Subject: [PATCHID: KP3004] fix for video card catching fire
Then the web interface to the patch database could also have
the archived discussion available right there
Also there should be some flag to turn off the "automatic posting"
feature for the truly TRULY trivial patches ("i found a spelling
error in a comment") that just don't merit discussion
- Linus should reject most out-of-band patches if this is to work.
Yes, but you should be able to select people other than Linus that
they want the patch sent to (and probably different mailing lists you
want the patch discussed on). That way this can scale to the various
maintainers. For instance if I haved a great new networking feature
I could have the system send it to davem (assuming that he signs
up for it - I'm just using him as an example) and discussion of it
on netdev. David decides that he likes the patch, and he sends
a (GPG/PGP signed) message to the server indicating this. Now the
patch goes into Linus's queue (and lkml) with a note indicating
that davem has blessed it.
Of course, other developers with public keys on file could also tag it
so that if a patch touches several different subsystems it can get
"signed off on" by the involved maintainers before Linus has to make
a call.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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, which looks something like this (exact details to be determined): Add optional entry 'list', to send the patch only to a relevant list (for testing patch). ... Linus wants the body of patches to be in text format and not MIME-encoded or uuencoded. kernel-paches should be capable to receive MIME and uuencoded mail. The robot will convert to the canonical text format. 3. A robot will process all patches for correctness (mostly, does it apply?) and if it is a unified patch with the right base directory. with the possibility of additional tests later such as compilation tests, regression tests, etc. 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: ... 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 database. We had some amount of discussion about whether a separate mailing list would be a good idea, but we ruled the idea out because fragmenting the kernel-related discussion would have negative effects on development. If it becomes a problem, we can always separate it later. IMHO we can already slit the lists in: linux-kernel : the normal developers list linux-bug (or linux-kernel-bug): for the "Alan Cox" tree (2.2 now) 6. When and if Linus applies an entire patch, the patch-log will be updated with a record of the changes. If Linus applies a partial patch, then he will remove (or edit) the patch-log section of the patch. 7. Testing. The people can test the patch and send a report. Thus it should be added the some happy/unhappy field somewhere on web. giacomo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 format for people with broken mailers If you want to use PGP signatures, you need to allow MIME encoding. Otherwise non-7bit chars or even trailing spaces may lead to invalid PGP signatures. I've gone through that once. That's why I use this (admittedly ugly quoted-printable). Regards, -- Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 + 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. Even if dependencies will scale, testing/bug hunting won't. Anybody who has doubts about it really ought to recall the situation with Minix circa '91. IOW, don't go overboard with the dependencies - number of simultaneous patches translates into number of people that have to be involved in any work on patched kernel and _that_ will give a bottleneck. Extra generality is not going to do any good. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 to register domains with InterNIC, so email templates aren't that hard :-) We could even have a simple web page where you check a few boxes and fill in "URL to patch" and hit submit. The thing that needs the most thinking about is how to handle patches that don't have all this id crap and stuff on them. 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. It's just like when you're converting a helpdesk to use a ticket tracking system. You need to teach the tech people that when they run into someone in the hallway that says "hey, my printer is broken, come fix it" they they need to reply "you must be mistaken - if your printer were broken you would have filed a trouble ticket... since I have no trouble ticket your printer must be fine". People catch on quick. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 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 + mac68k-patch-2.5.18" -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 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 + mac68k-patch-2.5.18" I'm less than sure that keeping architecture-specific development out of the main tree is a good thing. Usual scenario (seen that quite a few times): tree for architecture foo is based on mainstream version x.y.z, in x.y.z+5 change happens in the mainstream tree and in-tree variant of arch/foo/* is updated. In x.y.z+10 foo-specific stuff gets synced with the main tree and we are getting a huge mess, since repository for foo didn't get the updates back in x.y.z+5. Having all stuff in one place may help, but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 modified kernel. Of course you wouldn't do an test for applyability :-) Yes you can. Use the "Requires" identifier to add all the previous patches first. But if the patch for the prerequisite modification isn't available, what is the point of submitting the patch? Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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. If that attitude is taken the large numbers of patches will never make 2.4 proper. I've never asked for that attitude. If only 50% of the patches go through this system, my job will be made *much* easier. That being said, the existing system isn't perfect. I can tell you that there are a large number of "obvious" bug fixes which haven't been making it into 2.4 proper. I do try to keep track of patches, although in a much more informal way than actual bug reports. Some of them are very simple error checking fixes which got submitted a month or two ago, got ignored by Linus, and are pretty much forgotten. If the patch author doesn't aggressively submit (in my personal experience I've had to sometime retransmit three or more times), the patch can get dropped, even if an outside observer thinks that it's an obviously good patch. I have an RMAIL folder containing about 120 patches that fall in this category. Some of the patches may still require some fixing, and some of the patches may have since been applied (although every so often I sweep through the folder and try to eliminate those that have already been accepted). My guess is that percentage of "good patches" that haven't been accepted is probably 50-75%. If anyone would like to go through that list and retransmit some of the more obviously correct ones to Linus, let me know, and I'll send you that RMAIL folder. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management 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 on lkml) - some *will* break something (just for test purposes) - some are known to be buggy, but testers are needed - some patches are simply not tested - some are reported to work for a long time on a small amount of computers - some are reported to work, perhaps with small bugs (ie: raid, reiserfs, ide... mainly real projects) - some are known to involve absolutely no risk at all (mainly documentation patches). I personnaly would like to be able to classify the patches I sometimes send this way. I know that some of them are not good and I wouldn't like people to blindly rely on them. With such a method, it would be easy to select "reliable fixes" or "features that need to be fixed" on a search engine. Moreover, if a patch is finally reported to break something, it would be easy to change it reliability level afterwards. If we also add a field that tells if the patch is to be included, not to be included or simply proposed, it would be helpfull to include synthetic reports about the global reliability. Just my two cents here, Willy ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 seen some pretty dim folks manage to register domains with InterNIC, so email templates aren't that hard :-) When I sent Linus ten or twenty patches, that means I'm filling in ten to twenty e-mail templates, yum :) Jeff -- Jeff Garzik | Windows NT Performance, Building 1024| on the next "In Search Of" MandrakeSoft, Inc. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 problem. Realtime diffs are good for developers, not as useful for someone trying to track bug reports and see what has been applied, from whom, descriptions, etc. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 see what has been applied, from whom, descriptions, etc. 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 entities. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 entities. How exactly does a system to tracking patches and bugs/fixes (not to mention helping Linus and Ted) not help developers? In other words, it is meant to help all three entities. Anyway, I understand your request, but it's not my call. Obviously, it's better if patches successfully apply to the live tree the first time, but aside from that, it doesn't have much effect on the mechanics of the patch management system. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 submissions effectively already. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management 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 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 been fixed. OK. 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 patch first. So under a "good" patch maintenance system, I'd have liked to generate the patch, and have it wait until I approve it. That way, it might be available for "public" testing by others, while I can give the "goahead" to send to Linus or retract the patch if it doesn't work as advertized. Another features that I REALLY REALLY would like in a patch maintenance system would be that it could try and automatically (re-)generate the patch against a different kernel version: Suppose I make a patch against 2.4.0-test8 and then Linus releases a newer version (possibly even before I give the "goahead bug Linus") Then applying my patch to 2.4.0-test9 and generating a new patch against 2.4.0-test9-clean is one possibility. The other is to apply patch-2.4.0-test9 to my patched kernel. The results could be compared for consistency. Also, sometimes a backport of a patch is required. Automating that as far as possible is useful! (What Larry McVoy seems to miss is that "automated patch-port failed" is a valid answer, as long as it works in 99% of the cases). Isn't this "new" patch maintenance system much like bitkeeper? Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 and Ted) not help developers? It has the potential to make more work for those of us who do our patch submissions effectively already. 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, 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 been fixed. Right now, having to paw through diff files to see when Linus has applied a particular patch (add grumble about lack of a source code control system) is really not fun. Alan did it for a while, and burned out, and I can tell you, I can't really blame him --- it's a lot of work. Is it really that hard to annotate the patch with a bit of information, and then send it off to a different mailing address instead of sending it directly to Linus and the l-k list? What can we do to make things simpler on developers? Certainly this isn't going to work unless the developers use it, and that means we need to keep things as easy as possible for the patch submitters. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Proposal: Linux Kernel Patch Management System
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 and Linus's life much easier. 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 been fixed. Right now, having to paw through diff files to see when Linus has applied a particular patch (add grumble about lack of a source code control system) is really not fun. Alan did it for a while, and burned out, and I can tell you, I can't really blame him --- it's a lot of work. Is it really that hard to annotate the patch with a bit of information, and then send it off to a different mailing address instead of sending it directly to Linus and the l-k list? What can we do to make things simpler on developers? Certainly this isn't going to work unless the developers use it, and that means we need to keep things as easy as possible for the patch submitters. Ted, 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 you do it. I'm willing to do it for USB, but I'm not willing to duplicate your work if you continue to do it. I don't expect you to know/understand all of the filesystem or I/O subsystem or VM or process issues and be able to track them without asking lots of questions. (Maybe you do, but I don't think that should be a requirement of the status-bot.) You should roll up reports from maintainers for a summary kernel status report. ~Randy PS: This is probably too good to be true and would require the assistance of lots of maintainers, but that's how it should be done IMO. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 mention helping Linus and Ted) not help developers? It has the potential to make more work for those of us who do our patch submissions effectively already. 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, 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 been fixed. Right now, having to paw through diff files to see when Linus has applied a particular patch (add grumble about lack of a source code control system) is really not fun. Alan did it for a while, and burned out, and I can tell you, I can't really blame him --- it's a lot of work. Is it really that hard to annotate the patch with a bit of information, and then send it off to a different mailing address instead of sending it directly to Linus and the l-k list? What can we do to make things simpler on developers? Certainly this isn't going to work unless the developers use it, and that means we need to keep things as easy as possible for the patch submitters. Something I've been planning on implementing for some time now is a small patch to patch, so that it recognises lines of the form: Notify: email,id in a patch, then an email is sent to email stating that a patch with ID 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. This way, I wouldn't have to sift through a diff to see if my patch has been applied. And it doesn't require any change in the way Linus works. An extension which does change the way he works would involve him running a patch --reject on a patch before hitting 'd'. And possibly also a patch --not-now. It also doesn't require developers to change their habits. It's entirely optional. Separately, making Linus' unpacked working trees available: ftp://ftp.??.kernel.org/pub/linux/kernel/v*/LIVE/ would make patch generation a lot easier. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 developers, not as useful for someone trying to track bug reports and see what has been applied, from whom, descriptions, etc. Ok, so lets be clear. Who is this facility really meant for? Linus (to decrease his I suspect this new system is designed for the needs of lower-volume patch submitters like myself. For example, I had to submit my latest patch (a binary compatibility fix) to Linus about 8 times (without ever getting a response I might add) before it showed up in the latest kernel. Very inefficient. Furthermore, I had to make a couple of changes to the patch -- first a logic error then a spelling error. Each required a new patch cluttering poor Linus' Inbox. With a system in place where I could have updated a numbered patch, and had immediate feedback on its status, life would have simpler for me, and Linus would not have had his mailbox so cluttered -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 Linus all the time to make pre-patches so I can send him known clean diffs. This is orthogonal to the patch management system, but I agree this would be highly useful. Would Linus be willing to have an hourly cron job that rsync'ed his live kernel sources to ftp.kernel.org? (I suspect a number of patch submitters would then have rsync jobs that would sync from kernel.org to their local directories. I know I would.) It would certainly make it easier to send clean patches to Linus. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
-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. I guess this should wait until Larry makes a comment. David Lang Isn't this "new" patch maintenance system much like bitkeeper? Heh. I'm surprised Larry hasn't jumped into this discussion by now. What we've implemented is a very small subset of the sort of features 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; that's what's necessary to really get a good feel for how it works and why it's so nice. The problem, though, is that bitkeeper is only useful if a large number of other developers use it, and given its non-OSS license, it's not clear it will get that critical mass. Personally, I have no problem with the license. But if there are enough other people who are license fanatics who do have a problem with it, then bitkeeper loses a lot of value for me. If Linus were willing to dictate from high that we were going to use bitkeeper, and that all patches had to come in as bitkeeper changelogs, then that might get us critical mass. If he doesn't do that, though, my big concern is whether or not it'll be able to garner enough critical mass for it to be worth the trouble for kernel developers to want to spend time learning it. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQEVAwUBOb/Qvz7msCGEppcbAQEOAQf/e++B2UDp326KCg88YUvDvhvKzUBYPkKk Y6kqaDgQdfso7wtzIEtmxbboFCEndzsby8ccnF/OW1+7/OlZjaxNH2SOizZnND/K l2HquT8ptE94VV40IUqgjaOsy5+bx43iI+WD5eOvjtOGnkVYSro5b3IJLQ1q5rBV 1ae0coqsF0fCnL/5LjKkJoVIrB0jQU2X7703UKP2kex//45gnRokioQ7Yf2M3jIQ Dx7XL+hvAtmWmo5/dSMCwQWC/8QWghqQJ+JK5gzUrjvyn+JqV68+B1Ok6ykTLLy7 XTUiGg2VCmzjNjDfsiWpiOTHl/NrS/Ojo0v1lk3Er8SD37E+83TicQ== =UsJX -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 you do it. I'm willing to do it for USB, but I'm not willing to duplicate your work if you continue to do it. I don't expect you to know/understand all of the filesystem or I/O subsystem or VM or process issues and be able to track them without asking lots of questions. (Maybe you do, but I don't think that should be a requirement of the status-bot.) Tell you what. If you're willing to handle USB bug reports, I'll segregate them into one area, and then have you send me updates every few days. The updates should hopefully include bug reports from users who post to linux-kernel. What I currently do is save those e-mail messages in a mail folder, and then include their names (but not e-mail address) in the bug list. You should roll up reports from maintainers for a summary kernel status report. If maintainers are willing to do a good job capturing bug reports, that's great. We can break those out into subsystems. The problem is that sometimes maintainers can get egos involved and not be willing to admit that something might be a bug, especially if the bug report doesn't contain full information. This works much better if the subsystem is maintained by a team, and one person of that team is responsible for the overal bug tracking for that subsystem. It sounds like the USB subsystem meets this criteria quite handily. PS: This is probably too good to be true and would require the assistance of lots of maintainers, but that's how it should be done IMO. Well, yes, and in a perfect world Linus would be using a bug tracking system. But we've managed quite well despite that not being the case. :-) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 no problem with the license. But if there are enough other people who are license fanatics who do have a problem with it, then bitkeeper loses a lot of value for me. If Linus were willing to dictate from high that we were going to use bitkeeper, and that all patches had to come in If Linus requires bitkeeper only then there will be two kernel trees. Linux ceases to be free software when you require nonfree software to contribute it. Note: I think the BK license is fair, I understand Larry's problem and I support his right to use whatever license he likes. I also happen to support my right to decline to use his software - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Proposal: Linux Kernel Patch Management System
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 been fixed. Ok, I claim: 1) I always have an uptodate bug list for the things I maintain 2) I always notify you instantly when Linus puts up a pre-patch that closes bugs in areas I maintain. 3) By going over every diff by hand I (and others) spot bugs that would not be found easily by testing. It's free code review to keep going over relative diffs like this as new pre-patches come out. (I'd say there about 10 to 20 people who, like me, religiously read over and review the diffs between pre-patches as they are released. There is _real_ value in this. It won't all stop due to the patch robot, but you for one aparently will do it less often than you do now.) So changing the mechanism is going to make my life easier and better how? But still, Ted, I respect you enough that if you are so convinced this is going to make things better, I'm going to give it a try as is. No problem. However, I contend that some of us will feel that they are being punished for doing a good job thus far without this patch robot. I don't think the big problem is VFS, MM, or networking bug 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. If you agree with the previous paragraph, then my final argument is that forcing these driver "maintainers" to go through the patch robot system will not necessarily get them to look at the bug list and hunt people down to fix bugs. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
