On Mon, Nov 19, 2007 at 01:19:47PM +0100, Jean Delvare wrote:
Hi Luc,
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 "devel" list instead, it's not really a surprise that the "commits" list doesn't 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 reference.
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. 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?
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 fine.
No it doesn't solve anything. It just unnecessarily splits up the information flow.
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 water. 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. 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. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org