hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Osipov <micha...@apache.org>
Subject Re: Do not commit to HttpCore SVN!
Date Mon, 15 May 2017 13:18:09 GMT
Am 2017-05-15 um 15:05 schrieb Oleg Kalnichevski:
> On Mon, 2017-05-15 at 14:58 +0200, Michael Osipov wrote:
>> Am 2017-05-15 um 13:13 schrieb Oleg Kalnichevski:
>>> On Mon, 2017-05-15 at 11:54 +0200, Julian Sedding wrote:
>>>> Force pushing is considered a bad practice in Git for good
>>>> reasons,
>>>> thus rewriting history of published branches is IMHO a no-go. It
>>>> makes
>>>> everybody's life harder (and developers less experienced with Git
>>>> may
>>>> not be able to integrate the rewritten history at all).
>>>>
>>>
>>> How so exactly? So, it is not OK to have a developer spend a few
>>> minutes integrating upstream changes into the local branch but it
>>> is OK
>>> to have the release manager waste time wading through hundreds of
>>> unnecessary commits when preparing a release or chasing a
>>> regression?
>>
>> It is absolutely not OK for you as RM spending valuable time fixing
>> an
>> ugly log. Every committer is obliged to leave a clean log. If a dev
>> does
>> not stick to these rules he should be taken away his commit right.
>>
>> If you want to clean up because committers are too stupid to do so,
>> we
>> should take the command-and-leutnant approach.
>
> I have _no_ intention of policing other committers. It is emotionally
> cheaper for me to take time to clean things up and than to hold all
> those conversations about policies.

But why do you want to do the extra work to clean up somebody's else 
mess? A project team needs to agree on some standards and rules making 
life easier for everyone -- the project members as well as our clients 
reading the log and using the software.

A project won't run w/o rules. It is pretty discouring for every a lot 
of devs if someone else does not stick to the rules and produces garbage 
commits.

>> Committers never push
>> directly to a live release branch, but request a PR for it. You as
>> the
>> RM will merge it. It will give you all the freedom you need. So
>> 5.0/master and 4.4/master should be protected branches writable by
>> you
>> only. I am fine with that.
>>
>> Michael
>>
>
> If folks can live with the restriction of release branches being
> writable to PMs only, I am fine with that but I think it is just a
> matter of time this rule gets broken. It is just cannot be enforced
> properly without git commit hooks.

This dev commit branch should not be rewritten of course. But will you 
really go through all commits, cherry pick and squash. This is just 
daunting.

If people cannot bring up the disciple, they should reconsider their work.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message