I was thinking that google groups deals great with two views on the same discussion (forum-like comments and ml). Could something like that be done for trac? Would it be a good idea?
On 6 July 2010 09:07, Simon Schampijer <si...@schampijer.de> wrote: > On 07/05/2010 02:47 PM, Tomeu Vizoso wrote: >> On 07/01/2010 08:32 PM, Gary Martin wrote: >>> Hi folks, >>> >>> Just wanted to ask the obvious question. Patches to mail list, or >>> patches to trac? >> >> About acceptance, the current process is in place until its wiki page is >> changed: >> >> http://wiki.sugarlabs.org/go/Development_Team/Code_Review >> >> Now, that process already mentioned reviews on mailing lists in some >> cases and of course, doesn't forbid people from sending patches to the >> ml for non-acceptance reviews. >> >>> Patches to mail-list seem great for quick random 'easy' feedback from >>> and for any one who cares to give it, and I really like seeing little >>> code snippets go past. However it seems vital that with the current >>> process we at least make a final closing stage (currently tickets in >>> trac) where the hard final call can be made and the loop closed. >> >> Yup, I guess this is the acceptance part of it which needs to be very >> clear to submitters and thus should be agreed by all maintainers of >> official modules. >> >>> Personally I read mail in a bunch of different places/devices and >>> there's no way I can currently (and sanely) keep track of all the >>> list activity and know who suggested what, what was actually agreed, >>> and what is still outstanding. I've had a few patches and reviews now >>> from kind folk posting to the mail-list, but for me, I've ended up >>> having to ask folks to create git clones so I can pull in patches in >>> a maintainable work flow. >>> >>> I dread to think what it must be like trying to look after several >>> large core modules! >> >> Last we discussed this, I understood that the conclusion is that the >> parties interested in a particular submission will keep pinging the >> maintainer in public (irc, ml) until it gets reviewed. >> >> I still think it would be much better to have a simpler queue such as >> http://bugs.sugarlabs.org/wiki/TomeuReviewQueue in which you know more >> clearly what is awaiting review and exactly which patches they are >> (well, when the submitter properly discards all patches and don't put >> several patches in the same ticket), but it was contended that the >> "bureaucracy" needed was too much and discouraged contributions. >> >> Regards, >> >> Tomeu > > The main problem I am seeing with having trac and the mailing list being > used is that the two parts get out of sync. As a "well-behaving" > maintainer, I have to follow both discussions in order to follow up. > > For example take http://bugs.sugarlabs.org/ticket/1926 There is a > ticket and a mailing list discussion with patches, icons etc. Now, there > is no link in the ticket to this discussion, and one needs to follow > both tracks. Of course adding policies such as "link the ml-discussion > in the ticket" can help here. > > Do people have a plan/policy for this? > > Regards, > Simon > > > > > > > > > > > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel