login
Search
Since T: and L: are already taken, add U: for URL of todo list. Also add the RCU todo list to both the RCU and RCUTORTURE projects. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> diff --git a/MAINTAINERS b/MAINTAINERS index 3f21c27..1c57186 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -103,6 +103,7 @@ Descriptions of section entries: matches patches or files that contain one or more of the words printk, pr_info or pr_err One regex pattern per line. Multiple K: lines acceptable. + U: URL of todo list. Note: For the hard of thinking, this list is meant to remain in alphabetical order. If you could add yourselves to it in alphabetical order that would be @@ -4801,6 +4802,7 @@ M: Josh Triplett <josh@freedesktop.org> M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> S: Supported T: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git +U: http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html F: Documentation/RCU/torture.txt F: kernel/rcutorture.c @@ -4826,6 +4828,7 @@ M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> W: http://www.rdrop.com/users/paulmck/rclock/ S: Supported T: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git +U: http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html F: Documentation/RCU/ F: include/linux/rcu* F: include/linux/srcu* --
While you are at it, I am aware at least of these additional ones: http://vger.kernel.org/~davem/net_todo.html http://wireless.kernel.org/en/developers/todo-list https://ieee1394.wiki.kernel.org/index.php/To_Do http://selinuxproject.org/page/Kernel_Development -- Jiri Kosina SUSE Labs, Novell Inc. --
Also renamed NETWORKING patch queue from "W:" to "Q:" Signed-off-by: Joe Perches <joe@perches.com> --- MAINTAINERS | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a1df54b..3d29d8c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2346,6 +2346,7 @@ FIREWIRE SUBSYSTEM M: Stefan Richter <stefanr@s5r6.in-berlin.de> L: linux1394-devel@lists.sourceforge.net W: http://ieee1394.wiki.kernel.org/ +W: https://ieee1394.wiki.kernel.org/index.php/To_Do T: git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git S: Maintained F: drivers/firewire/ @@ -4039,7 +4040,8 @@ NETWORKING [GENERAL] M: "David S. Miller" <davem@davemloft.net> L: netdev@vger.kernel.org W: http://www.linuxfoundation.org/en/Net -W: http://patchwork.ozlabs.org/project/netdev/list/ +W: http://vger.kernel.org/~davem/net_todo.html +Q: http://patchwork.ozlabs.org/project/netdev/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git S: Maintained @@ -4071,6 +4073,7 @@ S: Maintained NETWORKING [WIRELESS] M: "John W. Linville" <linville@tuxdriver.com> L: linux-wireless@vger.kernel.org +W: http://wireless.kernel.org/en/developers/todo-list Q: http://patchwork.kernel.org/project/linux-wireless/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git S: Maintained @@ -5114,6 +5117,7 @@ M: James Morris <jmorris@namei.org> M: Eric Paris <eparis@parisplace.org> L: selinux@tycho.nsa.gov (subscribers-only, general discussion) W: http://selinuxproject.org +W: http://selinuxproject.org/page/Kernel_Development T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git S: Supported F: include/linux/selinux* --
Hi Paul I think W: already works perfectly well for this use. From MAINTAINERS: W: http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html --
OK, how about the following, then?
Thanx, Paul
------------------------------------------------------------------------
commit 47d3177f3435e2600c98370dc07ed20a3a585c32
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Thu Aug 26 08:59:13 2010 -0700
MAINTAINERS: add RCU todo list
Add the RCU todo list to RCUTORTURE and RCU. Also add a note to
W: stating that it may be used for todo list information.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f21c27..e02882b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -70,7 +70,7 @@ Descriptions of section entries:
P: Person (obsolete)
M: Mail patches to: FullName <address@domain>
L: Mailing list that is relevant to this area
- W: Web-page with status/info
+ W: Web-page with status/info/todo
Q: Patchwork web based patch tracking system site
T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.
S: Status, one of the following:
@@ -4799,6 +4799,8 @@ F: drivers/net/wireless/ray*
RCUTORTURE MODULE
M: Josh Triplett <josh@freedesktop.org>
M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
+W: http://www.rdrop.com/users/paulmck/RCU/
+W: http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html
S: Supported
T: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
F: Documentation/RCU/torture.txt
@@ -4823,7 +4825,8 @@ F: net/rds/
READ-COPY UPDATE (RCU)
M: Dipankar Sarma <dipankar@in.ibm.com>
M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
-W: http://www.rdrop.com/users/paulmck/rclock/
+W: http://www.rdrop.com/users/paulmck/RCU/
+W: http://kernel.org/pub/linux/kernel/people/paulmck/rcutodo.html
S: Supported
T: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
F: Documentation/RCU/
--
Got to say I really think overloading W which means web page/status information isn't a very good idea: jejb@mulgrave:~/git/linux-2.6> grep -w 'W:' MAINTAINERS |wc -l 371 We already have ~400 of them ... how's anyone looking for a todo list going to find the right one in amongst all the others (assuming a newbie with no subject predisposition simply trying to find any todo list). James --
Did you have an alternate suggestion? Do you prefer a Grand Unified Todo List? I don't mind the kernelnewbies list/location, but we need to give it some TLC. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --
New tag was fine ... kernelnewbies wiki is also fine. My point is that if we're going to put them somewhere, lets make it obvious, not a find I already gave my opinion on that ... --
On Thu, 26 Aug 2010 09:29:23 -0700 I have to say that I'm not yet convinced that keeping a todo list in a place that's not with the actual source code does not give me warm fuzzy feelings. Every time we've kept information about the source code separate from our source code it's been a failure; it gets out of sync fast and it just adds to the maintenance. A git commit that both fixes an issue and removed the line from the todo file (or moves it to a "done" section, whatever) is the ultimate goal obviously... having a U: seems to go in exactly the opposite direction. otoh having a kernel-doc type (eg structured, parsable) way of gathering todo items throughout the tree.... that I can see as useful. --
I still feel that if maintainer is willing to keep TODO list on web for whatever reason (hyperlinks, nice tables, images, whatever), then he should be free to do so. The U: (or whatever) tag in MAINTAINERS file still could point to file in the actual sources, in cases maintainer choses to have the list there, of course. -- Jiri Kosina SUSE Labs, Novell Inc. --
TODO might disappear without implementation, if you decide that the idea Yep, I do not want to be restricted to updating TODO during merge window only as the changes to the list are not likely to count as bugfixes ;) -- Dmitry --
We could add a toplevel "todo/" directory, with each project file in it and a list of things todo. When the todo is done, that same commit could remove the todo item. Just a worthless thought ;-) -- Steve --
I am with Dmitry on this one. I really don't want to be prevented from updating my todo items outside of the merge window. Different people have different needs, so we need to accommodate todo lists both within and outside the kernel source tree. Thanx, Paul --
Actually, that would probably happen automatically. If you are working on a subsystem, you should probably be working against the git tree for that subsystem. When something is done in the todo list, the subsystem tree would be updated with the commit that does said change. Then, the list is maintained outside of mainline (in the subsystem git tree) and will automatically update mainline in the next merge window when the tree is pulled. -- Steve --
Seriously, given the known history of Documentation/feature-removal-schedule.txt, I don't think this is going to work. Thanks, Rafael --
But this would mean that the version of the todo list in Linus' tree is usually a release (3 months) out of date. It would be a good idea for a list maintained this way to include instructions on how to find the current version, lest some unsuspecting person waste time working on items that are already fixed and waiting for the next merge. -Tony --
There are already reasonable mechanisms for this. It's perfectly fine to have multiple T: entries, one for a current tree, another for a -next tree. SECTION - name M: who <email.address> T: git <url> T: git <url-next> F: dir/file_pattern Linus rarely seems to object to pulling Documentation updates. Note the Documentation updates after any -rc2 $ for ((i=25 ; i<36 ; i++)) ; do \ cv=v2.6.$i-rc2..v2.6.$i ; \ echo -n "$cv: " ; \ git log --pretty=oneline --no-merges $cv -- Documentation | wc -l; \ done v2.6.25-rc2..v2.6.25: 87 v2.6.26-rc2..v2.6.26: 48 v2.6.27-rc2..v2.6.27: 65 v2.6.28-rc2..v2.6.28: 67 v2.6.29-rc2..v2.6.29: 50 v2.6.30-rc2..v2.6.30: 44 v2.6.31-rc2..v2.6.31: 35 v2.6.32-rc2..v2.6.32: 74 v2.6.33-rc2..v2.6.33: 31 v2.6.34-rc2..v2.6.34: 32 v2.6.35-rc2..v2.6.35: 8 --
If I just downloaded a big tar ball and started trolling randomly through the source how am I going to know what the MAINTAINERS file is? How am I going to know that todo entries should be located by opening the magic file called MAINTAINERS, looking for T: entries, and then checking out the listed web page? random todo files scattered around the kernel, all with references that might duplicate MAINTAINERS info, but which make it clear to a complete newbie how development for that subsys works, seems simple and easy. subsys maintainers might want to put all kinds of info in there, what tree to develop against (rarely a tar ball of Linus' tree), pointers to particularly relevant Documentation/ files, how they like to get patches, where those patches usually end getting applied, what lists and cc's to use, things like that. I just think that hoping a newbie is going to naturally know MAINTAINERS isn't the best. -Eric --
I think that tarball trolling is pretty rare these days. Any one know the statistics for kernel git traffic vs tarballs? --
My experience is that there's an awful lot of people working with whatever kernel has been provided by their vendor rather than getting kernels direct from kernel.org and they tend to only look as far as the The kernel.org traffic is going to miss people using distribution or other non kernel.org traffic so might be a bit misleading. --
On Wed, Sep 1, 2010 at 11:54 AM, Mark Brown People that are working with vendor provided kernels do not tend to contribute upstream. And those who want to contribute will find what -- Sincerely Yours, Mike. --
While the majority of people won't contribute upstream some do, or come looking for support, and MAINTAINERS doesn't seem entirely reliable. I think some people are expecting it to be for maintainers rather than a list of them. --
Probably because you started with Documentation/* which explains it in If they can't find the MAINTAINERS file in the top level directory, and haven't read SubmittingPatches either then maybe that's not a complete disaster at that point ? --
cat /sys/kernel/todo cat /sys/module/*/todo -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --
Those folk might be better playing/practicing/honing skills in staging where there already are TODO files. --
$ find -name TODO | wc -l 40 --
Hopefully the todo lists have "todo" or "TODO" in the URL. ;-) Thanx, Paul --
That may not be the case if you use a public todo list on rememberthemilk.com. It doesn't make sense to end multiple todo list names with "todo" for on site that's specifically designed to help with todo lists. I like the idea of a separate letter for todo lists URLs. Sarah Sharp --
So do I! ;-) Another option for URLs not containing "todo" or "TODO" is something like: W: rememberthemilk.com (todo) I suspect that most people would know not to include " (todo)" in the string they fed to their browser. Seem reasonable? Thanx, Paul --
On Thu, 26 Aug 2010 16:23:23 -0700 Yes as long as it is easy to machine-parse. The idea that appeals to me is for the 'todo list' URL to be an RSS feed, and we have some site that automagically extracts all the todo lists and creates a todo planet. (todo.kernelplanet.org ??) Then interested parties could subscribe to that and watch the ideas go by. But getting a useful subset of maintainers to put a todo list in an RSS feed feels somewhat like herding wild-cats... NeilBrown --
I think the best approach would be to start doing it and hope others
follow suit.
What would the standard template be for something like this? Would we
just stick to title, link, description?
-eric
--
These W: links from MAINTAINERS seem dead. Should they be removed? W: drama.obuda.kando.hu/~fero/cgi-bin/hgafb.shtml W: firstlight.net/cvs W: ftp.openlinux.org/pub/people/hch/vxfs W: geocities.com/i0xox0i W: janitor.kernelnewbies.org/ W: logfs.org W: megaraid.lsilogic.com W: miguelojeda.es/auxdisplay.htm W: oops.ghostprotocols.net W: prism54.org W: projects.buici.com/arm W: twibble.org/dist/dc395x/ W: www.baycom.org/~tom/ham/ham.html W: www.developer.ibm.com/welcome/netfinity/serveraid.html W: www.ibm.com/linux/ltc/projects/ppc W: www.linux-ntfs.org/content/view/19/37/ W: www.linux-usb.org/usbnet W: www.neteffect.com W: www.nt.tuwien.ac.at/~kkudielk/Linux/ W: www.openib.org/ W: www.torque.net/sg W: www.uni-mainz.de/~langm000/linux.html W: www.winischhofer.at/linuxsisusbvga.shtml --
> W: www.openib.org/ Should be replaced by www.openfabrics.org/ I'll queue up a patch. - R. --
this is changed to http://kernelnewbies.org/KernelJanitors Ill send out a patch if youd like, and/or you got it already.. Justin P. Mattock --
I don't have a tree that gets pulled. Andrew Morton generally picks up MAINTAINERS fixes. --
alright.. I sent it out to trivial.. if they want it's it there.. Justin P. Mattock --
I'll queue-up a patch to redirect this appropriately. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. --
