ll just create 2 issues so we have a way of keeping
> track
> >> of them.
> >>>>
> >>>> Cheers,
> >>>> Wilder
> >>>>
> >>>>
> >>>> On 18 May 2015, at 11:16, Stephen Turner >> <mailto:st
like that we would
>> have an improvement ticket, pointing to the wiki page.
>>>>
>>>> By the way, this also allows us to schedule the work on our sprint, but
>> we had the policy even before we were doing Scrum. In a large, distributed,
>> volunteer orga
vement ticket, pointing to the wiki page.
> >>
> >> By the way, this also allows us to schedule the work on our sprint, but
> we had the policy even before we were doing Scrum. In a large, distributed,
> volunteer organisation, I would argue that it's even more i
t; > have
> > > > an improvement ticket, pointing to the wiki page.
> > > >
> > > > By the way, this also allows us to schedule the work on our sprint,
> but
> > > we
> > > > had the policy even before we were doing Scrum. In a large,
> > distributed,
&g
important to be
>> able to trace the change back to its reason, now and later.
>>
>> --
>> Stephen Turner
>>
>>
>> -Original Message-
>> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
>> Sent: 18 May 2015 10:11
>> To:
o
> be
> > > able to trace the change back to its reason, now and later.
> > >
> > > --
> > > Stephen Turner
> > >
> > >
> > > -Original Message-
> > > From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> > &g
ws us to schedule the work on our sprint, but
> >> we
> >>> had the policy even before we were doing Scrum. In a large,
> distributed,
> >>> volunteer organisation, I would argue that it's even more important to
> be
> >>> able to trace the change back
gt;>> had the policy even before we were doing Scrum. In a large, distributed,
>>> volunteer organisation, I would argue that it's even more important to be
>>> able to trace the change back to its reason, now and later.
>>>
>>> --
>>> Stephen
ow and later.
> >
> > --
> > Stephen Turner
> >
> >
> > -Original Message-
> > From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> > Sent: 18 May 2015 10:11
> > To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org&g
uld argue that it's even more important to be
> able to trace the change back to its reason, now and later.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> Sent: 18 May 2015 10:11
> To: dev@c
d later.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com]
> Sent: 18 May 2015 10:11
> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
> Subject: Re: Preparing for 4.6
>
>
can also
contain screenshots of the error, discussion with other developers, etc.
--
Stephen Turner
-Original Message-
From: Rene Moser [mailto:m...@renemoser.net]
Sent: 18 May 2015 10:13
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6
Hi Stephan
On 18.05.2015 10:39
.apache.org<mailto:dev@cloudstack.apache.org>
Subject: Re: Preparing for 4.6
Hi there,
I agree with the Jira ticket for the "new features, important fixes, security
fixes"
But I don’t think only about "new features, important fixes, security fixes”. I
put most of my time in make
> On 18-May-2015, at 2:02 pm, Erik Weber wrote:
>
> On Mon, May 18, 2015 at 10:26 AM, Rene Moser wrote:
>
>> Hi
>>
>> On 15.05.2015 11:27, Sebastien Goasguen wrote:
>>> Folks,
>>>
>>> As we prepare to try a new process for 4.6 release it would be nice to
>> start paying attention to master.
>>>
ik Weber [mailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6
On Mon, May 18, 2015 at 10:26 AM, Rene Moser
mailto:m...@renemoser.net>> wrote:
Hi
On 15.05.2015 11:27, Sebastien Goasguen wrote:
Folks,
As we prepare to try a new process for 4.6 release i
Hi Stephan
On 18.05.2015 10:39, Stephen Turner wrote:
> In my XenCenter dev team at Citrix, we have the policy of requiring a ticket
> number on every commit. If we find a bug and there isn't already a ticket, we
> create a ticket before committing the fix. I guess I've just dug through
> histo
ailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6
On Mon, May 18, 2015 at 10:26 AM, Rene Moser
mailto:m...@renemoser.net>> wrote:
Hi
On 15.05.2015 11:27, Sebastien Goasguen wrote:
Folks,
As we prepare to try a new process for 4.6 release it would
That is a problem with linear history while its not actually linear.
If you look at the DAG, its reflects the actual
$ git log --graph --pretty=short
* commit 256e227cd5be63186a989e2c99ded0da5e7dea71
| Author: Rohit Yadav
|
| schema: fix foreign key checks for 3.0.7 to 4.1.0 upgrade path
|
*
at appears wrong was done,
only to find an inadequate description at the end of the trail.
--
Stephen Turner
-Original Message-
From: Erik Weber [mailto:terbol...@gmail.com]
Sent: 18 May 2015 09:32
To: dev
Subject: Re: Preparing for 4.6
On Mon, May 18, 2015 at 10:26 AM, Rene Moser wr
On Mon, May 18, 2015 at 10:26 AM, Rene Moser wrote:
> Hi
>
> On 15.05.2015 11:27, Sebastien Goasguen wrote:
> > Folks,
> >
> > As we prepare to try a new process for 4.6 release it would be nice to
> start paying attention to master.
> >
> > - Good commit messages
>
> The question is, what makes
Hi
On 15.05.2015 11:27, Sebastien Goasguen wrote:
> Folks,
>
> As we prepare to try a new process for 4.6 release it would be nice to start
> paying attention to master.
>
> - Good commit messages
The question is, what makes a commit message good? Maybe this helps:
http://chris.beams.io/posts
hink you get the best of
> both worlds that way.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Rajani Karuturi [mailto:raj...@apache.org]
> Sent: 16 May 2015 03:38
> To: dev@cloudstack.apache.org
> Subject: Re: Preparing for 4.6
>
> -1 for
-Original Message-
From: Rajani Karuturi [mailto:raj...@apache.org]
Sent: 16 May 2015 03:38
To: dev@cloudstack.apache.org
Subject: Re: Preparing for 4.6
-1 for squashed commits. I agree to what Daan said. Feature branch merge is
more convenient than squashed single commit.
If it was a smal
So I was looking at the libvirt commit from wilder:
https://github.com/apache/cloudstack/commits/master?page=2
is that what we want ?
> On May 16, 2015, at 4:37 AM, Rajani Karuturi wrote:
>
> -1 for squashed commits. I agree to what Daan said. Feature branch merge is
> more convenient than sq
-1 for squashed commits. I agree to what Daan said. Feature branch merge is
more convenient than squashed single commit.
If it was a small feature which involved single dev squashing is still ok.
But, a big no when it comes to big feature/refactoring involving effort
from multiple people and multip
Those comments may or may not be useful anymore. What they describe may
have been superseded by a subsequent commit.
On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland
wrote:
> those comments will then have to be squashed s well, to this i put a -1. If
> those comments where usefull at review-time t
those comments will then have to be squashed s well, to this i put a -1. If
those comments where usefull at review-time they will be usefull in the
future as well.
Op vr 15 mei 2015 om 19:29 schreef Marcus :
> I'm not sure it is any different. Either you have a giant block of code
> that represen
I'm not sure it is any different. Either you have a giant block of code
that represents a bunch of little commits, or a giant block that is one
commit. We don't want to merge little chunks to master that don't fully
implement the feature.
To the extent that features and goals can be split up, yes,
Sebastien, I don't think commits in a big feature should be squashed. It
hinders review if to big chunks are submitted at once.
Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen :
> Folks,
>
> As we prepare to try a new process for 4.6 release it would be nice to
> start paying attention to m
Folks,
As we prepare to try a new process for 4.6 release it would be nice to start
paying attention to master.
- Good commit messages
- Reference to a JIRA bug
- Squashing commits ( cc/ wilder :))
While you can apply patches directly, good practice is to apply the patch to a
branch and then m
30 matches
Mail list logo
