Alon Bar-Lev ha scritto: > 2010/4/14 Samuli Seppänen <sam...@openvpn.net>: > >>> First of all, let's bring in the history. This feature was discussed in >>> the weekly meeting February 26, 2010. See the chat log at [1], around >>> the time stamp 20:45:15. >>> >>> >>>> David, IRC is not a development tool, it is sync tool that require all >>>> to be available at the same time, which is never the case. I don't >>>> understand why you took this approach, but its down-side is that >>>> people discover such commits later on. >>>> >> There are several good reasons why we do use IRC as a development tool. >> First, it's the best/only available way to get James' input into >> "testing" development. Second, many patches have fail to receive an >> ACK/NACK or even any comments in the mailing list discussions. It's this >> kind of patches which are discussed in the meetings and more often than >> not we've managed to get an ACK/NACK for them. >> >> As you say, there are problems with using IRC as a development tool, >> timezones being one big problem. That's why after every meeting I send a >> summary to openvpn-devel which documents every single patch ACK/NACK. A >> full chatlog is also attached to this mail. To make sure the summaries & >> chatlogs don't get lost in mailing list archives, they are also linked >> to from here: >> >> http://www.secure-computing.net/wiki/index.php/OpenVPN/IRC_meetings >> >> The preliminary meeting agenda / topic list is also visible prior the >> meeting so that people can choose whether to attend or not (if they can). >> >> However, I think there's definitely room for improvement. IRC is >> addictive, because it allows making decisions fast and easily. The >> downside is that not all people can attend the meetings and are thus >> unable to affect their outcome or provide valuable feedback. What we >> need to avoid is creating two classes of developers: those who can >> attend the IRC (and make the decisions) and those who can't (and don't >> decide). >> >> As a concrete measure I suggest that patches ACK'd in IRC meetings >> should not be merged until, say, Monday. That way people can review the >> chatlog and if they don't like what they see, they can provide their >> comments. I think that we should from now on "propose" rather than >> "decide" to include patches based on IRC discussions. Otherwise people >> might get the wrong impression that we don't want/need further comments. >> I also suggest that we really focus on using IRC only when the mailing >> list discussions have led nowhere, not just for it's convenience. >> >> What do you think? >> > > Thanks for the constructive criticism, Alon.
> I think that using IRC is much too chatty to begin with. Async > communication is much complete and atomic. > That's probably true most of the time. However, IRC like any synchronous communication method has less overhead than async methods. That's why people prefer to talk to each other directly - if possible - rather than send them email. Due to the directness and "chattiness" of the IRC the meetings also serve an important social function, bonding together people from the company and the community. They do not _have_ to be patch discussion meetings to achieve that goal, though. > Also, your summary contains so much unrelated issues that it is harder to > track. > I assume you mean the full chatlog rather than the summary. If so, I agree. > Proper mailing list management proved themselves for a long time, the > LKML is a good example of such. > That's why we are using and should use the mailing lists as the primary communication channel. > However, if you truly want to manage the change sets, install bugzilla > [or any other *DECENT* tracker except trac], and follow change request > from submittion to release. > > This way you can track the full history of a single change, and not > follow several meeting logs, mail messages and other means of > discussion. > Could you share your views about the concrete benefits we'd get from being able to track change requests / patches from submit to release? What kind of problems would it solve? What kind of problems can we expect if we can't do that? I would appreciate if you could spell it out so that even a dummy like me can understand ;). > All relevant people [weather decision making or interest] may be CCed, > also the devel mailing list can be CCed so outsider can track the > status of changes. > > Managing software is a complex task, the IRC session you conducting > does not make it more organize/simpler/complete. > As I said in this mail and my previous email, the IRC meetings solve real problems. If you have a better alternatives that address these problems, please share them with us. The current process (incl. IRC meetings) is tailored to our specific needs. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
