Integrating early and often

[Alan Conway <ac...@redhat.com>]

I said this in a mail regarding some porting work, but I think it's of more 
general relevance to committers at large. I'm a fan of integrating small, 
incremental changes as early as possible rather than waiting till everything is 
complete because

  - it's easier to localize problems in small changes.
  - the earlier a change is committed the more it gets tested.
  - it tends to reduce the probability and scope of conflicts.
  - it tends to reduce the scale of "oh crap I forgot about THAT" mistakes by 
identifying some problems early

Basically, if you have a patch that does something useful, adds tests for new 
functionalit and doesn't break anything else, IMO it's ready to commit. I find 
it's usually worth the trouble to break big tasks into small incremental changes.

I understand that some jobs (e.g. porting work) are harder to break down this 
way and it may not suit everybody's style, so I'm not telling anybody what to 
do. I'm just saying if ever the thought "maybe I could commit this bit 
separately" crosses your mind, I'm rooting for it.

Cheers,
Alan.

Re: Integrating early and often

[Aidan Skinner <ai...@apache.org>]

On Thu, Jun 12, 2008 at 12:25 PM, Manuel Teira <mt...@tid.es> wrote:

> No I don't. I'm afraid I will have to talk with my employer to do such a
> thing. Since I'm an invididual, working for a company, involved in a project
> that will eventually make use of qpid, who should be actually signing the
> ICLA?

You should sign the ICLA, but if you're working on this as part of
your day job it's probably worth getting your employer to file a CCLA
as well if they're willing too.

- Aidan
-- 
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

Re: Integrating early and often

[Manuel Teira <mt...@tid.es>]

Steve Huston escribió:
>> -----Original Message-----
>> From: aidan.skinner@gmail.com
>>
>> On Wed, Jun 11, 2008 at 10:44 AM, Martin Ritchie
>> <ri...@apache.org> wrote:
>>
>>     
>>> I'm all for the git repo. (just wish we had a full repo
>>>       
>> including the
>>     
>>> branches so we can do easy merging :)) but at this point
>>>       
>> I'd still be
>>     
>>> looking for patches on JIRAs rather than pushing directly from
>>>       
> git.
>   
>>> Though I'm sure the svn commit log isn't necessarily going
>>>       
>> to identify
>>     
>>> the commit as coming from the git repo.
>>>       
>> Sorry if I wasn't clear, this (patches from non-comitters coming in
>> through Jira) is what I would expect too. The git repo is basically
>>     
> a
>   
>> staging area and integration point before we persue the normal
>>     
> process
>   
>> for landing patches, and shouldn't be used to circumvent normal
>> procedure.
>>     
>
> Right, and what I think I heard on this sequence was a concern I
> raised before setting up the git repo that git is wide open and may
> pose an issue for someone wedging in a change that gets taken up in a
> patch. That concern is somewhat allayed by the fact that I have to add
> collaborators to git in order for them to change files in the
> repository. As long as I make sure everyone who asks to be a
> collaborator has an ICLA, things should be good.
>
> Of course, I don't have an ICLA yet... But it's in the mail.
>
> Manuel and Danushka are the other two people who can commit to the git
> repo. Manuel, Danushka - do you have ICLAs? Are you submitting one?
>   
No I don't. I'm afraid I will have to talk with my employer to do such a 
thing. Since I'm an invididual, working for a company, involved in a 
project that will eventually make use of qpid, who should be actually 
signing the ICLA?

Even in this situation, I don't see that having a git repository where 
somebody (without ICLA) could commit a change that later could be 
included unexpectly in a patch to the JIRA itself, makes a difference. 
When you submit a patch directly to JIRA, you are the only person that 
knows where the change comes from, and it could be also adding some non 
ICLA agreed stuff.

> -Steve
>
>
> .
>
>   

RE: Integrating early and often

[Steve Huston <sh...@riverace.com>]

> -----Original Message-----
> From: aidan.skinner@gmail.com 
> 
> On Wed, Jun 11, 2008 at 10:44 AM, Martin Ritchie 
> <ri...@apache.org> wrote:
> 
> > I'm all for the git repo. (just wish we had a full repo 
> including the
> > branches so we can do easy merging :)) but at this point 
> I'd still be
> > looking for patches on JIRAs rather than pushing directly from
git.
> > Though I'm sure the svn commit log isn't necessarily going 
> to identify
> > the commit as coming from the git repo.
> 
> Sorry if I wasn't clear, this (patches from non-comitters coming in
> through Jira) is what I would expect too. The git repo is basically
a
> staging area and integration point before we persue the normal
process
> for landing patches, and shouldn't be used to circumvent normal
> procedure.

Right, and what I think I heard on this sequence was a concern I
raised before setting up the git repo that git is wide open and may
pose an issue for someone wedging in a change that gets taken up in a
patch. That concern is somewhat allayed by the fact that I have to add
collaborators to git in order for them to change files in the
repository. As long as I make sure everyone who asks to be a
collaborator has an ICLA, things should be good.

Of course, I don't have an ICLA yet... But it's in the mail.

Manuel and Danushka are the other two people who can commit to the git
repo. Manuel, Danushka - do you have ICLAs? Are you submitting one?

-Steve

Re: Integrating early and often

[Aidan Skinner <ai...@apache.org>]

On Wed, Jun 11, 2008 at 10:44 AM, Martin Ritchie <ri...@apache.org> wrote:

> I'm all for the git repo. (just wish we had a full repo including the
> branches so we can do easy merging :)) but at this point I'd still be
> looking for patches on JIRAs rather than pushing directly from git.
> Though I'm sure the svn commit log isn't necessarily going to identify
> the commit as coming from the git repo.

Sorry if I wasn't clear, this (patches from non-comitters coming in
through Jira) is what I would expect too. The git repo is basically a
staging area and integration point before we persue the normal process
for landing patches, and shouldn't be used to circumvent normal
procedure.

- Aidan

-- 
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

Re: Integrating early and often

[Martin Ritchie <ri...@apache.org>]

2008/6/11 Aidan Skinner <ai...@apache.org>:
> On Wed, Jun 11, 2008 at 8:48 AM, Martin Ritchie <ri...@apache.org> wrote:
>
>> git-port repository. We do need to make absolutely sure that all code
>> coming from is either brought in via JIRA attached patches or we try
>> and ensure all the commiters there have a signed ICLA. It is great
>
> I don't see why the git repo makes a difference here, you'd need a
> commit bit to push to svn anyway (and we would have done the ICLA/CCLA
> stuff there) or patches would need to be comitted having come through
> during Jira. The git repo is, from a copyright PoV, a fork outside the
> ASF.
>
> If people are going to be contributing large chunks of code, it's
> worth getting an ICLA on file for them no matter what route into
> svn.apache.org they take.

IANAL, but I would have thought just pushing changes from the git repo
in to svn where the licensing of the code their is unclear could be a
problem. The fact that the person that pushes it into svn has an ICLA
is not enough. I'd see it like applying a patch from a jira that
hasn't had the ASL granted to on the patch.

Without everyone with commit bits on the git repo having an ICLA I'm
not sure I'd be comfortable with a push to svn directly. Having the
ICLA may not even be enough to grant the ASL on the code.

I'm all for the git repo. (just wish we had a full repo including the
branches so we can do easy merging :)) but at this point I'd still be
looking for patches on JIRAs rather than pushing directly from git.
Though I'm sure the svn commit log isn't necessarily going to identify
the commit as coming from the git repo.

I'd suggest perhaps a quick email to legal-discuss might be in order
just to clear things up.

Regards
Martin

> - Aidan
> --
> aim/y!:aidans42 g:aidan.skinner@gmail.com
> http://aidan.skinner.me.uk/
> "We belong to nobody and nobody belongs to us. We don't even belong to
> each other."
>



-- 
Martin Ritchie

Re: Integrating early and often

[Aidan Skinner <ai...@apache.org>]

On Wed, Jun 11, 2008 at 8:48 AM, Martin Ritchie <ri...@apache.org> wrote:

> git-port repository. We do need to make absolutely sure that all code
> coming from is either brought in via JIRA attached patches or we try
> and ensure all the commiters there have a signed ICLA. It is great

I don't see why the git repo makes a difference here, you'd need a
commit bit to push to svn anyway (and we would have done the ICLA/CCLA
stuff there) or patches would need to be comitted having come through
during Jira. The git repo is, from a copyright PoV, a fork outside the
ASF.

If people are going to be contributing large chunks of code, it's
worth getting an ICLA on file for them no matter what route into
svn.apache.org they take.

- Aidan
-- 
aim/y!:aidans42 g:aidan.skinner@gmail.com
http://aidan.skinner.me.uk/
"We belong to nobody and nobody belongs to us. We don't even belong to
each other."

Re: Integrating early and often

[Martin Ritchie <ri...@apache.org>]

2008/6/10 Alan Conway <ac...@redhat.com>:
> I said this in a mail regarding some porting work, but I think it's of more
> general relevance to committers at large. I'm a fan of integrating small,
> incremental changes as early as possible rather than waiting till everything
> is complete because
>
>  - it's easier to localize problems in small changes.
>  - the earlier a change is committed the more it gets tested.
>  - it tends to reduce the probability and scope of conflicts.
>  - it tends to reduce the scale of "oh crap I forgot about THAT" mistakes by
> identifying some problems early
>
> Basically, if you have a patch that does something useful, adds tests for
> new functionalit and doesn't break anything else, IMO it's ready to commit.
> I find it's usually worth the trouble to break big tasks into small
> incremental changes.
>
> I understand that some jobs (e.g. porting work) are harder to break down
> this way and it may not suit everybody's style, so I'm not telling anybody
> what to do. I'm just saying if ever the thought "maybe I could commit this
> bit separately" crosses your mind, I'm rooting for it.
>
> Cheers,
> Alan.

I'm +1 for that Alan.

To often have we all see the problem of working on a branch to add
some new functionality that creeps in to fixing/adjusting/changing
more things that is needed and then fighting against the moving target
of the mainline. Git can help the merging way more than svn would but
that doesn't mean we shouldn't still be aiming for small commits early
and often. Committing to the main line also helps raise awareness of
the changes are being done so they can be reviewed. Branches often get
over looked in our busy schedules making the final merge commit a long
and potentially error prone review.

I've been wanting to start using git for a while to enable me to
easily isolate my small changes as creating local branches is very
cheep. Anyway, as I'm writing about git I do have a concern about the
git-port repository. We do need to make absolutely sure that all code
coming from is either brought in via JIRA attached patches or we try
and ensure all the commiters there have a signed ICLA. It is great
that we are growing the product to work on windows and Solaris but we
need to ensure that no licensing issue crop up. I'm sure everything is
or will be fine but we do need to be vigilant about what we commit
back to the Apache repository.

Regards,

Martin
-- 
Martin Ritchie