You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2014/10/17 13:04:04 UTC
git workflow?
Hi guys,
just browsed the git workflow Andy wrote
(http://tomee.staging.apache.org/dev/source-code.html) and I have a
few question:
1) (more a surprise than anything else) we don't discuss it?
2) I find it overcomplicated - this develop branch thing. Today we are
not big enough to need it IMHO and we are agile enough to change when
we'll need this. It is great if we would like to rewrite the history
but we are open source and I think it is important to not do it.
3) if we really use it it means release preparation will take one
extra day - to not say a week - to merge properly from develop to
master but I don't see the gain
4) ds doesn't use it and project goes well so what do we expect? ->
https://deltaspike.apache.org/suggested-git-workflows.html
any inputs?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
Re: git workflow?
Posted by Daniel Kasmeroglu <da...@kasisoft.net>.
Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau:
> Hi guys,
>
> just browsed the git workflow Andy wrote
> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
> few question:
> 1) (more a surprise than anything else) we don't discuss it?
> 2) I find it overcomplicated - this develop branch thing. Today we are
> not big enough to need it IMHO and we are agile enough to change when
> we'll need this. It is great if we would like to rewrite the history
> but we are open source and I think it is important to not do it.
> 3) if we really use it it means release preparation will take one
> extra day - to not say a week - to merge properly from develop to
> master but I don't see the gain
> 4) ds doesn't use it and project goes well so what do we expect? ->
> https://deltaspike.apache.org/suggested-git-workflows.html
>
> any inputs?
>
I cannot access this as I don't have the necessary permissions (at least
my apache account is not working here).
Best regards
Daniel Kasmeroglu
Re: git workflow?
Posted by "John D. Ament" <jo...@gmail.com>.
I personally like the idea of using gitflow, makes the project look more
stable and quality focused. Allows you to stay in a shape of ready to
tackle major issues immediately. Plus it makes contributions easier to
manage.
On Fri, Oct 17, 2014 at 7:25 AM, Andy Gumbrecht <ag...@tomitribe.com>
wrote:
> +1
>
> The issue here really is that this discussion was due once the staging
> site was in place, not before it. Never mind, we'll just have to see how it
> works out.
>
> On 17/10/2014 13:16, Christofer Dutz wrote:
>
>> Just my 50ct to this topic:
>>
>> At the Apache Flex project we too introduced GitFlow (even if we never
>> explicitly called it that way)
>> Working on Develop and having Master in the state of the last release is
>> a very good thing to have (in my opinion). this way someone can always
>> start with a working build as Develop usually tends to be buggy now and
>> then.
>>
>> I don’t quite understand why you claim that a merge from develop to
>> master after a release adds another day to the process … no commit should
>> to to master and therefore there shouldn’t be any conflicts. So a merge
>> should be a on-command thing in Git.
>>
>> Also one thing with the feature branches. In flex some people tend to
>> start working on something together. So they start a feature-branch and
>> work on that … as soon as that’s finished they might decide to give it up
>> or to merge the stuff back to develop. This way their experiments don’t
>> interfere with any other people.
>>
>> I think it’s a good thing.
>>
>> Chris
>>
>> --
>>
>> Mit freundlichen Grüßen | Best regards
>>
>> Christofer Dutz | Senior IT Consultant
>>
>> codecentric AG | An der Welle 4 | 60322 Frankfurt am Main | Deutschland
>> mobil: +49 (0) 1525.3057806 | fax: +49 (0) 69.7593-8200
>> www.codecentric.de <http://www.codecentric.de/> | blog.codecentric.de <
>> http://blog.codecentric.de/> | www.meettheexperts.de <
>> http://www.meettheexperts.de/> | www.more4fi.de <http://www.more4fi.de/>
>>
>>
>> Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
>> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
>> Schütz
>>
>> Diese E-Mail einschließlich evtl. beigefügter Dateien enthält
>> vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht
>> der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
>> informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail und
>> evtl. beigefügter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder
>> Öffnen evtl. beigefügter Dateien sowie die unbefugte Weitergabe dieser
>> E-Mail ist nicht gestattet.
>>
>> Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>> <ma...@gmail.com>>:
>>
>> Hi guys,
>>>
>>> just browsed the git workflow Andy wrote
>>> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
>>> few question:
>>> 1) (more a surprise than anything else) we don't discuss it?
>>> 2) I find it overcomplicated - this develop branch thing. Today we are
>>> not big enough to need it IMHO and we are agile enough to change when
>>> we'll need this. It is great if we would like to rewrite the history
>>> but we are open source and I think it is important to not do it.
>>> 3) if we really use it it means release preparation will take one
>>> extra day - to not say a week - to merge properly from develop to
>>> master but I don't see the gain
>>> 4) ds doesn't use it and project goes well so what do we expect? ->
>>> https://deltaspike.apache.org/suggested-git-workflows.html
>>>
>>> any inputs?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>
>>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
>
Re: git workflow?
Posted by Mark Struberg <st...@yahoo.de>.
> PS. Something that really got me the other day is the inability to just
> export a single directory (eg. examples) from the remote git repo
git does NOT support sparse checkout. Simply because git is repo oriented vs SVN is file oriented.
I've summed up quite a few aspects in a very old post when we introduced GIT at the ASF [1][2].
> I really like the 'Feature Branch Workflow', but if we cannot
> use it due to Apache restrictions that would be huge minus for me
That has nothing to do with ASF restrictions.
Just look at Linux. It has no cannonical repo as we do technical. But it still has one socially at the end. And to this repo only Linus can push. Not 30 people, not 5, just Linus. And thus he can also easily remove 'dead' branches and do other cleanup tasks. But really consider one thing: you cannot 'delete' branches from a downstream clone. E.g. if we have a feature branch blaBlub at our cannonical repo then it will get pulled over to github.com/apache/tomee. And even if you delete this blaBlub branch @ASF it will NOT get removed from our github mirror nor anywhere else!
The workflow as described by Atlassian really works great for companies. But it totalls sucks for OSS projects (in general, that's not even ASF related).
In addition we (ASF) decided to prevent history rewrite. This has multiple reasons. One is e.g. that we must have a strong code provenance to guard ourselves legally against copyright infringement claims. Thus we decided to technically make sure that history rewrite is forbidden.
> Another topic but wondered since years why we don't hack
> maven release plugin to support it?
We have added support for GIT in maven-release-plugin a long time ago.
We should make sure to have the following config settings set though:
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
> AFAIK we should create submodules for such things - didnt use it
> "for real" so no idea it is good or bad in practise.
Last time I checked they totally sucked.
It's e.g not possible to do a maven release over multiple submodules
You should really take a look how we do it over at DeltaSpike [3]. It works pretty fine imo.
LieGrue,
strub
[1] http://wiki.apache.org/couchdb/Git_At_Apache_Guide
[2] http://wiki.apache.org/couchdb/SVNvsGIT
[3] https://deltaspike.apache.org/suggested-git-workflows.html
Re: git workflow?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-10-27 13:03 GMT+01:00 Mark Struberg <st...@yahoo.de>:
> In all the scenarios I know this works by NOT working on the upstream repo at all.
> Instead this commit gets performed on some other repo and a pull request is issued. The pull request triggers a merge in a auto-generated temporary throw-away branch (integration branch) and if it passes it can get pulled in by some maintainer.
>
> This is fine, but fundamentally different to what we do/have at ASF in general.
>
> The problem with the tests is something different. WAY too many tests are just broken in lots of situations. E.g. they are depending on the order in which they get executed (which might be different depending on OS and JDK version), do not work if you have a proxy configured, don't work if you have a firewall, etc
>
Something for another thread I guess. Personally I think integration
profiles are useless and actually we don't have a single "envrt
dependent" test which can 't pass by default so just a matter of time.
> We really must fix the random ones and move all those infrastructure specific tests to an integration-test profile.
> After this is done a lot less people will have problems to build TomEE themselves.
>
>
> LieGrue,
> strub
>
>
>
>
>> On Monday, 27 October 2014, 11:40, Marius Kruger <am...@gmail.com> wrote:
>> > Hi,
>> one way I think working on the develop branch could be very useful is if we
>> can have a bot that runs the test-suite after every commit and only pushes
>> commits to master if all the tests pass, and notify the committer if it
>> doesn't.
>> This would also alleviate developer/casual contributor frustrations in
>> getting a 'clean' tree to start working on (like what Daniel is
>> experiencing).
>>
>> --
>> my2c
>> ✝ Marius
>>
Re: git workflow?
Posted by Mark Struberg <st...@yahoo.de>.
In all the scenarios I know this works by NOT working on the upstream repo at all.
Instead this commit gets performed on some other repo and a pull request is issued. The pull request triggers a merge in a auto-generated temporary throw-away branch (integration branch) and if it passes it can get pulled in by some maintainer.
This is fine, but fundamentally different to what we do/have at ASF in general.
The problem with the tests is something different. WAY too many tests are just broken in lots of situations. E.g. they are depending on the order in which they get executed (which might be different depending on OS and JDK version), do not work if you have a proxy configured, don't work if you have a firewall, etc
We really must fix the random ones and move all those infrastructure specific tests to an integration-test profile.
After this is done a lot less people will have problems to build TomEE themselves.
LieGrue,
strub
> On Monday, 27 October 2014, 11:40, Marius Kruger <am...@gmail.com> wrote:
> > Hi,
> one way I think working on the develop branch could be very useful is if we
> can have a bot that runs the test-suite after every commit and only pushes
> commits to master if all the tests pass, and notify the committer if it
> doesn't.
> This would also alleviate developer/casual contributor frustrations in
> getting a 'clean' tree to start working on (like what Daniel is
> experiencing).
>
> --
> my2c
> ✝ Marius
>
Re: git workflow?
Posted by Marius Kruger <am...@gmail.com>.
Hi,
one way I think working on the develop branch could be very useful is if we
can have a bot that runs the test-suite after every commit and only pushes
commits to master if all the tests pass, and notify the committer if it
doesn't.
This would also alleviate developer/casual contributor frustrations in
getting a 'clean' tree to start working on (like what Daniel is
experiencing).
--
my2c
✝ Marius
Re: git workflow?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-10-27 10:47 GMT+01:00 Andy Gumbrecht <ag...@tomitribe.com>:
> So we really need to come up with something that works for everyone, but at
> least one of these well defined flows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> The idea is to use a well established workflow that has at least some
> background and stick to it. It's easy to say I've used this and that and it
> works for me. That seems to be a more of a git 'problem' that allows
> everyone to come up with their own flow. Kind of a step away from a standard
> API, but this seems to be why git is winning the scm war. It's not about
> personal taste, it is about what do we enforce upon the future devs that
> join the project (and ourselves) that will leave them (and us) in good
> standing for the rest of the world.
>
> So let's work together to come up with a choice.
>
> I really like the 'Feature Branch Workflow', but if we cannot use it due to
> Apache restrictions that would be huge minus for me and make me wonder why
> SVN was dropped in the first place. Gitflow 'just' adds a develop branch as
> the trunk, and that makes sense to me (master just being used like the svn
> 'tags' branch). But it does seem to upset at least a few people (must just
> be an Atlassian mistake, and let's not go anywhere near 'Forking Worklow'
> ...yes I said 'Forking' :-D ).
>
There is no restriction but we didn't extract any advantage of using
it until now.
Another thing is for a newcomer (maybe even not used to git) it would
be easier to hack on master by default IMO.
> The release manager actually faces this maintenance challenge every time a
> release is performed in svn or git, as the project was/is not compatible
> with any standard/automated Maven release process or plugins (due to the
> lack of separation of the OpenEJB and TomEE projects).
>
Another topic but wondered since years why we don't hack maven release
plugin to support it? Should be pretty easy.
> Andy.
>
> PS. Something that really got me the other day is the inability to just
> export a single directory (eg. examples) from the remote git repo (in a one
> liner cmd). How did that get missed in the dev process, or does anyone have
> a magic solution to that?
>
AFAIK we should create submodules for such things - didnt use it "for
real" so no idea it is good or bad in practise.
>
> On 27/10/2014 09:12, Jean-Louis Monteiro wrote:
>>
>> Unfortunately, not enough GIT background to help much in this discussion.
>> I can only say that I used (copied) the Deltaspike workflow in the past
>> and
>> it was enough for our needs.
>>
>> Jean-Louis
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>> On Sun, Oct 26, 2014 at 10:11 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> Folks, that gitflow is totally nuts imo!
>>>
>>> First, this is a project with only senior devs, this would be the first
>>> ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is
>>> usually only done for maintenance- and/or relaese-branches. Everything
>>> else
>>> is CTR. The develop branch is just a useless buffer without a
>>> build/release
>>> manager who does the review and merging. It will be a hell to maintain.
>>>
>>>
>>>
>>> Second: Creating tons of temporary branches is NOT a good idea for an
>>> upstream cannonical repo.
>>>
>>>
>>>> git push -u origin TOMEE-007
>>>
>>> Such things are perfectly fine on private repos or for sending pull
>>> requests, but not on the central ASF repo. Why? Simple because you cannot
>>> delete those branches later (ASF repos are usually configured to prevent
>>> history rewrite). And also opposite to SVN you cannot get back a branch
>>> someone deleted or a history someone rewrote. Once a GIT repo is trashed,
>>> then you can only do a restore of the whole repo from some file backup.
>>>
>>>
>>>> git pull origin develop
>>>
>>> Third: You should explain the difference between pull and fetch resp git
>>> pull --rebase
>>>
>>> Otherwise our history will either be broken (history rewrite) or full
>>> with
>>> useless merge-commits.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> PS: I am using GIT since 2006 and I e.g. wrote the
>>> maven-scm-providers-git
>>> stuff back then. GIT IS cool, but also a strong weapon to shoot yourself
>>> in
>>> the knee if you don't be careful.
>>>
>>>
>>>
>>>> On Friday, 17 October 2014, 17:35, Romain Manni-Bucau <
>>>
>>> rmannibucau@gmail.com> wrote:
>>>>>
>>>>> yes, so master is just a single branch showing only tags, what's the
>>>>
>>>> need behind?
>>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau
>>>> http://www.tomitribe.com
>>>> http://rmannibucau.wordpress.com
>>>> https://github.com/rmannibucau
>>>>
>>>>
>>>> 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>>>
>>>>> Release branches act as a buffer between feature development
>>>>> (develop)
>>>
>>> and
>>>>>
>>>>> public releases (master).
>>>>> Whenever you merge something into master, you should tag the commit
>>>>> for
>>>>> reference
>>>>>
>>>>> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
>>>>> git push --tags
>>>>>
>>>>>
>>>>> On 17/10/2014 16:46, Romain Manni-Bucau wrote:
>>>>>>
>>>>>> sorry I'm surely slow today but it if can avoid me 1h ;): so
>>>>
>>>> what's
>>>>>>
>>>>>> different with tags? ie when do you go to master without having a
>>>>>> release?
>>>>>>
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau
>>>>>> http://www.tomitribe.com
>>>>>> http://rmannibucau.wordpress.com
>>>>>> https://github.com/rmannibucau
>>>>>>
>>>>>>
>>>>>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht
>>>>
>>>> <ag...@tomitribe.com>:
>>>>>>>
>>>>>>> Not quite, the /release /branch takes place 'whenever' -
>>>>
>>>> This means it
>>>>>>>
>>>>>>> would
>>>>>>> be 'nice' to create it from a stable /develop/, but is NOT
>>>>
>>>> required (this
>>>>>>>
>>>>>>> is
>>>>>>> the big +1 for me).
>>>>>>>
>>>>>>> The /release /branch is where the release is polished and prepared
>>>>
>>>> and
>>>>>>>
>>>>>>> all
>>>>>>> the tests must 'eventually' pass - work can continue in
>>>>
>>>> /develop/
>>>>>>>
>>>>>>> (another
>>>>>>> big +1) - everyone can help make the /release /stable.
>>>>>>>
>>>>>>> When the /release /branch is ready then it is merged to /master
>>>>
>>>> /*and
>>>>>>>
>>>>>>> */develop /(if there were changes in the /release /then they also
>>>>
>>>> need to
>>>>>>>
>>>>>>> get merged back to /develop/)
>>>>>>>
>>>>>>> The /master /branch only ever contains stable production ready
>>>>
>>>> code.
>>>>>>>
>>>>>>> Andy.
>>>>>>>
>>>>>>>
>>>>>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>>>>>>>
>>>>>>>> Regarding the creation of a release branch I assume that
>>>>
>>>> creating the
>>>>>>>>
>>>>>>>> branch from 'develop' implies that all available tests
>>>>
>>>> and quality
>>>>>>>>
>>>>>>>> criteries must be matched before the actual branching takes
>>>>
>>>> place.
>>>>>>>>
>>>>>>>> Am I right on this ?
>>>>>>>>
>>>>>>>> Best regards
>>>>>>>>
>>>>>>>> Daniel Kasmeroglu
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Andy Gumbrecht
>>>>>>> https://twitter.com/AndyGeeDe
>>>>>>> http://www.tomitribe.com
>>>>>>>
>>>>> --
>>>>> Andy Gumbrecht
>>>>> https://twitter.com/AndyGeeDe
>>>>> http://www.tomitribe.com
>>>>>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: git workflow?
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
So we really need to come up with something that works for everyone, but
at least one of these well defined flows:
https://www.atlassian.com/git/tutorials/comparing-workflows
The idea is to use a well established workflow that has at least some
background and stick to it. It's easy to say I've used this and that and
it works for me. That seems to be a more of a git 'problem' that allows
everyone to come up with their own flow. Kind of a step away from a
standard API, but this seems to be why git is winning the scm war. It's
not about personal taste, it is about what do we enforce upon the future
devs that join the project (and ourselves) that will leave them (and us)
in good standing for the rest of the world.
So let's work together to come up with a choice.
I really like the 'Feature Branch Workflow', but if we cannot use it due
to Apache restrictions that would be huge minus for me and make me
wonder why SVN was dropped in the first place. Gitflow 'just' adds a
develop branch as the trunk, and that makes sense to me (master just
being used like the svn 'tags' branch). But it does seem to upset at
least a few people (must just be an Atlassian mistake, and let's not go
anywhere near 'Forking Worklow' ...yes I said 'Forking' :-D ).
The release manager actually faces this maintenance challenge every time
a release is performed in svn or git, as the project was/is not
compatible with any standard/automated Maven release process or plugins
(due to the lack of separation of the OpenEJB and TomEE projects).
Andy.
PS. Something that really got me the other day is the inability to just
export a single directory (eg. examples) from the remote git repo (in a
one liner cmd). How did that get missed in the dev process, or does
anyone have a magic solution to that?
On 27/10/2014 09:12, Jean-Louis Monteiro wrote:
> Unfortunately, not enough GIT background to help much in this discussion.
> I can only say that I used (copied) the Deltaspike workflow in the past and
> it was enough for our needs.
>
> Jean-Louis
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> On Sun, Oct 26, 2014 at 10:11 PM, Mark Struberg <st...@yahoo.de> wrote:
>
>> Folks, that gitflow is totally nuts imo!
>>
>> First, this is a project with only senior devs, this would be the first
>> ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is
>> usually only done for maintenance- and/or relaese-branches. Everything else
>> is CTR. The develop branch is just a useless buffer without a build/release
>> manager who does the review and merging. It will be a hell to maintain.
>>
>>
>>
>> Second: Creating tons of temporary branches is NOT a good idea for an
>> upstream cannonical repo.
>>
>>
>>> git push -u origin TOMEE-007
>> Such things are perfectly fine on private repos or for sending pull
>> requests, but not on the central ASF repo. Why? Simple because you cannot
>> delete those branches later (ASF repos are usually configured to prevent
>> history rewrite). And also opposite to SVN you cannot get back a branch
>> someone deleted or a history someone rewrote. Once a GIT repo is trashed,
>> then you can only do a restore of the whole repo from some file backup.
>>
>>
>>> git pull origin develop
>> Third: You should explain the difference between pull and fetch resp git
>> pull --rebase
>>
>> Otherwise our history will either be broken (history rewrite) or full with
>> useless merge-commits.
>>
>>
>> LieGrue,
>> strub
>>
>>
>> PS: I am using GIT since 2006 and I e.g. wrote the maven-scm-providers-git
>> stuff back then. GIT IS cool, but also a strong weapon to shoot yourself in
>> the knee if you don't be careful.
>>
>>
>>
>>> On Friday, 17 October 2014, 17:35, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>>> yes, so master is just a single branch showing only tags, what's the
>>> need behind?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>> Release branches act as a buffer between feature development (develop)
>> and
>>>> public releases (master).
>>>> Whenever you merge something into master, you should tag the commit for
>>>> reference
>>>>
>>>> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
>>>> git push --tags
>>>>
>>>>
>>>> On 17/10/2014 16:46, Romain Manni-Bucau wrote:
>>>>> sorry I'm surely slow today but it if can avoid me 1h ;): so
>>> what's
>>>>> different with tags? ie when do you go to master without having a
>>>>> release?
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>> http://www.tomitribe.com
>>>>> http://rmannibucau.wordpress.com
>>>>> https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht
>>> <ag...@tomitribe.com>:
>>>>>> Not quite, the /release /branch takes place 'whenever' -
>>> This means it
>>>>>> would
>>>>>> be 'nice' to create it from a stable /develop/, but is NOT
>>> required (this
>>>>>> is
>>>>>> the big +1 for me).
>>>>>>
>>>>>> The /release /branch is where the release is polished and prepared
>>> and
>>>>>> all
>>>>>> the tests must 'eventually' pass - work can continue in
>>> /develop/
>>>>>> (another
>>>>>> big +1) - everyone can help make the /release /stable.
>>>>>>
>>>>>> When the /release /branch is ready then it is merged to /master
>>> /*and
>>>>>> */develop /(if there were changes in the /release /then they also
>>> need to
>>>>>> get merged back to /develop/)
>>>>>>
>>>>>> The /master /branch only ever contains stable production ready
>>> code.
>>>>>> Andy.
>>>>>>
>>>>>>
>>>>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>>>>>> Regarding the creation of a release branch I assume that
>>> creating the
>>>>>>> branch from 'develop' implies that all available tests
>>> and quality
>>>>>>> criteries must be matched before the actual branching takes
>>> place.
>>>>>>> Am I right on this ?
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Daniel Kasmeroglu
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Andy Gumbrecht
>>>>>> https://twitter.com/AndyGeeDe
>>>>>> http://www.tomitribe.com
>>>>>>
>>>> --
>>>> Andy Gumbrecht
>>>> https://twitter.com/AndyGeeDe
>>>> http://www.tomitribe.com
>>>>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: git workflow?
Posted by Jean-Louis Monteiro <jl...@tomitribe.com>.
Unfortunately, not enough GIT background to help much in this discussion.
I can only say that I used (copied) the Deltaspike workflow in the past and
it was enough for our needs.
Jean-Louis
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Sun, Oct 26, 2014 at 10:11 PM, Mark Struberg <st...@yahoo.de> wrote:
> Folks, that gitflow is totally nuts imo!
>
> First, this is a project with only senior devs, this would be the first
> ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is
> usually only done for maintenance- and/or relaese-branches. Everything else
> is CTR. The develop branch is just a useless buffer without a build/release
> manager who does the review and merging. It will be a hell to maintain.
>
>
>
> Second: Creating tons of temporary branches is NOT a good idea for an
> upstream cannonical repo.
>
>
> > git push -u origin TOMEE-007
>
> Such things are perfectly fine on private repos or for sending pull
> requests, but not on the central ASF repo. Why? Simple because you cannot
> delete those branches later (ASF repos are usually configured to prevent
> history rewrite). And also opposite to SVN you cannot get back a branch
> someone deleted or a history someone rewrote. Once a GIT repo is trashed,
> then you can only do a restore of the whole repo from some file backup.
>
>
> > git pull origin develop
>
> Third: You should explain the difference between pull and fetch resp git
> pull --rebase
>
> Otherwise our history will either be broken (history rewrite) or full with
> useless merge-commits.
>
>
> LieGrue,
> strub
>
>
> PS: I am using GIT since 2006 and I e.g. wrote the maven-scm-providers-git
> stuff back then. GIT IS cool, but also a strong weapon to shoot yourself in
> the knee if you don't be careful.
>
>
>
> > On Friday, 17 October 2014, 17:35, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
> > > yes, so master is just a single branch showing only tags, what's the
> > need behind?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau
> > http://www.tomitribe.com
> > http://rmannibucau.wordpress.com
> > https://github.com/rmannibucau
> >
> >
> > 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> >> Release branches act as a buffer between feature development (develop)
> and
> >> public releases (master).
> >> Whenever you merge something into master, you should tag the commit for
> >> reference
> >>
> >> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
> >> git push --tags
> >>
> >>
> >> On 17/10/2014 16:46, Romain Manni-Bucau wrote:
> >>>
> >>> sorry I'm surely slow today but it if can avoid me 1h ;): so
> > what's
> >>> different with tags? ie when do you go to master without having a
> >>> release?
> >>>
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau
> >>> http://www.tomitribe.com
> >>> http://rmannibucau.wordpress.com
> >>> https://github.com/rmannibucau
> >>>
> >>>
> >>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht
> > <ag...@tomitribe.com>:
> >>>>
> >>>> Not quite, the /release /branch takes place 'whenever' -
> > This means it
> >>>> would
> >>>> be 'nice' to create it from a stable /develop/, but is NOT
> > required (this
> >>>> is
> >>>> the big +1 for me).
> >>>>
> >>>> The /release /branch is where the release is polished and prepared
> > and
> >>>> all
> >>>> the tests must 'eventually' pass - work can continue in
> > /develop/
> >>>> (another
> >>>> big +1) - everyone can help make the /release /stable.
> >>>>
> >>>> When the /release /branch is ready then it is merged to /master
> > /*and
> >>>> */develop /(if there were changes in the /release /then they also
> > need to
> >>>> get merged back to /develop/)
> >>>>
> >>>> The /master /branch only ever contains stable production ready
> > code.
> >>>>
> >>>> Andy.
> >>>>
> >>>>
> >>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
> >>>>>
> >>>>> Regarding the creation of a release branch I assume that
> > creating the
> >>>>> branch from 'develop' implies that all available tests
> > and quality
> >>>>> criteries must be matched before the actual branching takes
> > place.
> >>>>> Am I right on this ?
> >>>>>
> >>>>> Best regards
> >>>>>
> >>>>> Daniel Kasmeroglu
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Andy Gumbrecht
> >>>> https://twitter.com/AndyGeeDe
> >>>> http://www.tomitribe.com
> >>>>
> >>>
> >>
> >> --
> >> Andy Gumbrecht
> >> https://twitter.com/AndyGeeDe
> >> http://www.tomitribe.com
> >>
> >
>
Re: git workflow?
Posted by Mark Struberg <st...@yahoo.de>.
Folks, that gitflow is totally nuts imo!
First, this is a project with only senior devs, this would be the first ASF project which has Review-Then-Commmit (RTC) on trunk/master. RTC is usually only done for maintenance- and/or relaese-branches. Everything else is CTR. The develop branch is just a useless buffer without a build/release manager who does the review and merging. It will be a hell to maintain.
Second: Creating tons of temporary branches is NOT a good idea for an upstream cannonical repo.
> git push -u origin TOMEE-007
Such things are perfectly fine on private repos or for sending pull requests, but not on the central ASF repo. Why? Simple because you cannot delete those branches later (ASF repos are usually configured to prevent history rewrite). And also opposite to SVN you cannot get back a branch someone deleted or a history someone rewrote. Once a GIT repo is trashed, then you can only do a restore of the whole repo from some file backup.
> git pull origin develop
Third: You should explain the difference between pull and fetch resp git pull --rebase
Otherwise our history will either be broken (history rewrite) or full with useless merge-commits.
LieGrue,
strub
PS: I am using GIT since 2006 and I e.g. wrote the maven-scm-providers-git stuff back then. GIT IS cool, but also a strong weapon to shoot yourself in the knee if you don't be careful.
> On Friday, 17 October 2014, 17:35, Romain Manni-Bucau <rm...@gmail.com> wrote:
> > yes, so master is just a single branch showing only tags, what's the
> need behind?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>> Release branches act as a buffer between feature development (develop) and
>> public releases (master).
>> Whenever you merge something into master, you should tag the commit for
>> reference
>>
>> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
>> git push --tags
>>
>>
>> On 17/10/2014 16:46, Romain Manni-Bucau wrote:
>>>
>>> sorry I'm surely slow today but it if can avoid me 1h ;): so
> what's
>>> different with tags? ie when do you go to master without having a
>>> release?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht
> <ag...@tomitribe.com>:
>>>>
>>>> Not quite, the /release /branch takes place 'whenever' -
> This means it
>>>> would
>>>> be 'nice' to create it from a stable /develop/, but is NOT
> required (this
>>>> is
>>>> the big +1 for me).
>>>>
>>>> The /release /branch is where the release is polished and prepared
> and
>>>> all
>>>> the tests must 'eventually' pass - work can continue in
> /develop/
>>>> (another
>>>> big +1) - everyone can help make the /release /stable.
>>>>
>>>> When the /release /branch is ready then it is merged to /master
> /*and
>>>> */develop /(if there were changes in the /release /then they also
> need to
>>>> get merged back to /develop/)
>>>>
>>>> The /master /branch only ever contains stable production ready
> code.
>>>>
>>>> Andy.
>>>>
>>>>
>>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>>>>
>>>>> Regarding the creation of a release branch I assume that
> creating the
>>>>> branch from 'develop' implies that all available tests
> and quality
>>>>> criteries must be matched before the actual branching takes
> place.
>>>>> Am I right on this ?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Daniel Kasmeroglu
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Andy Gumbrecht
>>>> https://twitter.com/AndyGeeDe
>>>> http://www.tomitribe.com
>>>>
>>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>>
>
Re: git workflow?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes, so master is just a single branch showing only tags, what's the
need behind?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-17 17:30 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> Release branches act as a buffer between feature development (develop) and
> public releases (master).
> Whenever you merge something into master, you should tag the commit for
> reference
>
> git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
> git push --tags
>
>
> On 17/10/2014 16:46, Romain Manni-Bucau wrote:
>>
>> sorry I'm surely slow today but it if can avoid me 1h ;): so what's
>> different with tags? ie when do you go to master without having a
>> release?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>>>
>>> Not quite, the /release /branch takes place 'whenever' - This means it
>>> would
>>> be 'nice' to create it from a stable /develop/, but is NOT required (this
>>> is
>>> the big +1 for me).
>>>
>>> The /release /branch is where the release is polished and prepared and
>>> all
>>> the tests must 'eventually' pass - work can continue in /develop/
>>> (another
>>> big +1) - everyone can help make the /release /stable.
>>>
>>> When the /release /branch is ready then it is merged to /master /*and
>>> */develop /(if there were changes in the /release /then they also need to
>>> get merged back to /develop/)
>>>
>>> The /master /branch only ever contains stable production ready code.
>>>
>>> Andy.
>>>
>>>
>>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>>>
>>>> Regarding the creation of a release branch I assume that creating the
>>>> branch from 'develop' implies that all available tests and quality
>>>> criteries must be matched before the actual branching takes place.
>>>> Am I right on this ?
>>>>
>>>> Best regards
>>>>
>>>> Daniel Kasmeroglu
>>>>
>>>>
>>>>
>>>
>>> --
>>> Andy Gumbrecht
>>> https://twitter.com/AndyGeeDe
>>> http://www.tomitribe.com
>>>
>>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: git workflow?
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Release branches act as a buffer between feature development (develop)
and public releases (master).
Whenever you merge something into master, you should tag the commit for
reference
git tag -a tomee-1.7.2 -m "TomEE 1.7.2 Release" master
git push --tags
On 17/10/2014 16:46, Romain Manni-Bucau wrote:
> sorry I'm surely slow today but it if can avoid me 1h ;): so what's
> different with tags? ie when do you go to master without having a
> release?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-10-17 16:41 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
>> Not quite, the /release /branch takes place 'whenever' - This means it would
>> be 'nice' to create it from a stable /develop/, but is NOT required (this is
>> the big +1 for me).
>>
>> The /release /branch is where the release is polished and prepared and all
>> the tests must 'eventually' pass - work can continue in /develop/ (another
>> big +1) - everyone can help make the /release /stable.
>>
>> When the /release /branch is ready then it is merged to /master /*and
>> */develop /(if there were changes in the /release /then they also need to
>> get merged back to /develop/)
>>
>> The /master /branch only ever contains stable production ready code.
>>
>> Andy.
>>
>>
>> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>> Regarding the creation of a release branch I assume that creating the
>>> branch from 'develop' implies that all available tests and quality
>>> criteries must be matched before the actual branching takes place.
>>> Am I right on this ?
>>>
>>> Best regards
>>>
>>> Daniel Kasmeroglu
>>>
>>>
>>>
>>
>> --
>> Andy Gumbrecht
>> https://twitter.com/AndyGeeDe
>> http://www.tomitribe.com
>>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: git workflow?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
sorry I'm surely slow today but it if can avoid me 1h ;): so what's
different with tags? ie when do you go to master without having a
release?
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-17 16:41 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> Not quite, the /release /branch takes place 'whenever' - This means it would
> be 'nice' to create it from a stable /develop/, but is NOT required (this is
> the big +1 for me).
>
> The /release /branch is where the release is polished and prepared and all
> the tests must 'eventually' pass - work can continue in /develop/ (another
> big +1) - everyone can help make the /release /stable.
>
> When the /release /branch is ready then it is merged to /master /*and
> */develop /(if there were changes in the /release /then they also need to
> get merged back to /develop/)
>
> The /master /branch only ever contains stable production ready code.
>
> Andy.
>
>
> On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
>>
>> Regarding the creation of a release branch I assume that creating the
>> branch from 'develop' implies that all available tests and quality
>> criteries must be matched before the actual branching takes place.
>> Am I right on this ?
>>
>> Best regards
>>
>> Daniel Kasmeroglu
>>
>>
>>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: git workflow?
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Not quite, the /release /branch takes place 'whenever' - This means it
would be 'nice' to create it from a stable /develop/, but is NOT
required (this is the big +1 for me).
The /release /branch is where the release is polished and prepared and
all the tests must 'eventually' pass - work can continue in /develop/
(another big +1) - everyone can help make the /release /stable.
When the /release /branch is ready then it is merged to /master /*and
*/develop /(if there were changes in the /release /then they also need
to get merged back to /develop/)
The /master /branch only ever contains stable production ready code.
Andy.
On 17/10/2014 15:54, Daniel Kasmeroglu wrote:
> Regarding the creation of a release branch I assume that creating the
> branch from 'develop' implies that all available tests and quality
> criteries must be matched before the actual branching takes place.
> Am I right on this ?
>
> Best regards
>
> Daniel Kasmeroglu
>
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: git workflow?
Posted by Daniel Kasmeroglu <da...@kasisoft.net>.
Regarding the creation of a release branch I assume that creating the
branch from 'develop' implies that all available tests and quality
criteries must be matched before the actual branching takes place.
Am I right on this ?
Best regards
Daniel Kasmeroglu
Re: git workflow?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
we'll see but I don't get any reason for it:
1) master is in the state of last release: so start from the tag to
develop if that's what you want. In most case merges will be an issue
(at least for tomee) if you really do it.
2) the extra work is cause you do it when releasing and then you need
to merge develop/master ensuring history is good ie not 1-1 merge
(manual process). if you don't do it then develop branch doesn't bring
anything
3) agree that feature branches are great (local or remote depending
the visibility of the work)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-10-17 13:25 GMT+02:00 Andy Gumbrecht <ag...@tomitribe.com>:
> +1
>
> The issue here really is that this discussion was due once the staging site
> was in place, not before it. Never mind, we'll just have to see how it works
> out.
>
> On 17/10/2014 13:16, Christofer Dutz wrote:
>>
>> Just my 50ct to this topic:
>>
>> At the Apache Flex project we too introduced GitFlow (even if we never
>> explicitly called it that way)
>> Working on Develop and having Master in the state of the last release is a
>> very good thing to have (in my opinion). this way someone can always start
>> with a working build as Develop usually tends to be buggy now and then.
>>
>> I don’t quite understand why you claim that a merge from develop to master
>> after a release adds another day to the process … no commit should to to
>> master and therefore there shouldn’t be any conflicts. So a merge should be
>> a on-command thing in Git.
>>
>> Also one thing with the feature branches. In flex some people tend to
>> start working on something together. So they start a feature-branch and work
>> on that … as soon as that’s finished they might decide to give it up or to
>> merge the stuff back to develop. This way their experiments don’t interfere
>> with any other people.
>>
>> I think it’s a good thing.
>>
>> Chris
>>
>> --
>>
>> Mit freundlichen Grüßen | Best regards
>>
>> Christofer Dutz | Senior IT Consultant
>>
>> codecentric AG | An der Welle 4 | 60322 Frankfurt am Main | Deutschland
>> mobil: +49 (0) 1525.3057806 | fax: +49 (0) 69.7593-8200
>> www.codecentric.de <http://www.codecentric.de/> | blog.codecentric.de
>> <http://blog.codecentric.de/> | www.meettheexperts.de
>> <http://www.meettheexperts.de/> | www.more4fi.de <http://www.more4fi.de/>
>>
>>
>> Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
>> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
>> Schütz
>>
>> Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche
>> und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige
>> Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie
>> bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter
>> Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl.
>> beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht
>> gestattet.
>>
>> Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>> <ma...@gmail.com>>:
>>
>>> Hi guys,
>>>
>>> just browsed the git workflow Andy wrote
>>> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
>>> few question:
>>> 1) (more a surprise than anything else) we don't discuss it?
>>> 2) I find it overcomplicated - this develop branch thing. Today we are
>>> not big enough to need it IMHO and we are agile enough to change when
>>> we'll need this. It is great if we would like to rewrite the history
>>> but we are open source and I think it is important to not do it.
>>> 3) if we really use it it means release preparation will take one
>>> extra day - to not say a week - to merge properly from develop to
>>> master but I don't see the gain
>>> 4) ds doesn't use it and project goes well so what do we expect? ->
>>> https://deltaspike.apache.org/suggested-git-workflows.html
>>>
>>> any inputs?
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>
>>
>
>
> --
> Andy Gumbrecht
> https://twitter.com/AndyGeeDe
> http://www.tomitribe.com
>
Re: git workflow?
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
+1
The issue here really is that this discussion was due once the staging
site was in place, not before it. Never mind, we'll just have to see how
it works out.
On 17/10/2014 13:16, Christofer Dutz wrote:
> Just my 50ct to this topic:
>
> At the Apache Flex project we too introduced GitFlow (even if we never
> explicitly called it that way)
> Working on Develop and having Master in the state of the last release
> is a very good thing to have (in my opinion). this way someone can
> always start with a working build as Develop usually tends to be buggy
> now and then.
>
> I don’t quite understand why you claim that a merge from develop to
> master after a release adds another day to the process … no commit
> should to to master and therefore there shouldn’t be any conflicts. So
> a merge should be a on-command thing in Git.
>
> Also one thing with the feature branches. In flex some people tend to
> start working on something together. So they start a feature-branch
> and work on that … as soon as that’s finished they might decide to
> give it up or to merge the stuff back to develop. This way their
> experiments don’t interfere with any other people.
>
> I think it’s a good thing.
>
> Chris
>
> --
>
> Mit freundlichen Grüßen | Best regards
>
> Christofer Dutz | Senior IT Consultant
>
> codecentric AG | An der Welle 4 | 60322 Frankfurt am Main | Deutschland
> mobil: +49 (0) 1525.3057806 | fax: +49 (0) 69.7593-8200
> www.codecentric.de <http://www.codecentric.de/> | blog.codecentric.de
> <http://blog.codecentric.de/> | www.meettheexperts.de
> <http://www.meettheexperts.de/> | www.more4fi.de <http://www.more4fi.de/>
>
>
> Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
> Schütz
>
> Diese E-Mail einschließlich evtl. beigefügter Dateien enthält
> vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie
> nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
> haben, informieren Sie bitte sofort den Absender und löschen Sie diese
> E-Mail und evtl. beigefügter Dateien umgehend. Das unerlaubte
> Kopieren, Nutzen oder Öffnen evtl. beigefügter Dateien sowie die
> unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
>
> Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau
> <rmannibucau@gmail.com <ma...@gmail.com>>:
>
>> Hi guys,
>>
>> just browsed the git workflow Andy wrote
>> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
>> few question:
>> 1) (more a surprise than anything else) we don't discuss it?
>> 2) I find it overcomplicated - this develop branch thing. Today we are
>> not big enough to need it IMHO and we are agile enough to change when
>> we'll need this. It is great if we would like to rewrite the history
>> but we are open source and I think it is important to not do it.
>> 3) if we really use it it means release preparation will take one
>> extra day - to not say a week - to merge properly from develop to
>> master but I don't see the gain
>> 4) ds doesn't use it and project goes well so what do we expect? ->
>> https://deltaspike.apache.org/suggested-git-workflows.html
>>
>> any inputs?
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com
Re: git workflow?
Posted by Christofer Dutz <ch...@codecentric.de>.
Just my 50ct to this topic:
At the Apache Flex project we too introduced GitFlow (even if we never explicitly called it that way)
Working on Develop and having Master in the state of the last release is a very good thing to have (in my opinion). this way someone can always start with a working build as Develop usually tends to be buggy now and then.
I don’t quite understand why you claim that a merge from develop to master after a release adds another day to the process … no commit should to to master and therefore there shouldn’t be any conflicts. So a merge should be a on-command thing in Git.
Also one thing with the feature branches. In flex some people tend to start working on something together. So they start a feature-branch and work on that … as soon as that’s finished they might decide to give it up or to merge the stuff back to develop. This way their experiments don’t interfere with any other people.
I think it’s a good thing.
Chris
--
Mit freundlichen Grüßen | Best regards
Christofer Dutz | Senior IT Consultant
codecentric AG | An der Welle 4 | 60322 Frankfurt am Main | Deutschland
mobil: +49 (0) 1525.3057806 | fax: +49 (0) 69.7593-8200
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de
Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
Am 17.10.2014 um 13:04 schrieb Romain Manni-Bucau <rm...@gmail.com>:
> Hi guys,
>
> just browsed the git workflow Andy wrote
> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
> few question:
> 1) (more a surprise than anything else) we don't discuss it?
> 2) I find it overcomplicated - this develop branch thing. Today we are
> not big enough to need it IMHO and we are agile enough to change when
> we'll need this. It is great if we would like to rewrite the history
> but we are open source and I think it is important to not do it.
> 3) if we really use it it means release preparation will take one
> extra day - to not say a week - to merge properly from develop to
> master but I don't see the gain
> 4) ds doesn't use it and project goes well so what do we expect? ->
> https://deltaspike.apache.org/suggested-git-workflows.html
>
> any inputs?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
Re: git workflow?
Posted by Andy Gumbrecht <ag...@tomitribe.com>.
Explain where the extra week is required?
Also, someone just went an released the git repository without
discussing it or letting others check it or waiting for the docs and
buildbot etc?
This was not the plan - The plan was to put everything in place and fire
off a discussion on staging and or vote before opening the door.
So now you/we get to discuss it with the door open. I will have to
publish the docs now so that at least others have a chance at hearing
that something has changed.
Andy.
On 17/10/2014 13:04, Romain Manni-Bucau wrote:
> Hi guys,
>
> just browsed the git workflow Andy wrote
> (http://tomee.staging.apache.org/dev/source-code.html) and I have a
> few question:
> 1) (more a surprise than anything else) we don't discuss it?
> 2) I find it overcomplicated - this develop branch thing. Today we are
> not big enough to need it IMHO and we are agile enough to change when
> we'll need this. It is great if we would like to rewrite the history
> but we are open source and I think it is important to not do it.
> 3) if we really use it it means release preparation will take one
> extra day - to not say a week - to merge properly from develop to
> master but I don't see the gain
> 4) ds doesn't use it and project goes well so what do we expect? ->
> https://deltaspike.apache.org/suggested-git-workflows.html
>
> any inputs?
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
--
Andy Gumbrecht
https://twitter.com/AndyGeeDe
http://www.tomitribe.com