[vlc-devel] Request for removal of commit rights
Rov Juvano
rovjuvano at users.sourceforge.net
Fri Jul 11 05:19:27 CEST 2008
I'm with you, Remi. With ~12000 commits since 0.8.6h,
bisecting that transcode resample bug (#1630) should have
taken max 14 builds, but took well over 50 because of broken
builds, segfaults, and otherwise unusable commits. I'm
reluctant to do that again.
Don't stop with Pierre. Revoke jb's, fkuehne's, fenrir's,
dionoea's, funman's. This ain't svn. Revoke everyone's.
If no one else can commit to master, no one else will. They
don't need it.
I've contributed to master. I've gotten author credit for my
contributions. I've shared commits. All without commit
access to master or publishing my branches.
No project has this issue solved. Git opens up a lot of
possibilities, and no one has figured out the best way to
use it. Even linux, with its mature git workflow, is still
in flux with their new next branch.
But, most projects I have come across that use git with many
branches have a policy that master is merge-only by only one
(rarely two) lead developers. They occasionally violate
policy for small fixes, but the policy forces the patch to
be reviewed or at least, embarrassing to the lead developer
who authored, committed, and signed-off on the botched commit.
The other developers freely work on other branches and share
code, even when the lead developer goes on vacation. Plus
they have the freedom to amend, squash, and rebase those
botched commits. No need to screw up master. No need for
freezes or long, arduous debugging and hardening at the end
of a release cycle. Master stays clean.
Improving commit practices can go a long way towards improving
code quality and maintainability.
--
rovjuvano
More information about the vlc-devel
mailing list