Separate mailing lists
I'm stating to get a lot of stuff from this mailing list. Would it be possible to separate it? radeonhd-{bugs,commits} or something like that? Best regards. -- Felipe Contreras -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Le lundi 19 novembre 2007, Felipe Contreras a écrit :
I'm stating to get a lot of stuff from this mailing list.
Would it be possible to separate it? radeonhd-{bugs,commits} or something like that?
+1 At the current rate, chances are good that I'll unsubscribe soon. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Mon, Nov 19, 2007 at 11:35:59AM +0200, Felipe Contreras wrote:
I'm stating to get a lot of stuff from this mailing list.
Would it be possible to separate it? radeonhd-{bugs,commits} or something like that?
Best regards.
-- Felipe Contreras
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. 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. 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. 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. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
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. 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.
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.
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.
-- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
On Nov 19, 2007 4:32 PM, Luc Verhaegen
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.
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 "xorg-team@lists.x.org".
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.
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 water.
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 them. 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 feeds.
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 branch. 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. Best regards. -- Felipe Contreras -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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.
You may prefer reading the list via Gmane, then. Stefan "who rather agrees with Luc, but doesn't care strongly" -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
On Mon, Nov 19, 2007 at 04:25:21PM +0100, Jean Delvare wrote:
Hi Luc,
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.
Have you tried lkml? openbios ml?
I'm not saying that the commit messages aren't good. I just say that I do not have the time to read them.
Then don't. This is the thing with mailinglists, you do not tend to care about all that is being said there. (unless you're the developer of the radeonhd driver and you're on the radeonhd ml :p)
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 ;)
How many, unbelievably short, commit messages have been sent to this list? How easy are they to identify visually, as being part of this list and as being commit messages? It's so easy to press d and get rid of them.
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 ;)
A very simple and undeniable fact here is: the volume simply doesn't warrant a split, at all.
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.
This is a shared development/user support mailing list. This is what happens on such mailing lists.
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.
The volume of commits is rather low, the volume of the ml is also not lkml level.
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.
As you said, our time is precious. Doing summaries is never correct, as the next commit might undo things already, and this is also very time consuming. We are also quite a bit away from a driver release, we just commit changes to the driver and hope that things start working better for everybody. Commit messages tell people what is moving, how it is moving and when it is moving. They are a crucial part of developing with a community. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Luc Verhaegen wrote:
On Mon, Nov 19, 2007 at 04:25:21PM +0100, Jean Delvare wrote:
Hi Luc,
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.
Have you tried lkml? openbios ml?
I'm not saying that the commit messages aren't good. I just say that I do not have the time to read them.
Then don't. This is the thing with mailinglists, you do not tend to care about all that is being said there. (unless you're the developer of the radeonhd driver and you're on the radeonhd ml :p)
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 ;)
How many, unbelievably short, commit messages have been sent to this list? How easy are they to identify visually, as being part of this list and as being commit messages? It's so easy to press d and get rid of them.
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 ;)
A very simple and undeniable fact here is: the volume simply doesn't warrant a split, at all.
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.
This is a shared development/user support mailing list. This is what happens on such mailing lists.
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.
The volume of commits is rather low, the volume of the ml is also not lkml level.
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.
As you said, our time is precious. Doing summaries is never correct, as the next commit might undo things already, and this is also very time consuming. We are also quite a bit away from a driver release, we just commit changes to the driver and hope that things start working better for everybody.
Commit messages tell people what is moving, how it is moving and when it is moving. They are a crucial part of developing with a community.
I would like to say that I am a FreeBSD developer, as well as a software engineer (day job) working with numerous open-source projects. I am subscribed to numerous mailing lists, and I have various rules set up to filter the messages and route them to the appropriate Inbox sub-folders. This list is typically one of the lower trafficked lists that I have seen, and I never have a problem catching up with the emails that accumulate here. If this were broken up into multiple lists, I would have more difficulty dealing with the distributed content. This is especially true for commit messages which may or may not be followed up by lengthy discussion that is benefited by input from non-commits subscribers. I really prefer the format as it is now, in a single list rather than segregating the discussions. You don't tend to hear much from the people who are happy with the way things are, so I figured I would donate my 2 cents. -- Coleman Kane -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Nov 19, 07 13:19:47 +0100, Jean Delvare wrote:
Obviously, not everyone shares your point of view. 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.
Different usage.
But be aware that ATM this is actually a developers' mailing list. We
don't have a user or "announce" mailing list, just because the current
traffic doesn't indicate a split is necessary, and/or the user base
isn't big enough for a user mailing list, and/or we don't have any
releases yet, so no need for an announce mailing list.
This will change, eventually. Dunno when, though. Certainly not this
year any more.
CU
Matthias
--
Matthias Hopf
participants (6)
-
Coleman Kane -
Felipe Contreras -
Jean Delvare -
Luc Verhaegen -
Matthias Hopf -
Stefan Monnier