what is which branch up for?
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
Re: what is which branch up for?
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 : > 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
Re: what is which branch up for?
master is on the state of OKTOBER 2014! Now people think about that: what do others look at when they check out a project. They look at trunk/master! And there they see that the project didn't move since almost a half yea? Christ, that's totally nuts! LieGrue, strub > On Wednesday, 28 January 2015, 9: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 : >> 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 >
Re: what is which branch up for?
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 : 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
Re: what is which branch up for?
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 : > 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 : >>> >>> 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
Re: what is which branch up for?
agree. Gitflow is basically a workflow replacement of what we have with out commit mails anyway. This is something we technically do not need at ASF. Plus it requires extra manpower for managing the merges... LieGrue, strub > On Wednesday, 28 January 2015, 11:00, Romain Manni-Bucau > 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 : >> 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 : 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 >
Re: what is which branch up for?
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 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 : > > 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 : > >>> > >>> Hi folks! > >>> > >>> Just noticed that our branch naming schema in GIT is still outerwordly > >>> fucked up. > >>> > >>> > >>> > >>> Why don't we do
Re: what is which branch up for?
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 x cd x 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 : > 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 > 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 : >> > 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'
Re: what is which branch up for?
>>...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 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 x > cd x > 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 : > > 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 : > >> > 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 s
Re: what is which branch up for?
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 > 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 > > 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 x >> cd x >> 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 : >> > 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 merg
Re: what is which branch up for?
@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 : > 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 >> 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 >> >> 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 x >>> cd x >>> 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 : >>> > 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" >>
Example+request
Hi guys, is there a way to mimic JBoss modules in Tommy? Thanks Max
Re: Example+request
Hi You mean "OSGi" like feature? Intentionally not to keep thing simple for everybody and avoid to depend on it in apps. why do you need it in a EE app BTW? Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 14:44 GMT+01:00 Massimiliano Maggiari : > Hi guys, is there a way to mimic JBoss modules in Tommy? > Thanks > Max >
useless branches and branch deletes at asf git repos
Hi folks! I've found another thing which is ugly release-tomee-1.7.2 and tomee-1.7.2 branches which are actually just leftovers it seems? Please be aware that we MUST NOT DELETE anything at ASF repos! We must not do history rewrite! So think REALLY hard before creating branches which are just utter garbage. In git you just cannot get rid of them that easily. They get mirrored downstream automatically and we have no whatever control about them anymore! Please read how we handle GIT over at DeltaSpike. We e.g. release with localCheckout=true and pushChanges=false. Just ping me if I need to go into details. LieGrue, strub
Re: useless branches and branch deletes at asf git repos
I'd just delete them since it is not tag but working branch - tag shouldn't have been pushed since vote didnt pass. We are free to create branches and remove them once we consider them useless Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 15:07 GMT+01:00 Mark Struberg : > Hi folks! > > I've found another thing which is ugly > > release-tomee-1.7.2 and > tomee-1.7.2 branches which are actually just leftovers it seems? > > > Please be aware that we MUST NOT DELETE anything at ASF repos! We must not do > history rewrite! > > So think REALLY hard before creating branches which are just utter garbage. > In git you just cannot get rid of them that easily. They get mirrored > downstream automatically and we have no whatever control about them anymore! > > Please read how we handle GIT over at DeltaSpike. > > We e.g. release with localCheckout=true and pushChanges=false. > > > Just ping me if I need to go into details. > > LieGrue, > strub
Re: useless branches and branch deletes at asf git repos
These are leftovers from the vote cancelled earlier this week. My intention was to clean them up - sounds like that should not be done from what you're saying? I'll ping you to discuss. Jon On Wed, Jan 28, 2015 at 2:09 PM, Romain Manni-Bucau wrote: > I'd just delete them since it is not tag but working branch - tag > shouldn't have been pushed since vote didnt pass. > > We are free to create branches and remove them once we consider them > useless > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-28 15:07 GMT+01:00 Mark Struberg : > > Hi folks! > > > > I've found another thing which is ugly > > > > release-tomee-1.7.2 and > > tomee-1.7.2 branches which are actually just leftovers it seems? > > > > > > Please be aware that we MUST NOT DELETE anything at ASF repos! We must > not do history rewrite! > > > > So think REALLY hard before creating branches which are just utter > garbage. In git you just cannot get rid of them that easily. They get > mirrored downstream automatically and we have no whatever control about > them anymore! > > > > Please read how we handle GIT over at DeltaSpike. > > > > We e.g. release with localCheckout=true and pushChanges=false. > > > > > > Just ping me if I need to go into details. > > > > LieGrue, > > strub >
Re: useless branches and branch deletes at asf git repos
No worries John. I think what happened is that the setup for GIT is still wrong. Will need to dig and fix it. LieGrue, strub > On Wednesday, 28 January 2015, 15:49, Jonathan Gallimore > wrote: > >T hese are leftovers from the vote cancelled earlier this week. My intention > was to clean them up - sounds like that should not be done from what you're > saying? I'll ping you to discuss. > > Jon > > > On Wed, Jan 28, 2015 at 2:09 PM, Romain Manni-Bucau > > wrote: > >> I'd just delete them since it is not tag but working branch - tag >> shouldn't have been pushed since vote didnt pass. >> >> We are free to create branches and remove them once we consider them >> useless >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-28 15:07 GMT+01:00 Mark Struberg : >> > Hi folks! >> > >> > I've found another thing which is ugly >> > >> > release-tomee-1.7.2 and >> > tomee-1.7.2 branches which are actually just leftovers it seems? >> > >> > >> > Please be aware that we MUST NOT DELETE anything at ASF repos! We must >> not do history rewrite! >> > >> > So think REALLY hard before creating branches which are just utter >> garbage. In git you just cannot get rid of them that easily. They get >> mirrored downstream automatically and we have no whatever control about >> them anymore! >> > >> > Please read how we handle GIT over at DeltaSpike. >> > >> > We e.g. release with localCheckout=true and pushChanges=false. >> > >> > >> > Just ping me if I need to go into details. >> > >> > LieGrue, >> > strub >> >
Re: what is which branch up for?
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 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 : > > 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 > >> > >> 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 x > >>> cd x > >>> mvn clean install > >>> > >>> > >>> ...oops for tomee you dont get the snapshot > >>> > >>> > >>> > >>> > >>> Romain Manni-Buc
Re: useless branches and branch deletes at asf git repos
Deleting committed changes is definitely bad. Deleting branches that ultimately participate in the release is also bad. However, deleting tags for "failed" releases is fine as is deleting a branch that never transitively participated in a release should be fine as well. Do I misunderstand something? Is there some infrastructure limitation? Sent from my iPhone > On Jan 28, 2015, at 6:07 AM, Mark Struberg wrote: > > Hi folks! > > I've found another thing which is ugly > > release-tomee-1.7.2 and > tomee-1.7.2 branches which are actually just leftovers it seems? > > > Please be aware that we MUST NOT DELETE anything at ASF repos! We must not do > history rewrite! > > So think REALLY hard before creating branches which are just utter garbage. > In git you just cannot get rid of them that easily. They get mirrored > downstream automatically and we have no whatever control about them anymore! > > Please read how we handle GIT over at DeltaSpike. > > We e.g. release with localCheckout=true and pushChanges=false. > > > Just ping me if I need to go into details. > > LieGrue, > strub
Re: what is which branch up for?
answering inline 2015-01-28 18:13 GMT+01:00 Thiago Veronezi : > 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 > +1 > ... 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? > we take the last maintainance branch, add the few fixes we need and then create the release branch and release from here. Once the vote passed the RM pushes the tag. If it doesnt we can either delete the release branch or fix it if it is minor. Of course if the diff between last maintaince branch and the fix we want to do - assume we want to fix something in 1.0 now - we'll create another maintaince branch from the 1.0 tag. I'd like a master which is our old trunk = not an issue if not stable, that's the branch interesting guys going to sources so let it be the default. > 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 > 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 : >> > 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,
Re: useless branches and branch deletes at asf git repos
Deleting those is fine. But we must make sure that no essential commit gets lost. And this is only doable by totally forbidding history rewrite on the repo. LieGrue, strub > On Wednesday, 28 January 2015, 18:27, Alan Cabrera > wrote: > > Deleting committed changes is definitely bad. Deleting branches that > > ultimately > participate in the release is also bad. > > However, deleting tags for "failed" releases is fine as is deleting a > branch that never transitively participated in a release should be fine as > well. > > Do I misunderstand something? Is there some infrastructure limitation? > > Sent from my iPhone > > >> On Jan 28, 2015, at 6:07 AM, Mark Struberg wrote: >> >> Hi folks! >> >> I've found another thing which is ugly >> >> release-tomee-1.7.2 and >> tomee-1.7.2 branches which are actually just leftovers it seems? >> >> >> Please be aware that we MUST NOT DELETE anything at ASF repos! We must not > do history rewrite! >> >> So think REALLY hard before creating branches which are just utter garbage. > In git you just cannot get rid of them that easily. They get mirrored > downstream > automatically and we have no whatever control about them anymore! >> >> Please read how we handle GIT over at DeltaSpike. >> >> We e.g. release with localCheckout=true and pushChanges=false. >> >> >> Just ping me if I need to go into details. >> >> LieGrue, >> strub >
Re: useless branches and branch deletes at asf git repos
Ahh, ok, your warnings did seem overly broad to me. How is that enforced on ASF infrastructure? Is it by an “honor system” that we assume no history rewrites are taking place? Regards, Alan > On Jan 28, 2015, at 10:12 AM, Mark Struberg wrote: > > Deleting those is fine. But we must make sure that no essential commit gets > lost. And this is only doable by totally forbidding history rewrite on the > repo. > > LieGrue, > strub > > > > > >> On Wednesday, 28 January 2015, 18:27, Alan Cabrera >> wrote: >>> Deleting committed changes is definitely bad. Deleting branches that >>> ultimately >> participate in the release is also bad. >> >> However, deleting tags for "failed" releases is fine as is deleting a >> branch that never transitively participated in a release should be fine as >> well. >> >> Do I misunderstand something? Is there some infrastructure limitation? >> >> Sent from my iPhone >> >> >>> On Jan 28, 2015, at 6:07 AM, Mark Struberg wrote: >>> >>> Hi folks! >>> >>> I've found another thing which is ugly >>> >>> release-tomee-1.7.2 and >>> tomee-1.7.2 branches which are actually just leftovers it seems? >>> >>> >>> Please be aware that we MUST NOT DELETE anything at ASF repos! We must not >> do history rewrite! >>> >>> So think REALLY hard before creating branches which are just utter garbage. >> In git you just cannot get rid of them that easily. They get mirrored >> downstream >> automatically and we have no whatever control about them anymore! >>> >>> Please read how we handle GIT over at DeltaSpike. >>> >>> We e.g. release with localCheckout=true and pushChanges=false. >>> >>> >>> Just ping me if I need to go into details. >>> >>> LieGrue, >>> strub >>
Re: useless branches and branch deletes at asf git repos
Nothing forbids it so it is responsability of everyone. Le 28 janv. 2015 19:59, "Alan D. Cabrera" a écrit : > Ahh, ok, your warnings did seem overly broad to me. > > How is that enforced on ASF infrastructure? Is it by an “honor system” > that we assume no history rewrites are taking place? > > > Regards, > Alan > > > > On Jan 28, 2015, at 10:12 AM, Mark Struberg wrote: > > > > Deleting those is fine. But we must make sure that no essential commit > gets lost. And this is only doable by totally forbidding history rewrite on > the repo. > > > > LieGrue, > > strub > > > > > > > > > > > >> On Wednesday, 28 January 2015, 18:27, Alan Cabrera < > l...@toolazydogs.com> wrote: > >>> Deleting committed changes is definitely bad. Deleting branches that > ultimately > >> participate in the release is also bad. > >> > >> However, deleting tags for "failed" releases is fine as is deleting a > >> branch that never transitively participated in a release should be fine > as well. > >> > >> Do I misunderstand something? Is there some infrastructure limitation? > >> > >> Sent from my iPhone > >> > >> > >>> On Jan 28, 2015, at 6:07 AM, Mark Struberg wrote: > >>> > >>> Hi folks! > >>> > >>> I've found another thing which is ugly > >>> > >>> release-tomee-1.7.2 and > >>> tomee-1.7.2 branches which are actually just leftovers it seems? > >>> > >>> > >>> Please be aware that we MUST NOT DELETE anything at ASF repos! We must > not > >> do history rewrite! > >>> > >>> So think REALLY hard before creating branches which are just utter > garbage. > >> In git you just cannot get rid of them that easily. They get mirrored > downstream > >> automatically and we have no whatever control about them anymore! > >>> > >>> Please read how we handle GIT over at DeltaSpike. > >>> > >>> We e.g. release with localCheckout=true and pushChanges=false. > >>> > >>> > >>> Just ping me if I need to go into details. > >>> > >>> LieGrue, > >>> strub > >> > >
Re: useless branches and branch deletes at asf git repos
I personally would suggest we disable history rewrite for our whole ASF repo. This is a single config line in the repo. History rewrite has a huge potential to crack the repo beyond repair anyway. LieGrue, strub > On Wednesday, 28 January 2015, 20:12, Romain Manni-Bucau > wrote: > > Nothing forbids it so it is responsability of everyone. > > Le 28 janv. 2015 19:59, "Alan D. Cabrera" > a écrit : > >> Ahh, ok, your warnings did seem overly broad to me. >> >> How is that enforced on ASF infrastructure? Is it by an “honor system” >> that we assume no history rewrites are taking place? >> >> >> Regards, >> Alan >> >> >> > On Jan 28, 2015, at 10:12 AM, Mark Struberg > wrote: >> > >> > Deleting those is fine. But we must make sure that no essential commit >> gets lost. And this is only doable by totally forbidding history rewrite on >> the repo. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> > >> >> On Wednesday, 28 January 2015, 18:27, Alan Cabrera < >> l...@toolazydogs.com> wrote: >> >>> Deleting committed changes is definitely bad. Deleting > branches that >> ultimately >> >> participate in the release is also bad. >> >> >> >> However, deleting tags for "failed" releases is fine as > is deleting a >> >> branch that never transitively participated in a release should be > fine >> as well. >> >> >> >> Do I misunderstand something? Is there some infrastructure > limitation? >> >> >> >> Sent from my iPhone >> >> >> >> >> >>> On Jan 28, 2015, at 6:07 AM, Mark Struberg > wrote: >> >>> >> >>> Hi folks! >> >>> >> >>> I've found another thing which is ugly >> >>> >> >>> release-tomee-1.7.2 and >> >>> tomee-1.7.2 branches which are actually just leftovers it > seems? >> >>> >> >>> >> >>> Please be aware that we MUST NOT DELETE anything at ASF repos! > We must >> not >> >> do history rewrite! >> >>> >> >>> So think REALLY hard before creating branches which are just > utter >> garbage. >> >> In git you just cannot get rid of them that easily. They get > mirrored >> downstream >> >> automatically and we have no whatever control about them anymore! >> >>> >> >>> Please read how we handle GIT over at DeltaSpike. >> >>> >> >>> We e.g. release with localCheckout=true and pushChanges=false. >> >>> >> >>> >> >>> Just ping me if I need to go into details. >> >>> >> >>> LieGrue, >> >>> strub >> >> >> >> >
Re: what is which branch up for?
What about having something like this? https://dl.dropboxusercontent.com/u/1459144/tomee_git.jpg * master is the place we push bleeding edge stuff. * 1.7.x is stable and will never get back to master. We create our current release tags (bug fixes, tomcat upgrades etc) out of it. * 2.x.x is stable and contains code out of master (rebase). During release, we rebase this branch, create auxiliary branches out of it for voting purposes. Once the voting passes, we merge it back to 2.x.x, create the release tag out of 2.x.x and delete the auxiliary branch. []s, Thiago. On Wed, Jan 28, 2015 at 12:32 PM, Romain Manni-Bucau wrote: > answering inline > > 2015-01-28 18:13 GMT+01:00 Thiago Veronezi : > > 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 > > > > +1 > > > ... 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? > > > > we take the last maintainance branch, add the few fixes we need and > then create the release branch and release from here. Once the vote > passed the RM pushes the tag. If it doesnt we can either delete the > release branch or fix it if it is minor. > > Of course if the diff between last maintaince branch and the fix we > want to do - assume we want to fix something in 1.0 now - we'll create > another maintaince branch from the 1.0 tag. > > I'd like a master which is our old trunk = not an issue if not stable, > that's the branch interesting guys going to sources so let it be the > default. > > > 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 : > >> > 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
Re: what is which branch up for?
well while master = 2.x.x I wouldn't create it but yes (Tomcat model basically is nice 1 maintaince branch by N-1 maintained version + trunk for last one). Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 20:48 GMT+01:00 Thiago Veronezi : > What about having something like this? > https://dl.dropboxusercontent.com/u/1459144/tomee_git.jpg > > * master is the place we push bleeding edge stuff. > * 1.7.x is stable and will never get back to master. We create our current > release tags (bug fixes, tomcat upgrades etc) out of it. > * 2.x.x is stable and contains code out of master (rebase). During release, > we rebase this branch, create auxiliary branches out of it for voting > purposes. Once the voting passes, we merge it back to 2.x.x, create the > release tag out of 2.x.x and delete the auxiliary branch. > > []s, > Thiago. > > > > > > On Wed, Jan 28, 2015 at 12:32 PM, Romain Manni-Bucau > wrote: > >> answering inline >> >> 2015-01-28 18:13 GMT+01:00 Thiago Veronezi : >> > 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 >> > >> >> +1 >> >> > ... 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? >> > >> >> we take the last maintainance branch, add the few fixes we need and >> then create the release branch and release from here. Once the vote >> passed the RM pushes the tag. If it doesnt we can either delete the >> release branch or fix it if it is minor. >> >> Of course if the diff between last maintaince branch and the fix we >> want to do - assume we want to fix something in 1.0 now - we'll create >> another maintaince branch from the 1.0 tag. >> >> I'd like a master which is our old trunk = not an issue if not stable, >> that's the branch interesting guys going to sources so let it be the >> default. >> >> > 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 : >> >> > 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 bran
Re: what is which branch up for?
Please note that having "2.x.x" covers all the requirements: * master is the bleeding edge - it doesn't need to be stable * no code-freeze necessary * stable and ready for production "2.x.x" branch * quick bug fix release possible without interrupting development on master []s, Thiago. On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau wrote: > well while master = 2.x.x I wouldn't create it but yes (Tomcat model > basically is nice 1 maintaince branch by N-1 maintained version + > trunk for last one). > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau >
Re: what is which branch up for?
If I have a fix to do in 2.x, where do I code? 2.x.x or master? While master = 2.x I'm not convinced we need it. Doesnt solve the need of a release branch while mvn tools are not compliant with tomee setup. Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : > Please note that having "2.x.x" covers all the requirements: > * master is the bleeding edge - it doesn't need to be stable > * no code-freeze necessary > * stable and ready for production "2.x.x" branch > * quick bug fix release possible without interrupting development on master > > []s, > Thiago. > > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau > wrote: > >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model >> basically is nice 1 maintaince branch by N-1 maintained version + >> trunk for last one). >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >>
Re: what is which branch up for?
Hi, This is what I was thinking... Quick bug fix in 2.x.x: * You create a new auxiliary branch from 2.x.x. -> Let's call it "2.0.2" as example * You fix your issue in this new "2.0.2" branch * Call a vote for "2.0.2". * The vote passes. You merge "2.0.2" back to "2.x.x". * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" * You destroy the auxiliary branch "2.0.2" * You merge "2.x.x" back to master. Normal 2.x.x release * You rebase "2.x.x" * You follow the same steps as the ones for "quick bug fixes in 2.x.x" []s, Thiago. On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau wrote: > If I have a fix to do in 2.x, where do I code? 2.x.x or master? While > master = 2.x I'm not convinced we need it. Doesnt solve the need of a > release branch while mvn tools are not compliant with tomee setup. > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : > > Please note that having "2.x.x" covers all the requirements: > > * master is the bleeding edge - it doesn't need to be stable > > * no code-freeze necessary > > * stable and ready for production "2.x.x" branch > > * quick bug fix release possible without interrupting development on > master > > > > []s, > > Thiago. > > > > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model > >> basically is nice 1 maintaince branch by N-1 maintained version + > >> trunk for last one). > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> >
Re: what is which branch up for?
Maybe it can be something like... Quick bug fix in 2.x.x: * You fix your issue in "2.x.x" * Call a vote for "2.x.x". * The vote passes. You merge "2.x.x" back to "master". * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" Normal 2.x.x release * You rebase "2.x.x" * You follow the same steps as the ones for "quick bug fixes in 2.x.x" This way we avoid the auxiliary branches. We just need to be sure that "2.x.x" is not a development branch. It needs to be stable. So, once we rebase it, we need to make it stable before merging it back to master. "2.x.x" is the branch that contains the release tags. []s, Thiago. On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi wrote: > Hi, > This is what I was thinking... > > Quick bug fix in 2.x.x: > * You create a new auxiliary branch from 2.x.x. -> Let's call it "2.0.2" > as example > * You fix your issue in this new "2.0.2" branch > * Call a vote for "2.0.2". > * The vote passes. You merge "2.0.2" back to "2.x.x". > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > * You destroy the auxiliary branch "2.0.2" > * You merge "2.x.x" back to master. > > Normal 2.x.x release > * You rebase "2.x.x" > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" > > []s, > Thiago. > > > > On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau > wrote: > >> If I have a fix to do in 2.x, where do I code? 2.x.x or master? While >> master = 2.x I'm not convinced we need it. Doesnt solve the need of a >> release branch while mvn tools are not compliant with tomee setup. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : >> > Please note that having "2.x.x" covers all the requirements: >> > * master is the bleeding edge - it doesn't need to be stable >> > * no code-freeze necessary >> > * stable and ready for production "2.x.x" branch >> > * quick bug fix release possible without interrupting development on >> master >> > >> > []s, >> > Thiago. >> > >> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model >> >> basically is nice 1 maintaince branch by N-1 maintained version + >> >> trunk for last one). >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> > >
Re: what is which branch up for?
well you shouldn't rebase/merge from a lower to upper branch IMO - ie it is always fixed first on mainstream then backported if needed - or just dev in the lower version if specific. That said this doesn't justify 2.x while master = 2.x Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 22:12 GMT+01:00 Thiago Veronezi : > Maybe it can be something like... > > Quick bug fix in 2.x.x: > * You fix your issue in "2.x.x" > * Call a vote for "2.x.x". > * The vote passes. You merge "2.x.x" back to "master". > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > > Normal 2.x.x release > * You rebase "2.x.x" > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" > > This way we avoid the auxiliary branches. We just need to be sure that > "2.x.x" is not a development branch. It needs to be stable. So, once we > rebase it, we need to make it stable before merging it back to master. > "2.x.x" is the branch that contains the release tags. > > []s, > Thiago. > > > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > wrote: > >> Hi, >> This is what I was thinking... >> >> Quick bug fix in 2.x.x: >> * You create a new auxiliary branch from 2.x.x. -> Let's call it "2.0.2" >> as example >> * You fix your issue in this new "2.0.2" branch >> * Call a vote for "2.0.2". >> * The vote passes. You merge "2.0.2" back to "2.x.x". >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> * You destroy the auxiliary branch "2.0.2" >> * You merge "2.x.x" back to master. >> >> Normal 2.x.x release >> * You rebase "2.x.x" >> * You follow the same steps as the ones for "quick bug fixes in 2.x.x" >> >> []s, >> Thiago. >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau > > wrote: >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? While >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of a >>> release branch while mvn tools are not compliant with tomee setup. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau >>> http://www.tomitribe.com >>> http://rmannibucau.wordpress.com >>> https://github.com/rmannibucau >>> >>> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : >>> > Please note that having "2.x.x" covers all the requirements: >>> > * master is the bleeding edge - it doesn't need to be stable >>> > * no code-freeze necessary >>> > * stable and ready for production "2.x.x" branch >>> > * quick bug fix release possible without interrupting development on >>> master >>> > >>> > []s, >>> > Thiago. >>> > >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < >>> rmannibu...@gmail.com> >>> > wrote: >>> > >>> >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model >>> >> basically is nice 1 maintaince branch by N-1 maintained version + >>> >> trunk for last one). >>> >> >>> >> >>> >> Romain Manni-Bucau >>> >> @rmannibucau >>> >> http://www.tomitribe.com >>> >> http://rmannibucau.wordpress.com >>> >> https://github.com/rmannibucau >>> >> >>> >> >>
Re: what is which branch up for?
But if you only have master, any quick fix would bring unnecessary baggage, right? I mean, merging the fix changes from 2.x.x to master would be trivial because it would only contain changes for that particular fix. If the release tags are on master, for a quick fix, we would need to create a new branch from the latest release tag, do the fix in the new branch and release it again. Where would this new release tag live? Do we keep this new branch just to hold a minor code change for a bug fix? []s, Thiago On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau wrote: > well you shouldn't rebase/merge from a lower to upper branch IMO - ie > it is always fixed first on mainstream then backported if needed - or > just dev in the lower version if specific. > > That said this doesn't justify 2.x while master = 2.x > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-28 22:12 GMT+01:00 Thiago Veronezi : > > Maybe it can be something like... > > > > Quick bug fix in 2.x.x: > > * You fix your issue in "2.x.x" > > * Call a vote for "2.x.x". > > * The vote passes. You merge "2.x.x" back to "master". > > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > > > > Normal 2.x.x release > > * You rebase "2.x.x" > > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" > > > > This way we avoid the auxiliary branches. We just need to be sure that > > "2.x.x" is not a development branch. It needs to be stable. So, once we > > rebase it, we need to make it stable before merging it back to master. > > "2.x.x" is the branch that contains the release tags. > > > > []s, > > Thiago. > > > > > > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > > wrote: > > > >> Hi, > >> This is what I was thinking... > >> > >> Quick bug fix in 2.x.x: > >> * You create a new auxiliary branch from 2.x.x. -> Let's call it "2.0.2" > >> as example > >> * You fix your issue in this new "2.0.2" branch > >> * Call a vote for "2.0.2". > >> * The vote passes. You merge "2.0.2" back to "2.x.x". > >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > >> * You destroy the auxiliary branch "2.0.2" > >> * You merge "2.x.x" back to master. > >> > >> Normal 2.x.x release > >> * You rebase "2.x.x" > >> * You follow the same steps as the ones for "quick bug fixes in 2.x.x" > >> > >> []s, > >> Thiago. > >> > >> > >> > >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < > rmannibu...@gmail.com > >> > wrote: > >> > >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? While > >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of a > >>> release branch while mvn tools are not compliant with tomee setup. > >>> > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau > >>> http://www.tomitribe.com > >>> http://rmannibucau.wordpress.com > >>> https://github.com/rmannibucau > >>> > >>> > >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : > >>> > Please note that having "2.x.x" covers all the requirements: > >>> > * master is the bleeding edge - it doesn't need to be stable > >>> > * no code-freeze necessary > >>> > * stable and ready for production "2.x.x" branch > >>> > * quick bug fix release possible without interrupting development on > >>> master > >>> > > >>> > []s, > >>> > Thiago. > >>> > > >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < > >>> rmannibu...@gmail.com> > >>> > wrote: > >>> > > >>> >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model > >>> >> basically is nice 1 maintaince branch by N-1 maintained version + > >>> >> trunk for last one). > >>> >> > >>> >> > >>> >> Romain Manni-Bucau > >>> >> @rmannibucau > >>> >> http://www.tomitribe.com > >>> >> http://rmannibucau.wordpress.com > >>> >> https://github.com/rmannibucau > >>> >> > >>> > >> > >> >
Re: what is which branch up for?
2015-01-28 22:29 GMT+01:00 Thiago Veronezi : > But if you only have master, any quick fix would bring unnecessary baggage, > right? > I mean, merging the fix changes from 2.x.x to master would be trivial > because it would only contain changes for that particular fix. > > If the release tags are on master, for a quick fix, we would need to create > a new branch from the latest release tag, do the fix in the new branch and > release it again. Where would this new release tag live? Do we keep this > new branch just to hold a minor code change for a bug fix? If that's a fix for a recent release we just create a branch for the release, release, tag, delete the release branch - like we'd have do it just after the release ignoring all commit in between. Otherwise you are back to current status = you merge all commit done on 2.x on master which is: 1) useless 2) makes a lot of noise when done 3) makes getting started not obvious (need doc) > > []s, > Thiago > > > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau > wrote: > >> well you shouldn't rebase/merge from a lower to upper branch IMO - ie >> it is always fixed first on mainstream then backported if needed - or >> just dev in the lower version if specific. >> >> That said this doesn't justify 2.x while master = 2.x >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi : >> > Maybe it can be something like... >> > >> > Quick bug fix in 2.x.x: >> > * You fix your issue in "2.x.x" >> > * Call a vote for "2.x.x". >> > * The vote passes. You merge "2.x.x" back to "master". >> > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> > >> > Normal 2.x.x release >> > * You rebase "2.x.x" >> > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" >> > >> > This way we avoid the auxiliary branches. We just need to be sure that >> > "2.x.x" is not a development branch. It needs to be stable. So, once we >> > rebase it, we need to make it stable before merging it back to master. >> > "2.x.x" is the branch that contains the release tags. >> > >> > []s, >> > Thiago. >> > >> > >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi >> > wrote: >> > >> >> Hi, >> >> This is what I was thinking... >> >> >> >> Quick bug fix in 2.x.x: >> >> * You create a new auxiliary branch from 2.x.x. -> Let's call it "2.0.2" >> >> as example >> >> * You fix your issue in this new "2.0.2" branch >> >> * Call a vote for "2.0.2". >> >> * The vote passes. You merge "2.0.2" back to "2.x.x". >> >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> >> * You destroy the auxiliary branch "2.0.2" >> >> * You merge "2.x.x" back to master. >> >> >> >> Normal 2.x.x release >> >> * You rebase "2.x.x" >> >> * You follow the same steps as the ones for "quick bug fixes in 2.x.x" >> >> >> >> []s, >> >> Thiago. >> >> >> >> >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < >> rmannibu...@gmail.com >> >> > wrote: >> >> >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? While >> >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of a >> >>> release branch while mvn tools are not compliant with tomee setup. >> >>> >> >>> >> >>> Romain Manni-Bucau >> >>> @rmannibucau >> >>> http://www.tomitribe.com >> >>> http://rmannibucau.wordpress.com >> >>> https://github.com/rmannibucau >> >>> >> >>> >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : >> >>> > Please note that having "2.x.x" covers all the requirements: >> >>> > * master is the bleeding edge - it doesn't need to be stable >> >>> > * no code-freeze necessary >> >>> > * stable and ready for production "2.x.x" branch >> >>> > * quick bug fix release possible without interrupting development on >> >>> master >> >>> > >> >>> > []s, >> >>> > Thiago. >> >>> > >> >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < >> >>> rmannibu...@gmail.com> >> >>> > wrote: >> >>> > >> >>> >> well while master = 2.x.x I wouldn't create it but yes (Tomcat model >> >>> >> basically is nice 1 maintaince branch by N-1 maintained version + >> >>> >> trunk for last one). >> >>> >> >> >>> >> >> >>> >> Romain Manni-Bucau >> >>> >> @rmannibucau >> >>> >> http://www.tomitribe.com >> >>> >> http://rmannibucau.wordpress.com >> >>> >> https://github.com/rmannibucau >> >>> >> >> >>> >> >> >> >> >>
Re: what is which branch up for?
Hmmm... I think I see how it works now. It starts to make more sense. :) Something doesn't feel right though. Why Gitflow is so popular? How would it protect the companies from having bad commits? I need to think about it. Just wanted to let you know that I see your point. []s, Thiago. On Wed, Jan 28, 2015 at 4:32 PM, Romain Manni-Bucau wrote: > 2015-01-28 22:29 GMT+01:00 Thiago Veronezi : > > But if you only have master, any quick fix would bring unnecessary > baggage, > > right? > > I mean, merging the fix changes from 2.x.x to master would be trivial > > because it would only contain changes for that particular fix. > > > > If the release tags are on master, for a quick fix, we would need to > create > > a new branch from the latest release tag, do the fix in the new branch > and > > release it again. Where would this new release tag live? Do we keep this > > new branch just to hold a minor code change for a bug fix? > > If that's a fix for a recent release we just create a branch for the > release, release, tag, delete the release branch - like we'd have do > it just after the release ignoring all commit in between. > > Otherwise you are back to current status = you merge all commit done > on 2.x on master which is: > 1) useless > 2) makes a lot of noise when done > 3) makes getting started not obvious (need doc) > > > > > > []s, > > Thiago > > > > > > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > >> well you shouldn't rebase/merge from a lower to upper branch IMO - ie > >> it is always fixed first on mainstream then backported if needed - or > >> just dev in the lower version if specific. > >> > >> That said this doesn't justify 2.x while master = 2.x > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi : > >> > Maybe it can be something like... > >> > > >> > Quick bug fix in 2.x.x: > >> > * You fix your issue in "2.x.x" > >> > * Call a vote for "2.x.x". > >> > * The vote passes. You merge "2.x.x" back to "master". > >> > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > >> > > >> > Normal 2.x.x release > >> > * You rebase "2.x.x" > >> > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" > >> > > >> > This way we avoid the auxiliary branches. We just need to be sure that > >> > "2.x.x" is not a development branch. It needs to be stable. So, once > we > >> > rebase it, we need to make it stable before merging it back to master. > >> > "2.x.x" is the branch that contains the release tags. > >> > > >> > []s, > >> > Thiago. > >> > > >> > > >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > > >> > wrote: > >> > > >> >> Hi, > >> >> This is what I was thinking... > >> >> > >> >> Quick bug fix in 2.x.x: > >> >> * You create a new auxiliary branch from 2.x.x. -> Let's call it > "2.0.2" > >> >> as example > >> >> * You fix your issue in this new "2.0.2" branch > >> >> * Call a vote for "2.0.2". > >> >> * The vote passes. You merge "2.0.2" back to "2.x.x". > >> >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" > >> >> * You destroy the auxiliary branch "2.0.2" > >> >> * You merge "2.x.x" back to master. > >> >> > >> >> Normal 2.x.x release > >> >> * You rebase "2.x.x" > >> >> * You follow the same steps as the ones for "quick bug fixes in > 2.x.x" > >> >> > >> >> []s, > >> >> Thiago. > >> >> > >> >> > >> >> > >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < > >> rmannibu...@gmail.com > >> >> > wrote: > >> >> > >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? > While > >> >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of > a > >> >>> release branch while mvn tools are not compliant with tomee setup. > >> >>> > >> >>> > >> >>> Romain Manni-Bucau > >> >>> @rmannibucau > >> >>> http://www.tomitribe.com > >> >>> http://rmannibucau.wordpress.com > >> >>> https://github.com/rmannibucau > >> >>> > >> >>> > >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : > >> >>> > Please note that having "2.x.x" covers all the requirements: > >> >>> > * master is the bleeding edge - it doesn't need to be stable > >> >>> > * no code-freeze necessary > >> >>> > * stable and ready for production "2.x.x" branch > >> >>> > * quick bug fix release possible without interrupting development > on > >> >>> master > >> >>> > > >> >>> > []s, > >> >>> > Thiago. > >> >>> > > >> >>> > On Wed, Jan 28, 2015 at 3:34 PM, Romain Manni-Bucau < > >> >>> rmannibu...@gmail.com> > >> >>> > wrote: > >> >>> > > >> >>> >> well while master = 2.x.x I wouldn't create it but yes (Tomcat > model > >> >>> >> basically is nice 1 maintaince branch by N-1 maintained version + > >> >>> >> trunk for last one). > >> >>> >> > >> >>> >> > >> >>> >> Romain Manni-Bucau > >> >>> >> @rmannibucau > >> >>> >> http://www.tomitribe.com > >> >>> >> http://rmannib
Re: what is which branch up for?
it is great when you really need to work on release and often squash commits, we dont do it @asf. + dont forget theory != practise and most of the time overhead to get a nice theory is useless (why we still use newton law even if we know they are wrong ;)) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-28 22:59 GMT+01:00 Thiago Veronezi : > Hmmm... I think I see how it works now. It starts to make more sense. :) > Something doesn't feel right though. Why Gitflow is so popular? How would > it protect the companies from having bad commits? I need to think about it. > Just wanted to let you know that I see your point. > > []s, > Thiago. > > > On Wed, Jan 28, 2015 at 4:32 PM, Romain Manni-Bucau > wrote: > >> 2015-01-28 22:29 GMT+01:00 Thiago Veronezi : >> > But if you only have master, any quick fix would bring unnecessary >> baggage, >> > right? >> > I mean, merging the fix changes from 2.x.x to master would be trivial >> > because it would only contain changes for that particular fix. >> > >> > If the release tags are on master, for a quick fix, we would need to >> create >> > a new branch from the latest release tag, do the fix in the new branch >> and >> > release it again. Where would this new release tag live? Do we keep this >> > new branch just to hold a minor code change for a bug fix? >> >> If that's a fix for a recent release we just create a branch for the >> release, release, tag, delete the release branch - like we'd have do >> it just after the release ignoring all commit in between. >> >> Otherwise you are back to current status = you merge all commit done >> on 2.x on master which is: >> 1) useless >> 2) makes a lot of noise when done >> 3) makes getting started not obvious (need doc) >> >> >> > >> > []s, >> > Thiago >> > >> > >> > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> >> well you shouldn't rebase/merge from a lower to upper branch IMO - ie >> >> it is always fixed first on mainstream then backported if needed - or >> >> just dev in the lower version if specific. >> >> >> >> That said this doesn't justify 2.x while master = 2.x >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi : >> >> > Maybe it can be something like... >> >> > >> >> > Quick bug fix in 2.x.x: >> >> > * You fix your issue in "2.x.x" >> >> > * Call a vote for "2.x.x". >> >> > * The vote passes. You merge "2.x.x" back to "master". >> >> > * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> >> > >> >> > Normal 2.x.x release >> >> > * You rebase "2.x.x" >> >> > * You follow the same steps as the ones for "quick bug fixes in 2.x.x" >> >> > >> >> > This way we avoid the auxiliary branches. We just need to be sure that >> >> > "2.x.x" is not a development branch. It needs to be stable. So, once >> we >> >> > rebase it, we need to make it stable before merging it back to master. >> >> > "2.x.x" is the branch that contains the release tags. >> >> > >> >> > []s, >> >> > Thiago. >> >> > >> >> > >> >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > > >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> This is what I was thinking... >> >> >> >> >> >> Quick bug fix in 2.x.x: >> >> >> * You create a new auxiliary branch from 2.x.x. -> Let's call it >> "2.0.2" >> >> >> as example >> >> >> * You fix your issue in this new "2.0.2" branch >> >> >> * Call a vote for "2.0.2". >> >> >> * The vote passes. You merge "2.0.2" back to "2.x.x". >> >> >> * You create a new tag in 2.x.x -> Let's call it "tag 2.0.2" >> >> >> * You destroy the auxiliary branch "2.0.2" >> >> >> * You merge "2.x.x" back to master. >> >> >> >> >> >> Normal 2.x.x release >> >> >> * You rebase "2.x.x" >> >> >> * You follow the same steps as the ones for "quick bug fixes in >> 2.x.x" >> >> >> >> >> >> []s, >> >> >> Thiago. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < >> >> rmannibu...@gmail.com >> >> >> > wrote: >> >> >> >> >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x or master? >> While >> >> >>> master = 2.x I'm not convinced we need it. Doesnt solve the need of >> a >> >> >>> release branch while mvn tools are not compliant with tomee setup. >> >> >>> >> >> >>> >> >> >>> Romain Manni-Bucau >> >> >>> @rmannibucau >> >> >>> http://www.tomitribe.com >> >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >> >>> >> >> >>> >> >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi : >> >> >>> > Please note that having "2.x.x" covers all the requirements: >> >> >>> > * master is the bleeding edge - it doesn't need to be stable >> >> >>> > * no code-freeze necessary >> >> >>> > * stable and ready for production "2.x.x" branch >> >> >>> > * quick bug fix release possible wit
Re: what is which branch up for?
> On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau 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. I’m sure that I’m being dense but how is this form of branch management not the apache way? Regards, Alan
Re: what is which branch up for?
Cause it implies history rewrite by design Le 29 janv. 2015 07:51, "Alan D. Cabrera" a écrit : > > > On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau > 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. > > I’m sure that I’m being dense but how is this form of branch management > not the apache way? > > > Regards, > Alan > >
Re: what is which branch up for?
I am dense. :) Can you provide an explicit example? > On Jan 28, 2015, at 11:09 PM, Romain Manni-Bucau > wrote: > > Cause it implies history rewrite by design > Le 29 janv. 2015 07:51, "Alan D. Cabrera" a écrit : > >> >>> On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau >> 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. >> >> I’m sure that I’m being dense but how is this form of branch management >> not the apache way? >> >> >> Regards, >> Alan >> >>
Re: what is which branch up for?
Well it basically forces you to move commits to master once you released and since that is git you can rewrite the history (caricatirally you ll just add 1 commit to master saying release-x). If you dont want to use it what is the point having another dev dead branch - ie master? Seeing last stable release? That is a tag. Seeing last stable state - ie you update it regularly? No way to have it without the release process - we failed at it for each releases and it would be worse than using current snapshots. Le 29 janv. 2015 08:13, "Alan D. Cabrera" a écrit : > I am dense. :) > > Can you provide an explicit example? > > > On Jan 28, 2015, at 11:09 PM, Romain Manni-Bucau > wrote: > > > > Cause it implies history rewrite by design > > Le 29 janv. 2015 07:51, "Alan D. Cabrera" a > écrit : > > > >> > >>> On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau > > >> 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. > >> > >> I’m sure that I’m being dense but how is this form of branch management > >> not the apache way? > >> > >> > >> Regards, > >> Alan > >> > >> > >
Re: what is which branch up for?
+1 We don't even need upfront maintenance branches for 1.7.1 vs 1.7.2 etc. IF we need to ship a 1.7.1.1 version, then we can easily create such a branch from the 1.7.1 tag at any time anyway. Of course if it takes us longer to stabilize a version then we can roll a maintenance-1.7.1 branch even before we cut the release. But I'd only do this if we don't get this managed in other ways. Usually it is enough to just shout to the list that a release will be cut soon and people should abstain from committing experimental stuff but only fix important bugs on that branch. LieGrue, strub > On Wednesday, 28 January 2015, 21:35, Romain Manni-Bucau > wrote: > > well while master = 2.x.x I wouldn't create it but yes (Tomcat model > basically is nice 1 maintaince branch by N-1 maintained version + > trunk for last one). > >
Re: what is which branch up for?
Again, gitflow IS nice if you have a bunch of juniors who don't know much what they do. And they keep trashing your project every single day... But for such projects I'd rather use Gerrit and enforce a tight review chain. If you have a mature team then you don't need all this stuff. If someone mails to the list that he is working towards 1.7.2 then I hope that everybody will simply not commit any experimental stuff to this branch. LieGrue, strub > On Wednesday, 28 January 2015, 23:00, Thiago Veronezi > wrote: > > Hmmm... I think I see how it works now. It starts to make more sense. :) > Something doesn't feel right though. Why Gitflow is so popular? How would > it protect the companies from having bad commits? I need to think about it. > Just wanted to let you know that I see your point. > > []s, > Thiago. > > > > On Wed, Jan 28, 2015 at 4:32 PM, Romain Manni-Bucau > > wrote: > >> 2015-01-28 22:29 GMT+01:00 Thiago Veronezi : >> > But if you only have master, any quick fix would bring unnecessary >> baggage, >> > right? >> > I mean, merging the fix changes from 2.x.x to master would be trivial >> > because it would only contain changes for that particular fix. >> > >> > If the release tags are on master, for a quick fix, we would need to >> create >> > a new branch from the latest release tag, do the fix in the new branch >> and >> > release it again. Where would this new release tag live? Do we keep > this >> > new branch just to hold a minor code change for a bug fix? >> >> If that's a fix for a recent release we just create a branch for the >> release, release, tag, delete the release branch - like we'd have do >> it just after the release ignoring all commit in between. >> >> Otherwise you are back to current status = you merge all commit done >> on 2.x on master which is: >> 1) useless >> 2) makes a lot of noise when done >> 3) makes getting started not obvious (need doc) >> >> >> > >> > []s, >> > Thiago >> > >> > >> > On Wed, Jan 28, 2015 at 4:17 PM, Romain Manni-Bucau < >> rmannibu...@gmail.com> >> > wrote: >> > >> >> well you shouldn't rebase/merge from a lower to upper branch > IMO - ie >> >> it is always fixed first on mainstream then backported if needed - > or >> >> just dev in the lower version if specific. >> >> >> >> That said this doesn't justify 2.x while master = 2.x >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-28 22:12 GMT+01:00 Thiago Veronezi > : >> >> > Maybe it can be something like... >> >> > >> >> > Quick bug fix in 2.x.x: >> >> > * You fix your issue in "2.x.x" >> >> > * Call a vote for "2.x.x". >> >> > * The vote passes. You merge "2.x.x" back to > "master". >> >> > * You create a new tag in 2.x.x -> Let's call it > "tag 2.0.2" >> >> > >> >> > Normal 2.x.x release >> >> > * You rebase "2.x.x" >> >> > * You follow the same steps as the ones for "quick bug > fixes in 2.x.x" >> >> > >> >> > This way we avoid the auxiliary branches. We just need to be > sure that >> >> > "2.x.x" is not a development branch. It needs to be > stable. So, once >> we >> >> > rebase it, we need to make it stable before merging it back > to master. >> >> > "2.x.x" is the branch that contains the release > tags. >> >> > >> >> > []s, >> >> > Thiago. >> >> > >> >> > >> >> > On Wed, Jan 28, 2015 at 4:07 PM, Thiago Veronezi > > > >> >> > wrote: >> >> > >> >> >> Hi, >> >> >> This is what I was thinking... >> >> >> >> >> >> Quick bug fix in 2.x.x: >> >> >> * You create a new auxiliary branch from 2.x.x. -> > Let's call it >> "2.0.2" >> >> >> as example >> >> >> * You fix your issue in this new "2.0.2" branch >> >> >> * Call a vote for "2.0.2". >> >> >> * The vote passes. You merge "2.0.2" back to > "2.x.x". >> >> >> * You create a new tag in 2.x.x -> Let's call it > "tag 2.0.2" >> >> >> * You destroy the auxiliary branch "2.0.2" >> >> >> * You merge "2.x.x" back to master. >> >> >> >> >> >> Normal 2.x.x release >> >> >> * You rebase "2.x.x" >> >> >> * You follow the same steps as the ones for "quick > bug fixes in >> 2.x.x" >> >> >> >> >> >> []s, >> >> >> Thiago. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Jan 28, 2015 at 3:54 PM, Romain Manni-Bucau < >> >> rmannibu...@gmail.com >> >> >> > wrote: >> >> >> >> >> >>> If I have a fix to do in 2.x, where do I code? 2.x.x > or master? >> While >> >> >>> master = 2.x I'm not convinced we need it. Doesnt > solve the need of >> a >> >> >>> release branch while mvn tools are not compliant with > tomee setup. >> >> >>> >> >> >>> >> >> >>> Romain Manni-Bucau >> >> >>> @rmannibucau >> >> >>> http://www.tomitribe.com >> >> >>> http://rmannibucau.wordpress.com >> >> >>> https://github.com/rmannibucau >> >> >>> >> >> >>> >> >> >>> 2015-01-28 21:52 GMT+01:00 Thiago Veronezi > : >>
Re: what is which branch up for?
Alan, the gitflow way is basically review then commit. Because the 'Release Manager' (of whom we lack...) needs to review and choose (cherry-pick) EACH AND EVERY SINGLE COMMIT. And even worse - by deleting the 'temp' branch afterwards we also loose all the other work later. And once again: We must not delete anything from our repos! We must not squash commits! We must not loose any history! We must guarantee a verifyable code provenance! Those are no 'should' those are MUST! LieGrue, strub > On Thursday, 29 January 2015, 7:51, Alan D. Cabrera > wrote: > > >> On Jan 28, 2015, at 1:59 AM, Romain Manni-Bucau > 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. > > I’m sure that I’m being dense but how is this form of branch management not > the > apache way? > > > Regards, > Alan >
