git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Raphael Hertzog writes ("Re: triggers in dpkg, and dpkg maintenance"):
> However you haven't made it easy to merge your code... you repository is a
> mess to proof-read and the cleaning work that you don't want to do has
> thus to be done by Guillem.
This is precisely the git bikeshedding I was talking about.
The `work' that needs to be done is simply `git pull'. [1]
My changes are not that hard to review and in any case they have been
ready for merge for SIX MONTHS and deployed in a widely-used released
Linux distribution for four months.
What more evidence is needed of their suitability ?
> FWIW, you do have access to the repository but I would request you to be
> removed from the team if you made usage of it in a way that doesn't
> conform to the rules of the team. This includes having meaningful commit
> logs and using private rebased branches for most of the work except when
> we have a public branch where multiple persons of the team cooperate (such
> as what happens with the sourcev3 branch currently).
> http://wiki.debian.org/Teams/Dpkg/GitUsage
This development model has been imported from the Linux kernel. It
may be appropriate when there are hundreds or thousands of people
generating huge quantities of patches, all trying to get their changes
committed, with no organisational connection to the handful of people
picked by the original author who need to act as gatekeeper.
It is not appropriate for a project which has about four people
submitting any significant number of patches, all of whom are fully
signed-up members of a shared governance infrastructure, and where the
gatekeepers are just the people in that project whose hands the code
has most recently fallen into.
Ian.
[1] Well, `git pull' is what needed to be done in August. Now
obviously a bit of merge conflict sorting will need to be done. I am
obviously volunteering to do this but only if it means I can be sure
it will be the last time.
Reply to: