> Does it make a difference to the downsides of the nightly branch if it was > actually a fast-forward branch along the master branch instead of a "new > changeset in the git world" merge?
I feel like my opinion may be worth even less than two cents here, but it seems like it would be kind of nice to have merges from master into nightly have a merge cset in nightly, because then you can answer the question "which historic csets were nightlies?" At least, I'd like to be able to ask that question about m-c, and I can't, because m-c-git is set up with fast-forward merges as you describe. On Tue, Jan 29, 2013 at 4:30 PM, Axel Hecht <[email protected]> wrote: > Uneducated 2cents: > > Does it make a difference to the downsides of the nightly branch if it was > actually a fast-forward branch along the master branch instead of a "new > changeset in the git world" merge? > > Axel > > > On 29.01.13 18:10, Vivien wrote: >> >> On 29/01/2013 16:38, Alex Keybl wrote: >>>> >>>> Why are you going to delete the nightly branch? gaia-master is the >>>> equivalent of mozilla-inbound and gaia-nightly is the equivalent of >>>> mozilla-central. Are you going to delete mozilla-central as well? :) >>> >>> We were under the impression that the nightly branch caused a lot of >>> overhead and some landing lag, since testing that branch prior to >>> merging is a manual job. >> >> The lag for landing is expected but I feel like it could be reduce if >> >> there were more sheriffs. Nobody wants this responsibility right now >> because it force you to run a set of tests manually so overhead is a >> consequence of the lack of automation tests. This should hopefully be >> resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=813301 >> >>> It seemed as if master would be an appropriate place to do "nightly" >>> equivalent work prior to uplift to v1-train/v1.x branches. >>> >>> If that's not the case, engineering can feel free to continue using >>> it. I'm just curious which repo below "nightly" would feed into. >>> >>> v1.0.0 - as named >>> v1-train - tip of v1.x, currently v1.0.1 >>> master - v2 (but can also include future v1 feature work) >> >> >> I think you should s/master/nightly/ here. Nightly will be fed by master >> as usual. As I suggest most of the confusion seems to come from naming >> but master should never be considered as a safe branch. Use at your own >> risk. >> >> Vivien. >> >>> >>> -Alex >>> >>> On Jan 29, 2013, at 7:16 AM, Vivien <[email protected]> wrote: >>> >>>> On 28/01/2013 23:51, John Ford wrote: >>>>> >>>>> Hello, >>>>> >>>>> We are deprecating the nightly branch of both Gaia and b2g-manifest >>>>> (repo manifests). The nightly branch will be superseded by the >>>>> v1-train branch of both Gaia and b2g-manifest. We will be deleting >>>>> the nightly branch in the near future. >>>> >>>> Why are you going to delete the nightly branch? gaia-master is the >>>> equivalent of mozilla-inbound and gaia-nightly is the equivalent of >>>> mozilla-central. Are you going to delete mozilla-central as well? :) >>>> >>>> We learned a lot on the field in the past, please does not regress >>>> things and put us back in a state where it is impossible for devs to >>>> provide a stable build and for QA to give a reasonable changesets. >>>> v1-train is one things but for all the people that are going to work >>>> on 2.0 features they should expect to have a stable branch is >>>> possible. If that's just a naming question we can rename master to >>>> inbound... >>>> >>>>> There will also be a v1.0.0 branch of both repositories for the >>>>> work tracking our 1.0.0 release. >>>>> >>>>> The new default branch to pull in B2G's config.sh script is >>>>> 'v1-train'. If you're currently on the nightly branch and would >>>>> like to be on the supported v1-train branch, you can pull updates to >>>>> your top level B2G repository and rerun ./config.sh. An example to >>>>> do this would be: >>>>> >>>>> $ cd B2G >>>>> $ git fetch origin && git merge origin/master >>>>> $ ./config.sh <device> >>>>> >>>>> This will set up your repo tree and do a repo sync with the new >>>>> branches. In an effort to reduce confusion, here is the mappings >>>>> between the BRANCH value passed to config.sh and the branches of >>>>> Gecko and Gaia you'll end up with: >>>>> >>>>> * "BRANCH=master ./config.sh" will yield an ancient copy [1] of >>>>> Gecko's 'master' branch (mozilla-central) and Gaia's 'master' branch >>>> >>>> I feel strongly against that. This is bringing Chaos back. What are >>>> the rationale to not use the nightly branch? >>>> >>>>> * "BRANCH=v1-train ./config.sh" will yield Gecko's 'gecko-18' >>>>> (mozilla-b2g18) branch and Gaia's 'v1-train' branch >>>>> * "BRANCH=v1.0.0 ./config.sh" will yield Gecko's 'v1.0.0' branch and >>>>> Gaia's 'v1.0.0' branch >>>>> >>>>> If you have more questions about branching or about what code ends >>>>> up where, there is a helpful wiki page that's maintained by our >>>>> Release Management team at >>>>> https://wiki.mozilla.org/Release_Management/B2G_Landing that >>>>> explains B2G branching in more detail. If you still have questions, >>>>> please feel free to ask me. >>>>> >>>>> Thanks, >>>>> >>>>> John Ford >>>>> >>>>> [1] for info, see >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=820955. If you want to >>>>> work on mozilla-central, it's probably best to manage your own m-c >>>>> tree and use GECKO_PATH in .userconfig >>>>> _______________________________________________ >>>>> dev-gaia mailing list >>>>> [email protected] >>>>> https://lists.mozilla.org/listinfo/dev-gaia >> >> > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
