who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

I'm doing some work on weinre this week, trying to get it a point of doing
an "official" Apache build.

I just committed the license change switcheroo, directly from a local
branch to the apache master.

I'm wondering if someone would like to experiment with me on getting an
approval process in place for commits.

The basic story would be this:

- when I have something to commit, push the branch the work is on to my
GitHub fork
- side note: that commit should be squashed for ease of review
- update the JIRA issue for the thing I'm fixing (every commit needs an
issue) with the location of the commit
- someone reviews the commit, adds comment to the JIRA issue that they
approve (or not) the commit
- person who did the work commits to master

I'd have used GitHub pull requests in the process, but they aren't working
at the moment, near as I can tell.  Specifically, no emails are sent to the
-dev list when someone issues a pull request against one of our GitHub
mirrors.

Some assumptions here:

- that we want a commit process that includes approval
- that we commit current work to master, instead of having a multi-level
dev branch scheme like this [1]

In terms of the specific commits I'll be doing, I don't assume that you
know much about weinre, because you probably don't.  Hopefully you'll learn
more though if play with me.  I'd like to just debug the process at this
point.  Longer term I'd like to see folks actually apply candidate commits,
do a build, make sure it passes tests, etc.  Or have a build process that
can do this.  Or at least have a 'build after commit' buildbot which would
test the commit after it's been committed (to whatever branch).

[1] http://nvie.com/posts/a-successful-git-branching-model/

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Jan 16, 2012 at 9:04 PM, Brian LeRoux <b...@brian.io> wrote:
> Jukka: Very curious about how we can help infra w/ the stuff Patrick
> is describing here. We have it in our queue to block out some
> resources to improve our testing automation. This is close enough that
> the work could be combined. Just don't know the implications to Apache
> infrastructure.

The build systems are not part of the core infrastructure, so it's
fairly easy to get involved. As Patrick already did, showing up on
builds@apache.org is a good first step.

See [1] for more information about all Apache infrastructure, and [2]
for the build infrastructure in particular. And [3] has good info on
how to interact with and get involved in the ASF infra team.

[1] http://www.apache.org/dev/infrastructure.html
[2] http://ci.apache.org/
[3] http://www.apache.org/dev/infra-volunteer.html

BR,

Jukka Zitting

Re: who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

On Mon, Jan 16, 2012 at 15:04, Brian LeRoux <b...@brian.io> wrote:

> Patrick: I'd like to help on this. We could cobble this together on
> our own servers to get things going. Appears we could use the Jira
> rest api: http://docs.atlassian.com/jira/REST/latest/


While I'd love to work on this kind of automation, I don't think my
schedule is going to allow for it.  Unless there's plenty of hooks already
available, and we just have to script some bits.

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Brian LeRoux <b...@brian.io>]

Jukka: Very curious about how we can help infra w/ the stuff Patrick
is describing here. We have it in our queue to block out some
resources to improve our testing automation. This is close enough that
the work could be combined. Just don't know the implications to Apache
infrastructure.

Patrick: I'd like to help on this. We could cobble this together on
our own servers to get things going. Appears we could use the Jira
rest api: http://docs.atlassian.com/jira/REST/latest/





On Mon, Jan 16, 2012 at 9:06 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 11:32, Patrick Mueller <pm...@gmail.com> wrote:
>
>> I'm wondering if someone would like to experiment with me on getting an
>> approval process in place for commits.
>>
>
> BTW, I'd be interested in finding out about other Apache project's commit
> processes.
>
> Probably the most interesting commit process for a non-Apache project I've
> seen is WebKit's.  It goes like this:
>
> - open a bug
> - when you have code ready to commit, add the patch as an attachment to the
> bug; there's a command-line script that will do this for you
> - WebKit's Bugzilla knows about these attachments, and provides a mechanism
> for you to signal that a commit needs a review, that the commit has passed
> review, and that the commit has failed review.
> - the reviewer signals pass/fail on the review
> - if the review passes, the code is automagically comitted and a build is
> done
>
> Since I've been involved, they've taken this one step further, in that you
> can have a build run against your patch without having it committed to the
> SCM.  This is a substitute for the presumed step of the reviewer applying
> the patch and making sure things till work.  Again, there's an indicator in
> Bugzilla to show you the status of this build.
>
> But wait, there's more!
>
> - all this stuff is logged to IRC as well as other obvious channels (bug
> emails, scm emails, etc)
> - there's an IRC bot that can be used to automagically "back out" a
> committed patch by creating a new bug and a "reverse patch", then applying
> it and committing it.
>
> It's a pretty nice system, but obviously relies on:
>
> - some automation code running in various places
> - extending the bug system to take all this stuff into account
>
> All in all, it's quite nice - everything revolves around Bugzilla.
>
> Anything else in this vein available at Apache?
>
> --
> Patrick Mueller
> http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

On Mon, Jan 16, 2012 at 11:32, Patrick Mueller <pm...@gmail.com> wrote:

> I'm wondering if someone would like to experiment with me on getting an
> approval process in place for commits.
>

BTW, I'd be interested in finding out about other Apache project's commit
processes.

Probably the most interesting commit process for a non-Apache project I've
seen is WebKit's.  It goes like this:

- open a bug
- when you have code ready to commit, add the patch as an attachment to the
bug; there's a command-line script that will do this for you
- WebKit's Bugzilla knows about these attachments, and provides a mechanism
for you to signal that a commit needs a review, that the commit has passed
review, and that the commit has failed review.
- the reviewer signals pass/fail on the review
- if the review passes, the code is automagically comitted and a build is
done

Since I've been involved, they've taken this one step further, in that you
can have a build run against your patch without having it committed to the
SCM.  This is a substitute for the presumed step of the reviewer applying
the patch and making sure things till work.  Again, there's an indicator in
Bugzilla to show you the status of this build.

But wait, there's more!

- all this stuff is logged to IRC as well as other obvious channels (bug
emails, scm emails, etc)
- there's an IRC bot that can be used to automagically "back out" a
committed patch by creating a new bug and a "reverse patch", then applying
it and committing it.

It's a pretty nice system, but obviously relies on:

- some automation code running in various places
- extending the bug system to take all this stuff into account

All in all, it's quite nice - everything revolves around Bugzilla.

Anything else in this vein available at Apache?

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Filip Maj <fi...@adobe.com>]

I'll poke around later today, once I have a beer in hand to help ward off
the fear. :)

On 12-01-17 8:44 AM, "Patrick Mueller" <pm...@gmail.com> wrote:

>On Tue, Jan 17, 2012 at 11:40, Filip Maj <fi...@adobe.com> wrote:
>
>> I think it's actually scooj that scares me the most.
>
>
>The scooj is gone man!  I automated a conversion from scooj to
>CoffeeScript
>in some previous release.  Now it's all CoffeeScript, all the time.
>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

On Tue, Jan 17, 2012 at 11:40, Filip Maj <fi...@adobe.com> wrote:

> I think it's actually scooj that scares me the most.


The scooj is gone man!  I automated a conversion from scooj to CoffeeScript
in some previous release.  Now it's all CoffeeScript, all the time.

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Filip Maj <fi...@adobe.com>]

I think it's actually scooj that scares me the most.

On 12-01-17 8:37 AM, "Patrick Mueller" <pm...@gmail.com> wrote:

>On Tue, Jan 17, 2012 at 11:07, Filip Maj <fi...@adobe.com> wrote:
>
>> Pat, if/when you move the server component to node, I am all for helping
>> out :D
>
>
>Well that should just take me a few minutes :-)
>
>And, ya know, there's plenty of CoffeeScript goodness in the "target" bits
>of weinre as well, for you folks afraid of Java.
>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

On Tue, Jan 17, 2012 at 11:07, Filip Maj <fi...@adobe.com> wrote:

> Pat, if/when you move the server component to node, I am all for helping
> out :D


Well that should just take me a few minutes :-)

And, ya know, there's plenty of CoffeeScript goodness in the "target" bits
of weinre as well, for you folks afraid of Java.

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Filip Maj <fi...@adobe.com>]

Pat, if/when you move the server component to node, I am all for helping
out :D

On 12-01-17 4:44 AM, "Patrick Mueller" <pm...@gmail.com> wrote:

>On Mon, Jan 16, 2012 at 19:52, Filip Maj <fi...@adobe.com> wrote:
>
>> >What's the process that was used within PhoneGap?
>>
>> I would say a mix... Something that was considered a "big" change was
>>RTC,
>> but day-to-day / bug-fix type stuff was CTR (or even just "C" ;) )
>>
>
>What I fear is CTR just becomes C all the time.
>
>But I have no big issues with keeping with the old flow, as Fil described.
>
>For the weinre, we could use some developers.  if there's anyone who'd
>like
>to delve deeper into this evil application, I'd love to you have you
>review
>commits for me.  And certainly, I'd like to review commits anyone wants to
>make to weinre.
>
>For now, after I have a commit ready to add to weinre, I'll post a message
>here with a link to the bug and commit, in case anyone wants to join in.
>
>-- 
>Patrick Mueller
>http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Patrick Mueller <pm...@gmail.com>]

On Mon, Jan 16, 2012 at 19:52, Filip Maj <fi...@adobe.com> wrote:

> >What's the process that was used within PhoneGap?
>
> I would say a mix... Something that was considered a "big" change was RTC,
> but day-to-day / bug-fix type stuff was CTR (or even just "C" ;) )
>

What I fear is CTR just becomes C all the time.

But I have no big issues with keeping with the old flow, as Fil described.

For the weinre, we could use some developers.  if there's anyone who'd like
to delve deeper into this evil application, I'd love to you have you review
commits for me.  And certainly, I'd like to review commits anyone wants to
make to weinre.

For now, after I have a commit ready to add to weinre, I'll post a message
here with a link to the bug and commit, in case anyone wants to join in.

-- 
Patrick Mueller
http://muellerware.org

Re: who wants to play with me on a commit approval process for weinre?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Jan 17, 2012 at 1:52 AM, Filip Maj <fi...@adobe.com> wrote:
>>What's the process that was used within PhoneGap?
>
> I would say a mix... Something that was considered a "big" change was RTC,
> but day-to-day / bug-fix type stuff was CTR (or even just "C" ;) )

Sounds like a good practice to follow also in Cordova.

BR,

Jukka Zitting

Re: who wants to play with me on a commit approval process for weinre?

[Filip Maj <fi...@adobe.com>]

>What's the process that was used within PhoneGap?

I would say a mix... Something that was considered a "big" change was RTC,
but day-to-day / bug-fix type stuff was CTR (or even just "C" ;) )

Re: who wants to play with me on a commit approval process for weinre?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Mon, Jan 16, 2012 at 5:32 PM, Patrick Mueller <pm...@gmail.com> wrote:
> Some assumptions here:
>
> - that we want a commit process that includes approval

Do we?

Within Apache the terms RTC and CTR (as in Review-Then-Commit [1] and
Commit-Then-Review [2]) are widely used to describe the kind of review
process used by a project. In RTC you put your changes up for review
before committing (or pushing) them to the shared trunk or master
branch. In CTR you simply commit your changes and people will review
them afterwards if or where needed.

Most Apache projects follow CTR for pretty much all actively developed
code. RTC is more commonly used for maintenance branches, APIs or
other bits that are either too complex or otherwise critical to be
changed without a full review. And even when CTR policy is used, a
committer can always call for a review of any particular change that
he or she isn't entirely sure about.

What's the process that was used within PhoneGap?

As for build system automation, probably the deepest integration so
far was done by Nigel Daley for the Hadoop project. The Hadoop build
setup takes any patches attached to the issue tracker, applies them to
the latest trunk version and runs a full set of tests on the resulting
codebase. The result of the test run is reported as a +1 or -1 comment
on the relevant issue. See Nigel's blog post [3] for more details
about the setup.

Another related tool that might be of interest is the Review Board
instance [4] that's available to help projects do code reviews of both
incoming patches and already committed changes.

[1] http://www.apache.org/foundation/glossary.html#ReviewThenCommit
[2] http://www.apache.org/foundation/glossary.html#CommitThenReview
[3] http://developer.yahoo.com/blogs/hadoop/posts/2007/12/if_it_hurts_automate_it_1/
[4] https://reviews.apache.org/

BR,

Jukka Zitting