You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zeppelin.apache.org by moon soo Lee <mo...@apache.org> on 2015/05/05 04:22:34 UTC
[DISCUSS] Create branch 'branch-0.5'
Hi,
I'd like discuss about creating a branch(ZEPPELIN-67
<https://issues.apache.org/jira/browse/ZEPPELIN-67>).
Currently, building source from master branch is the only official way user
can use Zeppelin. Therefore, we're extremely careful when merging code into
master and that slows down development.
If we make a branch and keep the branch stable, so user can build Zeppelin
from it and make a release from it. That'll help both keeping code stable
and faster accepting pullrequests.
What do you guys think?
Thanks,
moon
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by moon soo Lee <mo...@apache.org>.
We had good discussions and i can see at least we need release branch.
I'd like to proceed creating 'branch-0.5' as a release branch.
Once it is created from current master, Pullrequests are going to merge
into master branch only. If there're some fix to be applied to branch-0.5,
it will be merged into both master and branch-0.5 branch. (our merge tool
already support it).
Target branch for the pullrequest can be marked as a 'fix version' in
related jira issue or explicitly say in a pullrequest's comment. Otherwise,
will be merged into master branch only.
Once we have 'branch-0.5' we can try release from it.
I'm creating a branch in next 24 hours if there're no possible serious
downside.
Best,
moon
On Wed, May 6, 2015 at 5:37 AM moon soo Lee <mo...@apache.org> wrote:
> Thanks for the feedback. Overall i agree with Cos proposed way.
>
> In my experience, keeping master branch (always production ready) as well
> as development branch sometimes confuses people (eg. when people branching
> for new feature). And master branch is very easy to end up with being just
> a reference to latest release tag.
> That's the reason why i think it's enough to have release tags for
> production ready code without master branch.
> And then development branch can use name 'master'. To me, branch name
> 'master' in git feels more like 'trunk' in svn. I think the name fits more
> for dev branch.
>
> Best,
> moon
>
>
>
> On Tue, May 5, 2015 at 8:16 PM Konstantin Boudnik <co...@apache.org> wrote:
>
>> On Tue, May 05, 2015 at 02:50PM, York, Brennon wrote:
>> > Cos, can you dive a bit deeper into what you’re proposing? I’ll be the
>> > first to admit that I assume there’s a better way to do this than what’s
>> > been done previously and I’m trying to understand this new methodology.
>>
>> I thought the diagram I've sent was pretty clear, but here's a
>> description of
>> it. Everything is done on branches: hotfixes, feature development and
>> releases
>> (after all git branches are free).
>>
>> Now, if you need to issue a fix for an older release you as the workflow
>> suggests:
>> - cut a branch for the hotfix (let's call it HF-branch) most likelt off
>> the
>> release branch
>> - do usual CI on it
>> - merge HF-branch into master and the release branch in question
>> - do the rest of the work on the release branch: bump the version, etc.
>> - delete HF-branch
>>
>> Does it make sense?
>> Cos
>>
>> > My question is honestly purely a question from worry for production
>> > support. To dive deeper, how, given this Git style, would one retrofit a
>> > bug fix into an older release? From my experience its terribly difficult
>> > to get enterprises to bump up versions without tons of internal
>> regression
>> > testing, but, oftentimes, there are hot fixes pushed into previously
>> > releases (1.3.0 -> 1.3.1 versioning for instance) that will get rolled
>> out
>> > quickly (with the bugs typically found from enterprise regression).
>> >
>> > In short though, if this new way can handle that, I’d love to give it a
>> > try! :)
>> >
>> > On 5/5/15, 11:38 AM, "Konstantin Boudnik" <co...@apache.org> wrote:
>> >
>> > >On Tue, May 05, 2015 at 08:58AM, moon soo Lee wrote:
>> > >> Hi Cos,
>> > >>
>> > >> Thanks for useful information. I think we're in the same page.
>> > >>
>> > >> The branch i'm suggesting ('branch-0.5') is considered as a release
>> > >>branch,
>> > >> while we do stabilize code and make a release from the branch.
>> > >>
>> > >> Zeppelin receives patch via pullrequest and it is looks like
>> > >>pullrequest is
>> > >> feature branch.
>> > >>
>> > >> I was thinking managing branch 'master' as a dev branch and
>> maintaining
>> > >> master source tree by creating tags. Not a branch. This is a
>> difference
>> > >> from the link.
>> > >
>> > >That's a possibility as well. But in this case you might end up with
>> > >either
>> > > a) a necessity to do multiple merges across all active branches from
>> the
>> > > master. This will get very tricky as soon as the branches drift
>> apart
>> > >far
>> > > enough
>> > > b) you will face a need to start cherry-picking, which will ruin the
>> > >history
>> > > of changes migration across the branches. Remember, cherry-pick is
>> > > changing commit hash.
>> > >
>> > >Does it make sense?
>> > > Cos
>> > >
>> > >> Any thoughts?
>> > >>
>> > >> Thanks,
>> > >> moon
>> > >>
>> > >> On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org>
>> wrote:
>> > >>
>> > >> > One of my long time favorite git branching models and one that is
>> > >>really
>> > >> > working
>> > >> > http://nvie.com/posts/a-successful-git-branching-model/
>> > >> >
>> > >> > Perhaps something to consider?
>> > >> > Cos
>> > >> >
>> > >> > On Tue, May 05, 2015 at 01:56PM, Alex wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > I like the idea of really simple git workflow with only one
>> branch
>> > >>so
>> > >> > there
>> > >> > > is no questions like where to merge things to? Which branch to
>> build
>> > >> > from?
>> > >> > > Which is latest, which is stable etc..
>> > >> > >
>> > >> > > Because all this requires human interaction to resolve.
>> > >> > >
>> > >> > > But at the same time if you think that having multiple branches
>> > >>witch
>> > >> > are up
>> > >> > > to date and documented well will solve the problem of
>> > >>stability/faster PR
>> > >> > > merge time - I think it might be worth giving it a try, say for
>> > >>next 3
>> > >> > > months, and see if that helps.
>> > >> > >
>> > >> > >
>> > >> > > --
>> > >> > > Kind regards,
>> > >> > > Alexander
>> > >> > >
>> > >> > > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org>
>> wrote:
>> > >> > > >
>> > >> > > > Hi,
>> > >> > > >
>> > >> > > > I'd like discuss about creating a branch(ZEPPELIN-67
>> > >> > > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
>> > >> > > >
>> > >> > > > Currently, building source from master branch is the only
>> > >>official way
>> > >> > user
>> > >> > > > can use Zeppelin. Therefore, we're extremely careful when
>> merging
>> > >>code
>> > >> > into
>> > >> > > > master and that slows down development.
>> > >> > > >
>> > >> > > > If we make a branch and keep the branch stable, so user can
>> build
>> > >> > Zeppelin
>> > >> > > > from it and make a release from it. That'll help both keeping
>> code
>> > >> > stable
>> > >> > > > and faster accepting pullrequests.
>> > >> > > >
>> > >> > > > What do you guys think?
>> > >> > > >
>> > >> > > > Thanks,
>> > >> > > > moon
>> > >> >
>> >
>> > ________________________________________________________
>> >
>> > The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the
>> intended recipient, you are hereby notified that any review,
>> retransmission, dissemination, distribution, copying or other use of, or
>> taking of any action in reliance upon this information is strictly
>> prohibited. If you have received this communication in error, please
>> contact the sender and delete the material from your computer.
>>
>
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by moon soo Lee <mo...@apache.org>.
Thanks for the feedback. Overall i agree with Cos proposed way.
In my experience, keeping master branch (always production ready) as well
as development branch sometimes confuses people (eg. when people branching
for new feature). And master branch is very easy to end up with being just
a reference to latest release tag.
That's the reason why i think it's enough to have release tags for
production ready code without master branch.
And then development branch can use name 'master'. To me, branch name
'master' in git feels more like 'trunk' in svn. I think the name fits more
for dev branch.
Best,
moon
On Tue, May 5, 2015 at 8:16 PM Konstantin Boudnik <co...@apache.org> wrote:
> On Tue, May 05, 2015 at 02:50PM, York, Brennon wrote:
> > Cos, can you dive a bit deeper into what you’re proposing? I’ll be the
> > first to admit that I assume there’s a better way to do this than what’s
> > been done previously and I’m trying to understand this new methodology.
>
> I thought the diagram I've sent was pretty clear, but here's a description
> of
> it. Everything is done on branches: hotfixes, feature development and
> releases
> (after all git branches are free).
>
> Now, if you need to issue a fix for an older release you as the workflow
> suggests:
> - cut a branch for the hotfix (let's call it HF-branch) most likelt off
> the
> release branch
> - do usual CI on it
> - merge HF-branch into master and the release branch in question
> - do the rest of the work on the release branch: bump the version, etc.
> - delete HF-branch
>
> Does it make sense?
> Cos
>
> > My question is honestly purely a question from worry for production
> > support. To dive deeper, how, given this Git style, would one retrofit a
> > bug fix into an older release? From my experience its terribly difficult
> > to get enterprises to bump up versions without tons of internal
> regression
> > testing, but, oftentimes, there are hot fixes pushed into previously
> > releases (1.3.0 -> 1.3.1 versioning for instance) that will get rolled
> out
> > quickly (with the bugs typically found from enterprise regression).
> >
> > In short though, if this new way can handle that, I’d love to give it a
> > try! :)
> >
> > On 5/5/15, 11:38 AM, "Konstantin Boudnik" <co...@apache.org> wrote:
> >
> > >On Tue, May 05, 2015 at 08:58AM, moon soo Lee wrote:
> > >> Hi Cos,
> > >>
> > >> Thanks for useful information. I think we're in the same page.
> > >>
> > >> The branch i'm suggesting ('branch-0.5') is considered as a release
> > >>branch,
> > >> while we do stabilize code and make a release from the branch.
> > >>
> > >> Zeppelin receives patch via pullrequest and it is looks like
> > >>pullrequest is
> > >> feature branch.
> > >>
> > >> I was thinking managing branch 'master' as a dev branch and
> maintaining
> > >> master source tree by creating tags. Not a branch. This is a
> difference
> > >> from the link.
> > >
> > >That's a possibility as well. But in this case you might end up with
> > >either
> > > a) a necessity to do multiple merges across all active branches from
> the
> > > master. This will get very tricky as soon as the branches drift
> apart
> > >far
> > > enough
> > > b) you will face a need to start cherry-picking, which will ruin the
> > >history
> > > of changes migration across the branches. Remember, cherry-pick is
> > > changing commit hash.
> > >
> > >Does it make sense?
> > > Cos
> > >
> > >> Any thoughts?
> > >>
> > >> Thanks,
> > >> moon
> > >>
> > >> On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org>
> wrote:
> > >>
> > >> > One of my long time favorite git branching models and one that is
> > >>really
> > >> > working
> > >> > http://nvie.com/posts/a-successful-git-branching-model/
> > >> >
> > >> > Perhaps something to consider?
> > >> > Cos
> > >> >
> > >> > On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> > >> > > Hi,
> > >> > >
> > >> > > I like the idea of really simple git workflow with only one branch
> > >>so
> > >> > there
> > >> > > is no questions like where to merge things to? Which branch to
> build
> > >> > from?
> > >> > > Which is latest, which is stable etc..
> > >> > >
> > >> > > Because all this requires human interaction to resolve.
> > >> > >
> > >> > > But at the same time if you think that having multiple branches
> > >>witch
> > >> > are up
> > >> > > to date and documented well will solve the problem of
> > >>stability/faster PR
> > >> > > merge time - I think it might be worth giving it a try, say for
> > >>next 3
> > >> > > months, and see if that helps.
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Kind regards,
> > >> > > Alexander
> > >> > >
> > >> > > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> > >> > > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > I'd like discuss about creating a branch(ZEPPELIN-67
> > >> > > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> > >> > > >
> > >> > > > Currently, building source from master branch is the only
> > >>official way
> > >> > user
> > >> > > > can use Zeppelin. Therefore, we're extremely careful when
> merging
> > >>code
> > >> > into
> > >> > > > master and that slows down development.
> > >> > > >
> > >> > > > If we make a branch and keep the branch stable, so user can
> build
> > >> > Zeppelin
> > >> > > > from it and make a release from it. That'll help both keeping
> code
> > >> > stable
> > >> > > > and faster accepting pullrequests.
> > >> > > >
> > >> > > > What do you guys think?
> > >> > > >
> > >> > > > Thanks,
> > >> > > > moon
> > >> >
> >
> > ________________________________________________________
> >
> > The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the
> intended recipient, you are hereby notified that any review,
> retransmission, dissemination, distribution, copying or other use of, or
> taking of any action in reliance upon this information is strictly
> prohibited. If you have received this communication in error, please
> contact the sender and delete the material from your computer.
>
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, May 05, 2015 at 02:50PM, York, Brennon wrote:
> Cos, can you dive a bit deeper into what you’re proposing? I’ll be the
> first to admit that I assume there’s a better way to do this than what’s
> been done previously and I’m trying to understand this new methodology.
I thought the diagram I've sent was pretty clear, but here's a description of
it. Everything is done on branches: hotfixes, feature development and releases
(after all git branches are free).
Now, if you need to issue a fix for an older release you as the workflow
suggests:
- cut a branch for the hotfix (let's call it HF-branch) most likelt off the
release branch
- do usual CI on it
- merge HF-branch into master and the release branch in question
- do the rest of the work on the release branch: bump the version, etc.
- delete HF-branch
Does it make sense?
Cos
> My question is honestly purely a question from worry for production
> support. To dive deeper, how, given this Git style, would one retrofit a
> bug fix into an older release? From my experience its terribly difficult
> to get enterprises to bump up versions without tons of internal regression
> testing, but, oftentimes, there are hot fixes pushed into previously
> releases (1.3.0 -> 1.3.1 versioning for instance) that will get rolled out
> quickly (with the bugs typically found from enterprise regression).
>
> In short though, if this new way can handle that, I’d love to give it a
> try! :)
>
> On 5/5/15, 11:38 AM, "Konstantin Boudnik" <co...@apache.org> wrote:
>
> >On Tue, May 05, 2015 at 08:58AM, moon soo Lee wrote:
> >> Hi Cos,
> >>
> >> Thanks for useful information. I think we're in the same page.
> >>
> >> The branch i'm suggesting ('branch-0.5') is considered as a release
> >>branch,
> >> while we do stabilize code and make a release from the branch.
> >>
> >> Zeppelin receives patch via pullrequest and it is looks like
> >>pullrequest is
> >> feature branch.
> >>
> >> I was thinking managing branch 'master' as a dev branch and maintaining
> >> master source tree by creating tags. Not a branch. This is a difference
> >> from the link.
> >
> >That's a possibility as well. But in this case you might end up with
> >either
> > a) a necessity to do multiple merges across all active branches from the
> > master. This will get very tricky as soon as the branches drift apart
> >far
> > enough
> > b) you will face a need to start cherry-picking, which will ruin the
> >history
> > of changes migration across the branches. Remember, cherry-pick is
> > changing commit hash.
> >
> >Does it make sense?
> > Cos
> >
> >> Any thoughts?
> >>
> >> Thanks,
> >> moon
> >>
> >> On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
> >>
> >> > One of my long time favorite git branching models and one that is
> >>really
> >> > working
> >> > http://nvie.com/posts/a-successful-git-branching-model/
> >> >
> >> > Perhaps something to consider?
> >> > Cos
> >> >
> >> > On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> >> > > Hi,
> >> > >
> >> > > I like the idea of really simple git workflow with only one branch
> >>so
> >> > there
> >> > > is no questions like where to merge things to? Which branch to build
> >> > from?
> >> > > Which is latest, which is stable etc..
> >> > >
> >> > > Because all this requires human interaction to resolve.
> >> > >
> >> > > But at the same time if you think that having multiple branches
> >>witch
> >> > are up
> >> > > to date and documented well will solve the problem of
> >>stability/faster PR
> >> > > merge time - I think it might be worth giving it a try, say for
> >>next 3
> >> > > months, and see if that helps.
> >> > >
> >> > >
> >> > > --
> >> > > Kind regards,
> >> > > Alexander
> >> > >
> >> > > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > I'd like discuss about creating a branch(ZEPPELIN-67
> >> > > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> >> > > >
> >> > > > Currently, building source from master branch is the only
> >>official way
> >> > user
> >> > > > can use Zeppelin. Therefore, we're extremely careful when merging
> >>code
> >> > into
> >> > > > master and that slows down development.
> >> > > >
> >> > > > If we make a branch and keep the branch stable, so user can build
> >> > Zeppelin
> >> > > > from it and make a release from it. That'll help both keeping code
> >> > stable
> >> > > > and faster accepting pullrequests.
> >> > > >
> >> > > > What do you guys think?
> >> > > >
> >> > > > Thanks,
> >> > > > moon
> >> >
>
> ________________________________________________________
>
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by "York, Brennon" <Br...@capitalone.com>.
Cos, can you dive a bit deeper into what you’re proposing? I’ll be the
first to admit that I assume there’s a better way to do this than what’s
been done previously and I’m trying to understand this new methodology.
My question is honestly purely a question from worry for production
support. To dive deeper, how, given this Git style, would one retrofit a
bug fix into an older release? From my experience its terribly difficult
to get enterprises to bump up versions without tons of internal regression
testing, but, oftentimes, there are hot fixes pushed into previously
releases (1.3.0 -> 1.3.1 versioning for instance) that will get rolled out
quickly (with the bugs typically found from enterprise regression).
In short though, if this new way can handle that, I’d love to give it a
try! :)
On 5/5/15, 11:38 AM, "Konstantin Boudnik" <co...@apache.org> wrote:
>On Tue, May 05, 2015 at 08:58AM, moon soo Lee wrote:
>> Hi Cos,
>>
>> Thanks for useful information. I think we're in the same page.
>>
>> The branch i'm suggesting ('branch-0.5') is considered as a release
>>branch,
>> while we do stabilize code and make a release from the branch.
>>
>> Zeppelin receives patch via pullrequest and it is looks like
>>pullrequest is
>> feature branch.
>>
>> I was thinking managing branch 'master' as a dev branch and maintaining
>> master source tree by creating tags. Not a branch. This is a difference
>> from the link.
>
>That's a possibility as well. But in this case you might end up with
>either
> a) a necessity to do multiple merges across all active branches from the
> master. This will get very tricky as soon as the branches drift apart
>far
> enough
> b) you will face a need to start cherry-picking, which will ruin the
>history
> of changes migration across the branches. Remember, cherry-pick is
> changing commit hash.
>
>Does it make sense?
> Cos
>
>> Any thoughts?
>>
>> Thanks,
>> moon
>>
>> On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
>>
>> > One of my long time favorite git branching models and one that is
>>really
>> > working
>> > http://nvie.com/posts/a-successful-git-branching-model/
>> >
>> > Perhaps something to consider?
>> > Cos
>> >
>> > On Tue, May 05, 2015 at 01:56PM, Alex wrote:
>> > > Hi,
>> > >
>> > > I like the idea of really simple git workflow with only one branch
>>so
>> > there
>> > > is no questions like where to merge things to? Which branch to build
>> > from?
>> > > Which is latest, which is stable etc..
>> > >
>> > > Because all this requires human interaction to resolve.
>> > >
>> > > But at the same time if you think that having multiple branches
>>witch
>> > are up
>> > > to date and documented well will solve the problem of
>>stability/faster PR
>> > > merge time - I think it might be worth giving it a try, say for
>>next 3
>> > > months, and see if that helps.
>> > >
>> > >
>> > > --
>> > > Kind regards,
>> > > Alexander
>> > >
>> > > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
>> > > >
>> > > > Hi,
>> > > >
>> > > > I'd like discuss about creating a branch(ZEPPELIN-67
>> > > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
>> > > >
>> > > > Currently, building source from master branch is the only
>>official way
>> > user
>> > > > can use Zeppelin. Therefore, we're extremely careful when merging
>>code
>> > into
>> > > > master and that slows down development.
>> > > >
>> > > > If we make a branch and keep the branch stable, so user can build
>> > Zeppelin
>> > > > from it and make a release from it. That'll help both keeping code
>> > stable
>> > > > and faster accepting pullrequests.
>> > > >
>> > > > What do you guys think?
>> > > >
>> > > > Thanks,
>> > > > moon
>> >
________________________________________________________
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, May 05, 2015 at 08:58AM, moon soo Lee wrote:
> Hi Cos,
>
> Thanks for useful information. I think we're in the same page.
>
> The branch i'm suggesting ('branch-0.5') is considered as a release branch,
> while we do stabilize code and make a release from the branch.
>
> Zeppelin receives patch via pullrequest and it is looks like pullrequest is
> feature branch.
>
> I was thinking managing branch 'master' as a dev branch and maintaining
> master source tree by creating tags. Not a branch. This is a difference
> from the link.
That's a possibility as well. But in this case you might end up with either
a) a necessity to do multiple merges across all active branches from the
master. This will get very tricky as soon as the branches drift apart far
enough
b) you will face a need to start cherry-picking, which will ruin the history
of changes migration across the branches. Remember, cherry-pick is
changing commit hash.
Does it make sense?
Cos
> Any thoughts?
>
> Thanks,
> moon
>
> On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
>
> > One of my long time favorite git branching models and one that is really
> > working
> > http://nvie.com/posts/a-successful-git-branching-model/
> >
> > Perhaps something to consider?
> > Cos
> >
> > On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> > > Hi,
> > >
> > > I like the idea of really simple git workflow with only one branch so
> > there
> > > is no questions like where to merge things to? Which branch to build
> > from?
> > > Which is latest, which is stable etc..
> > >
> > > Because all this requires human interaction to resolve.
> > >
> > > But at the same time if you think that having multiple branches witch
> > are up
> > > to date and documented well will solve the problem of stability/faster PR
> > > merge time - I think it might be worth giving it a try, say for next 3
> > > months, and see if that helps.
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander
> > >
> > > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I'd like discuss about creating a branch(ZEPPELIN-67
> > > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> > > >
> > > > Currently, building source from master branch is the only official way
> > user
> > > > can use Zeppelin. Therefore, we're extremely careful when merging code
> > into
> > > > master and that slows down development.
> > > >
> > > > If we make a branch and keep the branch stable, so user can build
> > Zeppelin
> > > > from it and make a release from it. That'll help both keeping code
> > stable
> > > > and faster accepting pullrequests.
> > > >
> > > > What do you guys think?
> > > >
> > > > Thanks,
> > > > moon
> >
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, May 05, 2015 at 12:41PM, York, Brennon wrote:
> I’m in favor of setting a branch for each release (e.g. ‘branch-0.5’). For
> reference its what many other projects do in ASF (e.g. Spark, Hadoop).
>From first hand experience: unfortunately Hadoop is using SVN branching model
on git. And it is getting _very_ time consuming when you're dealing with 2+
more release trains. Eg in case of Hadoop 3.x (trunk) and 2.x branches. That's
pretty unfortunate they never adopted the benefits of git. Once of the most
troublesome outcomes of it is a need to either cherry-pick commits from trunk
or do multiple commits for each patch. Argh...
The biggest plus-side of the model I am referring, is that you have _all_ you
code on the master because feature branches are merged into it and got
deleted; and long-lived release branches are merged into master periodically
with tagging. As the result, you preserve the history of the changes, because
merges preserve commits SHA1. And you have non-material tags that allow you to
branch out later if you need to have a hot-fix for an older release or
something.
> I’ve personally seen it help to maintain feature sets per branch, back
> porting bugs into older versions, and, in the long run, help maintain
> production support for various versions.
Actually, it is not - see above ;)
Cos
>
> My 2c :)
>
> On 5/5/15, 1:58 AM, "moon soo Lee" <mo...@apache.org> wrote:
>
> >Hi Cos,
> >
> >Thanks for useful information. I think we're in the same page.
> >
> >The branch i'm suggesting ('branch-0.5') is considered as a release
> >branch,
> >while we do stabilize code and make a release from the branch.
> >
> >Zeppelin receives patch via pullrequest and it is looks like pullrequest
> >is
> >feature branch.
> >
> >I was thinking managing branch 'master' as a dev branch and maintaining
> >master source tree by creating tags. Not a branch. This is a difference
> >from the link.
> >
> >Any thoughts?
> >
> >Thanks,
> >moon
> >
> >On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
> >
> >> One of my long time favorite git branching models and one that is really
> >> working
> >> http://nvie.com/posts/a-successful-git-branching-model/
> >>
> >> Perhaps something to consider?
> >> Cos
> >>
> >> On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> >> > Hi,
> >> >
> >> > I like the idea of really simple git workflow with only one branch so
> >> there
> >> > is no questions like where to merge things to? Which branch to build
> >> from?
> >> > Which is latest, which is stable etc..
> >> >
> >> > Because all this requires human interaction to resolve.
> >> >
> >> > But at the same time if you think that having multiple branches witch
> >> are up
> >> > to date and documented well will solve the problem of
> >>stability/faster PR
> >> > merge time - I think it might be worth giving it a try, say for next
> >>3
> >> > months, and see if that helps.
> >> >
> >> >
> >> > --
> >> > Kind regards,
> >> > Alexander
> >> >
> >> > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > I'd like discuss about creating a branch(ZEPPELIN-67
> >> > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> >> > >
> >> > > Currently, building source from master branch is the only official
> >>way
> >> user
> >> > > can use Zeppelin. Therefore, we're extremely careful when merging
> >>code
> >> into
> >> > > master and that slows down development.
> >> > >
> >> > > If we make a branch and keep the branch stable, so user can build
> >> Zeppelin
> >> > > from it and make a release from it. That'll help both keeping code
> >> stable
> >> > > and faster accepting pullrequests.
> >> > >
> >> > > What do you guys think?
> >> > >
> >> > > Thanks,
> >> > > moon
> >>
>
> ________________________________________________________
>
> The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by "York, Brennon" <Br...@capitalone.com>.
I’m in favor of setting a branch for each release (e.g. ‘branch-0.5’). For
reference its what many other projects do in ASF (e.g. Spark, Hadoop).
I’ve personally seen it help to maintain feature sets per branch, back
porting bugs into older versions, and, in the long run, help maintain
production support for various versions.
My 2c :)
On 5/5/15, 1:58 AM, "moon soo Lee" <mo...@apache.org> wrote:
>Hi Cos,
>
>Thanks for useful information. I think we're in the same page.
>
>The branch i'm suggesting ('branch-0.5') is considered as a release
>branch,
>while we do stabilize code and make a release from the branch.
>
>Zeppelin receives patch via pullrequest and it is looks like pullrequest
>is
>feature branch.
>
>I was thinking managing branch 'master' as a dev branch and maintaining
>master source tree by creating tags. Not a branch. This is a difference
>from the link.
>
>Any thoughts?
>
>Thanks,
>moon
>
>On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
>
>> One of my long time favorite git branching models and one that is really
>> working
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Perhaps something to consider?
>> Cos
>>
>> On Tue, May 05, 2015 at 01:56PM, Alex wrote:
>> > Hi,
>> >
>> > I like the idea of really simple git workflow with only one branch so
>> there
>> > is no questions like where to merge things to? Which branch to build
>> from?
>> > Which is latest, which is stable etc..
>> >
>> > Because all this requires human interaction to resolve.
>> >
>> > But at the same time if you think that having multiple branches witch
>> are up
>> > to date and documented well will solve the problem of
>>stability/faster PR
>> > merge time - I think it might be worth giving it a try, say for next
>>3
>> > months, and see if that helps.
>> >
>> >
>> > --
>> > Kind regards,
>> > Alexander
>> >
>> > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'd like discuss about creating a branch(ZEPPELIN-67
>> > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
>> > >
>> > > Currently, building source from master branch is the only official
>>way
>> user
>> > > can use Zeppelin. Therefore, we're extremely careful when merging
>>code
>> into
>> > > master and that slows down development.
>> > >
>> > > If we make a branch and keep the branch stable, so user can build
>> Zeppelin
>> > > from it and make a release from it. That'll help both keeping code
>> stable
>> > > and faster accepting pullrequests.
>> > >
>> > > What do you guys think?
>> > >
>> > > Thanks,
>> > > moon
>>
________________________________________________________
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by moon soo Lee <mo...@apache.org>.
Hi Cos,
Thanks for useful information. I think we're in the same page.
The branch i'm suggesting ('branch-0.5') is considered as a release branch,
while we do stabilize code and make a release from the branch.
Zeppelin receives patch via pullrequest and it is looks like pullrequest is
feature branch.
I was thinking managing branch 'master' as a dev branch and maintaining
master source tree by creating tags. Not a branch. This is a difference
from the link.
Any thoughts?
Thanks,
moon
On 2015년 5월 5일 (화) at 오후 2:25 Konstantin Boudnik <co...@apache.org> wrote:
> One of my long time favorite git branching models and one that is really
> working
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Perhaps something to consider?
> Cos
>
> On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> > Hi,
> >
> > I like the idea of really simple git workflow with only one branch so
> there
> > is no questions like where to merge things to? Which branch to build
> from?
> > Which is latest, which is stable etc..
> >
> > Because all this requires human interaction to resolve.
> >
> > But at the same time if you think that having multiple branches witch
> are up
> > to date and documented well will solve the problem of stability/faster PR
> > merge time - I think it might be worth giving it a try, say for next 3
> > months, and see if that helps.
> >
> >
> > --
> > Kind regards,
> > Alexander
> >
> > > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> > >
> > > Hi,
> > >
> > > I'd like discuss about creating a branch(ZEPPELIN-67
> > > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> > >
> > > Currently, building source from master branch is the only official way
> user
> > > can use Zeppelin. Therefore, we're extremely careful when merging code
> into
> > > master and that slows down development.
> > >
> > > If we make a branch and keep the branch stable, so user can build
> Zeppelin
> > > from it and make a release from it. That'll help both keeping code
> stable
> > > and faster accepting pullrequests.
> > >
> > > What do you guys think?
> > >
> > > Thanks,
> > > moon
>
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by Konstantin Boudnik <co...@apache.org>.
One of my long time favorite git branching models and one that is really working
http://nvie.com/posts/a-successful-git-branching-model/
Perhaps something to consider?
Cos
On Tue, May 05, 2015 at 01:56PM, Alex wrote:
> Hi,
>
> I like the idea of really simple git workflow with only one branch so there
> is no questions like where to merge things to? Which branch to build from?
> Which is latest, which is stable etc..
>
> Because all this requires human interaction to resolve.
>
> But at the same time if you think that having multiple branches witch are up
> to date and documented well will solve the problem of stability/faster PR
> merge time - I think it might be worth giving it a try, say for next 3
> months, and see if that helps.
>
>
> --
> Kind regards,
> Alexander
>
> > On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
> >
> > Hi,
> >
> > I'd like discuss about creating a branch(ZEPPELIN-67
> > <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
> >
> > Currently, building source from master branch is the only official way user
> > can use Zeppelin. Therefore, we're extremely careful when merging code into
> > master and that slows down development.
> >
> > If we make a branch and keep the branch stable, so user can build Zeppelin
> > from it and make a release from it. That'll help both keeping code stable
> > and faster accepting pullrequests.
> >
> > What do you guys think?
> >
> > Thanks,
> > moon
Re: [DISCUSS] Create branch 'branch-0.5'
Posted by Alex <ke...@gmail.com>.
Hi,
I like the idea of really simple git workflow with only one branch so there is no questions like where to merge things to? Which branch to build from? Which is latest, which is stable etc..
Because all this requires human interaction to resolve.
But at the same time if you think that having multiple branches witch are up to date and documented well will solve the problem of stability/faster PR merge time - I think it might be worth giving it a try, say for next 3 months, and see if that helps.
--
Kind regards,
Alexander
> On 05 May 2015, at 11:22, moon soo Lee <mo...@apache.org> wrote:
>
> Hi,
>
> I'd like discuss about creating a branch(ZEPPELIN-67
> <https://issues.apache.org/jira/browse/ZEPPELIN-67>).
>
> Currently, building source from master branch is the only official way user
> can use Zeppelin. Therefore, we're extremely careful when merging code into
> master and that slows down development.
>
> If we make a branch and keep the branch stable, so user can build Zeppelin
> from it and make a release from it. That'll help both keeping code stable
> and faster accepting pullrequests.
>
> What do you guys think?
>
> Thanks,
> moon