Hi Luc, Le lundi 19 novembre 2007, Luc Verhaegen a écrit :
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.
That's fine with me, and I'll trust your judgment. This simply means that what you want the list to be is different from the kind of list I want to be subscribed to.
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.
I'm not saying that the commit messages aren't good. I just say that I do not have the time to read them.
Why was this not brought up when only bugs were being sent to the ml?
I guess that it's a matter of threshold. I am just as "annoyed" by the bugs as by the commit messages, but as long as the overall volume wasn't too high, I didn't feel like saying anything. Otherwise people say that I always complain about everything ;)
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.
What I'm saying is: splitting the lists or not is a different issue from sending commit messages to a list or not. Scientific fact, there's not much to argue here ;)
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.
I don't know how general it is, and I don't really care. My time is precious (as is yours), so if the list doesn't suit my criteria, I'll unsubscribe. That's all I said, I don't expect you care (about me). If you think that this is the way to go for the project, just do it.
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.
Again, you're arguing about sending commit messages to a list or not, while I never objected to doing this. I simply believe that it's more convenient to have a dedicated list for this, so that people interested in this, subscribe, and people not interested, do not.
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.
As a user (not developer) of the radeonhd driver, what I am interested in is a short summary of the changes when a new version of the driver is released. I just can't afford reading all the commit messages. By subscribing to this list, I hoped to see such summaries posted from times to times. If this isn't how you intend to work (and I fully respect your choice in the matter, as you're the one doing the actual work) then I'd better unsubscribe. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org