My only strong opinions are: 1. Using bugzilla as the one source of truth for bugs. Even b2g had to do it. 2. ELM is the place where the code ends up for nightly builds. How it gets there, I don't care. But we have a test infra that works with the hg repos and we need it to run.
----- Original Message ----- > 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
