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