Great, Jason and I were just talking about this today.
<proposed>
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.
</proposed>
Reasonable? Not reasonable?
-Dan
On Fri, Oct 22, 2010 at 6:19 AM, Pete Muir <pmuir(a)bleepbleep.org.uk> 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
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen