Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson <ian@davenant.greenend.org.uk> writes:
> 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 ?
They're suitable to get in but commit logs and team repository
policies need to be respected.
I'm with Raphael here and IMHO (even being not a member of team) is
that it shouldn't be merge until you, or someone interested, make it
follow the policies.
>> 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.
Sorry but I disagree with you. Every project ought to have sane commit
logs and logical changes. It makes cherry-picking, bisect and others
much easier and improves the general programming experience of others
devels since they see logical commits instead of a bunch of commit
doing different changes all the time.
Bear on mind that the comment used on the commit ought to be used to
justify the commit itself. It's not only to give something to show at
git log.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
Reply to: