commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Feature development model
Date Fri, 08 Jan 2016 00:45:12 GMT
On Thu, 7 Jan 2016 21:29:48 +0100, Luc Maisonobe wrote:
> Hi Sebb,
>
> Le 07/01/2016 04:21, sebb a écrit :
>> On 7 January 2016 at 01:48, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>> On Wed, 6 Jan 2016 18:42:06 +0100, Luc Maisonobe wrote:
>>>>
>>>> Le 06/01/2016 15:56, Gilles a écrit :
>>>>>
>>>>> Hi.
>>>>>
>>>>> I've reread this article (which IIRC was advertised on this list 
>>>>> some
>>>>> time ago):
>>>>>   http://nvie.com/posts/a-successful-git-branching-model/
>>>>>
>>>>> It is quite clear and I think that it would easy to get used to.
>>>>
>>>>
>>>> Yes, it is quite a good model.
>>>>
>>>>> Unless there are shortcomings that would prevent its use with the 
>>>>> CM
>>>>> repository, I propose that we adopt it officially, and assume its
>>>>> nomenclature in order to eventually develop scripts similar to
>>>>> what is mentioned below.
>>>>
>>>>
>>>> That would be fine with me. One should however be aware that we
>>>> cannot delete branches in Apache git repository anymore (at least
>>>> I think this is something that is now enforced). The reason is
>>>> that history should never be lost, or rewritten. So everything
>>>> that hits the repository remains there.
>>
>> Infra intended this as a temporary measure whilst the implications 
>> of
>> allowing deletes were worked out and a better solution found.
>
> OK. Thanks for the clarification.
>
>>
>> I expect the restriction will be relaxed soon.
>>
>>>>
>>>> Considering this, having very short lived hotfix branches may
>>>> prove unpractical. I would not like on the other hand having
>>>> such short lived branches fly around outside of Apache 
>>>> infrastructure
>>>> (like github or anything), as these would defeat the purpose of
>>>> preserving history.
>>>>
>>>> However, using more topic branches seems good to me. This is what
>>>> was done for the field-doe (and the branch is still there).
>>>
>>>
>>> Given the "git" model, it would make sense to allow deleting
>>> branches whose sole purpose is to allow developers to exchange
>>> work that is experimental.
>>
>> Agreed, but the problem is ensuring that the appropriate parts of 
>> the
>> repo are locked down.
>
> Yes, and sometimes we can learn from errors. I also had a few
> cases when I tried something, found it was bad, deleted it to
> try something else, only to find a few months later that in
> fact there was still a part I could have reused. But this is
> a corner case. If you delete something important and not
> saved elsewhere, you just blame yourself.
>
>>
>>> Deleting a "feature" branch is not deleting history. The code
>>> would become history only when this branch is merged in
>>> "development".
>
> If the branch is merged at the end, yes, history is preserved.
> It can be tricky to find again as you don't have a pointer on
> the tip of the branch, but the commits are there.
>
>>> IIUC, you have preserved all the history of your commits when
>>> merging your work into "master". [By the way, I think that
>>> it would be better to squash one "feature" into a single
>>> commit so that it is trivial to figure out whether this
>>> commit introduced some problem (as is advised in the article
>>> IIUC).  The detailed history of a "feature" work is not
>>> necessary since even if a bug is uncovered, it is unlikely
>>> that one will search for a commit to be reverted rather than
>>> make a new one with the fix!  And it will avoid a flood of
>>> messages to the ML which only code archaeologists would ever
>>> read.]
>
> I could have done both ways. When I proposed this a few weeks
> ago, it was thought that the history was worth preserving,
> moreover remembering that these commits are not in the
> common ancestors of the master branch (they occurred after
> MATH_3_X was forked).
> Perhaps next time I will do it at once. Or better perhaps
> next time we will not have to go through these hops because
> we can use more straightforward git commands (git cherry-pick
> and the like). Using the other classical way of squashing commits
> using git rebase interactive will certainly not be allowed
> by infra, as this really is a dangerous command and it opens
> ways to destroy or rewrite history).
>
>>>
>>> So (from the article),
>>> * the "master" branch is the one from which tags for released
>>>   code are made and is of course "history",
>>> * the "develop" branch is "history";
>>> and those must not be deleted, obviously.
>>>
>>> If we want to avoid the proliferation of short-lived branches
>>> that are also "history" (of hot fixes and releases), we could
>>> perhaps further simplify the model and have two long-lived
>>> branches:
>>> * "hotfix" for hot fixes, and
>>> * "release" for release candidates.
>>> In the latter, a tag is enough to indicate the commit that is
>>> the target of the vote (IIUC).
>
> This is basically what was done for the last release. The
> tag was also signed with my key so it coud be checked by
> anyone, and its SHA1 id was sent in the vote message.
>
>>> [Anyway, this point is fairly moot, as we don't expect many
>>> hot fixes or releases in CM...]
>>>
>>> But the "feature" branches, why keep them?
>>> The code that is in such a branch will become "history" once
>>> it is merged into "develop" (and only in that case, if we follow
>>> the convention).
>
> As above, yes if the code is merged, the feature branch could be
> deleted.
>
>>>
>>> Keeping all those short-lived branches is as if files in the
>>> "home" directories were archived and the owner would be
>>> forbidden to delete his own files...
>>> Or, suppose that I'd create a hypothetical branch, in which I
>>> would suddenly start to do some crazy stuff to the RNG code...
>>> Wouldn't we want to be able to delete this ASAP? 8-/
>>>
>>> So, in summary, it is sufficient to enforce a "no delete" policy
>>> only for the "history"-making branches: "master", "develop",
>>> "hotfix" and "release".
>>> We should be allowed to delete anything else (if I did not miss
>>> anything).
>>
>> The problem is determining what must be kept and what is transient.
>> Commons may agree on only using these 4 branch names, however other
>> projects may use different names.
>>
>> Since Git does not have restrictions on what branch names are used,
>> this is a non-trivial issue to solve.
>>
>> This is really a discussion for Infra.
>
> Yes, I think so. I don't know what is the current status of
> their thoughts about this.

Can't we decide here about the convention which we adopt for
development (i.e. the model discussed in the blog post referred
to above)?

I mean:
* Do we stop updating "master" with ongoing work (i.e. only
   allowing released code to be merged into it)?
* Do we create a "development" branch (consequence of "Yes" to
   the above question)?
* Do we create a feature branch for each new feature that we'd
   like to allow other people to look at and review and test before
   it is included in the "development" branch?
* What is the OK convention for directly updating "development"
   (i.e. for a bug fix)?
* What is the OK convention for merging a feature branch?
* ...

* Do we follow the same approach for MATH_3_X?

This links to my other post about the development management
(or any other word or expression that is meant to clarify
what developers can expect in the coming months):
* Do we continue maintaining "MATH_3_X" beyond bug-fixing (as was
   done for the previous cycle with backporting)?
* "Yes" or "no" to the above is likely to have an impact on what
   people think is fair game for 4.0.  And for choosing a target
   Java version (which in turn will have a big impact on how
   likely the library is going to evolve.

Hopefully we can advance before we know whether we'll be allowed
to delete the temporary branches...


Regards,
Gilles


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


Mime
View raw message