hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Sedding <jsedd...@gmail.com>
Subject Re: Git policies and practices
Date Fri, 19 May 2017 15:54:47 GMT
On Fri, May 19, 2017 at 3:30 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Fri, 2017-05-19 at 15:14 +0200, Julian Sedding wrote:
>> Hi Oleg
>>
>> As I explained in the thread branched from this one, I fear that
>> rewriting public history will irritate/alienate potential
>> contributors
>> as well as existing committers.
>>
>>
>> In my opinion deterring contributors is a hefty price to pay in order
>> to satisfy your desire for an immaculate public history.
>>
>
> ah, please, let us not start over again. Rebasing is a problem only for

What exactly are we starting over? You have not replied to one single
question or statement of mine. I am trying to have a constructive
discussion.

> projects that have long standing forks maintained by external parties,
> like Linux kernel project. We do _not_ have external forks maintained
> externally as far as I know. The rest is just subjective speculations.
>

I never said anything about forks. Every *clone* of the repository is
affected, causing any developer (committer or not) with a local clone
problems. I argue that this will deter possible contributions.

>
>> As I understand it, you "need" the clean public history in order to
>> create the release notes. Is that correct?
>>
>> I suggested to base the release notes on JIRA issues instead. Is this
>> not possible? If yes, why?
>>
>
> Because the commit log is the _only_ _authoritative_ representation of
> the project state.
>
> I do pretty much all the heaving lifting for the project. Please do not
> make me raise a bloody JIRA for every bloody commit. You do not get
> enough of raising tickets at work? I do.

If an issue is important enough to appear in the release notes, I
think a JIRA ticket is warranted.

If an issue is so insignificant that a JIRA seems like overhead, then
it does not need to appear in the release notes.

>
> The problem immediately goes away as soon as people start using release
> branches responsibly.

That's why I argue we should rather educate the projects committers
than institutionalize a documented bad practice.

>
> Oleg

I would still be interested to get a reply to the questions and
suggestions I made in order to find a compromise that everyone can
live with.

Regards
Julian

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

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


Mime
View raw message