We've toyed around with this idea before, let's put it into practice and see if people use it. The idea is to create some generic project branches for short-lived projects. Instead of having to spin up a new branch, developers could just book (via a wiki) one of these generic branches and get to work immediately. We may have to reset the hg repo between usages, needs some testing. Suggested branch names: - apple, orange, banana, ... - red, green, blue, ... - glad, hefty, wm, ... - birch, cedar, oak, ... (I like this one) Let's start with 3 branches, with the full gambit of tests enabled. No l10n or nightlies for now.

Will we need a 3rd production master to handle these?

The descriptions of the hg repositories should point to the wiki page which describes the purpose of these branches, and which ones are currently booked, and for whom.

(In reply to comment #1) > Will we need a 3rd production master to handle these? Yes. Maybe share it with the try master?

If we're ok blocking this on try server refactoring I think that's a fantastic idea

(In reply to comment #0) > We've toyed around with this idea before, let's put it into practice and see if > people use it. > > The idea is to create some generic project branches for short-lived projects. > Instead of having to spin up a new branch, developers could just book (via a > wiki) one of these generic branches and get to work immediately. > > We may have to reset the hg repo between usages, needs some testing. Resetting the repo is one option, and probably cleanest, but takes coordination with IT. Another option would be to have developer start by doing a large merge from m-c (or whatever branch they want to consider "parent branch"). This becomes much more self-service, but maybe gets cluttered over time? Maybe try this first, and see how often these switch hands and clutter up? > Suggested branch names: > - apple, orange, banana, ... > - red, green, blue, ... > - glad, hefty, wm, ... > - birch, cedar, oak, ... (I like this one) (groan). Yes, I like the wood names. > Let's start with 3 branches, with the full gambit of tests enabled. No l10n or > nightlies for now. +1

I think we should reset the repo so there is no possibility of any residual changes from the previous user, and it creates a cleaner history. It's not a big deal for IT to do this AFAIK.

(In reply to comment #6) > I think we should reset the repo so there is no possibility of any residual > changes from the previous user, and it creates a cleaner history. It's not a > big deal for IT to do this AFAIK. I agree with Nick. It also eliminates the possibility that somebody could accidentally push someone else's changes along with theirs back to a main repository.

i'd like to get this in on tomorrow's downtime and then perhaps do an additional patch to add a flag for 'talos_sendchanges' so that any of these branches can have talos or not depending.

only talos for now - not sure if we can send over unittests yet.

Comment on attachment 451766 [details] [diff] [review] add twig mozconfigs to staging/production http://hg.mozilla.org/build/buildbot-configs/rev/bd69ffa8b728

Comment on attachment 451765 [details] [diff] [review] add twigs to buildbot-configs/mozilla staging/production configs http://hg.mozilla.org/build/buildbot-configs/rev/7b7106bf0c5d

Comment on attachment 451767 [details] [diff] [review] add twigs to data.sql http://hg.mozilla.org/graphs/rev/6f08ca2d9662

Comment on attachment 451772 [details] [diff] [review] add twigs to talos-r3/talos-staging-pool http://hg.mozilla.org/build/buildbot-configs/rev/07302fb9ebd9

until bug 558180 is fixed and this is no longer needed

Comment on attachment 452895 [details] [diff] [review] update mozconfigs for twigs to allow for custom mozconfig >diff --git a/mozilla2/win32/maple/nightly/mozconfig b/mozilla2/win32/maple/nightly/mozconfig >--- a/mozilla2/win32/maple/nightly/mozconfig >+++ b/mozilla2/win32/maple/nightly/mozconfig >@@ -9,8 +9,14 @@ ac_add_options --enable-tests > > # For NSS symbols > export MOZ_DEBUG_SYMBOLS=1 > > # Needed to enable breakpad in application.ini > export MOZILLA_OFFICIAL=1 > > . $topsrcdir/configs/mozilla2/win32/include/choose-make-flags >+if [ -f $topsrcdir/mozconfig-extra ] ; then >+ . $topsrcdir/mozconfig-extra >+fi >+if [ -f $topsrcdir/mozconfig-extra-linux ] ; then >+ . $topsrcdir/mozconfig-extra-linux >+fi >\ No newline at end of file So, I didn't read the whole patch, but this is definitely wrong. win32 should be including mozconfig-extra-win32.

Apologies for the copy and paste errors in the last patch. This time each mozconfig-extra reference has the right platform.

Comment on attachment 453423 [details] [diff] [review] update mozconfigs for twigs to allow for custom mozconfig (with proper platforms) Sorry, don't use gcc-4.5 any more :(

Comment on attachment 453592 [details] [diff] [review] update mozconfigs for twigs to allow for custom mozconfig (using gcc 4.3.3) Please base this off of the current mozilla-central mozconfigs. You still have LDFLAGS="-static-libstdc++' from the gcc-4.5 mozconfigs

copied most up to date mozilla-central configs

Comment on attachment 455303 [details] [diff] [review] update mozconfigs for twigs to allow for custom mozconfig (using gcc 4.3.3) - synched with m-c mozconfigs Something about this patch makes it hard to import but I didn't figure out what. Thanks for the tarball of the repo. >diff --git a/mozilla2-staging/linux/birch/codecoverage/mozconfig b/mozilla2-staging/linux/birch/codecoverage/mozconfig >new file mode 100644 Please only add nightly and debug configs for the twigs. codecoverage and xulrunner aren't being run and unittest is deprecated. I think you can just hg rm them again. I haven't reviewed this line by line, but looked at the differences between mozilla-central and twigs for each platform, and at mozilla2-staging vs mozilla2.

Comment on attachment 455303 [details] [diff] [review] update mozconfigs for twigs to allow for custom mozconfig (using gcc 4.3.3) - synched with m-c mozconfigs http://hg.mozilla.org/build/buildbot-configs/rev/01f3b3aa85c0 with xulrunner,release,unittest,codecoverage not added.

These have now been used a couple of times and work well. Closing.