You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Yakov Zhdanov <yz...@apache.org> on 2015/07/06 17:11:54 UTC
Important: Git Policy Changed
Igniters,
As it has been discussed, we are applying an updated Git policy which
should be more flexible and transparent that we have now.
Process is described here:
https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
I would also put points here (taken from the page above)
- Master should become the development branch for the next release
(current sprint).
- Whenever current release (sprint) goes to QA, new branch should be
created from master. This way master can be used to develop functionality
of the next release. All release fixes get merged to release branch and
then to master.
- All individual ticket branches should be created off of the master
branch (or release branch if one exists - in this case changes get merged
to release branch and then to master branch).
- Git tag should be created for every release.
- All CI tests must pass before the merge of ticket branches to the
master (or release) branch.
ignite-sprint-7 branch will be removed soon.
Please let me know if anyone has questions.
--Yakov
Re: Important: Git Policy Changed
Posted by Branko Čibej <br...@apache.org>.
On 23.07.2015 03:44, Alexey Goncharuk wrote:
> Folks,
>
> Kindly reminder: when committing a patch provided by a contributor, do not
> forget to specify --author tag with the commit in order to preserve the
> identity of the person created the patch, for example:
>
> git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in REST
> log command"
Agreed. However: I strongly suggest not including the contributor's
e-mail address unless they've specifically allowed you to do so. Every
little bit helps against spammers, and the name is quite sufficient.
> I have updated the document accordingly.
>
> Thanks!
> --Alexey
>
> 2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
>
>> Ok, I have fixed the CI on builds.apache.org - now they take master as
>> default.
>>
>> Cos
>>
>> On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
>>> Yes, I am aware about this issue. However my account stopped working and
>> I
>>> need to take it to INFRA. Will take care about this in a day or two:
>> thanks
>>> for the reminder.
>>>
>>> If anyone feel like getting an account on the Apache CI and fixing the
>> build -
>>> please do so by all means!
>>>
>>> Cos
>>>
>>> On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
>>>> It looks like we forgot to change the nightly builds trigger. The
>> website
>>>> link
>>>>
>> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
>>>> points to the build based on sprint-2.
>>>>
>>>> 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
>>>>
>>>>> Looks good - thanks for putting this together!
>>>>>
>>>>> Cos
>>>>>
>>>>> On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
>>>>>> Igniters,
>>>>>>
>>>>>> As it has been discussed, we are applying an updated Git policy
>> which
>>>>>> should be more flexible and transparent that we have now.
>>>>>>
>>>>>> Process is described here:
>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
>>>>>>
>>>>>> I would also put points here (taken from the page above)
>>>>>>
>>>>>> - Master should become the development branch for the next
>> release
>>>>>> (current sprint).
>>>>>> - Whenever current release (sprint) goes to QA, new branch
>> should be
>>>>>> created from master. This way master can be used to develop
>>>>> functionality
>>>>>> of the next release. All release fixes get merged to release
>> branch
>>>>> and
>>>>>> then to master.
>>>>>> - All individual ticket branches should be created off of the
>> master
>>>>>> branch (or release branch if one exists - in this case changes
>> get
>>>>> merged
>>>>>> to release branch and then to master branch).
>>>>>> - Git tag should be created for every release.
>>>>>> - All CI tests must pass before the merge of ticket branches to
>> the
>>>>>> master (or release) branch.
>>>>>>
>>>>>> ignite-sprint-7 branch will be removed soon.
>>>>>>
>>>>>> Please let me know if anyone has questions.
>>>>>>
>>>>>> --Yakov
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Jul 28, 2015 at 11:02AM, Dmitriy Setrakyan wrote:
> On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <pt...@gridgain.com>
> wrote:
>
> > As said above, squash should be used when merging to master (git merge
> > branchName --squash "Message"; there are checkboxes in Idea, too).
> > This way there is a single commit with a meaningful message in master,
> > and it does not matter what happened in the personal branch.
> >
>
> Pavel, I am not a GIT expert, so bare with me :)
>
> Will the commits that got merged from master be squashed too? In other
> words, will the master commits be piled together with all the user-commits
> in one uber-commit from that user?
Absolutely no. You never touch objects that are already in the remote.
Cos
> > I think this is the simplest workflow.
> >
> > Thanks,
> >
> > On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> >
> > > On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > > > > I hope so, it'd be horrible to do that on master!
> > > >
> > > > Exactly!
> > > > But I do not see much sense in enforcing any kind of policy in personal
> > > > branches. Sometimes rebase may be better, sometimes I may want to use
> > > merge
> > > > so I see when and which changes came from master branch, etc.
> > > > Only the implementer cares about the look of history in his branch, so
> > it
> > > > is up to him.
> > >
> > > You can do with your personal branch whatever you pleased with, of
> > course.
> > > However, if you make 112 intermediate commits while working on something,
> > > there's no need to unleash it on everyone; also it is of little interest
> > to
> > > anyone to see how many times you merged from the master to your local
> > > branch.
> > >
> > > In this respect, hygiene of the personal branches are of little concern
> > to
> > > anyone, until one starts contaminating the shared history. Does it make
> > > sense?
> > >
> > > > > Also what will happen if someone will do merge but other rebase?
> > > >
> > > > Nothing will happen, we are talking about personal branches, they end
> > up
> > > > being removed. And resulting work is squashed into a patch.
> > >
> > > Actually, I didn't say anything on how the content of the change is
> > > delivered
> > > to the master. If you want to do it with patches - sure; but I think it'd
> > > be
> > > better to do keep using git facilities for that and simply merge dev ->
> > > master
> > > when you're ready.
> > >
> > > Cos
> > >
> > > > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> > > akuznetsov@gridgain.com>
> > > > wrote:
> > > >
> > > > > One more. Could I use rebase in my branch if I already use merge on
> > > this
> > > > > branch before?
> > > > >
> > > > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> > > akuznetsov@gridgain.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I can start user rebase at any moment? Or I should wait for day X ?
> > > > > > Or we will start vote?
> > > > > >
> > > > > > Also what will happen if someone will do merge but other rebase?
> > > > > >
> > > > > > --
> > > > > > Alexey Kuznetsov
> > > > > > GridGain Systems
> > > > > > www.gridgain.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > Pavel Tupitsyn
> > > > GridGain Systems, Inc.
> > > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
You can use squash independent from merge. It is done via simple interactive
rebase and can be used at any time at one's convenience. However, it is
important to remember not to squash someone's else commits as it changes the
SHAs of the object.
I'd be happy to do a session for anyone who needs a bit of education around
these technologies, but I am fairly sure there's plenty of materials like that
on the net.
Cos
On Tue, Jul 28, 2015 at 08:34PM, Pavel Tupitsyn wrote:
> As said above, squash should be used when merging to master (git merge
> branchName --squash "Message"; there are checkboxes in Idea, too).
> This way there is a single commit with a meaningful message in master, and
> it does not matter what happened in the personal branch.
>
> I think this is the simplest workflow.
>
> Thanks,
>
> On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > > > I hope so, it'd be horrible to do that on master!
> > >
> > > Exactly!
> > > But I do not see much sense in enforcing any kind of policy in personal
> > > branches. Sometimes rebase may be better, sometimes I may want to use
> > merge
> > > so I see when and which changes came from master branch, etc.
> > > Only the implementer cares about the look of history in his branch, so it
> > > is up to him.
> >
> > You can do with your personal branch whatever you pleased with, of course.
> > However, if you make 112 intermediate commits while working on something,
> > there's no need to unleash it on everyone; also it is of little interest to
> > anyone to see how many times you merged from the master to your local
> > branch.
> >
> > In this respect, hygiene of the personal branches are of little concern to
> > anyone, until one starts contaminating the shared history. Does it make
> > sense?
> >
> > > > Also what will happen if someone will do merge but other rebase?
> > >
> > > Nothing will happen, we are talking about personal branches, they end up
> > > being removed. And resulting work is squashed into a patch.
> >
> > Actually, I didn't say anything on how the content of the change is
> > delivered
> > to the master. If you want to do it with patches - sure; but I think it'd
> > be
> > better to do keep using git facilities for that and simply merge dev ->
> > master
> > when you're ready.
> >
> > Cos
> >
> > > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com>
> > > wrote:
> > >
> > > > One more. Could I use rebase in my branch if I already use merge on
> > this
> > > > branch before?
> > > >
> > > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > I can start user rebase at any moment? Or I should wait for day X ?
> > > > > Or we will start vote?
> > > > >
> > > > > Also what will happen if someone will do merge but other rebase?
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
Re: Important: Git Policy Changed
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Tue, Jul 28, 2015 at 10:34 AM, Pavel Tupitsyn <pt...@gridgain.com>
wrote:
> As said above, squash should be used when merging to master (git merge
> branchName --squash "Message"; there are checkboxes in Idea, too).
> This way there is a single commit with a meaningful message in master,
> and it does not matter what happened in the personal branch.
>
Pavel, I am not a GIT expert, so bare with me :)
Will the commits that got merged from master be squashed too? In other
words, will the master commits be piled together with all the user-commits
in one uber-commit from that user?
>
> I think this is the simplest workflow.
>
> Thanks,
>
> On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > > > I hope so, it'd be horrible to do that on master!
> > >
> > > Exactly!
> > > But I do not see much sense in enforcing any kind of policy in personal
> > > branches. Sometimes rebase may be better, sometimes I may want to use
> > merge
> > > so I see when and which changes came from master branch, etc.
> > > Only the implementer cares about the look of history in his branch, so
> it
> > > is up to him.
> >
> > You can do with your personal branch whatever you pleased with, of
> course.
> > However, if you make 112 intermediate commits while working on something,
> > there's no need to unleash it on everyone; also it is of little interest
> to
> > anyone to see how many times you merged from the master to your local
> > branch.
> >
> > In this respect, hygiene of the personal branches are of little concern
> to
> > anyone, until one starts contaminating the shared history. Does it make
> > sense?
> >
> > > > Also what will happen if someone will do merge but other rebase?
> > >
> > > Nothing will happen, we are talking about personal branches, they end
> up
> > > being removed. And resulting work is squashed into a patch.
> >
> > Actually, I didn't say anything on how the content of the change is
> > delivered
> > to the master. If you want to do it with patches - sure; but I think it'd
> > be
> > better to do keep using git facilities for that and simply merge dev ->
> > master
> > when you're ready.
> >
> > Cos
> >
> > > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com>
> > > wrote:
> > >
> > > > One more. Could I use rebase in my branch if I already use merge on
> > this
> > > > branch before?
> > > >
> > > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > I can start user rebase at any moment? Or I should wait for day X ?
> > > > > Or we will start vote?
> > > > >
> > > > > Also what will happen if someone will do merge but other rebase?
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>
Re: Important: Git Policy Changed
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
As said above, squash should be used when merging to master (git merge
branchName --squash "Message"; there are checkboxes in Idea, too).
This way there is a single commit with a meaningful message in master, and
it does not matter what happened in the personal branch.
I think this is the simplest workflow.
Thanks,
On Tue, Jul 28, 2015 at 8:33 PM, Konstantin Boudnik <co...@apache.org> wrote:
> On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > > I hope so, it'd be horrible to do that on master!
> >
> > Exactly!
> > But I do not see much sense in enforcing any kind of policy in personal
> > branches. Sometimes rebase may be better, sometimes I may want to use
> merge
> > so I see when and which changes came from master branch, etc.
> > Only the implementer cares about the look of history in his branch, so it
> > is up to him.
>
> You can do with your personal branch whatever you pleased with, of course.
> However, if you make 112 intermediate commits while working on something,
> there's no need to unleash it on everyone; also it is of little interest to
> anyone to see how many times you merged from the master to your local
> branch.
>
> In this respect, hygiene of the personal branches are of little concern to
> anyone, until one starts contaminating the shared history. Does it make
> sense?
>
> > > Also what will happen if someone will do merge but other rebase?
> >
> > Nothing will happen, we are talking about personal branches, they end up
> > being removed. And resulting work is squashed into a patch.
>
> Actually, I didn't say anything on how the content of the change is
> delivered
> to the master. If you want to do it with patches - sure; but I think it'd
> be
> better to do keep using git facilities for that and simply merge dev ->
> master
> when you're ready.
>
> Cos
>
> > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com>
> > wrote:
> >
> > > One more. Could I use rebase in my branch if I already use merge on
> this
> > > branch before?
> > >
> > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com
> > > >
> > > wrote:
> > >
> > > > I can start user rebase at any moment? Or I should wait for day X ?
> > > > Or we will start vote?
> > > >
> > > > Also what will happen if someone will do merge but other rebase?
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Jul 28, 2015 at 01:33PM, Pavel Tupitsyn wrote:
> > I hope so, it'd be horrible to do that on master!
>
> Exactly!
> But I do not see much sense in enforcing any kind of policy in personal
> branches. Sometimes rebase may be better, sometimes I may want to use merge
> so I see when and which changes came from master branch, etc.
> Only the implementer cares about the look of history in his branch, so it
> is up to him.
You can do with your personal branch whatever you pleased with, of course.
However, if you make 112 intermediate commits while working on something,
there's no need to unleash it on everyone; also it is of little interest to
anyone to see how many times you merged from the master to your local branch.
In this respect, hygiene of the personal branches are of little concern to
anyone, until one starts contaminating the shared history. Does it make sense?
> > Also what will happen if someone will do merge but other rebase?
>
> Nothing will happen, we are talking about personal branches, they end up
> being removed. And resulting work is squashed into a patch.
Actually, I didn't say anything on how the content of the change is delivered
to the master. If you want to do it with patches - sure; but I think it'd be
better to do keep using git facilities for that and simply merge dev -> master
when you're ready.
Cos
> On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <ak...@gridgain.com>
> wrote:
>
> > One more. Could I use rebase in my branch if I already use merge on this
> > branch before?
> >
> > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> > >
> > wrote:
> >
> > > I can start user rebase at any moment? Or I should wait for day X ?
> > > Or we will start vote?
> > >
> > > Also what will happen if someone will do merge but other rebase?
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
Re: Important: Git Policy Changed
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
Alexey, we were talking about master->personal.
As for merging to master, there should be strictly one commit per feature.
This can be achieved in multiple ways (patch, merge/pull with squash). And
with squash, it does not matter how personal branch history looks.
On Tue, Jul 28, 2015 at 1:38 PM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:
> So we are going to work only with patches?
> No more merges from personal branches into master?
>
> On Tue, Jul 28, 2015 at 5:33 PM, Pavel Tupitsyn <pt...@gridgain.com>
> wrote:
>
> > > I hope so, it'd be horrible to do that on master!
> >
> > Exactly!
> > But I do not see much sense in enforcing any kind of policy in personal
> > branches. Sometimes rebase may be better, sometimes I may want to use
> merge
> > so I see when and which changes came from master branch, etc.
> > Only the implementer cares about the look of history in his branch, so it
> > is up to him.
> >
> > > Also what will happen if someone will do merge but other rebase?
> >
> > Nothing will happen, we are talking about personal branches, they end up
> > being removed. And resulting work is squashed into a patch.
> >
> > On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com
> > >
> > wrote:
> >
> > > One more. Could I use rebase in my branch if I already use merge on
> this
> > > branch before?
> > >
> > > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> > akuznetsov@gridgain.com
> > > >
> > > wrote:
> > >
> > > > I can start user rebase at any moment? Or I should wait for day X ?
> > > > Or we will start vote?
> > > >
> > > > Also what will happen if someone will do merge but other rebase?
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
So we are going to work only with patches?
No more merges from personal branches into master?
On Tue, Jul 28, 2015 at 5:33 PM, Pavel Tupitsyn <pt...@gridgain.com>
wrote:
> > I hope so, it'd be horrible to do that on master!
>
> Exactly!
> But I do not see much sense in enforcing any kind of policy in personal
> branches. Sometimes rebase may be better, sometimes I may want to use merge
> so I see when and which changes came from master branch, etc.
> Only the implementer cares about the look of history in his branch, so it
> is up to him.
>
> > Also what will happen if someone will do merge but other rebase?
>
> Nothing will happen, we are talking about personal branches, they end up
> being removed. And resulting work is squashed into a patch.
>
> On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > One more. Could I use rebase in my branch if I already use merge on this
> > branch before?
> >
> > On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com
> > >
> > wrote:
> >
> > > I can start user rebase at any moment? Or I should wait for day X ?
> > > Or we will start vote?
> > >
> > > Also what will happen if someone will do merge but other rebase?
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
> I hope so, it'd be horrible to do that on master!
Exactly!
But I do not see much sense in enforcing any kind of policy in personal
branches. Sometimes rebase may be better, sometimes I may want to use merge
so I see when and which changes came from master branch, etc.
Only the implementer cares about the look of history in his branch, so it
is up to him.
> Also what will happen if someone will do merge but other rebase?
Nothing will happen, we are talking about personal branches, they end up
being removed. And resulting work is squashed into a patch.
On Tue, Jul 28, 2015 at 1:29 PM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:
> One more. Could I use rebase in my branch if I already use merge on this
> branch before?
>
> On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > I can start user rebase at any moment? Or I should wait for day X ?
> > Or we will start vote?
> >
> > Also what will happen if someone will do merge but other rebase?
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
One more. Could I use rebase in my branch if I already use merge on this
branch before?
On Tue, Jul 28, 2015 at 5:28 PM, Alexey Kuznetsov <ak...@gridgain.com>
wrote:
> I can start user rebase at any moment? Or I should wait for day X ?
> Or we will start vote?
>
> Also what will happen if someone will do merge but other rebase?
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
I can start user rebase at any moment? Or I should wait for day X ?
Or we will start vote?
Also what will happen if someone will do merge but other rebase?
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Branko Čibej <br...@apache.org>.
On 28.07.2015 12:15, Pavel Tupitsyn wrote:
> Hi, I'm a bit confused, are we talking about merge vs rebase in a feature
> (personal) branches?
I hope so, it'd be horrible to do that on master!
-- Brane
Re: Important: Git Policy Changed
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
Hi, I'm a bit confused, are we talking about merge vs rebase in a feature
(personal) branches?
On Tue, Jul 28, 2015 at 12:49 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> This can be done from command line.
>
> I think here is a very good article on merge vs rebase -
> https://www.atlassian.com/git/tutorials/merging-vs-rebasing
>
> As for me, I think we should switch to rebase.
>
> --Yakov
>
> 2015-07-28 11:12 GMT+03:00 Alexey Kuznetsov <ak...@gridgain.com>:
>
> > I,m not a git ninja.
> >
> > And will be very pleased if some one add a screenshot to our wiki how to
> do
> > rebase from Idea UI.
> >
> > On Tue, Jul 28, 2015 at 3:06 PM, Atri Sharma <at...@gmail.com>
> wrote:
> >
> > > +1
> > >
> > > On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > I actually agree with Cos and think we can switch to "rebase" instead
> > of
> > > > "merge".
> > > >
> > > > Does anyone foresee any problems with this change?
> > > >
> > > > D.
> > > >
> > > > On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > wrote:
> > > >
> > > > > I would like to propose the following modification of the process,
> > > > offered
> > > > > in
> > > > > this page (and it would apply for the ppl working on their branches
> > > > > directly
> > > > > too). Namely:
> > > > >
> > > > > - replace
> > > > > % git merge master
> > > > > with
> > > > > % git rebase master
> > > > >
> > > > > which will allow to avoid empty and non-informative non-fast
> forward
> > > > > commits and also will help to maintain the clean history. You still
> > > need
> > > > to
> > > > > resolve the conflicts though, but most likely you won't have stuff
> > like
> > > > > this sitting around:
> > > > >
> > > > > | * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
> > > > > | |\ Merge: 0b25ec2 c044bb8
> > > > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > > > | | | Date: Wed Jul 22 15:49:04 2015 +0300
> > > > > | | |
> > > > > | | | Merge branch 'master' of
> > > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite
> > > > > | | |
> > > > > | * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
> > > > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > > > | | | Date: Wed Jul 22 15:48:36 2015 +0300
> > > > > | | |
> > > > > | | | muted failing discovery test
> > > > > | | |
> > > > > * | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
> > > > > |\ \ \ Merge: 5202527 c044bb8
> > > > > | | |/ Author: S.Vladykin <sv...@gridgain.com>
> > > > > | |/| Date: Wed Jul 22 15:11:38 2015 +0300
> > > > > | | |
> > > > > | | | Merge branches 'ignite-1015' and 'master' of
> > > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > > > ignite-1015
> > > > > | | |
> > > > > | * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
> > > > > | | | Author: S.Vladykin <sv...@gridgain.com>
> > > > > | | | Date: Wed Jul 22 15:10:29 2015 +0300
> > > > > | | |
> > > > > | | | master - disabled test. fix in ignite-959-z
> > > > > | | |
> > > > > * | | commit 52025271f3db6e764ab62d0483966159d004b42c
> > > > > |\ \ \ Merge: 301f573 8e1492a
> > > > > | |/ / Author: S.Vladykin <sv...@gridgain.com>
> > > > > | | | Date: Wed Jul 22 09:04:55 2015 +0300
> > > > > | | |
> > > > > | | | Merge branch 'master' of
> > > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > > > ignite-1015
> > > > >
> > > > > - squash the intermediate commits in your own branch, as they are
> > > adding
> > > > no
> > > > > value to anyone, but polluting the history and making potential
> > > reverts
> > > > > nearly impossible.
> > > > >
> > > > > With these two changes in the process the patch preparation scripts
> > > > (which
> > > > > I
> > > > > found to be overly complex) would be replaced with a single command
> > > > >
> > > > > % git format-patch HEAD~1 --stdout > JIRA-###.patch
> > > > >
> > > > > Would be happy to answer any questions, if needed.
> > > > > Cos
> > > > >
> > > > > On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> > > > > > The patch process is also described in "How to Contribute"
> section:
> > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > > >
> > > > > > I think it makes sense to update this page as well.
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> > > > > > alexey.goncharuk@gmail.com> wrote:
> > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Alexey, can you provide the link to the updated document? I
> > > cannot
> > > > > find
> > > > > > > it
> > > > > > > > on Wiki or website.
> > > > > > >
> > > > > > >
> > > > > > > It is the document about the sprint process:
> > > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > > >
> > > > > > > --AG
> > > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > *l'apprenant*
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Yakov Zhdanov <yz...@apache.org>.
This can be done from command line.
I think here is a very good article on merge vs rebase -
https://www.atlassian.com/git/tutorials/merging-vs-rebasing
As for me, I think we should switch to rebase.
--Yakov
2015-07-28 11:12 GMT+03:00 Alexey Kuznetsov <ak...@gridgain.com>:
> I,m not a git ninja.
>
> And will be very pleased if some one add a screenshot to our wiki how to do
> rebase from Idea UI.
>
> On Tue, Jul 28, 2015 at 3:06 PM, Atri Sharma <at...@gmail.com> wrote:
>
> > +1
> >
> > On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> > > I actually agree with Cos and think we can switch to "rebase" instead
> of
> > > "merge".
> > >
> > > Does anyone foresee any problems with this change?
> > >
> > > D.
> > >
> > > On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > >
> > > > I would like to propose the following modification of the process,
> > > offered
> > > > in
> > > > this page (and it would apply for the ppl working on their branches
> > > > directly
> > > > too). Namely:
> > > >
> > > > - replace
> > > > % git merge master
> > > > with
> > > > % git rebase master
> > > >
> > > > which will allow to avoid empty and non-informative non-fast forward
> > > > commits and also will help to maintain the clean history. You still
> > need
> > > to
> > > > resolve the conflicts though, but most likely you won't have stuff
> like
> > > > this sitting around:
> > > >
> > > > | * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
> > > > | |\ Merge: 0b25ec2 c044bb8
> > > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > > | | | Date: Wed Jul 22 15:49:04 2015 +0300
> > > > | | |
> > > > | | | Merge branch 'master' of
> > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite
> > > > | | |
> > > > | * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
> > > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > > | | | Date: Wed Jul 22 15:48:36 2015 +0300
> > > > | | |
> > > > | | | muted failing discovery test
> > > > | | |
> > > > * | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
> > > > |\ \ \ Merge: 5202527 c044bb8
> > > > | | |/ Author: S.Vladykin <sv...@gridgain.com>
> > > > | |/| Date: Wed Jul 22 15:11:38 2015 +0300
> > > > | | |
> > > > | | | Merge branches 'ignite-1015' and 'master' of
> > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > > ignite-1015
> > > > | | |
> > > > | * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
> > > > | | | Author: S.Vladykin <sv...@gridgain.com>
> > > > | | | Date: Wed Jul 22 15:10:29 2015 +0300
> > > > | | |
> > > > | | | master - disabled test. fix in ignite-959-z
> > > > | | |
> > > > * | | commit 52025271f3db6e764ab62d0483966159d004b42c
> > > > |\ \ \ Merge: 301f573 8e1492a
> > > > | |/ / Author: S.Vladykin <sv...@gridgain.com>
> > > > | | | Date: Wed Jul 22 09:04:55 2015 +0300
> > > > | | |
> > > > | | | Merge branch 'master' of
> > > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > > ignite-1015
> > > >
> > > > - squash the intermediate commits in your own branch, as they are
> > adding
> > > no
> > > > value to anyone, but polluting the history and making potential
> > reverts
> > > > nearly impossible.
> > > >
> > > > With these two changes in the process the patch preparation scripts
> > > (which
> > > > I
> > > > found to be overly complex) would be replaced with a single command
> > > >
> > > > % git format-patch HEAD~1 --stdout > JIRA-###.patch
> > > >
> > > > Would be happy to answer any questions, if needed.
> > > > Cos
> > > >
> > > > On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> > > > > The patch process is also described in "How to Contribute" section:
> > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > >
> > > > > I think it makes sense to update this page as well.
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> > > > > alexey.goncharuk@gmail.com> wrote:
> > > > >
> > > > > > >
> > > > > > >
> > > > > > > Alexey, can you provide the link to the updated document? I
> > cannot
> > > > find
> > > > > > it
> > > > > > > on Wiki or website.
> > > > > >
> > > > > >
> > > > > > It is the document about the sprint process:
> > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > >
> > > > > > --AG
> > > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Regards,
> >
> > Atri
> > *l'apprenant*
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>
Re: Important: Git Policy Changed
Posted by Alexey Kuznetsov <ak...@gridgain.com>.
I,m not a git ninja.
And will be very pleased if some one add a screenshot to our wiki how to do
rebase from Idea UI.
On Tue, Jul 28, 2015 at 3:06 PM, Atri Sharma <at...@gmail.com> wrote:
> +1
>
> On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > I actually agree with Cos and think we can switch to "rebase" instead of
> > "merge".
> >
> > Does anyone foresee any problems with this change?
> >
> > D.
> >
> > On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> >
> > > I would like to propose the following modification of the process,
> > offered
> > > in
> > > this page (and it would apply for the ppl working on their branches
> > > directly
> > > too). Namely:
> > >
> > > - replace
> > > % git merge master
> > > with
> > > % git rebase master
> > >
> > > which will allow to avoid empty and non-informative non-fast forward
> > > commits and also will help to maintain the clean history. You still
> need
> > to
> > > resolve the conflicts though, but most likely you won't have stuff like
> > > this sitting around:
> > >
> > > | * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
> > > | |\ Merge: 0b25ec2 c044bb8
> > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > | | | Date: Wed Jul 22 15:49:04 2015 +0300
> > > | | |
> > > | | | Merge branch 'master' of
> > > https://git-wip-us.apache.org/repos/asf/incubator-ignite
> > > | | |
> > > | * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
> > > | | | Author: Denis Magda <dm...@gridgain.com>
> > > | | | Date: Wed Jul 22 15:48:36 2015 +0300
> > > | | |
> > > | | | muted failing discovery test
> > > | | |
> > > * | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
> > > |\ \ \ Merge: 5202527 c044bb8
> > > | | |/ Author: S.Vladykin <sv...@gridgain.com>
> > > | |/| Date: Wed Jul 22 15:11:38 2015 +0300
> > > | | |
> > > | | | Merge branches 'ignite-1015' and 'master' of
> > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > ignite-1015
> > > | | |
> > > | * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
> > > | | | Author: S.Vladykin <sv...@gridgain.com>
> > > | | | Date: Wed Jul 22 15:10:29 2015 +0300
> > > | | |
> > > | | | master - disabled test. fix in ignite-959-z
> > > | | |
> > > * | | commit 52025271f3db6e764ab62d0483966159d004b42c
> > > |\ \ \ Merge: 301f573 8e1492a
> > > | |/ / Author: S.Vladykin <sv...@gridgain.com>
> > > | | | Date: Wed Jul 22 09:04:55 2015 +0300
> > > | | |
> > > | | | Merge branch 'master' of
> > > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> > ignite-1015
> > >
> > > - squash the intermediate commits in your own branch, as they are
> adding
> > no
> > > value to anyone, but polluting the history and making potential
> reverts
> > > nearly impossible.
> > >
> > > With these two changes in the process the patch preparation scripts
> > (which
> > > I
> > > found to be overly complex) would be replaced with a single command
> > >
> > > % git format-patch HEAD~1 --stdout > JIRA-###.patch
> > >
> > > Would be happy to answer any questions, if needed.
> > > Cos
> > >
> > > On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> > > > The patch process is also described in "How to Contribute" section:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > >
> > > > I think it makes sense to update this page as well.
> > > >
> > > > D.
> > > >
> > > > On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> > > > alexey.goncharuk@gmail.com> wrote:
> > > >
> > > > > >
> > > > > >
> > > > > > Alexey, can you provide the link to the updated document? I
> cannot
> > > find
> > > > > it
> > > > > > on Wiki or website.
> > > > >
> > > > >
> > > > > It is the document about the sprint process:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > >
> > > > > --AG
> > > > >
> > >
> >
>
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>
--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Atri Sharma <at...@gmail.com>.
+1
On Tue, Jul 28, 2015 at 1:35 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> I actually agree with Cos and think we can switch to "rebase" instead of
> "merge".
>
> Does anyone foresee any problems with this change?
>
> D.
>
> On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > I would like to propose the following modification of the process,
> offered
> > in
> > this page (and it would apply for the ppl working on their branches
> > directly
> > too). Namely:
> >
> > - replace
> > % git merge master
> > with
> > % git rebase master
> >
> > which will allow to avoid empty and non-informative non-fast forward
> > commits and also will help to maintain the clean history. You still need
> to
> > resolve the conflicts though, but most likely you won't have stuff like
> > this sitting around:
> >
> > | * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
> > | |\ Merge: 0b25ec2 c044bb8
> > | | | Author: Denis Magda <dm...@gridgain.com>
> > | | | Date: Wed Jul 22 15:49:04 2015 +0300
> > | | |
> > | | | Merge branch 'master' of
> > https://git-wip-us.apache.org/repos/asf/incubator-ignite
> > | | |
> > | * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
> > | | | Author: Denis Magda <dm...@gridgain.com>
> > | | | Date: Wed Jul 22 15:48:36 2015 +0300
> > | | |
> > | | | muted failing discovery test
> > | | |
> > * | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
> > |\ \ \ Merge: 5202527 c044bb8
> > | | |/ Author: S.Vladykin <sv...@gridgain.com>
> > | |/| Date: Wed Jul 22 15:11:38 2015 +0300
> > | | |
> > | | | Merge branches 'ignite-1015' and 'master' of
> > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> ignite-1015
> > | | |
> > | * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
> > | | | Author: S.Vladykin <sv...@gridgain.com>
> > | | | Date: Wed Jul 22 15:10:29 2015 +0300
> > | | |
> > | | | master - disabled test. fix in ignite-959-z
> > | | |
> > * | | commit 52025271f3db6e764ab62d0483966159d004b42c
> > |\ \ \ Merge: 301f573 8e1492a
> > | |/ / Author: S.Vladykin <sv...@gridgain.com>
> > | | | Date: Wed Jul 22 09:04:55 2015 +0300
> > | | |
> > | | | Merge branch 'master' of
> > https://git-wip-us.apache.org/repos/asf/incubator-ignite into
> ignite-1015
> >
> > - squash the intermediate commits in your own branch, as they are adding
> no
> > value to anyone, but polluting the history and making potential reverts
> > nearly impossible.
> >
> > With these two changes in the process the patch preparation scripts
> (which
> > I
> > found to be overly complex) would be replaced with a single command
> >
> > % git format-patch HEAD~1 --stdout > JIRA-###.patch
> >
> > Would be happy to answer any questions, if needed.
> > Cos
> >
> > On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> > > The patch process is also described in "How to Contribute" section:
> > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > >
> > > I think it makes sense to update this page as well.
> > >
> > > D.
> > >
> > > On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> > > alexey.goncharuk@gmail.com> wrote:
> > >
> > > > >
> > > > >
> > > > > Alexey, can you provide the link to the updated document? I cannot
> > find
> > > > it
> > > > > on Wiki or website.
> > > >
> > > >
> > > > It is the document about the sprint process:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > >
> > > > --AG
> > > >
> >
>
--
Regards,
Atri
*l'apprenant*
Re: Important: Git Policy Changed
Posted by Dmitriy Setrakyan <ds...@apache.org>.
I actually agree with Cos and think we can switch to "rebase" instead of
"merge".
Does anyone foresee any problems with this change?
D.
On Mon, Jul 27, 2015 at 2:01 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I would like to propose the following modification of the process, offered
> in
> this page (and it would apply for the ppl working on their branches
> directly
> too). Namely:
>
> - replace
> % git merge master
> with
> % git rebase master
>
> which will allow to avoid empty and non-informative non-fast forward
> commits and also will help to maintain the clean history. You still need to
> resolve the conflicts though, but most likely you won't have stuff like
> this sitting around:
>
> | * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
> | |\ Merge: 0b25ec2 c044bb8
> | | | Author: Denis Magda <dm...@gridgain.com>
> | | | Date: Wed Jul 22 15:49:04 2015 +0300
> | | |
> | | | Merge branch 'master' of
> https://git-wip-us.apache.org/repos/asf/incubator-ignite
> | | |
> | * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
> | | | Author: Denis Magda <dm...@gridgain.com>
> | | | Date: Wed Jul 22 15:48:36 2015 +0300
> | | |
> | | | muted failing discovery test
> | | |
> * | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
> |\ \ \ Merge: 5202527 c044bb8
> | | |/ Author: S.Vladykin <sv...@gridgain.com>
> | |/| Date: Wed Jul 22 15:11:38 2015 +0300
> | | |
> | | | Merge branches 'ignite-1015' and 'master' of
> https://git-wip-us.apache.org/repos/asf/incubator-ignite into ignite-1015
> | | |
> | * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
> | | | Author: S.Vladykin <sv...@gridgain.com>
> | | | Date: Wed Jul 22 15:10:29 2015 +0300
> | | |
> | | | master - disabled test. fix in ignite-959-z
> | | |
> * | | commit 52025271f3db6e764ab62d0483966159d004b42c
> |\ \ \ Merge: 301f573 8e1492a
> | |/ / Author: S.Vladykin <sv...@gridgain.com>
> | | | Date: Wed Jul 22 09:04:55 2015 +0300
> | | |
> | | | Merge branch 'master' of
> https://git-wip-us.apache.org/repos/asf/incubator-ignite into ignite-1015
>
> - squash the intermediate commits in your own branch, as they are adding no
> value to anyone, but polluting the history and making potential reverts
> nearly impossible.
>
> With these two changes in the process the patch preparation scripts (which
> I
> found to be overly complex) would be replaced with a single command
>
> % git format-patch HEAD~1 --stdout > JIRA-###.patch
>
> Would be happy to answer any questions, if needed.
> Cos
>
> On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> > The patch process is also described in "How to Contribute" section:
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> >
> > I think it makes sense to update this page as well.
> >
> > D.
> >
> > On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> > > >
> > > >
> > > > Alexey, can you provide the link to the updated document? I cannot
> find
> > > it
> > > > on Wiki or website.
> > >
> > >
> > > It is the document about the sprint process:
> > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > >
> > > --AG
> > >
>
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
I would like to propose the following modification of the process, offered in
this page (and it would apply for the ppl working on their branches directly
too). Namely:
- replace
% git merge master
with
% git rebase master
which will allow to avoid empty and non-informative non-fast forward commits
and also will help to maintain the clean history. You still need to resolve
the conflicts though, but most likely you won't have stuff like this sitting
around:
| * commit a57707f6ef387ea6f48fd878747e8c5044e7758e
| |\ Merge: 0b25ec2 c044bb8
| | | Author: Denis Magda <dm...@gridgain.com>
| | | Date: Wed Jul 22 15:49:04 2015 +0300
| | |
| | | Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/incubator-ignite
| | |
| * | commit 0b25ec2216f7d7c54f29cc9c4ca465c55ed8c0a1
| | | Author: Denis Magda <dm...@gridgain.com>
| | | Date: Wed Jul 22 15:48:36 2015 +0300
| | |
| | | muted failing discovery test
| | |
* | | commit 2e1dea945b486006214eaa8005a7d3b398c8f549
|\ \ \ Merge: 5202527 c044bb8
| | |/ Author: S.Vladykin <sv...@gridgain.com>
| |/| Date: Wed Jul 22 15:11:38 2015 +0300
| | |
| | | Merge branches 'ignite-1015' and 'master' of https://git-wip-us.apache.org/repos/asf/incubator-ignite into ignite-1015
| | |
| * | commit c044bb8278d724336d17fbc2dcd34b0957ac41ec
| | | Author: S.Vladykin <sv...@gridgain.com>
| | | Date: Wed Jul 22 15:10:29 2015 +0300
| | |
| | | master - disabled test. fix in ignite-959-z
| | |
* | | commit 52025271f3db6e764ab62d0483966159d004b42c
|\ \ \ Merge: 301f573 8e1492a
| |/ / Author: S.Vladykin <sv...@gridgain.com>
| | | Date: Wed Jul 22 09:04:55 2015 +0300
| | |
| | | Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/incubator-ignite into ignite-1015
- squash the intermediate commits in your own branch, as they are adding no
value to anyone, but polluting the history and making potential reverts
nearly impossible.
With these two changes in the process the patch preparation scripts (which I
found to be overly complex) would be replaced with a single command
% git format-patch HEAD~1 --stdout > JIRA-###.patch
Would be happy to answer any questions, if needed.
Cos
On Mon, Jul 27, 2015 at 10:38AM, Dmitriy Setrakyan wrote:
> The patch process is also described in "How to Contribute" section:
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> I think it makes sense to update this page as well.
>
> D.
>
> On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > >
> > >
> > > Alexey, can you provide the link to the updated document? I cannot find
> > it
> > > on Wiki or website.
> >
> >
> > It is the document about the sprint process:
> > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> >
> > --AG
> >
Re: Important: Git Policy Changed
Posted by Dmitriy Setrakyan <ds...@apache.org>.
The patch process is also described in "How to Contribute" section:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
I think it makes sense to update this page as well.
D.
On Mon, Jul 27, 2015 at 10:32 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> >
> >
> > Alexey, can you provide the link to the updated document? I cannot find
> it
> > on Wiki or website.
>
>
> It is the document about the sprint process:
> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
>
> --AG
>
Re: Important: Git Policy Changed
Posted by Alexey Goncharuk <al...@gmail.com>.
>
>
> Alexey, can you provide the link to the updated document? I cannot find it
> on Wiki or website.
It is the document about the sprint process:
https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
--AG
Re: Important: Git Policy Changed
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Wed, Jul 22, 2015 at 6:44 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> Folks,
>
> Kindly reminder: when committing a patch provided by a contributor, do not
> forget to specify --author tag with the commit in order to preserve the
> identity of the person created the patch, for example:
>
> git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in REST
> log command"
>
> I have updated the document accordingly.
>
Alexey, can you provide the link to the updated document? I cannot find it
on Wiki or website.
>
> Thanks!
> --Alexey
>
> 2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
>
> > Ok, I have fixed the CI on builds.apache.org - now they take master as
> > default.
> >
> > Cos
> >
> > On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> > > Yes, I am aware about this issue. However my account stopped working
> and
> > I
> > > need to take it to INFRA. Will take care about this in a day or two:
> > thanks
> > > for the reminder.
> > >
> > > If anyone feel like getting an account on the Apache CI and fixing the
> > build -
> > > please do so by all means!
> > >
> > > Cos
> > >
> > > On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > > > It looks like we forgot to change the nightly builds trigger. The
> > website
> > > > link
> > > >
> >
> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > > > points to the build based on sprint-2.
> > > >
> > > > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > Looks good - thanks for putting this together!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > > > Igniters,
> > > > > >
> > > > > > As it has been discussed, we are applying an updated Git policy
> > which
> > > > > > should be more flexible and transparent that we have now.
> > > > > >
> > > > > > Process is described here:
> > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > >
> > > > > > I would also put points here (taken from the page above)
> > > > > >
> > > > > > - Master should become the development branch for the next
> > release
> > > > > > (current sprint).
> > > > > > - Whenever current release (sprint) goes to QA, new branch
> > should be
> > > > > > created from master. This way master can be used to develop
> > > > > functionality
> > > > > > of the next release. All release fixes get merged to release
> > branch
> > > > > and
> > > > > > then to master.
> > > > > > - All individual ticket branches should be created off of the
> > master
> > > > > > branch (or release branch if one exists - in this case changes
> > get
> > > > > merged
> > > > > > to release branch and then to master branch).
> > > > > > - Git tag should be created for every release.
> > > > > > - All CI tests must pass before the merge of ticket branches
> to
> > the
> > > > > > master (or release) branch.
> > > > > >
> > > > > > ignite-sprint-7 branch will be removed soon.
> > > > > >
> > > > > > Please let me know if anyone has questions.
> > > > > >
> > > > > > --Yakov
> > > > >
> >
>
Re: Important: Git Policy Changed
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Jul 23, 2015 at 11:29 AM, Konstantin Boudnik <co...@apache.org> wrote:
> Besides simple diff/patch flow, there are two ways of prep'ing (and
> applying)
> a patch in git: 'git apply' and 'git am' the former won't preserve author's
> name even if it's presented. The latter will.
>
> What we found useful in Bigtop is to also add --signoff option to indicate
> who
> did the review/commit of the patch.
>
Very good point, I think we should do this too.
>
> Cos
>
> On Thu, Jul 23, 2015 at 02:51PM, Andrey Gura wrote:
> > Alexey,
> >
> > patch usually contains info about author except cases when patch is a
> just
> > diff.
> >
> > On Thu, Jul 23, 2015 at 4:44 AM, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> > > Folks,
> > >
> > > Kindly reminder: when committing a patch provided by a contributor, do
> not
> > > forget to specify --author tag with the commit in order to preserve the
> > > identity of the person created the patch, for example:
> > >
> > > git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in
> REST
> > > log command"
> > >
> > > I have updated the document accordingly.
> > >
> > > Thanks!
> > > --Alexey
> > >
> > > 2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > Ok, I have fixed the CI on builds.apache.org - now they take master
> as
> > > > default.
> > > >
> > > > Cos
> > > >
> > > > On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> > > > > Yes, I am aware about this issue. However my account stopped
> working
> > > and
> > > > I
> > > > > need to take it to INFRA. Will take care about this in a day or
> two:
> > > > thanks
> > > > > for the reminder.
> > > > >
> > > > > If anyone feel like getting an account on the Apache CI and fixing
> the
> > > > build -
> > > > > please do so by all means!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > > > > > It looks like we forgot to change the nightly builds trigger. The
> > > > website
> > > > > > link
> > > > > >
> > > >
> > >
> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > > > > > points to the build based on sprint-2.
> > > > > >
> > > > > > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > > > > >
> > > > > > > Looks good - thanks for putting this together!
> > > > > > >
> > > > > > > Cos
> > > > > > >
> > > > > > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > As it has been discussed, we are applying an updated Git
> policy
> > > > which
> > > > > > > > should be more flexible and transparent that we have now.
> > > > > > > >
> > > > > > > > Process is described here:
> > > > > > > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > > > >
> > > > > > > > I would also put points here (taken from the page above)
> > > > > > > >
> > > > > > > > - Master should become the development branch for the next
> > > > release
> > > > > > > > (current sprint).
> > > > > > > > - Whenever current release (sprint) goes to QA, new branch
> > > > should be
> > > > > > > > created from master. This way master can be used to
> develop
> > > > > > > functionality
> > > > > > > > of the next release. All release fixes get merged to
> release
> > > > branch
> > > > > > > and
> > > > > > > > then to master.
> > > > > > > > - All individual ticket branches should be created off of
> the
> > > > master
> > > > > > > > branch (or release branch if one exists - in this case
> changes
> > > > get
> > > > > > > merged
> > > > > > > > to release branch and then to master branch).
> > > > > > > > - Git tag should be created for every release.
> > > > > > > > - All CI tests must pass before the merge of ticket
> branches
> > > to
> > > > the
> > > > > > > > master (or release) branch.
> > > > > > > >
> > > > > > > > ignite-sprint-7 branch will be removed soon.
> > > > > > > >
> > > > > > > > Please let me know if anyone has questions.
> > > > > > > >
> > > > > > > > --Yakov
> > > > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Andrey Gura
> > GridGain Systems, Inc.
> > www.gridgain.com
>
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
Besides simple diff/patch flow, there are two ways of prep'ing (and applying)
a patch in git: 'git apply' and 'git am' the former won't preserve author's
name even if it's presented. The latter will.
What we found useful in Bigtop is to also add --signoff option to indicate who
did the review/commit of the patch.
Cos
On Thu, Jul 23, 2015 at 02:51PM, Andrey Gura wrote:
> Alexey,
>
> patch usually contains info about author except cases when patch is a just
> diff.
>
> On Thu, Jul 23, 2015 at 4:44 AM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Folks,
> >
> > Kindly reminder: when committing a patch provided by a contributor, do not
> > forget to specify --author tag with the commit in order to preserve the
> > identity of the person created the patch, for example:
> >
> > git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in REST
> > log command"
> >
> > I have updated the document accordingly.
> >
> > Thanks!
> > --Alexey
> >
> > 2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > Ok, I have fixed the CI on builds.apache.org - now they take master as
> > > default.
> > >
> > > Cos
> > >
> > > On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> > > > Yes, I am aware about this issue. However my account stopped working
> > and
> > > I
> > > > need to take it to INFRA. Will take care about this in a day or two:
> > > thanks
> > > > for the reminder.
> > > >
> > > > If anyone feel like getting an account on the Apache CI and fixing the
> > > build -
> > > > please do so by all means!
> > > >
> > > > Cos
> > > >
> > > > On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > > > > It looks like we forgot to change the nightly builds trigger. The
> > > website
> > > > > link
> > > > >
> > >
> > https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > > > > points to the build based on sprint-2.
> > > > >
> > > > > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > > > >
> > > > > > Looks good - thanks for putting this together!
> > > > > >
> > > > > > Cos
> > > > > >
> > > > > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > > > > Igniters,
> > > > > > >
> > > > > > > As it has been discussed, we are applying an updated Git policy
> > > which
> > > > > > > should be more flexible and transparent that we have now.
> > > > > > >
> > > > > > > Process is described here:
> > > > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > > >
> > > > > > > I would also put points here (taken from the page above)
> > > > > > >
> > > > > > > - Master should become the development branch for the next
> > > release
> > > > > > > (current sprint).
> > > > > > > - Whenever current release (sprint) goes to QA, new branch
> > > should be
> > > > > > > created from master. This way master can be used to develop
> > > > > > functionality
> > > > > > > of the next release. All release fixes get merged to release
> > > branch
> > > > > > and
> > > > > > > then to master.
> > > > > > > - All individual ticket branches should be created off of the
> > > master
> > > > > > > branch (or release branch if one exists - in this case changes
> > > get
> > > > > > merged
> > > > > > > to release branch and then to master branch).
> > > > > > > - Git tag should be created for every release.
> > > > > > > - All CI tests must pass before the merge of ticket branches
> > to
> > > the
> > > > > > > master (or release) branch.
> > > > > > >
> > > > > > > ignite-sprint-7 branch will be removed soon.
> > > > > > >
> > > > > > > Please let me know if anyone has questions.
> > > > > > >
> > > > > > > --Yakov
> > > > > >
> > >
> >
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
Re: Important: Git Policy Changed
Posted by Andrey Gura <ag...@gridgain.com>.
Alexey,
patch usually contains info about author except cases when patch is a just
diff.
On Thu, Jul 23, 2015 at 4:44 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> Folks,
>
> Kindly reminder: when committing a patch provided by a contributor, do not
> forget to specify --author tag with the commit in order to preserve the
> identity of the person created the patch, for example:
>
> git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in REST
> log command"
>
> I have updated the document accordingly.
>
> Thanks!
> --Alexey
>
> 2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
>
> > Ok, I have fixed the CI on builds.apache.org - now they take master as
> > default.
> >
> > Cos
> >
> > On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> > > Yes, I am aware about this issue. However my account stopped working
> and
> > I
> > > need to take it to INFRA. Will take care about this in a day or two:
> > thanks
> > > for the reminder.
> > >
> > > If anyone feel like getting an account on the Apache CI and fixing the
> > build -
> > > please do so by all means!
> > >
> > > Cos
> > >
> > > On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > > > It looks like we forgot to change the nightly builds trigger. The
> > website
> > > > link
> > > >
> >
> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > > > points to the build based on sprint-2.
> > > >
> > > > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > > >
> > > > > Looks good - thanks for putting this together!
> > > > >
> > > > > Cos
> > > > >
> > > > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > > > Igniters,
> > > > > >
> > > > > > As it has been discussed, we are applying an updated Git policy
> > which
> > > > > > should be more flexible and transparent that we have now.
> > > > > >
> > > > > > Process is described here:
> > > > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > > >
> > > > > > I would also put points here (taken from the page above)
> > > > > >
> > > > > > - Master should become the development branch for the next
> > release
> > > > > > (current sprint).
> > > > > > - Whenever current release (sprint) goes to QA, new branch
> > should be
> > > > > > created from master. This way master can be used to develop
> > > > > functionality
> > > > > > of the next release. All release fixes get merged to release
> > branch
> > > > > and
> > > > > > then to master.
> > > > > > - All individual ticket branches should be created off of the
> > master
> > > > > > branch (or release branch if one exists - in this case changes
> > get
> > > > > merged
> > > > > > to release branch and then to master branch).
> > > > > > - Git tag should be created for every release.
> > > > > > - All CI tests must pass before the merge of ticket branches
> to
> > the
> > > > > > master (or release) branch.
> > > > > >
> > > > > > ignite-sprint-7 branch will be removed soon.
> > > > > >
> > > > > > Please let me know if anyone has questions.
> > > > > >
> > > > > > --Yakov
> > > > >
> >
>
--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com
Re: Important: Git Policy Changed
Posted by Alexey Goncharuk <al...@gmail.com>.
Folks,
Kindly reminder: when committing a patch provided by a contributor, do not
forget to specify --author tag with the commit in order to preserve the
identity of the person created the patch, for example:
git commit --author "Kale Libby <ka...@hackers.org>" -m "Fixed NPE in REST
log command"
I have updated the document accordingly.
Thanks!
--Alexey
2015-07-13 11:45 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> Ok, I have fixed the CI on builds.apache.org - now they take master as
> default.
>
> Cos
>
> On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> > Yes, I am aware about this issue. However my account stopped working and
> I
> > need to take it to INFRA. Will take care about this in a day or two:
> thanks
> > for the reminder.
> >
> > If anyone feel like getting an account on the Apache CI and fixing the
> build -
> > please do so by all means!
> >
> > Cos
> >
> > On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > > It looks like we forgot to change the nightly builds trigger. The
> website
> > > link
> > >
> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > > points to the build based on sprint-2.
> > >
> > > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> > >
> > > > Looks good - thanks for putting this together!
> > > >
> > > > Cos
> > > >
> > > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > > Igniters,
> > > > >
> > > > > As it has been discussed, we are applying an updated Git policy
> which
> > > > > should be more flexible and transparent that we have now.
> > > > >
> > > > > Process is described here:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > > >
> > > > > I would also put points here (taken from the page above)
> > > > >
> > > > > - Master should become the development branch for the next
> release
> > > > > (current sprint).
> > > > > - Whenever current release (sprint) goes to QA, new branch
> should be
> > > > > created from master. This way master can be used to develop
> > > > functionality
> > > > > of the next release. All release fixes get merged to release
> branch
> > > > and
> > > > > then to master.
> > > > > - All individual ticket branches should be created off of the
> master
> > > > > branch (or release branch if one exists - in this case changes
> get
> > > > merged
> > > > > to release branch and then to master branch).
> > > > > - Git tag should be created for every release.
> > > > > - All CI tests must pass before the merge of ticket branches to
> the
> > > > > master (or release) branch.
> > > > >
> > > > > ignite-sprint-7 branch will be removed soon.
> > > > >
> > > > > Please let me know if anyone has questions.
> > > > >
> > > > > --Yakov
> > > >
>
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
Ok, I have fixed the CI on builds.apache.org - now they take master as
default.
Cos
On Thu, Jul 09, 2015 at 01:00PM, Konstantin Boudnik wrote:
> Yes, I am aware about this issue. However my account stopped working and I
> need to take it to INFRA. Will take care about this in a day or two: thanks
> for the reminder.
>
> If anyone feel like getting an account on the Apache CI and fixing the build -
> please do so by all means!
>
> Cos
>
> On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> > It looks like we forgot to change the nightly builds trigger. The website
> > link
> > https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> > points to the build based on sprint-2.
> >
> > 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > Looks good - thanks for putting this together!
> > >
> > > Cos
> > >
> > > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > > Igniters,
> > > >
> > > > As it has been discussed, we are applying an updated Git policy which
> > > > should be more flexible and transparent that we have now.
> > > >
> > > > Process is described here:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > > >
> > > > I would also put points here (taken from the page above)
> > > >
> > > > - Master should become the development branch for the next release
> > > > (current sprint).
> > > > - Whenever current release (sprint) goes to QA, new branch should be
> > > > created from master. This way master can be used to develop
> > > functionality
> > > > of the next release. All release fixes get merged to release branch
> > > and
> > > > then to master.
> > > > - All individual ticket branches should be created off of the master
> > > > branch (or release branch if one exists - in this case changes get
> > > merged
> > > > to release branch and then to master branch).
> > > > - Git tag should be created for every release.
> > > > - All CI tests must pass before the merge of ticket branches to the
> > > > master (or release) branch.
> > > >
> > > > ignite-sprint-7 branch will be removed soon.
> > > >
> > > > Please let me know if anyone has questions.
> > > >
> > > > --Yakov
> > >
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
Yes, I am aware about this issue. However my account stopped working and I
need to take it to INFRA. Will take care about this in a day or two: thanks
for the reminder.
If anyone feel like getting an account on the Apache CI and fixing the build -
please do so by all means!
Cos
On Thu, Jul 09, 2015 at 12:31PM, Alexey Goncharuk wrote:
> It looks like we forgot to change the nightly builds trigger. The website
> link
> https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
> points to the build based on sprint-2.
>
> 2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
>
> > Looks good - thanks for putting this together!
> >
> > Cos
> >
> > On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > > Igniters,
> > >
> > > As it has been discussed, we are applying an updated Git policy which
> > > should be more flexible and transparent that we have now.
> > >
> > > Process is described here:
> > > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> > >
> > > I would also put points here (taken from the page above)
> > >
> > > - Master should become the development branch for the next release
> > > (current sprint).
> > > - Whenever current release (sprint) goes to QA, new branch should be
> > > created from master. This way master can be used to develop
> > functionality
> > > of the next release. All release fixes get merged to release branch
> > and
> > > then to master.
> > > - All individual ticket branches should be created off of the master
> > > branch (or release branch if one exists - in this case changes get
> > merged
> > > to release branch and then to master branch).
> > > - Git tag should be created for every release.
> > > - All CI tests must pass before the merge of ticket branches to the
> > > master (or release) branch.
> > >
> > > ignite-sprint-7 branch will be removed soon.
> > >
> > > Please let me know if anyone has questions.
> > >
> > > --Yakov
> >
Re: Important: Git Policy Changed
Posted by Alexey Goncharuk <al...@gmail.com>.
It looks like we forgot to change the nightly builds trigger. The website
link
https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
points to the build based on sprint-2.
2015-07-06 12:00 GMT-07:00 Konstantin Boudnik <co...@apache.org>:
> Looks good - thanks for putting this together!
>
> Cos
>
> On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> > Igniters,
> >
> > As it has been discussed, we are applying an updated Git policy which
> > should be more flexible and transparent that we have now.
> >
> > Process is described here:
> > https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
> >
> > I would also put points here (taken from the page above)
> >
> > - Master should become the development branch for the next release
> > (current sprint).
> > - Whenever current release (sprint) goes to QA, new branch should be
> > created from master. This way master can be used to develop
> functionality
> > of the next release. All release fixes get merged to release branch
> and
> > then to master.
> > - All individual ticket branches should be created off of the master
> > branch (or release branch if one exists - in this case changes get
> merged
> > to release branch and then to master branch).
> > - Git tag should be created for every release.
> > - All CI tests must pass before the merge of ticket branches to the
> > master (or release) branch.
> >
> > ignite-sprint-7 branch will be removed soon.
> >
> > Please let me know if anyone has questions.
> >
> > --Yakov
>
Re: Important: Git Policy Changed
Posted by Konstantin Boudnik <co...@apache.org>.
Looks good - thanks for putting this together!
Cos
On Mon, Jul 06, 2015 at 06:11PM, Yakov Zhdanov wrote:
> Igniters,
>
> As it has been discussed, we are applying an updated Git policy which
> should be more flexible and transparent that we have now.
>
> Process is described here:
> https://cwiki.apache.org/confluence/display/IGNITE/Sprint+Process
>
> I would also put points here (taken from the page above)
>
> - Master should become the development branch for the next release
> (current sprint).
> - Whenever current release (sprint) goes to QA, new branch should be
> created from master. This way master can be used to develop functionality
> of the next release. All release fixes get merged to release branch and
> then to master.
> - All individual ticket branches should be created off of the master
> branch (or release branch if one exists - in this case changes get merged
> to release branch and then to master branch).
> - Git tag should be created for every release.
> - All CI tests must pass before the merge of ticket branches to the
> master (or release) branch.
>
> ignite-sprint-7 branch will be removed soon.
>
> Please let me know if anyone has questions.
>
> --Yakov