[Sugar-devel] Bug tracking Vs Patch review

[David Farning]

On Mon, Jul 26, 2010 at 11:55 AM, C. Scott Ananian <cscott at laptop.org> wrote:
> On Mon, Jul 26, 2010 at 11:27 AM, David Farning <dfarning at gmail.com> wrote:
>> patch review process and (b) loosing patches.  If a patch is a
>> solution to a problem it is not necessary to discuss the problem and
>> if it is the patch submitters responsibility to track the patch the
>> need for a maintainer to track the patch goes away.
>
> It's easy to say "it's the patch submitter's responsibility", but that:
>  a) alienates new members of the community, who feel like their
> patches are being ignored and don't understand why their help is not
> appreciated, and

Is it preferable to worry about potentially alienating new members
because their patches 'might' be ignored or is preferable to worry
about the existing patches which deployments have written but have
given up trying to push upstream because of the current review
process? Please see
http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/

>  b) begs the question: now what does the patch submitter use to track
> submitted patches?  For major developers, this is still a big problem,
> and patches are lost simply because the developer lost track of them
> in the process.

The developer can use want ever they want.

> Similarly, even though a patch may be the "solution to a problem"
> doesn't mean its the best solution, or that the patch doesn't need
> work (style fixes, regression tests, fixes for corner cases,
> backports, updates to latest git).  Often a developer can push a patch
> "so far" and then needs to move on to other things.  Using a patch
> process -- ideally one associated with a bug tracker -- lets other
> developers pick up the pieces and finish the patch where needed.
>
> It's not hard to see examples in (say) Mozilla's bug tracker where 2
> or 3 developers (and several years!) were taken to take a particular
> patch all the way through the review process.  All of the patches
> attached to the bug were "the solution to a problem", and often
> individual users were successful in manually applying those patches to
> their local copy of the code for some particular use, even though it
> was not ready or able to be committed yet (for instance, it didn't
> apply to git head any more!).

There is no reason why allowing patch reviews on a mailing list would
prevent a maintainer from telling a patch submitter NCK patch and and
suggest that the submitter use the bug tracker for future discussions.

> So, following Einstein's maxim that a process should be "as simple as
> possible but not simpler" -- I think you've made things "too simple".

I'll see your theoretical physicist and raise you a computer scientist
'Premature optimization is the root of all evil' -- Donald Knuth