On Nov 19, 2007 4:32 PM, Luc Verhaegen <libv(a)skynet.be> wrote:
On Mon, Nov 19, 2007 at 01:19:47PM +0100, Jean Delvare
Le lundi 19 novembre 2007, Luc Verhaegen a ?crit?:
As the unichrome driver developer, i have the
following lists on
sourceforge: unichrome-devel, unichrome-bugs, unichrome-commits and
unichrome-users. They've been there since the spring of 2004.
All but one are completely useless and superfluous. And if i could have
another go, i would only have a single mailinglist there.
-bugs/-commits hasn't seen any traffic since early 2005. -devel has only
seen commit messages since about the same time. The level of traffic
never warranted seperate lists at all.
If you setup a "commits" list but send the commit messages to the
list instead, it's not really a surprise that the "commits" list
see any activity, is it? :D
Of course. -commits, after having used it for a year, turned out to be a
rather bad idea. Therefor we abandoned it.
As a reference, when you need to dig something up again, it is much
easier to do so with a single mailinglist and a single point of
For any new user it is also much easier to just sign up to a single
mailinglist than to have to describe and manage several.
Obviously, not everyone shares your point of view.
Not everyone has done X driver development before. My point is supported
by actual experience of using split mailing lists, for X driver
development, over a longer period of time.
I find it more
appealing to have a low volume list with just the info I need, than
a "high" (all relative, granted) volume list with much stuff I am
not interested in. When I start receiving many posts I never read,
I end up unsubscribing from the list, as my time can be used better.
So you are not interested in our short and rather pointed commit
messages? That's strange, as even phoronix finds the most
inconsequential ones interesting enough to post.
Right, because not everyone wants to subscribe to a mailing list just
to find those gems.
Did you ever click one open? Did you even notice that
there are no full
patchsets in there, but instead just the message and the diffstat? This
is rather highly condensed and useful information, nothing superfluous
is in there.
Why was this not brought up when only bugs were being sent to the ml?
I thought on doing it, but there are not so many bugs sent to the
mailing list, at least not as many as commits, and actually I wasn't
sure why I was receiving them. From what I can see those are sent to
Plus, this is only for a single driver, the traffic
will never be
excessive and never has been so far. I do not expect this to change in
any significant way. Even if we get slashdotted and the mailinglist gets
flooded, we will still return to normal after a week or so.
Having bugs and commit messages sent to the same list is a feature.
Everybody can easily track progress that way, no more git-pulling every
five minutes, just scroll through the ML and find out.
Moot point, as split mailing lists would solve the problem just as
No it doesn't solve anything. It just unnecessarily splits up the
The 'unnecessarily' part is debatable.
> Also, our
commit messages are very sensible and very readable, unlike
> the ones sent to, say, xorg-commit, which are huge and unparsable.
> This is another conscious choice based upon unichrome driver experience.
I do have actual points to support my stance. Rather more than "i
personally cannot be bothered with commit messages". This is a rather
personal stance of yours, which is certainly not general enough.
Many people on this mailing list would have been git-fetching or
checking the gitweb repository several times per day. For them, these
short and pointed commit message are the next best thing since boiled
There's a difference between gitweb and mail. With gitweb I can check
whenever I want and see details of the stuff I care about. With e-mail
I'll just keep receiving them and then I'll have to delete or archive
In the CVS era I liked the -commits mailing lists because there was no
other way to "see" commits (a single thing). But with svn/git now it's
possible to check them any time. Not only that, but you can have RSS
If people are actually interested in the software
being developed here,
these commit messages are what those people want. If people are just
here to complain about a single issue, then, when their issue is fixed,
they will unsubscribe.
Most people are interested in:
1) Having something that works
2) Having something that works well
3) Features like XRandr
4) 3D support
All this for their particular card. Some people will stay subscribed
just to see how things are going. Some people will be 100% involved
and would like to know every little detail.
Most people will loose interest completely once 3D is working well.
And honestly, i would've expected more complaints
about the bugzilla
mails than about the commit mails. The latter are useful for everybody,
the former is something more people will care less about.
But, if you really cannot be bothered by the commit messages, feel
free to filter them.
Personally I don't read 99% of the mails in this ml, not since my card
works well. An exception is when Matthias Hopf started the RandR
The list has become radeonhd-bugs+radeonhd-commits, things I don't
care about since I can already check commits in gitweb.
If this continue this way don't take it personally, but I'll just
unsubscribe and wait for radeonhd-users, -announcements or a phoronix
news post. But that's just me.
To unsubscribe, e-mail: radeonhd+unsubscribe(a)opensuse.org
For additional commands, e-mail: radeonhd+help(a)opensuse.org