Hi Mark, >>1.) trunk/master is the 'next planned big release'. Most of the work happens there.
As "master" is just a branch, it means we are simply renaming "develop" to "master". That would save a couple of keystrokes indeed. Instead of... git checkout -b my_local_branch origin/develop ... we would do... git checkout -b my_local_branch >>2.) For each released version we have a tag. If we need maintenance on those (like we have with 1.7.x then we simply create a maintenance branch for it. We create this tag from where? "origin/master"? If so, we would need to have a kind of code-freeze once "master" is stable and until we have our release tag ready. Our voting spans up to 3 days, maybe more. It means we wouldn't be able to push our local changes of on-going tasks until the release passes. Did I get it right? Gitflow proprosal: * we create a branch out of "develop" called "tomee-2.0.0" (for example). * we make "tomee-2.0.0" stable and call a vote. meanwhile, the developers are free to push to "develop" * "tomee-2.0.0" passes. we merge the code to "master" and to "develop" (in case minor changes were necessary) * we create a release tag out of "master" because this branch is supposed to be stable. >> 3.) If there is a need for a hotfix then simply grab the tag of the release and create a branch from it. Then just apply the fixes you really need and no bit more. Yeah, it seems simple enough. I have no problem with it. In fact, this looks like what gitflow proposes. :) So, I guess we need to decide where the main development will happen (develop or master), and whether code-freeze is acceptable or not. []s, Thiago. On Wed, Jan 28, 2015 at 8:27 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > @Thiago: if there is a security fixes we'll start from a tag anyway, > not from master > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-28 14:23 GMT+01:00 Mark Struberg <strub...@yahoo.de>: > > thiago, there is absolutely no sense in all the gitflow stuff. The more > I think about it the more I come to the conclusion they never did a big > project yet. > > > > Really the ONLY reason for such a workflow is if you have tons of > uneducated juniors working on the codebase and trashing your project by > committing more bad things than good things. But I hope that is NOT the > case for ASF projects... > > Btw, for such projects I'd rather suggest to use gerrit and not > gitflow... > > > > > > > > How does it work usually. > > > > 1.) trunk/master is the 'next planned big release'. Most of the work > happens there. > > > > > > 2.) For each released version we have a tag. If we need maintenance on > those (like we have with 1.7.x then we simply create a maintenance branch > for it. > > > > 3.) If there is a need for a hotfix then simply grab the tag of the > release and create a branch from it. Then just apply the fixes you really > need and no bit more. > > > > That works that way since years and I've never seen any issues. > > > > > > The point is that it doesn't make much sense to do all the work upfront > because you _might_ need it. Just do the work IF you need it instead. > That's really easy to do with GIT. > > > > LieGrue, > > strub > > > > > > > > > > > >> On Wednesday, 28 January 2015, 14:05, Thiago Veronezi < > thi...@veronezi.org> wrote: > >> >>> ...oops for tomee you dont get the snapshot > >> I agree. But that's the whole point. We shouldn't get the snapshot from > >> master, according to the "Gitflow". I think it pays off when we have a > >> hotfix like critical security bugs. Instead of rushing all the on-going > >> tasks in order to close them for a new release, we would simply create a > >> hotfix branch out of master, do the fix and merge it to develop and > back to > >> master. The link Andy provided has a chart that shows exactly how it > would > >> help. See the "hotfixes" line: http://nvie.com/img/git-mo...@2x.png. > >> > >> If the "pom.xml" file in "origin/master" does not use the > >> "SNAPSHOT", it > >> raises a flag to the developer. "Where the hell are the snapshots?" :) > >> She/he would need to switch to the develop branch. > >> > >> []s, > >> Thiago. > >> > >> > >> > >> On Wed, Jan 28, 2015 at 7:09 AM, Romain Manni-Bucau > >> <rmannibu...@gmail.com> > >> wrote: > >> > >>> was the idea but: > >>> - doesnt make sense @asf > >>> - are we numerous enough to commit to let it get any sense? > >>> - do we want this ability at all? > >>> > >>> IMO we dont > >>> > >>> master = 2.0.0-SNAPSHOT = last version of the main version so it is > >>> not wrong even if not sexy. > >>> > >>> What we'll do basically when releasing is just merging all to master > >>> if we keep develop so we just added noise for external guys > >>> > >>> > >>> When you go on github what do you do? > >>> > >>> git clone xxxxx > >>> cd xxxxx > >>> mvn clean install > >>> > >>> > >>> ...oops for tomee you dont get the snapshot > >>> > >>> > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-01-28 13:06 GMT+01:00 Thiago Veronezi <thi...@veronezi.org>: > >>> > Hi, > >>> > > >>> > If I get it right... > >>> > > >>> > * "origin/master" is just a regular branch, and a branch > >> represents what > >>> we > >>> > want it to be. For the "gitflow", "origin/master" > >> is our latest release. > >>> In > >>> > this case, if someone performs a checkout of master and builds the > >>> > application from it, she/he will build the 1.7.1 distribution. Note > >> that > >>> > currently it points to "2.0.0-SNAPSHOT". So maybe it is not > >> in good shape > >>> > because this source code it is not production ready. > >>> > * "origin/develop" is our tomee 2.0 > >>> > * "origin/tomee-1.7.x" is our tomee 1.7.x > >>> > > >>> > If we talk about commands, we would use the following in our > >> development > >>> > process [Just tested it to be sure. :) ]... > >>> > > >>> > // check out the source code. "origin/master" is the > >> default. We don't > >>> > commit to this guy. > >>> > git clone https://git-wip-us.apache.org/repos/asf/tomee.git > my_source > >>> > Cloning into 'my_source'... > >>> > remote: Counting objects: 236092, done. > >>> > remote: Compressing objects: 100% (73416/73416), done. > >>> > remote: Total 236092 (delta 115784), reused 233010 (delta 114168) > >>> > Receiving objects: 100% (236092/236092), 35.93 MiB | 986 KiB/s, > done. > >>> > Resolving deltas: 100% (115784/115784), done. > >>> > > >>> > // go to new directory > >>> > cd my_source > >>> > > >>> > // create a local "develop" branch for for tomee 2.0 from > >>> "origin/develop" > >>> > git checkout -b develop origin/develop > >>> > Branch develop set up to track remote branch develop from origin. > >>> > Switched to a new branch 'develop' > >>> > > >>> > // create a local "feature" branch for for tomee 2.0 from > >> the local > >>> > "develop" > >>> > git checkout -b cosmetic develop > >>> > Switched to a new branch 'cosmetic' > >>> > > >>> > // now we work on the tomee 2.0 feature and commit > >>> > git status > >>> > git add pom.xml > >>> > git commit -m "moving end tag up" > >>> > > >>> > // ready to merge back to develop > >>> > git checkout develop > >>> > > >>> > // update develop > >>> > git pull > >>> > > >>> > // merge our local branch > >>> > git merge cosmetic > >>> > Updating edaf6d2..21ad55b > >>> > Fast-forward > >>> > pom.xml | 3 +-- > >>> > 1 file changed, 1 insertion(+), 2 deletions(-) > >>> > > >>> > // push to remote develop > >>> > git push > >>> > > >>> > // delete local branch > >>> > git branch -d cosmetic > >>> > Deleted branch cosmetic (was 21ad55b). > >>> > > >>> > // if we have a new feature, we repeat step from this step... > >>> > git checkout -b new_feature develop > >>> > ... > >>> > > >>> > > >>> > Basically, we don't touch "origin/master". Only when we > >> merge > >>> > "origin/tomee.1.7.x" (or "origin/develop") back to > >> it. > >>> > I don't see a problem. We just need to keep in mind what > >> "origin/master", > >>> > "origin/develop" and "origin/tomee.1.7.x" > >> represent. > >>> > > >>> > Is that right? > >>> > > >>> > []s, > >>> > Thiago. > >>> > > >>> > > >>> > On Wed, Jan 28, 2015 at 4:59 AM, Romain Manni-Bucau < > >>> rmannibu...@gmail.com> > >>> > wrote: > >>> > > >>> >> well it is by design opposed to apache way since if it is used it > >> is > >>> >> to have the ability to change commit history - if not it is really > >>> >> useless. > >>> >> > >>> >> > >>> >> Romain Manni-Bucau > >>> >> @rmannibucau > >>> >> http://www.tomitribe.com > >>> >> http://rmannibucau.wordpress.com > >>> >> https://github.com/rmannibucau > >>> >> > >>> >> > >>> >> 2015-01-28 10:57 GMT+01:00 Andy Gumbrecht > >> <agumbre...@tomitribe.com>: > >>> >> > I know I set it up this way, but I am really +0 at the > >> moment. I don't > >>> >> feel > >>> >> > any anger towards it though. It is not 'my way', > >> rather the Gitflow > >>> way. > >>> >> > > >>> >> > I'm not going to push it other than to point to the > >> description of > >>> >> Gitflow. > >>> >> > It's only going to make sense if you use it, and then > >> really only if > >>> you > >>> >> > play release manager, and then only if you are managing both > >> 1.7.x and > >>> >> > develop releases. > >>> >> > > >>> >> > The scenario is described here in extreme detail - > >>> >> > > >>> >> > >>> > >> > https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow > >>> >> > > >>> >> > It just 'looks' future safe to do it that way, and > >> until the Gitflow > >>> has > >>> >> > been tried and tested on the upcoming releases we will not > >> know. Jon > >>> >> should > >>> >> > give us his feedback after the releases are done. And then we > >> should > >>> all > >>> >> > look at the repo. The decision to use it was based on that > >> description > >>> >> and > >>> >> > they guy who 'invented' it - > >>> >> > http://nvie.com/posts/a-successful-git-branching-model/ > >>> >> > > >>> >> > I actually don't know what is so painful about using > >> '-b develop' on > >>> the > >>> >> > initial developer checkout? That's it, everything else is > >> identical. > >>> As a > >>> >> > developer it is trivial. Where are the hard line drawbacks to > >> it other > >>> >> than > >>> >> > to say it's crap? Why is is so painful for some? I really > >> want to > >>> >> understand > >>> >> > what is causing the hate? > >>> >> > > >>> >> > The simple idea is that 'master' only ever contains > >> production ready > >>> >> code, > >>> >> > that's it. No more no less. > >>> >> > > >>> >> > Anyway, if everyone agrees on a way forward then votes on it > >> then I > >>> >> really > >>> >> > am +0, as it is not hard to do it either way. > >>> >> > > >>> >> > That doesn't mean: > >>> >> > -1 It's crap! > >>> >> > > >>> >> > That does mean: > >>> >> > -1 It's crap because.... and I will document 'my > >> way' for everyone to > >>> >> follow > >>> >> > to the letter. > >>> >> > > >>> >> > Andy. > >>> >> > > >>> >> > > >>> >> > On 28/01/2015 09:55, Romain Manni-Bucau wrote: > >>> >> >> > >>> >> >> hehe feel less alone now, +1 > >>> >> >> > >>> >> >> > >>> >> >> Romain Manni-Bucau > >>> >> >> @rmannibucau > >>> >> >> http://www.tomitribe.com > >>> >> >> http://rmannibucau.wordpress.com > >>> >> >> https://github.com/rmannibucau > >>> >> >> > >>> >> >> > >>> >> >> 2015-01-28 9:53 GMT+01:00 Mark Struberg > >> <strub...@yahoo.de>: > >>> >> >>> > >>> >> >>> Hi folks! > >>> >> >>> > >>> >> >>> Just noticed that our branch naming schema in GIT is > >> still > >>> outerwordly > >>> >> >>> fucked up. > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> Why don't we do it as everyone else does? > >>> >> >>> What does this crap of development branch do? > >> It's total nonsense to > >>> >> have > >>> >> >>> it! > >>> >> >>> > >>> >> >>> There is NO RTC for development at whole ASF except > >> for MAINTENANCE > >>> >> >>> BRANCHES maybe. All the standard community work is > >> CTR (Commmit Then > >>> >> Review) > >>> >> >>> That's a community wide modus operandi and we > >> should follow it as > >>> well. > >>> >> >>> > >>> >> >>> > >>> >> >>> So I for one will totally ignore this development > >> branch when > >>> working > >>> >> on > >>> >> >>> the TCK in the next days. > >>> >> >>> > >>> >> >>> Can we please finally merge in all the good work in > >> the development > >>> >> >>> branch to master and delete it finally? > >>> >> >>> > >>> >> >>> > >>> >> >>> LieGrue, > >>> >> >>> strub > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> -- > >>> >> >> Andy Gumbrecht > >>> >> >> https://twitter.com/AndyGeeDe > >>> >> >> http://www.tomitribe.com > >>> >> > >>> > >> >
