On Wed, Jan 6, 2016 at 6:48 PM, Gilles <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
