2014-10-27 10:47 GMT+01:00 Andy Gumbrecht <[email protected]>: > So we really need to come up with something that works for everyone, but at > least one of these well defined flows: > https://www.atlassian.com/git/tutorials/comparing-workflows > > The idea is to use a well established workflow that has at least some > background and stick to it. It's easy to say I've used this and that and it > works for me. That seems to be a more of a git 'problem' that allows > everyone to come up with their own flow. Kind of a step away from a standard > API, but this seems to be why git is winning the scm war. It's not about > personal taste, it is about what do we enforce upon the future devs that > join the project (and ourselves) that will leave them (and us) in good > standing for the rest of the world. > > So let's work together to come up with a choice. > > I really like the 'Feature Branch Workflow', but if we cannot use it due to > Apache restrictions that would be huge minus for me and make me wonder why > SVN was dropped in the first place. Gitflow 'just' adds a develop branch as > the trunk, and that makes sense to me (master just being used like the svn > 'tags' branch). But it does seem to upset at least a few people (must just > be an Atlassian mistake, and let's not go anywhere near 'Forking Worklow' > ...yes I said 'Forking' :-D ). >
There is no restriction but we didn't extract any advantage of using it until now. Another thing is for a newcomer (maybe even not used to git) it would be easier to hack on master by default IMO. > The release manager actually faces this maintenance challenge every time a > release is performed in svn or git, as the project was/is not compatible > with any standard/automated Maven release process or plugins (due to the > lack of separation of the OpenEJB and TomEE projects). > Another topic but wondered since years why we don't hack maven release plugin to support it? Should be pretty easy. > Andy. > > PS. Something that really got me the other day is the inability to just > export a single directory (eg. examples) from the remote git repo (in a one > liner cmd). How did that get missed in the dev process, or does anyone have > a magic solution to that? > AFAIK we should create submodules for such things - didnt use it "for real" so no idea it is good or bad in practise. > > On 27/10/2014 09:12, Jean-Louis Monteiro wrote: >> >> Unfortunately, not enough GIT background to help much in this discussion. >> I can only say that I used (copied) the Deltaspike workflow in the past >> and >> it was enough for our needs. >> >> Jean-Louis >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> On Sun, Oct 26, 2014 at 10:11 PM, Mark Struberg <[email protected]> wrote: >> >>> Folks, that gitflow is totally nuts imo! >>> >>> First, this is a project with only senior devs, this would be the first >>> ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is >>> usually only done for maintenance- and/or relaese-branches. Everything >>> else >>> is CTR. The develop branch is just a useless buffer without a >>> build/release >>> manager who does the review and merging. It will be a hell to maintain. >>> >>> >>> >>> Second: Creating tons of temporary branches is NOT a good idea for an >>> upstream cannonical repo. >>> >>> >>>> git push -u origin TOMEE-007 >>> >>> Such things are perfectly fine on private repos or for sending pull >>> requests, but not on the central ASF repo. Why? Simple because you cannot >>> delete those branches later (ASF repos are usually configured to prevent >>> history rewrite). And also opposite to SVN you cannot get back a branch >>> someone deleted or a history someone rewrote. Once a GIT repo is trashed, >>> then you can only do a restore of the whole repo from some file backup. >>> >>> >>>> git pull origin develop >>> >>> Third: You should explain the difference between pull and fetch resp git >>> pull --rebase >>> >>> Otherwise our history will either be broken (history rewrite) or full >>> with >>> useless merge-commits. >>> >>> >>> LieGrue, >>> strub >>> >>> >>> PS: I am using GIT since 2006 and I e.g. wrote the >>> maven-scm-providers-git >>> stuff back then. GIT IS cool, but also a strong weapon to shoot yourself >>> in >>> the knee if you don't be careful. >>> >>> >>> >>>> On Friday, 17 October 2014, 17:35, Romain Manni-Bucau < >>> >>> [email protected]> wrote: >>>>> >>>>> yes, so master is just a single branch showing only tags, what's the >>>> >>>> need behind? >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau >>>> http://www.tomitribe.com >>>> http://rmannibucau.wordpress.com >>>> https://github.com/rmannibucau >>>> >>>> >>>> 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <[email protected]>: >>>>> >>>>> Release branches act as a buffer between feature development >>>>> (develop) >>> >>> and >>>>> >>>>> public releases (master). >>>>> Whenever you merge something into master, you should tag the commit >>>>> for >>>>> reference >>>>> >>>>> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master >>>>> git push --tags >>>>> >>>>> >>>>> On 17/10/2014 16:46, Romain Manni-Bucau wrote: >>>>>> >>>>>> sorry I'm surely slow today but it if can avoid me 1h ;): so >>>> >>>> what's >>>>>> >>>>>> different with tags? ie when do you go to master without having a >>>>>> release? >>>>>> >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau >>>>>> http://www.tomitribe.com >>>>>> http://rmannibucau.wordpress.com >>>>>> https://github.com/rmannibucau >>>>>> >>>>>> >>>>>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht >>>> >>>> <[email protected]>: >>>>>>> >>>>>>> Not quite, the /release /branch takes place 'whenever' - >>>> >>>> This means it >>>>>>> >>>>>>> would >>>>>>> be 'nice' to create it from a stable /develop/, but is NOT >>>> >>>> required (this >>>>>>> >>>>>>> is >>>>>>> the big +1 for me). >>>>>>> >>>>>>> The /release /branch is where the release is polished and prepared >>>> >>>> and >>>>>>> >>>>>>> all >>>>>>> the tests must 'eventually' pass - work can continue in >>>> >>>> /develop/ >>>>>>> >>>>>>> (another >>>>>>> big +1) - everyone can help make the /release /stable. >>>>>>> >>>>>>> When the /release /branch is ready then it is merged to /master >>>> >>>> /*and >>>>>>> >>>>>>> */develop /(if there were changes in the /release /then they also >>>> >>>> need to >>>>>>> >>>>>>> get merged back to /develop/) >>>>>>> >>>>>>> The /master /branch only ever contains stable production ready >>>> >>>> code. >>>>>>> >>>>>>> Andy. >>>>>>> >>>>>>> >>>>>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote: >>>>>>>> >>>>>>>> Regarding the creation of a release branch I assume that >>>> >>>> creating the >>>>>>>> >>>>>>>> branch from 'develop' implies that all available tests >>>> >>>> and quality >>>>>>>> >>>>>>>> criteries must be matched before the actual branching takes >>>> >>>> place. >>>>>>>> >>>>>>>> Am I right on this ? >>>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> Daniel Kasmeroglu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Andy Gumbrecht >>>>>>> https://twitter.com/AndyGeeDe >>>>>>> http://www.tomitribe.com >>>>>>> >>>>> -- >>>>> Andy Gumbrecht >>>>> https://twitter.com/AndyGeeDe >>>>> http://www.tomitribe.com >>>>> > > -- > Andy Gumbrecht > https://twitter.com/AndyGeeDe > http://www.tomitribe.com >
