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: [email protected]
-P David Woodhouse
+P: David Woodhouse
M: [email protected]
L: [email protected]
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
On Fri, Jul 04, 2008 at 08:34:55AM +0200, Uwe Kleine-K?nig wrote:
> 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: [email protected]
> -P David Woodhouse
> +P: David Woodhouse
> M: [email protected]
> L: [email protected]
> 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.
If you succeed doing so it would be very good to fix up
all mail entries to read:
M: Paul Gortmaker <[email protected]>
so they are copy'n'paste friendly.
Sam
>
> 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
> --
> 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/
Sam Ravnborg wrote:
> On Fri, Jul 04, 2008 at 08:34:55AM +0200, Uwe Kleine-K?nig wrote:
> > 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: [email protected]
> > -P David Woodhouse
> > +P: David Woodhouse
> > M: [email protected]
> > L: [email protected]
> > 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.
>
> If you succeed doing so it would be very good to fix up
> all mail entries to read:
>
> M: Paul Gortmaker <[email protected]>
>
> 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
Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-K?nig:
> 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].
What good does alphabetic ordering? You'll grep it anyway.
Regards
Oliver
Hello Oliver,
Oliver Neukum wrote:
> Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-K?nig:
> > 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].
>
> What good does alphabetic ordering? You'll grep it anyway.
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
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=refs/heads/maintainers
and
git://http://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
On Fri, Jul 04, 2008 at 08:57:22AM +0200, Uwe Kleine-K?nig wrote:
> Oliver Neukum wrote:
> > Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-K?nig:
> > > 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].
> >
> > What good does alphabetic ordering? You'll grep it anyway.
> 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.
>
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,
Paul Mundt wrote:
> On Fri, Jul 04, 2008 at 08:57:22AM +0200, Uwe Kleine-K?nig wrote:
> > Oliver Neukum wrote:
> > > Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-K?nig:
> > > > 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].
> > >
> > > What good does alphabetic ordering? You'll grep it anyway.
> > 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.
> >
> 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.
That's how I interpret it, too. :-)
Look at
http://www.modarm9.com/git/people/ukleinek/linux-2.6.git?a=commitdiff;h=62110fbc73a9d3a4c7d39706b648b554b517f154#patch1
.
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
On Fre, 2008-07-04 at 08:52 +0200, Oliver Neukum wrote:
> Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-König:
[...]
> > 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].
>
> What good does alphabetic ordering? You'll grep it anyway.
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
Am Freitag 04 Juli 2008 14:02:49 schrieb Bernd Petrovitsch:
> On Fre, 2008-07-04 at 08:52 +0200, Oliver Neukum wrote:
> > Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-König:
> [...]
> > > 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].
> >
> > What good does alphabetic ordering? You'll grep it anyway.
>
> 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).
If you can come up with a rule for naming a driver, yes.
Regards
Oliver
> > 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.
> That's how I interpret it, too. :-)
>
> Look at
>
> http://www.modarm9.com/git/people/ukleinek/linux-2.6.git?a=commitdiff;h=62110fbc73a9d3a4c7d39706b648b554b517f154#patch1
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
Oliver Neukum <[email protected]> writes:
>> 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].
>
> What good does alphabetic ordering? You'll grep it anyway.
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
Hello,
Krzysztof Halasa wrote:
> Oliver Neukum <[email protected]> writes:
>
> >> 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].
> >
> > What good does alphabetic ordering? You'll grep it anyway.
>
> 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.
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
Hello,
Alan Cox wrote:
> > > 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.
> > That's how I interpret it, too. :-)
> >
> > Look at
> >
> > http://www.modarm9.com/git/people/ukleinek/linux-2.6.git?a=commitdiff;h=62110fbc73a9d3a4c7d39706b648b554b517f154#patch1
>
>
> 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
fixed and branch updated.
> BTW - I suspect your script needs to force a locale.
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
Uwe Kleine-K?nig <[email protected]> writes:
> 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.
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
Krzysztof Halasa wrote:
> Uwe Kleine-K?nig <[email protected]> writes:
>
>> 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.
>
> Because then:
> - the action is not effective immediately but sometimes after few
> months, not counting people still working with 2.6.12 or so.
We expect submissions to based on something more recent than 2.6.12.
Your patch service however...
> - 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.
...already exists. Check the "L:" entries in MAINTAINERS.
--
Stefan Richter
-=====-==--- -=== --===
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> We expect submissions to based on something more recent than 2.6.12.
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,
of course).
> Your patch service however...
> ...already exists. Check the "L:" entries in MAINTAINERS.
Nice joke.
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> writes:
>
>> We expect submissions to based on something more recent than 2.6.12.
>
> 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,
> of course).
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 be an appropriate tool for these people.)
>> Your patch service however...
>> ...already exists. Check the "L:" entries in MAINTAINERS.
>
> Nice joke.
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/
Stefan Richter <[email protected]> writes:
>> 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,
>> of course).
>
> 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.
They, too. Why not?
> As I see it, the people who want such a
> service are those who frequently send patches for various different
> areas of the kernel.
Sure, they too.
> (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.
And less skills. Though they would manage a single patch submission
address I guess.
> A "tell me a list of mail addresses; whatever
> you give me, I am not really interested in the particulars" service
> would not be an appropriate tool for these people.)
I think it would. Why not?
> 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.
Same here, except that it would be easier = "faster" and/or
"possible". "Faster" for regular kernel contributors and "possible"
for many occasional ones.
> 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.
Not the most important points IMHO but yes, that too.
> But the latter problem won't
> really go away with the proposed maintainers lookup service.
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
Krzysztof Halasa wrote:
> Stefan Richter <[email protected]> writes:
(occasional contributors)
>> But these are not the people anyway to which this maintainers lookup
>> service would be targeted to.
>
> They, too. Why not?
What comes first --- getting to know SubmittingPatches, or learning to
feed patches into a machine?
--
Stefan Richter
-=====-==--- -=== -=---
http://arcgraph.de/sr/
On Fri 2008-07-04 08:52:27, Oliver Neukum wrote:
> Am Freitag 04 Juli 2008 08:34:55 schrieb Uwe Kleine-K?nig:
> > 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].
>
> What good does alphabetic ordering? You'll grep it anyway.
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
On Fri 2008-07-04 14:34:13, Krzysztof Halasa wrote:
> Oliver Neukum <[email protected]> writes:
>
> >> 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].
> >
> > What good does alphabetic ordering? You'll grep it anyway.
>
> 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.
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