[was: Re: Maintainers master list]
Wed Jun 27 2001 - 10:12:18 EST, Jes Sorensen said: > A good place to start would be to write a script that checks the email > addresses listed in there for bounces say every 6 months (not too > often or people will get grumphy). Oh and maybe include the data about > the person so he/she can verify it's ok, maybe this way we can get > forget this meta-data sillyness. OK, but what about those people who have two addresses listed in the mainainers-file? Do they have to answer those autogenerated mails twice? A sollution to this may be that we only allow one address per entry, but I think that some people will object to this. And what should we do if the mail bounces? Should we remove the entry, or should we try to contact the (former) maintainer? I think this would be difficult, because we can't reach them by mail any more... Regards, Marc Brekoo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[was: Re: Maintainers master list]
Wed Jun 27 2001 - 10:12:18 EST, Jes Sorensen said: A good place to start would be to write a script that checks the email addresses listed in there for bounces say every 6 months (not too often or people will get grumphy). Oh and maybe include the data about the person so he/she can verify it's ok, maybe this way we can get forget this meta-data sillyness. OK, but what about those people who have two addresses listed in the mainainers-file? Do they have to answer those autogenerated mails twice? A sollution to this may be that we only allow one address per entry, but I think that some people will object to this. And what should we do if the mail bounces? Should we remove the entry, or should we try to contact the (former) maintainer? I think this would be difficult, because we can't reach them by mail any more... Regards, Marc Brekoo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
On Tue, 26 Jun 2001, Robert Love wrote: > me. I took issue with the MAINTAINERS file when Eric brought it up > originally. However, I don't think drastic measures need to be taken. > I have seen a lot of ideas, including Meta-data in the kernel source. > > What I think we need is the simple solution: find a maintainer for the > file, cleanup the current cruft and misinformation, and then actively > work to keep the file current. I am willing to be this maintainer. > > I am not a major "maintainer" in the kernel, but I have and do > contribute. Thus I think this is a good task for me. I am willing and > wanting to do this. Comments? I've been waiting for an opportunity like this to join in, so I'd be very happy to help you with this. (This would be my first contribution to linux, please be gentle :-) Regards, Marc Brekoo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
On 26 Jun 2001 16:03:05 -0300, Rik van Riel wrote: > On Tue, 26 Jun 2001, Holzrichter, Bruce wrote: > > > respect Eric, and all the developers work. How about starting > > with a simple MAINTAINERS file maintainer? Someone to actively > > follow project developers and contact info? > > That's the best idea I've read so far. > > Any takers? me. I took issue with the MAINTAINERS file when Eric brought it up originally. However, I don't think drastic measures need to be taken. I have seen a lot of ideas, including Meta-data in the kernel source. What I think we need is the simple solution: find a maintainer for the file, cleanup the current cruft and misinformation, and then actively work to keep the file current. I am willing to be this maintainer. I am not a major "maintainer" in the kernel, but I have and do contribute. Thus I think this is a good task for me. I am willing and wanting to do this. Comments? -- Robert M. Love rml at ufl.edu rml at tech9.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
>What happens now when somebody takes over responsibility for a file >or subsystem and the MAINTAINERS file doesn't get patched, either because >that person forgets to send a MAINTAINERS update or Linus doesn't >happen to take the MAINTAINERS patch for a while? >What happens when I look at a file and it's not obvious which >subsystem it belongs to? Sure, I can grovel through MAINTAINERS. But >how do I know which verbal description matches the function of the >cryptically-commented or uncommented code I have in front of me? >Distributed-information problems need distributed-information >solutions. Locality is your friend. This crowd should know that >if anybody should. I'll throw this back out again, and if you all are not interested, drop it if you want. I am looking for places and points to help out where I see issues come up several times, and this is one I have seen occasionally. I am not advocating Eric's proposal for sweeping maintainer's changes, though I respect Eric, and all the developers work. How about starting with a simple MAINTAINERS file maintainer? Someone to actively follow project developers and contact info? Not a small or simple project, I understand, but maybe a central point to send patches to Linus for the Maintainers file? Just my two cents, on a Tuesday :o) B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
On Tue, 26 Jun 2001, Robert Love wrote: me. I took issue with the MAINTAINERS file when Eric brought it up originally. However, I don't think drastic measures need to be taken. I have seen a lot of ideas, including Meta-data in the kernel source. What I think we need is the simple solution: find a maintainer for the file, cleanup the current cruft and misinformation, and then actively work to keep the file current. I am willing to be this maintainer. I am not a major maintainer in the kernel, but I have and do contribute. Thus I think this is a good task for me. I am willing and wanting to do this. Comments? I've been waiting for an opportunity like this to join in, so I'd be very happy to help you with this. (This would be my first contribution to linux, please be gentle :-) Regards, Marc Brekoo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
What happens now when somebody takes over responsibility for a file or subsystem and the MAINTAINERS file doesn't get patched, either because that person forgets to send a MAINTAINERS update or Linus doesn't happen to take the MAINTAINERS patch for a while? What happens when I look at a file and it's not obvious which subsystem it belongs to? Sure, I can grovel through MAINTAINERS. But how do I know which verbal description matches the function of the cryptically-commented or uncommented code I have in front of me? Distributed-information problems need distributed-information solutions. Locality is your friend. This crowd should know that if anybody should. I'll throw this back out again, and if you all are not interested, drop it if you want. I am looking for places and points to help out where I see issues come up several times, and this is one I have seen occasionally. I am not advocating Eric's proposal for sweeping maintainer's changes, though I respect Eric, and all the developers work. How about starting with a simple MAINTAINERS file maintainer? Someone to actively follow project developers and contact info? Not a small or simple project, I understand, but maybe a central point to send patches to Linus for the Maintainers file? Just my two cents, on a Tuesday :o) B. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
On 26 Jun 2001 16:03:05 -0300, Rik van Riel wrote: On Tue, 26 Jun 2001, Holzrichter, Bruce wrote: respect Eric, and all the developers work. How about starting with a simple MAINTAINERS file maintainer? Someone to actively follow project developers and contact info? That's the best idea I've read so far. Any takers? me. I took issue with the MAINTAINERS file when Eric brought it up originally. However, I don't think drastic measures need to be taken. I have seen a lot of ideas, including Meta-data in the kernel source. What I think we need is the simple solution: find a maintainer for the file, cleanup the current cruft and misinformation, and then actively work to keep the file current. I am willing to be this maintainer. I am not a major maintainer in the kernel, but I have and do contribute. Thus I think this is a good task for me. I am willing and wanting to do this. Comments? -- Robert M. Love rml at ufl.edu rml at tech9.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
On Friday 22 June 2001 17:19, Timur Tabi wrote: > ** Reply to message from "Eric S. Raymond" <[EMAIL PROTECTED]> on Fri, 22 Jun > 2001 17:09:45 -0400 > > > What happens now when somebody takes over responsibility for a file > > or subsystem and the MAINTAINERS file doesn't get patched, either because > > that person forgets to send a MAINTAINERS update or Linus doesn't > > happen to take the MAINTAINERS patch for a while? > > Wouldn't this whole problem go away if the kernel source were stored in a > master CVS repository? Maintainers would have write access to their > respective code, but only Linus and Alan would have delete access. > Everyone else would have read-only access. This has been suggested about eight thousand times so far, and the answer is "no". I'm fairly certain there's a FAQ entry on this. The reason Linus won't do it is it conflicts with the way he works. He approves patches by reading through them in his mail reader (Pine, I think) and appending the ones he likes to a file. Then when he's done reading mail he pipes the whole file to patch and it goes into his tree. (I'm pondering an idea of sending Linus a perl script that he can use to pipe that file to patch which will split out the individual emails and forward them to an otherwise read-only "patches-linus-has-applied" mailing list. The important part of this idea is it doesn't change the way he works or make him do any extra work at all. And we get the documentation in the emails and a record of what patches got applied when. And this WOULD allow a fairly granular CVS tree to be kept up-to-date by a third party who simply subscribes to the list and automatically feeds the patches into CVS.) But Linus will NOT allow a line of code into his tree which he hasn't personally approved. He may apply patches forwarded to him by maintainers without thoroughly reading them first, but he still approves them and knows when they go in, and makes sure they don't conflict with anything else he's applying or already applied. So in a "Linux-kernel CVS tree", only Linus would have the ability to check stuff in, so he considers it a waste of time and just sends us tarballs instead. The fact Linus does this is a bottleneck, sure. But the fact we've got one guy in charge making decisions and vetoing anything that shouldn't go in is also the main reason we've got a coherent source base. Look at the ongoing fight between Rik and Andrea: even smart people who are generally right can disagree about architectural direction, and if they both make changes without somebody steering Bad Things will result. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
On Friday 22 June 2001 17:19, Timur Tabi wrote: ** Reply to message from Eric S. Raymond [EMAIL PROTECTED] on Fri, 22 Jun 2001 17:09:45 -0400 What happens now when somebody takes over responsibility for a file or subsystem and the MAINTAINERS file doesn't get patched, either because that person forgets to send a MAINTAINERS update or Linus doesn't happen to take the MAINTAINERS patch for a while? Wouldn't this whole problem go away if the kernel source were stored in a master CVS repository? Maintainers would have write access to their respective code, but only Linus and Alan would have delete access. Everyone else would have read-only access. This has been suggested about eight thousand times so far, and the answer is no. I'm fairly certain there's a FAQ entry on this. The reason Linus won't do it is it conflicts with the way he works. He approves patches by reading through them in his mail reader (Pine, I think) and appending the ones he likes to a file. Then when he's done reading mail he pipes the whole file to patch and it goes into his tree. (I'm pondering an idea of sending Linus a perl script that he can use to pipe that file to patch which will split out the individual emails and forward them to an otherwise read-only patches-linus-has-applied mailing list. The important part of this idea is it doesn't change the way he works or make him do any extra work at all. And we get the documentation in the emails and a record of what patches got applied when. And this WOULD allow a fairly granular CVS tree to be kept up-to-date by a third party who simply subscribes to the list and automatically feeds the patches into CVS.) But Linus will NOT allow a line of code into his tree which he hasn't personally approved. He may apply patches forwarded to him by maintainers without thoroughly reading them first, but he still approves them and knows when they go in, and makes sure they don't conflict with anything else he's applying or already applied. So in a Linux-kernel CVS tree, only Linus would have the ability to check stuff in, so he considers it a waste of time and just sends us tarballs instead. The fact Linus does this is a bottleneck, sure. But the fact we've got one guy in charge making decisions and vetoing anything that shouldn't go in is also the main reason we've got a coherent source base. Look at the ongoing fight between Rik and Andrea: even smart people who are generally right can disagree about architectural direction, and if they both make changes without somebody steering Bad Things will result. Rob - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
** Reply to message from "Eric S. Raymond" <[EMAIL PROTECTED]> on Fri, 22 Jun 2001 17:09:45 -0400 > What happens now when somebody takes over responsibility for a file > or subsystem and the MAINTAINERS file doesn't get patched, either because > that person forgets to send a MAINTAINERS update or Linus doesn't > happen to take the MAINTAINERS patch for a while? Wouldn't this whole problem go away if the kernel source were stored in a master CVS repository? Maintainers would have write access to their respective code, but only Linus and Alan would have delete access. Everyone else would have read-only access. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
>I have proposed that the MAINTAINERS file should be replaced by >metadata markup in the kernel sources themselves, distributed so that >it will naturally be kept up to date by the people named in it and >mechanically gathered into a generated MAINTAINERS at make dep time. >I still think this is the right thing, and was planning to revisit the >issue after the 2.5 cutover. But it certainly doesn't have to be me that >does it, and between CML2 and the Configure.help file and countering >Microsoft's anti-open-source propaganda war I have plenty of other things >to worry about. >So if you want to take this on, I encourage you to go to it. Want a >copy of the metadata schema I wrote up? I would be happy to look at any work that you have already done on this, so feel free to send it along to me. Let's take a look at what you have and where we might be able to take this. B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Maintainers master list?
I have proposed that the MAINTAINERS file should be replaced by metadata markup in the kernel sources themselves, distributed so that it will naturally be kept up to date by the people named in it and mechanically gathered into a generated MAINTAINERS at make dep time. I still think this is the right thing, and was planning to revisit the issue after the 2.5 cutover. But it certainly doesn't have to be me that does it, and between CML2 and the Configure.help file and countering Microsoft's anti-open-source propaganda war I have plenty of other things to worry about. So if you want to take this on, I encourage you to go to it. Want a copy of the metadata schema I wrote up? I would be happy to look at any work that you have already done on this, so feel free to send it along to me. Let's take a look at what you have and where we might be able to take this. B. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainers master list?
** Reply to message from Eric S. Raymond [EMAIL PROTECTED] on Fri, 22 Jun 2001 17:09:45 -0400 What happens now when somebody takes over responsibility for a file or subsystem and the MAINTAINERS file doesn't get patched, either because that person forgets to send a MAINTAINERS update or Linus doesn't happen to take the MAINTAINERS patch for a while? Wouldn't this whole problem go away if the kernel source were stored in a master CVS repository? Maintainers would have write access to their respective code, but only Linus and Alan would have delete access. Everyone else would have read-only access. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
