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
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
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,
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
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
-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
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
-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
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
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
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
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
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
|
*
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
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
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
> 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.
>>>
.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
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
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
>
>
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
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
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
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
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
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:
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
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
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
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
30 matches
Mail list logo
