"Merge requests" or as they are known in github, "Pull requests (PR)" can be committed to the main repo by the folks who have commit access. Normally the basic workflow is.
* There is a main "xsce" repo. It's path would be xsce/xsce.git. * Developers create forks (or personal clones) of the repo, under their username. eg. gjh/xsce.git, or jvonau/xsce.git. * Typically the developer works on a branch per feature on their fork. So there might be a branch feature-xyz under m_anish/xsce.git. * When the feature is ready for merging, a Pull Request is created. Folks who have commit access to xsce/xsce.git get notified. * <Some decision making mechanism> takes place and the Pull Request is either merged or rejected. About <Some decision making mechanism> * I'd like to know how we do it currently, and what folks would be comfortable with, so we can try to follow it as closely as possible. * In DXS development, the the process we use is (just as an example): 1. Every developer has commit access to the main xsce repo. 2. The developer creating the pull request "should not" not be the one merging it. 3. The other developers in the team review and test the code, they accordingly leave comments of their review and test results against the pull request. 4. When there have been a total of two or more reviews/tests (combined), someone with the commit access merges the PR. One idea could be to have Jerry, George and Tim have commit access to the XSCE repo on github, and then they decide whom to add/remove from the accesslist and what process to follow for merging/rejecting PR's. Note, even if you don't have commit access, you can still create a fork, make a pull request, be notified of pull requests by others, and comment on them. Best, Anish On Sun, Oct 13, 2013 at 3:27 PM, Jerry Vonau <jvo...@shaw.ca> wrote: > On Sun, 2013-10-13 at 18:20 -0400, Tim Moody wrote: > > +1 for the move. I guess you need to be careful with the timing so > > you don’t end up with the repo offline during the sprint, but if you > > feel confident in that then go for it. > > > > +1 motion carried, lets proceed. Now the question is working with merge > requests, how are we going to handle that? > > Jerry > > > _______________________________________________ > > Change of Address > > > > timmo...@sympatico.ca is now t...@timmoody.com > > > > Please change your bookmarks. Thanks. > > _______________________________________________ > > > > > > From: Anish Mangal > > Sent: Sunday, October 13, 2013 2:11 PM > > To: Martin Dluhos ; xsce-devel > > Cc: server-devel > > Subject: [XSCE] Re: [Server-devel] XSCE Proposal | Moving to github > > and notifications > > > > *If* there is consensus on moving to github, should be think about > > making the switch before the hacksprint in SF? It might save us some > > time as then we would have set-up the buildbot, etc. > > > > On the other hand, if there isn't consensus, maybe the hacksprint > > would be a good opportunity to try github out. > > > > > > On Wed, Oct 9, 2013 at 8:30 AM, Martin Dluhos <mar...@gnu.org> wrote: > > On 10/09/2013 11:13 AM, Anish Mangal wrote: > > >> I think that it would be more appropriate to send > > notifications of merged pull > > >> > requests rather than individual commits to avoid too much > > noise on the channel. > > >> > Those who are interested can always follow the pull > > request link to access > > >> > individual commits. > > >> > > > > I would prefer notifications for pull requests *both* when > > they are > > > created and when they are merged. The creation of the pull > > request > > > will sort of open a review and test window for people > > willing to do > > > that, so notifying that event is necessary IMO. > > > > > > Very good point. I agree. > > _______________________________________________ > > Server-devel mailing list > > Server-devel@lists.laptop.org > > http://lists.laptop.org/listinfo/server-devel > > > > > > >
_______________________________________________ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
