Ok, a little pushback. My thought here was that github just has better collaboration tools than an hg only flow. milestones, issues, pull requests, line level commenting.
My thought was that we could all use the *same* github repository to raise the visibility of what we each do in isolation. My thought was that we (a couple of the many git ninjas among us) manually move patches back into ELM when they are interesting to have in a nightly available to QA/eng/product. My thought was that the HG history is clean and beautiful and the stuff that r+'d patches are made of (each would be uplifted in a bugzilla ticket describing the work). BUT! I'm not dogmatic here. I can roll with an etherpad and direct commits to elm if we believe that will better help us all collaborate. What say you? lloyd On Aug 9, 2013, at 9:08 PM, Richard Newman <[email protected]> wrote: >>> At the risk of wasted work, can we not just have a branch in >>> /mozilla/mozilla-central? Same organizational access rights, but master >>> would be automatically updated without someone having to pull between forks… >> >> And how does this relate to ELM? We don't build nightlies from github. > > As of this morning I have an action item to write this up, so thank you for > prompting me :P > > Essentially, working in git branches is more pleasant for some than working > in Bugzilla. > > In short: > > * Fork your own, or share, a GitHub mirror of m-c. > * Assign yourself a feature bug. > * Create a branch for your work: rnewman/bug-123456. > * Work in that branch, and keep it rebased on top of the 'elm' branch, which > tracks upstream hg elm (and thus everyone else's landing work). > * Do your own local builds, test, whatever. > * When you're ready to land: rebase, flatten, upload a patch to Bugzilla > (ideally), get review, land in hg, set bug flags. > * Automatic tools will ensure that hg elm -> GitHub elm in mere moments, and > your next Git branch can rebase on top of the work you just finished. > * Eventually, hg elm will merge to hg m-c, and we can continue mainline > development in the usual way. > > The hg alternative: > > * Assign yourself a feature bug. > * Use hg mq to handle one or more patch files implementing your work. > * Do your own local builds, test, whatever. > * When you're ready to land: rebase, flatten, upload a patch to Bugzilla, get > review, land in hg, set bug flags. > * Everything else proceeds in the same way. > _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
