My 2 cents: Since the switch to github, we've have a much better turn-around on reviews and we've attacked new reviewers. I think those data speak for themselves. As Daniel said, we welcome help further shaping the process.
regards. -walter On Mon, Oct 7, 2013 at 6:08 PM, Manuel QuiƱones <ma...@laptop.org> wrote: > 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 >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel > > > > -- > .. manuq .. > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel