507952 - Explore providing more continuity for release {tinder-|moz}configs

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Right now we fork a tinder-config for releases for the first milestone on a branch, and then we just just rsync the release config over from the previous milestone/release for each new release and run a sed on it.

This works well enough, except

1) it's one more thing that has to be done manually on the box itself

2) there's not currently any (automated) way of preserving continuity for 
   configs, particularly in case of acts of $DEITY

3) we periodically make changes to {tinder-|moz}configs over the course of 
   normal development, and then we have to remember to port them to the release 
   configs before spinning (there's a somewhat lengthy note stressing this 
   point in Branch Tag Build Release)

4) probably something else I'm not remembering at the moment

I haven't given this a ton of thought/investigation yet, but I'm thinking we could do something like this:

1) Create a new tinderbox-config, release/, per branch, with the initial 
   version forked from the nightly builder (for 1.6.x and 2.0.x, from the 
   existing "release" configs, merged and cleaned up to match the nightly ones)

2) Make a new tree on the nightly/release box, $branchname-release, whose 
   tinderbox-configs/ folder pulls from the new release/ tinderbox-config above

3) Instead of adding a new tree for each milestone/release in multi-config.pl, 
   multi-config.pl would be set up for $branchname-release with 
   --config-cvsup-dir, and spinning each release would involve just 
   uncommenting the tree; it would cvs up the config and start a clobber 
   release build (for absolute freshness, we could still rsync --delete the 
   source and object hierarchies from the $branchname-release tree to simulate 
   the current rsync of only tinderbox and config files)

4) Branching and tagging would involve bumping the numbers and tag (and/or 
   assorted other config settings) in the release/ {tinder-|moz}configs in 
   addition to client.mk and camino/config/version.txt

5) Any time we modify a {tinder-|moz}config during development, we'd also 
   modify release/, just like it was cb-miniosx01/ or any other (real) box

I haven't really checked to see if this will all work as I imagine it, and reading back over it after I've written it all down now, I wonder whether it's actually creating more work than it's saving (and preserving).  I guess option B would be to write a tool that we keep under version control and check out on the tinderbox that copies the parent branch mozconfig, copies the parent branch tinder-config.pl and prompts you for values that it replaces in the copy, and does some sort of sanity-check.  

Dunno. It's been bothering me while Sam's been hanging out with hackers all week, so I'm putting pen to paper as it were, and now it can bother everyone else, too ;)

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: 2.0b3 release tinder-config.pl

Just so we'll have some record/archive, here's the release tinder-config from 2.0b3.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: 1.6.8 release tinder-config.pl

Just so we'll have some record/archive, here's the release tinder-config from 1.6.8.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I thought about this again today randomly while in the shower, and I basically came up with comment 0 all over again.

Instead of part 2 and 3, we'd keep the traditional $version trees for the releases and just make sure their --config-cvsup-dir values were set to the release tag.

In part 4, the changes would be done on the mainline (like relnotes and installer/Makefile.in) so that the mainline always had the most current values; it would just be tagged for the release.

This is maybe a little less work (at least while releases are in CVS; it gets a little more annoying once we're in Hg, since we'll have to juggle two VCSes and repos).

In the meantime, I've been periodically pulling the tinder-configs off the box, so I have local copies.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: 2.1a1 release tinder-config.pl

…And 2.1a1.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I need to pull the one for 2.1.2, which has a larger Gecko timeout value, and I updated it tonight for the new symbolpush server, so that doesn't fail on release :P

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: 2.1.2 release tinder-config.pl, updated for new symbolpush server