commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Math] Feature development model
Date Sun, 10 Jan 2016 20:17:34 GMT
On Wed, Jan 6, 2016 at 6:48 PM, 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.
>>
>> 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).
>>
>
I am OK with all of this as long as we have incremental development
visibility (as we did with the field-ode stuff).  The blog post said
something about feature branches just living on developer or subteam repos
and IIUC that would not give the visibility that I at least would like to
have.  I would also like to as much as possible keep the feature branches
not too huge / long-running.   We also want it to be very easy for
non-committer contributors to collaborate with committers on features, so
they need to be able submit PRs against these.  I assume all that is easy.

>
> 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.
>
> Deleting a "feature" branch is not deleting history. The code
> would become history only when this branch is merged in
> "development".
>

Right, and per sebb's comments, this will not be a problem from ASF policy
standpoint.  The key is to keep these merges from getting too monstrously
large, IMO.


> 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 think I agree here; but need more experience with the model here to know
for sure.  I will be more comfortable with it if the feature commits are
not that big and they include good commit messages.



>
> 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.
>

Also, CI runs against "develop" and it is the target for feature branch
merges.

>
> 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
>

I don't think we need that.  We can always create release branches from
"develop."


> * "release" for release candidates.
>

+1 for always using release branches (what Luc just did)


> In the latter, a tag is enough to indicate the commit that is
> the target of the vote (IIUC).
> [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).
>
> 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).
>

I think you are right there, modulo comment on feature branches not getting
too big.


Phil

>
> Best,
> Gilles
>
>
> best regards,
>> Luc
>>
>>
>>> [...]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message