Hello,
I wanted to add an entry to MAINTAINERS and while doing it I saw that in

the corresponding region the alphabetic ordering is broken.  Then I

inteded to fix that up for a trivial patch.  Next was to check the rest

of the file and there are so much misorderings that it's not sensible to

choose the trivial path anymore as there are currently 114 entries out

of order[1].
Below is a script that shows the misorderings after applying the

following patch:
diff --git a/MAINTAINERS b/MAINTAINERS

index e6c06fa..e9e36f8 100644

--- a/MAINTAINERS

+++ b/MAINTAINERS

@@ -1585,7 +1585,7 @@ S:	Supported

 EMBEDDED LINUX

 P:	Paul Gortmaker

 M:	paul.gortmaker@windriver.com

-P	David Woodhouse

+P:	David Woodhouse

 M:	dwmw2@infradead.org

 L:	linux-embedded@vger.kernel.org

 S:	Maintained
IMHO there are two good ways to continue:

 - just ignore the misorderings; or

 - write a more clever script that not only shows the misorderings but

   fixes them and optimally let Linus directly apply it.
I will try to come up with a script to prepare the second way.
Best regards

Uwe
#! /bin/sh
tempfile="$(mktemp)";
# extract topics from MAINTAINERS

sed -n -e '1,/^P:/d' -e '/^[0-9a-zA-Z][^:]/p' MAINTAINERS >

"${tempfile}"
sort "${tempfile}" | diff -u "${tempfile}" -
rm "${tempfile}"
[1] ukleinek@zentaur:~/gsrc/linux-2.6$ order_maintainers | grep ^- | wc -l

114
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

Hello,
now I scripted a bit and the result is at
	http://www.modarm9.com/git/people/ukleinek/linux-2.6.git?a=shortlog;h=re...
and
	git://www.modarm9.com/gitsrc/pub/people/ukleinek/linux-2.6.git maintainers
.  Shortlog and diffstat are below.
Best regards

Uwe
Uwe Kleine-König (3):

      MAINTAINERS: fix format

      MAINTAINERS: fix alphabetic ordering

      MAINTAINERS: merge P: and M: fields to ease copy'n'paste
 MAINTAINERS | 3144 ++++++++++++++++++++++-------------------------------------

 1 files changed, 1189 insertions(+), 1955 deletions(-)
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

What good does alphabetic ordering? You'll grep it anyway.
	Regards

		Oliver
--

Actually alphabetic numberic sucks. It would be nice to group entries

by subsystem, so you have
networking
network drivers
wireless network drivers
iwl3945
...because sometimes grep is hard. Try greping for ALSA.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

I was thinking about a mailing list / database service instead:

- source file/directory-based (e.g. someone could maintain whole

  drivers/, someone else drivers/char and others drivers/char/asdfg.[ch])

- people would be able to add themselves as "observers" using mail

  and/or HTML interface

- sending a patch would automatically trigger Cc: to all people

  registered as maintainers (or "observers") for the files modified

- full recipient list would be present in mail sent by the service, so

  the following discussion wouldn't need it anymore. It would be used

  only for posting patches.

- as such, I don't expect a need for spam filtering - messages

  containing no patch would be rejected in the SMTP session.
Pro: no more missing Cc:, no more manual lookups and guessing, you

     just Cc: the service, possibility for "observers".

Con: another thing to create and maintain, you don't immediately know

     who exactly has been sent a copy.
I think I could create a test service but after the test phase it

should probably go to some machine more reliable/able than mine.
Comments?

--

Krzysztof Halasa

--

If something like that existed/was useful, I guess finding hosting

would not be huge problem.
And yes, I like the idea.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Hello,
Why not make that a script that parses MAINTAINERS and lives in scripts/

and that can be used as --cc-cmd to git-send-email?  Then no service

needs to be maintained, you don't get the observers functionality

though.  (But that's what mailing lists are good for.)
Of course MAINTAINERS needs to be modified to have the path specifiers.
Best regards

Uwe
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

Because then:

- the action is not effective immediately but sometimes after few

  months, not counting people still working with 2.6.12 or so.

- IMHO adding Cc: patch-service is a bit easier than using a script

- I think the "observers" thing is worth the effort. Now I only see

  changes to certain areas I'm interested in when they are accepted

  upstream.

- maintaining the script is probably more work than maintaining the

  database :-)
And with a service you can:

- maintain a patch archive

- be sure nobody tries to be "creative"

- perhaps other things I haven't thought about.

--

Krzysztof Halasa

--

We expect submissions to based on something more recent than 2.6.12.
...already exists.  Check the "L:" entries in MAINTAINERS.

--

Stefan Richter

-=====-==--- -=== --===

http://arcgraph.de/sr/

--

Unfortunately we can't enforce that. People are working with old

kernels (think of heavily-modified vendor trees), people send patches

against old kernels, and we accept such patches (if it makes sense,
Nice joke.

--

Krzysztof Halasa

--

If I get such patches and can apply them without /very/ much work, I

gladly take them of course too.
But these are not the people anyway to which this maintainers lookup

service would be targeted to.  As I see it, the people who want such a

service are those who frequently send patches for various different

areas of the kernel.  And these people don't work with 2.6.12.
(OTOH, occasional posters who don't even check if their patch would

apply to a newer kernel too before they post it will probably also have

less interest in figuring out the 100% optimum To: and Cc: list for

their submission.  A "tell me a list of mail addresses; whatever you

give me, I am not really interested in the particulars" service would 
Not at all.  These are the forums where patches can be discussed in more

detail because knowledgeable people are subscribed there.  You also have

archives which you can query for patch postings and their discussions.
What you don't get is of course a unified "look and feel".  Some list

archives are crap, some lists are subscriber-only, some kernel areas are

not covered by a special list.  But the latter problem won't really go

away with the proposed maintainers lookup service.

--

Stefan Richter

-=====-==--- -=== --===

http://arcgraph.de/sr/

--

And less skills. Though they would manage a single patch submission
Same here, except that it would be easier = "faster" and/or

"possible". "Faster" for regular kernel contributors and "possible"
Well, I think it should. Why not?

I don't say we replace mailing lists, far from it.

I expect mailing lists to be subscribed to the service.
Come on, the theory looks good but the thing needs to be created and

_that_ may be the weak spot :-)

--

Krzysztof Halasa

--

What comes first --- getting to know SubmittingPatches, or learning to

feed patches into a machine?

--

Stefan Richter

-=====-==--- -=== -=---

http://arcgraph.de/sr/

--

If two (or more) people submit patches to add a maintainer entry, is is

less likely to conflict.

And duplicates are more easily detected (without tools).
	Bernd

--

Firmix Software GmbH                   http://www.firmix.at/

mobil: +43 664 4416156                 fax: +43 1 7890849-55

          Embedded Linux Development and Services
--

If you can come up with a rule for naming a driver, yes.
	Regards

		Oliver

--

Hello Oliver,
This is fine for me, too.  Then I suggest to remove the section
	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

	so much easier [Ed]
.  That's why I posted before spending time on writing a clever script.
Best regards

Uwe
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

I always interpreted this to mean that the _entries_ are alphabetically

sorted, not the maintainers under each entry. IIRC, Alan has already

cleaned up most of the ordering of the entries through recent patches.
Historically the entries with multiple people listed have been in

decreasing order. Thus, the primary maintainer for a given entry is

listed first, with deputy maintainers following afterwards. Most places

where there are co-maintainers, there is still a single person who is the

main interface in to mainline, and it makes sense to have them listed

first. Re-ordering here would simply lead to confusion, or a lot of "send

this to xxx" mail. On the other hand, other entries with co-maintainers

tend to be more ad-hoc, so there doesn't seem to really be a good rule in

general. NETWORKING and KPROBES demonstrate both cases, as an example.

--

Hi Paul,
That's how I interpret it, too. :-)
Look at
	http://www.modarm9.com/git/people/ukleinek/linux-2.6.git?a=commitdiff;h=...
.
Best regards

Uwe
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

Nice but you've chopped off the Linus entry at the end. It would be good

to get the others fixed and the script in the scripts dir
BTW - I suspect your script needs to force a locale.
Alan

--

Hello,
Right.  At least if it gets a wider audience.  Done and Thanks.
Uwe
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--

If you succeed doing so it would be very good to fix up

all mail entries to read:
M: Paul Gortmaker <paul.gortmaker@windriver.com>
so they are copy'n'paste friendly.
--

IMHO this would be a second step, but I like it.
Best regards

Uwe
--

Uwe Kleine-König, Software Engineer

Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany

Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962

--