Il 23/01/2014 15.10, helix84 ha scritto: > On Thu, Jan 23, 2014 at 2:41 PM, Andrea Bollini <a.boll...@cineca.it> wrote: >> According to this workflow it looks better manage bugs as PR against 4.x >> than as PR against the master. In this way if we miss to merge something to >> the master we can do it later also in one go for multiple patches/bug fixes. > We currently do the opposite - as soon as we decide a minor release is > coming out, we scour master for bugfixes and backport them. This is a manual, error prone, boring, activity...
> The two > approaches are really interchangable and equally difficult, so as long > as we stick to either one of them, we should be fine. No really. Assuming that we are doing the thing well (all the patches go in 4.x) we can release a 4.1 at any time without any activity and at the time of feature freeze we just need to run git merge dspace-4.x from the current master to assure that all the bugs go in the next 4.1. > >> The opposite direction is not so easy as it requires cherry pick and is >> "untracked" by git, so we need to assure by ourself that we don't miss bug >> fix. > I'm not sure what you mean by untracked by git. Do you mean regular > merges of the release branch to the master branch after each fix is > commited to the release branch? You're right in that this is not > possible to do in the other direction because on master, there are > non-bugfix changes intermingled with bugfixes. But a merge is > something you have to do from the command line (i.e. GitHub doesn't > make it easier; we can also think about make post-hock on git so to trigger an automatic merge over the master when a commit is done in the maintenance branch. This sound probably adventurous but it is usually in enterprise workflow where there is a QA phase and CI (moreover we have both... testhaton and Travis/Bamboo). Andrea > well, unless you want to fire additional PRs for the > same thing, which we recently agreed is not a good thing because it > fragments the discussion to many places), just like cherry-pick. What > advantages do you see to a merge as opposed to a cherry-pick? Or did > you mean something else? > >> Also the famous GitFlow branching model >> http://nvie.com/posts/a-successful-git-branching-model/ >> suggest to work on the maintenance branch and after merge that in the >> develop branch (in our case the master). > Like I said above, the important thing is to standardize on one way. > This happens to describe the other way that the one we use, but I > really see no advantages to it. > > > Oh, and I forgot to mention one advantage to our current model I see. > It assures that if we forget to port the bugfix, it will be in all > subsequent releases, it will only miss from an old release. In the > reverse scenario, if we forget, it's fixed in the old version and not > in the future versions. I admit this doesn't happen to us very often, > but it's possible. > > The second important advantage is in case of conflict (i.e. for > complex fixes that touch code with unrelated changes between the two > branches). If we fix on master and have a problem with conflicts that > are hard to resolve, we can just decide to give up on the fix for old > release. If we start from the old one, we *have to* push through to > fix the the newer branch. > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Andrea Bollini Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria Divisione Ricerca Via dei Tizii, 6 00185 Roma, Italy tel. +39 06 44 486 087 - mob. +39 348 82 77 525 http://www.cineca.it ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
