On 9/9/2010, "Pieter Hintjens" <[email protected]> wrote:
>On Thu, Sep 9, 2010 at 10:02 AM, Martin Sustrik <[email protected]> wrote:
>
>> To make the contribution process completely deterministic, I am going to
>> post my patches on the mailing list in the same way as everybody else
>> does. Although I'll merge them myself, it still makes the license they
>> are contributed under clear and opens space for peer review.
>
>The 'we-eat-our-own-food' principle is good, but...
>
>Is this for patches (fixes) or also new functionality? And how do you
>distinguish the two?
>
>I'm not sure that sending all changes to the mailing list is sane, and
>it certainly won't scale to including other 0MQ-related projects.
>Anyone who wants to review a project's source evolution can use
>github.
>
>As I understood the process, people submit patches to the mailing list
>because they hope *someone* will pick them up, review them, and commit
>them. This doesn't apply to work done by the owner of a project.
I would rather say the distinction is between common day-by-day patches
and big codebase changes. For the former, the mailing list process is
sufficient. And there's no real reason why the maintainer should not
follow the process.
For big changes it's different. The changeset is normally maintained an
a topic branch. The merging is a collaborative process (as opposed to
maintainer merging a small fix) between patch submitter(s) and
maintainer(s). It's a complex and cannot be completely formalised.
We'll have to manage it on case-by-case basis.
Martin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
