Great, Jason and I were just talking about this today.

One possible process flow we were discussing is that module leads still do their work from a forked repository like any other contributor. When changes are ready, the module lead issues a pull request, giving the integration managers (namely Pete) the notification/heads-up to review the code. The module lead then completes their own pull request, only deferring if changes are requested by the reviewer.

The reason for this process is so that all changes can be tracked back to pull requests, and those pull requests can be linked to the related JIRA.

Of course, there is always the exception that "hot changes" are made to the upstream master for non-normative changes (formatting, layout, pom parent versions, etc). Use at your discretion would be the general policy there.

Reasonable? Not reasonable?


On Fri, Oct 22, 2010 at 6:19 AM, Pete Muir <> wrote:
I have set up teams for each module, giving the lead permission to push to their repo (except in a couple of cases where I couldn't find the leads username, so if you can't push, then please tell me your username). You should now be able to handle pull request directly.

Let's see how this system works :-)
seam-dev mailing list

Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597