commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [Math] Feature development model
Date Thu, 07 Jan 2016 03:21:16 GMT
On 7 January 2016 at 01:48, Gilles <> 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):
>>> 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.

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.

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

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.

> Best,
> Gilles
>> best regards,
>> Luc
>>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message