On 2 Sep 2010, at 21:02, Bernie Innocenti <ber...@codewiz.org> wrote: > Let's get started this way. If needed, we could refine the rules later > on. To avoid confusion, I'd wait updating the documentation in the wiki > until we've tested this new workflow for a while. > > If a maintainer cannot stand to approve patches submitted to the > mailing-list, I'd ask them to state it clearly, so we don't needlessly > disappoint submitters. If a submitter still prefers the old workflow, > they can keep filing patches in the bug tracker as before. > > Agreed?
Sounds good to me. I would put the notes somewhere on the wiki as experimental/unofficial so that we can integrate improvements. > >> I'm pretty confident we can setup and improve patchwork to help us >> tracking patch status reliably. I don't have a lot of time but I will >> commit to help out with both infrastructure and the reviews >> themselves. > > We've already had Patchwork on this list for a while: > > http://patchwork.sugarlabs.org/project/sugar/list/ > > It's a useful aid on the side, but I don't think it needs to get in the > middle of the patch workflow. People are generally good at keeping track > of threads in mailing list within their MUA. Some people are, some are less, included our most active maintainer :) I think we agree about patchwork being an additional tool anyway. > In case a patch gets overlooked by the maintainer, the submitter can > resend it after a while. If even the submitter forgets, someone else > could ping. If nobody cares to ping, it means that patch wasn't very > interesting after all. This is a bit simplistic. The submitter might just think we don't care and stop submitting patches. Let's forget about that for now though, we need to make this work well for the existing contributors before we even start thinking about involving more. Marco _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel