No subject

[bogus at does.not.exist.com]

patches left non discussed is smaller than before, could you please give
numbers backing your statement? mine had been already posted.

> This is moving the commit burden on a limited number of
> developers. This is not a good idea. To commit a change means in
> general to do many steps:
> * apply/update the patch
> * test the change (make test, other ad-hoc tests)
> * update docs/version numbers/APIchanges
> * global pre-commit checks on the patch
> 
> The contributor is usually willing to do so, since she's motivated in
> having the patch applied to the main branch, and is most of the time
> the most competent developer about how to apply it.

I see this as a good way to make contributors work less.

> I usually perform minor changes when applying a patch (commit log
> fine-tunings, minor cosmetics), sometimes I even found some bug just
> before to apply it, not being able to perform such changes is lowering
> the quality of my own contributed patches.

You are supposed to do that before hitting git-commit.

> If the committer is not motivated it will surely skip all these
> passages, or it will delay the application of the patch. This is about
> human nature, we tend to be lazy when not motivated enough, not taking
> care of this aspect is a major flaw in the design of these new rules.

You are thinking in svn.

> Having each developer a separate branch/repo doesn't help neither, as
> I believed our gsoc experience in the last 3+ years taught, indeed the
> main cost and the most difficult task is the integration of the branch
> in the official repo, rather than the development of the branch
> itself, which every kid with some git experience can indeed achieve.

Because we were using svn. Rebasing on svn is costly, on git is easy.

> Moving the focus of the developer from "getting the change integrated"
> to "developing in her own branch" is not helping if the objective is
> actually "getting the change integrated" in the main repo.

I'm of the opposite opinion

> Also having each user to "cherry-pick" the changes from N branches is
> not a good idea as well and will just multiplicate confusion and
> mistakes.

The ffmpeg.org and possibly other target repos are here for this
purpose, cf linux in this regard.

> From this point of view the "old" system was way better, as it was
> letting to do the work to the persons which were motivated in doing
> it, public changes needed to be discussed and approved by the
> respective maintainers. Unreviewed changes could be committed by
> threatening to apply in N days and finally applying them in case of no
> comments. This worked quite well in the past three years I've been
> into the project, with very few exceptions and intentional violations
> of the policy, and with an high overall quality achieved.

I have the completely opposite opinion.

> Now I see that the problem the new rules were trying to address was
> avoiding having a single control point and disallowing vetoing
> practice, indeed the new rules tell who can allow the commit (and
> enforce it via the commit mechanism itself) but don't tell nothing
> about who can veto the application of a patch (which I assume are only
> the "committers" rather than the file maintainers).

the "veto" option is available to everybody.

> And finally my proposal: to review the committership mechanism, I
> propose to restore the previous model, to give back commit rights to
> all the developers and enforce *via policy* some of the new rules, for
> example to require the approvation of non-controversial patches from
> at least another developer with expertise in the area. The queueing
> mechanism looks *good* and may be extended to all the developers.

I'd like to keep the current method for a bit longer and then see in
retrospect what should be fixed and what had been really better.


lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero