[Sugar-devel] Patches to mail list, or patches to trac?

[Lucian Branescu]

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 <simon at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>