Commit Rules

[Tomas Restrepo <to...@devdeo.com>]

I Finally got my apache account created today! Thanks to all for that.

I've, of course, read the new committers guide in the apache site, but still
wanted to ask a couple of general questions:

1- When can we start actually making commits to the qpid tree?

2- Do we have any rules or conventions in place for commits? (i.e. commit
message format and so on). Anything we need to be aware of to avoid screwing
things up?

3- Like many others, I'd start working on the M2 branch, but we need to keep
the trunk in sync as well. Could someone offer any suggestions on what the
best way to do this would be? Is it better to do so by hand, using svnmerge
or what? If the latter, can anyone offer any suggestions as to how to use
it? (I've seen http://www.orcaware.com/svn/wiki/Svnmerge.py of course).

4- Once I'm ready to start doing my own commits, I'd thought I'd start with
the JIRA's for which I've already submitted patches and that are pending.
These are:
QPID-435: Fix for Headers Exchange test
QPID-441: Fix handling of bounced messages
QPID-398: SSL Support for .NET Client

Does that sound OK? 

BTW, one final question: Who is supposed to close an issue in JIRA? At least
on the .NET client side, they seem to remain open forever, even when patches
have been proposed and even committed already into the trunk...

Thanks again,

Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Commit Rules

[Rajith Attapattu <ra...@gmail.com>]

LOL, I have to say I agree with Alan all the way.
Now I never took any short cuts :) , well ....maybe once or twice.

But yes changes to your java broker shouldn't break the c++ client... thats
a very good point.
One of the biggest selling points we have is the cross language
interoperability. So we need to ensure this all the time.

Regards,

Rajith.

On 4/30/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> > Hi Tomas,
> >
> > Like the others pointed out, the golden rule is that your commits
> doesn't
> > break the build.
> > At the minimum there shouldn't be any compilation errors.
> > But it would be great if all the unit tests pass too. (well there is the
> -
> > Dmaven.test.skip to get around that).
>
> I strongly disagree. At a minimum _all_ tests: unit, system, and interop
> when we have them must pass after _every_ commit unless there's some
> compelling and unusual situation that makes it impossible AND there are
> people actively working to resolve that unusual situation.
>
> You can take any shortcuts you like provided you don't get caught :) In
> particular if you're working on shared stuff like specs or gentools you
> need to be sure that *all* the projects still work after your changes.
> There have been several occasions where specs changes with Java commits
> broke the C++ and/or python builds.
>
> If that's too awkward or time consuming then document, optimize or
> redesign the test harness till it is usable. Tests deserve as much
> attention to quality as production code - don't forget we're the ones
> who suffer if they suck.
>
> I look forward to having cruise control and automatic public humiliation
> for build breakage.
>
> Cheers,
> Alan.
>
>

Re: Commit Rules

[John O'Hara <jo...@gmail.com>]

Buy that man a beer.

On 01/05/07, Alan Conway <ac...@redhat.com> wrote:
>
> On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> > Hi Tomas,
> >
> > Like the others pointed out, the golden rule is that your commits
> doesn't
> > break the build.
> > At the minimum there shouldn't be any compilation errors.
> > But it would be great if all the unit tests pass too. (well there is the
> -
> > Dmaven.test.skip to get around that).
>
> I strongly disagree. At a minimum _all_ tests: unit, system, and interop
> when we have them must pass after _every_ commit unless there's some
> compelling and unusual situation that makes it impossible AND there are
> people actively working to resolve that unusual situation.
>
> You can take any shortcuts you like provided you don't get caught :) In
> particular if you're working on shared stuff like specs or gentools you
> need to be sure that *all* the projects still work after your changes.
> There have been several occasions where specs changes with Java commits
> broke the C++ and/or python builds.
>
> If that's too awkward or time consuming then document, optimize or
> redesign the test harness till it is usable. Tests deserve as much
> attention to quality as production code - don't forget we're the ones
> who suffer if they suck.
>
> I look forward to having cruise control and automatic public humiliation
> for build breakage.
>
> Cheers,
> Alan.
>
>

Re: Commit Rules

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

On Mon, 2007-04-30 at 16:15 -0400, Rajith Attapattu wrote:
> Hi Tomas,
> 
> Like the others pointed out, the golden rule is that your commits doesn't
> break the build.
> At the minimum there shouldn't be any compilation errors.
> But it would be great if all the unit tests pass too. (well there is the -
> Dmaven.test.skip to get around that).

I strongly disagree. At a minimum _all_ tests: unit, system, and interop
when we have them must pass after _every_ commit unless there's some
compelling and unusual situation that makes it impossible AND there are
people actively working to resolve that unusual situation.

You can take any shortcuts you like provided you don't get caught :) In
particular if you're working on shared stuff like specs or gentools you
need to be sure that *all* the projects still work after your changes.
There have been several occasions where specs changes with Java commits
broke the C++ and/or python builds.

If that's too awkward or time consuming then document, optimize or
redesign the test harness till it is usable. Tests deserve as much
attention to quality as production code - don't forget we're the ones
who suffer if they suck.

I look forward to having cruise control and automatic public humiliation
for build breakage.

Cheers,
Alan.

Re: Commit Rules

[Rajith Attapattu <ra...@gmail.com>]

Hi Tomas,

Like the others pointed out, the golden rule is that your commits doesn't
break the build.
At the minimum there shouldn't be any compilation errors.
But it would be great if all the unit tests pass too. (well there is the -
Dmaven.test.skip to get around that).
But we all know that unit tests are important and should not be ignored.

Commit messages needs to have a reasonable description and a pointer to a
JIRA if applicable.
If it's a new feature, it's better if the design docs(or the disscussion
thread) are attached or linked to the JIRA.

Regards,

Rajith

Re: Commit Rules

[Marnie McCormack <ma...@googlemail.com>]

Hi Tomas,

Couldn't spot anywhere where someone else mentioned this - but if you
include the id of the JIRA e.g. QPID-100 in the commit remark then the svn
commits page on the JIRA will be updated with details of the changes
applied. Most useful when other committers are looking at the JIRA.

Hth !

Bfn,
Marnie


On 4/27/07, Tomas Restrepo <to...@devdeo.com> wrote:
>
> > :) Yeah, I was asking actually more specifically because something said
> > that
> > while the account got created it might "take a while before permissions
> > are
> > given to the subversion repository of the project". Hence my question
>
> And indeed it would appear I don't have permissions yet. I'll probably
> take
> a few days before this, but at least I think I'm all set up now to get
> started :)
>
>
> Tomas Restrepo
> http://www.winterdom.com/weblog/
>
>

RE: Commit Rules

[Tomas Restrepo <to...@devdeo.com>]

> :) Yeah, I was asking actually more specifically because something said
> that
> while the account got created it might "take a while before permissions
> are
> given to the subversion repository of the project". Hence my question

And indeed it would appear I don't have permissions yet. I'll probably take
a few days before this, but at least I think I'm all set up now to get
started :)


Tomas Restrepo
http://www.winterdom.com/weblog/

RE: Commit Rules

[Tomas Restrepo <to...@devdeo.com>]

Hi Alan,
> > 1- When can we start actually making commits to the qpid tree?
> When you've written some code worth committing :)

:) Yeah, I was asking actually more specifically because something said that
while the account got created it might "take a while before permissions are
given to the subversion repository of the project". Hence my question :)

> The golden rule is: no tests failing after your commit. For C++
> http://cwiki.apache.org/qpid/qpid-c-documentation.html has some
> guidelines, likewise for Java though I'm not as familiar.

Ohh, that's a given and I've been careful to try to ensure it (and have
fixed a number that were failing). My question was more about things like:
Is it the norm to reference the JIRA issue id of the bug/feature being
committed in the commit message? And stuff like that.

> svnmerge.py is the way to go. Rupert answered this one in another mail.

Thanks to Rupert for the detailed explanation, it helps a lot!

> IMO the person who commits the change (for themselves or on behalf of a
> non-committer) should close the JIRA, that's what I do. Ideally they
> should have already assigned the JIRA to themselves.

Ahh, excellent, then I'll start doing that later today.


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Commit Rules

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

Here's my take:

On Wed, 2007-04-25 at 18:57 -0500, Tomas Restrepo wrote:
> 1- When can we start actually making commits to the qpid tree?
When you've written some code worth committing :)

> 2- Do we have any rules or conventions in place for commits? (i.e. commit
> message format and so on). Anything we need to be aware of to avoid screwing
> things up?
The golden rule is: no tests failing after your commit. For C++
http://cwiki.apache.org/qpid/qpid-c-documentation.html has some
guidelines, likewise for Java though I'm not as familiar.

> 3- Like many others, I'd start working on the M2 branch, but we need to keep
> the trunk in sync as well. Could someone offer any suggestions on what the
> best way to do this would be? Is it better to do so by hand, using svnmerge
> or what? If the latter, can anyone offer any suggestions as to how to use
> it? (I've seen http://www.orcaware.com/svn/wiki/Svnmerge.py of course).

svnmerge.py is the way to go. Rupert answered this one in another mail.
Note that with svnmerge you can also block merges that should not be
done.

> 4- Once I'm ready to start doing my own commits, I'd thought I'd start with
> the JIRA's for which I've already submitted patches and that are pending.
> These are:
> QPID-435: Fix for Headers Exchange test
> QPID-441: Fix handling of bounced messages
> QPID-398: SSL Support for .NET Client
> 
> Does that sound OK? 
Sounds like an excellent way to get started.

> BTW, one final question: Who is supposed to close an issue in JIRA? 
IMO the person who commits the change (for themselves or on behalf of a
non-committer) should close the JIRA, that's what I do. Ideally they
should have already assigned the JIRA to themselves.

> At least
> on the .NET client side, they seem to remain open forever, even when patches
> have been proposed and even committed already into the trunk...

In that case either hound the person who resolved the problem to close
the JIRA or just close it yourself if you're certain its been resolved.

Cheers,
Alan.