2013/10/7 James Cameron <qu...@laptop.org>: > Daniel Narvaez wrote: >> Gonzalo Odiard wrote: >> > Daniel wrote: >> > > Gonzalo Odiard wrote: >> > > > Samuel Wrote: >> > > > In general one of my frustrations lately is that now that we no >> > > > longer publicly review patches on this mailing list, everyone >> > > > seems to be developing their own version of Sugar. >> > > >> > > Can you elaborate on this one? I haven't noticed this kind of >> > > change (and we have not been reviewing most patches on the mailing >> > > list since a long long time, well before the github switch). >> > >> > I think the change was the movement to github. If we can add >> > sugar-devel mailing list to the github mail destinations, that can >> > be solved. >> >> I was mostly concerned about Samuel feeling that everyone is >> developing they're own version of Sugar. I don't see that or at >> least I don't see differences with the past. > > I agree with Samuel; that with the loss of public review of patches > participation in development has been confined to those who take the > trouble to visit a web site. > > (The reviews by mail were also stimulating other discussion on list). > > So on the theory that developers are developing with less review (even > though it might be unseen greater review), this leads to the > conclusion that Sugar is being developed by these developers "on their > own". > > And, actually, I'm fine with that. A smaller group can achieve more > if they are able to use these new tools effectively. > > I have not been effective since that change, but you would have seen > that a review counter or tracking? Has there been a measure of review > rate? > >> We probably can have sugar-devel as email destination... Though I'm >> not sure why people wouldn't just watch the modules they are >> interested in? It seems more flexible. Anyway not opposed to send >> all modules to the whole mailing list if there is consensus on >> that. > > I don't see how "watching the modules they are interested in" is "more > flexible", nor whether greater flexibility increases the > communication.
James, Sam, I see this as a question of taste. At least starters find very odd emails with patch format in pain text. At least one reviewer (me) find very odd copy/pasting the email content to a file in order to give the patch a test. And we had the problem of email-patches being forgotten in the flow of threads. That is fixed, with zero patches in queue. As Daniel said, you can receive email notifications from GitHub by watching repositories. > Please don't configure github to send links to the patches; they have > to be the patches themselves. They should also have a from address > that matches the originator. > > What used to happen was easy. Get a mail with the patch. Scroll it > down while reviewing it. When the cognitive dissonance hits a > threshold, hit the reply button and begin a comment. Press send. > > Mail is a store and forward architecture. I can use mail without > having to wait for an internet connection. Github is not so lucky: > > $ ping -n github.com > rtt min/avg/max/mdev = 288.440/606.297/1049.233/262.776 ms, pipe 2 > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > Devel mailing list > de...@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- .. manuq .. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel