Last Comment Bug 534422 - Make 1.9.1 client.py pull specific state of extensions by default
: Make 1.9.1 client.py pull specific state of extensions by default
Status: RESOLVED FIXED
: fixed-seamonkey2.0.3
Product: MailNews Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Thunderbird 3
Assigned To: Robert Kaiser (not working on stability any more)
:
Mentors:
Depends on: 524682
Blocks: 529700
  Show dependency treegraph
 
Reported: 2009-12-12 11:07 PST by Robert Kaiser (not working on stability any more)
Modified: 2010-02-05 15:14 PST (History)
1 user (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
.1-fixed


Attachments
state revisions in buildbot configs (probably not good solution for the long term) (5.25 KB, patch)
2009-12-12 11:11 PST, Robert Kaiser (not working on stability any more)
no flags Details | Diff | Review
pull a COMM_1_9_1_BRANCH by default (1.07 KB, patch)
2009-12-13 06:59 PST, Robert Kaiser (not working on stability any more)
standard8: review+
standard8: approval‑thunderbird3.0.1+
Details | Diff | Review

Description Robert Kaiser (not working on stability any more) 2009-12-12 11:07:24 PST
As we can't take new strings (or even new features) for the "stable" SeaMonkey 2.0.x series, we need to basically "freeze" ChatZilla, venkman, and DOM inspector at the state they were in when SeaMonkey 2.0 shipped.

We can take selected fixes after serious investigation, but we can't just follow their trunk, esp. as we cannot take string changes (for ChatZilla and venkman they break all L10n trees).

The best way to do this is probably to make client.py pull some tag of those repos by default, which is even more easy once ChatZilla has been converted to being pulled from hg. I still need to figure out that tag or if it should just be a named branch, or whatever, but I intend to work on this and hopefully have a solution soon.

I'd be happy about technical details (i.e. should it be a specific revision, a static tag which we move as needed, or a named branch? What name should be used for the tag/branch?)

I think we're safe to do what fits SeaMonkey best here, as nobody else on the comm-* branch is packaging any of the extensions by default.
Comment 1 Robert Kaiser (not working on stability any more) 2009-12-12 11:11:37 PST
Created attachment 417272 [details] [diff] [review]
state revisions in buildbot configs (probably not good solution for the long term)

For reference, this is the solution I am currently using, which is to specify the specific revisions on the buildbot side. That works, but 1) needs a build person (me) to update what we are building and 2) confuses people building theirselves by giving them different versions on checkout than what the build machines are using.
I'm only attaching this patch to have it up somewhere for reference to what we're doing right now.
Comment 2 Serge Gautherie (:sgautherie) 2009-12-12 16:27:23 PST
Fwiw, I would probably prefer a named branch.
Comment 3 Robert Kaiser (not working on stability any more) 2009-12-13 06:59:36 PST
Created attachment 417346 [details] [diff] [review]
pull a COMM_1_9_1_BRANCH by default

This patch bases on bug 524682, as moving ChatZilla to hg makes this nicer to work with overall.

If this gets review, I'll create a named COMM_1_9_1_BRANCH (or whatever name comes out of the discussion) in the repos of those extensions, basing on what SeaMonkey 2.0 final (and 2.0.1) shipped.
Comment 4 Mark Banner (:standard8) 2009-12-15 05:14:32 PST
Comment on attachment 417346 [details] [diff] [review]
pull a COMM_1_9_1_BRANCH by default

r=Standard8 but please make sure that:

- This change is communicated to developers via the normal channels.
- This change is documented somewhere (https://developer.mozilla.org/en/comm-central#Branches may be an appropriate place).
Comment 5 Robert Kaiser (not working on stability any more) 2009-12-17 07:21:41 PST
OK, I have created a COMM_1_9_1_BRANCH on all those repos, now it just need communication/documentation and checkin.
Comment 6 Robert Kaiser (not working on stability any more) 2009-12-17 08:13:39 PST
I added a paragraph about it to https://developer.mozilla.org/en/comm-central#Branches and posted to the newsgroups, so I'll go for checkin now.
Comment 7 Robert Kaiser (not working on stability any more) 2009-12-17 08:21:12 PST
Pushed as http://hg.mozilla.org/releases/comm-1.9.1/rev/bdb2e5504488

Note You need to log in before you can comment on or make changes to this bug.