On Oct 31, 2012, at 7:33 AM, Geert Janssens <[email protected]> wrote:
> This discussion has been had multiple times before and frankly I hope this > will be the last time. > > The previous discussion didn't end in an explicit consensus, but I think we > were close to finding a compromise at least. A summary: > > - Nobody opposed to using github. In fact most developers are in favour of > using it. > - John indicated that github is good, but we shouldn't use the github issue > tracker or pull requests. They appear to be a source of trouble. > - Mostly Derek insists on having a canonical repository on code.gnucash.org > as well. Others haven't explicitly agreed or disagreed on this. > - Yawar proposed to have the main activity run on github, and pull > periodically to code.gnucash.org. The latter can be considered canonical. > > Let's continue to build on this. I propose this setup: > > One master repo hosted on github. One canonical repo on code.gnucash.org > pulls periodically from this master repo to keep in sync. > > Only selected developers have commit access to the github repository. This is > all access control we need here. > > All others that wish to contribute have to fork/clone this repository and > send in patches. > > It looks like we better don't use github's issue tracker and pull request > mechanisms. John stated this explicitly on the previous discussion, but there > is criticism on these tools also in other (large) projects. Instead we > continue to use our own contribution process, being: patches have to be sent > to bugzilla or the mailing list (the latter has a higher risk of getting > lost). Issues should be tracked in bugzilla. Ideas and requests could be > tracked in either bugzilla or uservoice. > > There is also a feature on github to annotate patches (write inline > comments). I don't know it's advantages or drawbacks, but given the opinion > on pull requests and issue tracker, it's probably safe to not promote the > annotation tool so far. Instead discussion of patches continues on the > mailing lists as is now. > > I have not really decided yet how to handle access control to the canonical > repository on code.gnucash.org yet. In principle nobody needs to push > anything to this repo. It should simply fully automatically pull from the > github master repo. But just in case for maintenance or other situations, I > think it makes sense to allow push access by the same developers that > currently can commit to svn on code.gnucash.org. > > I have deliberately skipped implementation details in this mail (how to > enforce access control, how to trigger push/pull requests,...). I first would > like to come to a consensus on the concept. Then work out the details. > > So any issues with this proposal ? (If so, please use bugzilla, not the > github issue tracker ;p ). Or if you agree, please state so as well, so we > can get an idea if we can pursue this proposal or not. Sounds good to me. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
