[Noticed while Jens (and I) worked on bug 728651 and its blockers.] First, the current situation: http://mxr.mozilla.org/comm-central/source/client.py 12 'REV': "default", ==> This seems fine, so Trunk can be used to test latest code(s). http://mxr.mozilla.org/comm-aurora/source/client.py 20 'CHATZILLA_REV': 'CHATZILLA_0_9_88_RELEASE', 24 'INSPECTOR_REV': 'DOMI_2_0_10', 28 'VENKMAN_REV': 'a38583d7164a', ==> The idea is right, except none of these revs are marked as "compatible" with SM 2.9 :-/ http://mxr.mozilla.org/comm-beta/source/client.py Same as comm-aurora. ==> The idea is right, except DOMi rev is not marked as "compatible" with SM 2.8 :-/ http://mxr.mozilla.org/comm-release/source/client.py Same as comm-central. ==> This is very wrong: it should be the same as (previous) comm-beta :-( *** Summarizing + commenting what Jens wrote to me: The first "LDAP-like" idea would be to (create and) use a tagged version for Venkman too. While I believe we do want to release SeaMonkey with official extension versions (as much as possible), we agree having to update client.py each time an extension version changes is a (additional) burden. Then the new "MOZILLA-like" idea is to use moving aliases in the extension repositories, like COMM_AURORA, COMM_BETA and COMM_RELEASE, and to shift these (only) at each cycle. I support this proposal. Who can decide? (Callek? Ian? Council?)

*Trunk: not to be applied, 'default' is fine. *Aurora: this patch, already needs compatibility bump included in this version. *Beta: should get it too, at least wrt aurora and release. *Release: this won't cause any issue because 'default' is/was currently pulled.

Comment on attachment 602713 [details] [diff] [review] (Av1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_1_RELEASE [Checkin: Comment 6] no need for release landing of this, but aurora+beta is fine, no l10n changes involved.

(In reply to Serge Gautherie (:sgautherie) from comment #0) > [Noticed while Jens (and I) worked on bug 728651 and its blockers.] > > http://mxr.mozilla.org/comm-beta/source/client.py > Same as comm-aurora. > ==> The idea is right, except DOMi rev is not marked as "compatible" with SM > 2.8 :-/ So for background as to why this stunk, I hadn't been updating them since 2.8 due to the "compat by default" thing, and admittedly my misunderstanding of it. > http://mxr.mozilla.org/comm-release/source/client.py > Same as comm-central. > ==> This is very wrong: it should be the same as (previous) comm-beta :-( Indeed it is wrong, but since we shipped already no real need to fix, we do advertise that release repo should use the SEAMONKEY_FOO_RELEASE tag to get the code, which the extension versions have. So if a user is following docs, they should be good. > Summarizing + commenting what Jens wrote to me: > > The first "LDAP-like" idea would be to (create and) use a tagged version for > Venkman too. This is a good idea, but I'd like to do that only when Venkman gets any real changes/a new version out. Currently Venkman has not had a new version/real changes in a long while. > While I believe we do want to release SeaMonkey with official extension > versions (as much as possible), we agree having to update client.py each > time an extension version changes is a (additional) burden. Well in my current design, we only (plan) on updating client.py at aurora uptake day to the "latest version available at that time" To account for cases where something would change l10n. And that update should propogate down to the other trains. And we continue testing |default| on trunk. > Then the new "MOZILLA-like" idea is to use moving aliases in the extension > repositories, like COMM_AURORA, COMM_BETA and COMM_RELEASE, and to shift > these (only) at each cycle. > I support this proposal. When venkman starts to get coherent changes again we can probably do this just fine, until then staying default for branches is even easier than using a specific tag. IMO. > Who can decide? (Callek? Ian? Council?) Any of the above?

(In reply to Justin Wood (:Callek) from comment #3) > > The first "LDAP-like" idea would be to (create and) use a tagged version for > > Venkman too. > > This is a good idea, but I'd like to do that only when Venkman gets any real > changes/a new version out. Currently Venkman has not had a new version/real > changes in a long while. Well, it doesn't really matter /how many/ changes went in but rather /which/ did. Yes, there has been no new version, but that is a Venkman releng problem. There *has* been an important change/fix: Changeset 148fe7bca62e (Bug 418426 - JavaScript Debugger (Venkman) ignores breakpoints) went in after revision a38583d7164a which we're using on comm-aurora and comm-beta. So we're currently in the strange situation to have this issue fixed on trunk and release, but neither Aurora nor Beta. > > Then the new "MOZILLA-like" idea is to use moving aliases in the extension > > repositories, like COMM_AURORA, COMM_BETA and COMM_RELEASE, and to shift > > these (only) at each cycle. > > I support this proposal. > > When venkman starts to get coherent changes again we can probably do this > just fine, until then staying default for branches is even easier than using > a specific tag. IMO. The problem with default is that it can (in theory) break any time, which is fine for trunk, but not so much for Beta (and Aurora to a little lesser degree). And it certainly is a problem for Release, but you already confirmed that.

Jens, patch Av1-CZ won't apply (cleanly) on comm-beta: please apply it manually, and while there add blank lines (like the other repo have).

Comment on attachment 602713 [details] [diff] [review] (Av1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_1_RELEASE [Checkin: Comment 6] http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c http://hg.mozilla.org/releases/comm-beta/rev/1732edd4de3d

(In reply to Justin Wood (:Callek) from comment #3) > So for background as to why this stunk, I hadn't been updating them since > 2.8 due to the "compat by default" thing, and admittedly my misunderstanding > of it. I assume "compat by default" works just fine for users. But there are 1+ tests that activate "strict compat" on purpose, so they report failures if (SeaMonkey) bundled extensions are not up-to-date :-| Though we could investigate whether a workaround at test level could be possible, the easiest(/better?) for now seems to continue to bump compatibility on the 3 add-ons. > Indeed it is wrong, but since we shipped already no real need to fix, we do > advertise that release repo should use the SEAMONKEY_FOO_RELEASE tag to get > the code, which the extension versions have. So if a user is following docs, > they should be good. I think we _do_ need to fix comm-release: 'default' (as a moving target) is not good for current 2.7.x and will not be good for upcoming 2.8+ either. Please, reconsider "approval-comm-release-". > This is a good idea, but I'd like to do that only when Venkman gets any real > changes/a new version out. Currently Venkman has not had a new version/real > changes in a long while. Of course, Venkman version release is up to that project, not SeaMonkey. (Though we can ask for it, if need be.) > Well in my current design, we only (plan) on updating client.py at aurora > uptake day to the "latest version available at that time" To account for > cases where something would change l10n. And that update should propogate > down to the other trains. And we continue testing |default| on trunk. I concur. Note: *Ftr, afaict, the client.py propagation needs to be manual at cycle shifts. *Extension compatibility bumps need to happen on Trunk at/soon_after each cycle shift. *comm-release current state is incoherent with that process, hence my request. > When venkman starts to get coherent changes again we can probably do this > just fine, until then staying default for branches is even easier than using > a specific tag. IMO. Not sure what you meant. The COMM_* proposal is to avoid updating client.py every 6 weeks for all 3 extensions, as in decouple it from extension version releases.

(In reply to Serge Gautherie (:sgautherie) from comment #7) > > Indeed it is wrong, but since we shipped already no real need to fix, we do > > advertise that release repo should use the SEAMONKEY_FOO_RELEASE tag to get > > the code, which the extension versions have. So if a user is following docs, > > they should be good. > > I think we _do_ need to fix comm-release: 'default' (as a moving target) is > not good for current 2.7.x and will not be good for upcoming 2.8+ either. > > Please, reconsider "approval-comm-release-". Two things a) The practice of updating client.py to include versions for extensions was only introduced recently, sometime in the last two cycles iirc, so the change just hasn't propagated yet, b) if you've not had loads of people complaining about compatibility, there's not much point in discussing about whether or not to land it with a little over a week to go for the next merge point (when it'll be picked up anyway), that's just a waste of time IMO. > > Well in my current design, we only (plan) on updating client.py at aurora > > uptake day to the "latest version available at that time" To account for > > cases where something would change l10n. And that update should propogate > > down to the other trains. And we continue testing |default| on trunk. > > I concur. > > Note: > *Ftr, afaict, the client.py propagation needs to be manual at cycle shifts. Nope. aurora -> beta and beta -> release is automatic. For trunk -> aurora we have a semi-automated script that inserts the versions: http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/file/b293b6ec5dec/comm-merges/doittrunk.sh#l27 I'm happy to accept agreed pushes to the extension tags (or requests via email if necessary), but I would like to be informed if/when people do push so that I can just keep an eye on the changes.

(In reply to Mark Banner (:standard8) from comment #8) > I'm happy to accept agreed pushes to the extension tags (or requests via > email if necessary) Can you clarify "extension tags"? Do you mean the ones we have right now, or the proposed ones (e.g. COMM_AURORA)? > but I would like to be informed if/when people do push > so that I can just keep an eye on the changes. Can we exclude simple version bumps here? I'd like to reduce the overhead as much as possible.

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #9) > (In reply to Mark Banner (:standard8) from comment #8) > > I'm happy to accept agreed pushes to the extension tags (or requests via > > email if necessary) > > Can you clarify "extension tags"? Do you mean the ones we have right now, or > the proposed ones (e.g. COMM_AURORA)? Did you look a at the link? Although I probably should have said revisions rather than tags - the revision that client.py will update to (which also could be a tag). > > but I would like to be informed if/when people do push > > so that I can just keep an eye on the changes. > > Can we exclude simple version bumps here? I'd like to reduce the overhead as > much as possible. Anything other than revision bumps, I'd want review on before push. Revision bumps I'd like to know they've happened anyway, but I'm not generally going to require review.

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #6) > http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c > http://hg.mozilla.org/releases/comm-beta/rev/1732edd4de3d seamonkey2.9 and seamonkey2.8: verified for CZ (only), per bug 730689. (In reply to Mark Banner (:standard8) from comment #8) > Two things a) The practice of updating client.py to include versions for > extensions was only introduced recently, sometime in the last two cycles > iirc, so the change just hasn't propagated yet, b) if you've not had loads Noted, I hadn't checked in details. Yet, I don't think that change should (have been) one to (wait to) propagate: in the meantime, comm-release (still) gets l10n changes that (have) happened on trunk, etc. > of people complaining about compatibility, there's not much point in > discussing about whether or not to land it with a little over a week to go > for the next merge point (when it'll be picked up anyway), that's just a > waste of time IMO. I thought it was better to fix this in the calm (just in case) rather than adding more load at next release time, but as you (have) decide. > Nope. aurora -> beta and beta -> release is automatic. For trunk -> aurora > we have a semi-automated script that inserts the versions: > > http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/file/ > b293b6ec5dec/comm-merges/doittrunk.sh#l27 Oh, good. I think that process+file should be documented in client.py, because it looks undiscoverable. Then, can you update doittrunk.sh to CHATZILLA_0_9_88_1_RELEASE too? (So it's not forgotten/missed and regressed.) > I'm happy to accept agreed pushes to the extension tags (or requests via > email if necessary), but I would like to be informed if/when people do push > so that I can just keep an eye on the changes. I think that review/email policy should be documented in client.py too, because it looks undiscoverable. (In reply to Mark Banner (:standard8) from comment #10) > (In reply to Jens Hatlak (:InvisibleSmiley) from comment #9) > > Can you clarify "extension tags"? Do you mean the ones we have right now, or > > the proposed ones (e.g. COMM_AURORA)? While you're here, what do you think about that COMM_* proposal? > Anything other than revision bumps I assume you meant _application_ compatibility bumps, didn't you?

(In reply to Serge Gautherie (:sgautherie) from comment #11) > (In reply to Jens Hatlak (:InvisibleSmiley) from comment #6) > > http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c > > http://hg.mozilla.org/releases/comm-beta/rev/1732edd4de3d > > seamonkey2.9 and seamonkey2.8: verified for CZ (only), per bug 730689. > > > (In reply to Mark Banner (:standard8) from comment #8) > > > Two things a) The practice of updating client.py to include versions for > > extensions was only introduced recently, sometime in the last two cycles > > iirc, so the change just hasn't propagated yet, b) if you've not had loads > > Noted, I hadn't checked in details. > Yet, I don't think that change should (have been) one to (wait to) > propagate: in the meantime, comm-release (still) gets l10n changes that > (have) happened on trunk, etc. Unless SM is doing something really weird, no-one should be landing things on comm-release/mozilla-release/l10n-release, except stuff for chemspill and merges. > I thought it was better to fix this in the calm (just in case) rather than > adding more load at next release time, but as you (have) decide. A merge takes the latest code from one repo, and shoves it in the other: i.e. zero additional work (assuming the first repo is correct). > Oh, good. I think that process+file should be documented in client.py, > because it looks undiscoverable. Not sure its entirely necessary, but I wouldn't be against it. > Then, can you update doittrunk.sh to CHATZILLA_0_9_88_1_RELEASE too? (So > it's not forgotten/missed and regressed.) I suggest that Callek tells me this is right and if he wants other changes before the next merge. > > I'm happy to accept agreed pushes to the extension tags (or requests via > > email if necessary), but I would like to be informed if/when people do push > > so that I can just keep an eye on the changes. > > I think that review/email policy should be documented in client.py too, > because it looks undiscoverable. Who's allowed to push is a repo thing not a file item. Generally its common courteously to ask to push to someone's user repo (I don't think we have set rules there) - I'm just giving an exclusion in this case. > (In reply to Mark Banner (:standard8) from comment #10) > > (In reply to Jens Hatlak (:InvisibleSmiley) from comment #9) > > > > Can you clarify "extension tags"? Do you mean the ones we have right now, or > > > the proposed ones (e.g. COMM_AURORA)? > > While you're here, what do you think about that COMM_* proposal? COMM_* sounds a bit too much like a branch to me, not a tag. I'd name it something else to avoid confusion. > > Anything other than revision bumps > > I assume you meant _application_ compatibility bumps, didn't you? No, I meant revision bumps for the extensions in doittrunk.sh.

for the doit* stuff, I have been just talking to Mark a few days before the uplift date as to what we want there. as for the compat bumps, to use as an example DOMi, which *has* l10n changes on |default| compared to the DOMI_2_10 branch, what I have been doing for bumps is to double-land, (as in, land on default, and transplant to the stable DOMI_2_10 branch) and we pull the tip of the branch. That is the sanest method to do this, imo. For things like cZ we can just create a named branch when we need to do this, but until then tags work fine. Overall I think the process of compat bumps and client.py bumps need not be closely tied together, and in fact should not be.

(In reply to Serge Gautherie (:sgautherie) from comment #0) > 28 'VENKMAN_REV': 'a38583d7164a', Callek, Branch: seamonkey-production http://hg.mozilla.org/build/buildbot-configs/rev/f542dd1ad682 { -releaseConfig['venkmanRepoRevision'] = 'a38583d7164a' +releaseConfig['venkmanRepoRevision'] = '65ad515ebba6' } was done to release SM 2.8b5, but it adds more confusion :-/ Though this is +/- what is wanted in bug 732745, pushing bug 730691 on top of a38583d7164a (and updating client.py) should be done instead.

(In reply to Serge Gautherie (:sgautherie) from comment #14) > was done to release SM 2.8b5, but it adds more confusion :-/ > > pushing bug 730691 on top of a38583d7164a (and updating client.py) should be > done instead. Ftr, this was/is not even needed for 2.8/beta, it is wanted for 2.9/aurora only. But as well apply that to both repositories, I agree.

(In reply to Serge Gautherie (:sgautherie) from comment #14) > Though this is +/- what is wanted in bug 732745, No progress on that bug: let's match client.py with build-release code! No l10n involved.

"a/12 -> a/13" cycle shift: http://hg.mozilla.org/releases/comm-aurora/rev/6b6a03301f18 "Fix broken client.py from release merge. a=auroramerge CLOSED TREE" is plain wrong! Mark, can you back that out and revert to http://hg.mozilla.org/releases/comm-aurora/file/0db16351395c/client.py which was just fine?

(In reply to Serge Gautherie (:sgautherie) from comment #17) > "a/12 -> a/13" cycle shift: > http://hg.mozilla.org/releases/comm-aurora/rev/6b6a03301f18 > "Fix broken client.py from release merge. a=auroramerge CLOSED TREE" > is plain wrong! No it isn't. It fixed what it was meant to fix which was the missing quotes, I had not been directly notified or provided with a pushed changeset about the additional change as I asked to have been (and I had forgotten about this bug, hence why I want people to update the file & notify me). > Mark, can you back that out and revert to > http://hg.mozilla.org/releases/comm-aurora/file/0db16351395c/client.py > which was just fine? No, a backout is wrong here. I have instead transplanted the original changeset: (orig) http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c (new) http://hg.mozilla.org/releases/comm-aurora/rev/728bd5650d8c I've also updated the merge script to include the change to the chatzilla revision and to fix the missing quotes/lines issue which was the need for that bustage fix: http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/rev/1a3877166efc

Comment on attachment 605003 [details] [diff] [review] (Bv1-V) client.py: Upgrade VENKMAN_REV to '65ad515ebba6' Whoever reviews this first.

Comment on attachment 605003 [details] [diff] [review] (Bv1-V) client.py: Upgrade VENKMAN_REV to '65ad515ebba6' Syntax is right, rev I'd like is wrong. Lets go with b6a784fb2a54 instead (which is the newest bump, no other changes since the one you posted here). I don't want this landed on c-r, but with that change good to go.

Bv1-V, with comment 20 suggestion(s).

Comment on attachment 606947 [details] [diff] [review] (Bv1a-V) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 22] http://hg.mozilla.org/releases/comm-beta/rev/17aac9f7b05b [Serge, I guess you hand-edited this; patch was for Aurora so I had to manually fix it for Beta.]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Beta/1332071783.1332076085.10987.gz WINNT 5.2 comm-beta debug test mochitest-other on 2012/03/18 04:56:23 seamonkey2.9: verified.

(In reply to Jens Hatlak (:InvisibleSmiley) from comment #22) > [Serge, I guess you hand-edited this; patch was for Aurora so I had to > manually fix it for Beta.] PS: Ah, the "MOZILLA_REPO" context line. Well, yes :-|

Comment on attachment 606947 [details] [diff] [review] (Bv1a-V) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 22] Mark, f? to let you know to sync' doit-central2aurora.sh.

(In reply to Mark Banner (:standard8) from comment #18) > (In reply to Serge Gautherie (:sgautherie) from comment #17) > > "a/12 -> a/13" cycle shift: > > http://hg.mozilla.org/releases/comm-aurora/rev/6b6a03301f18 > > "Fix broken client.py from release merge. a=auroramerge CLOSED TREE" > > is plain wrong! > > No it isn't. It fixed what it was meant to fix which was the missing quotes, I said "wrong" because I don't even understand how that changeset could apply, as the unquoted lines existed neither in central nor in aurora prior to the merge :-< (And I don't understand either how the blank lines, that were in both repositories, just vanished. (Though probably for the same reason.)) To me, it looks like there is something very odd in the cycle shift process... > I had not been directly notified or provided with a pushed changeset about > the additional change as I asked to have been (and I had forgotten about > this bug, hence why I want people to update the file & notify me). I don't know what happened: per comment 13, it seemed to me that would (have) be managed between Callek and you :-/ > > Mark, can you back that out and revert to > > http://hg.mozilla.org/releases/comm-aurora/file/0db16351395c/client.py > > which was just fine? > > No, a backout is wrong here. I have instead transplanted the original Well, either way, I'm only interested in the result. > changeset: > > (orig) http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c > (new) http://hg.mozilla.org/releases/comm-aurora/rev/728bd5650d8c Could you put the blank lines back in too? > I've also updated the merge script to include the change to the chatzilla > revision and to fix the missing quotes/lines issue which was the need for > that bustage fix: Thanks.

Comment on attachment 606947 [details] [diff] [review] (Bv1a-V) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 22] done http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/rev/f2cab155c881

(In reply to Serge Gautherie (:sgautherie) from comment #26) > (In reply to Mark Banner (:standard8) from comment #18) > > > (In reply to Serge Gautherie (:sgautherie) from comment #17) > > > "a/12 -> a/13" cycle shift: > > > http://hg.mozilla.org/releases/comm-aurora/rev/6b6a03301f18 > > > "Fix broken client.py from release merge. a=auroramerge CLOSED TREE" > > > is plain wrong! > > > > No it isn't. It fixed what it was meant to fix which was the missing quotes, > > I said "wrong" because I don't even understand how that changeset could > apply, as the unquoted lines existed neither in central nor in aurora prior > to the merge :-< The merge process closes the old branch, pulls everything across from the relevant repo (in this case comm-central). The tags, version bumps are all manual, or semi-automated in this case. If you look at the pushlog you'll see all the changesets pushed, including some that weren't in comm-central e.g. right at the top of that list: http://hg.mozilla.org/releases/comm-aurora/rev/f18ea070b063 > > changeset: > > > > (orig) http://hg.mozilla.org/releases/comm-aurora/rev/0db16351395c > > (new) http://hg.mozilla.org/releases/comm-aurora/rev/728bd5650d8c > > Could you put the blank lines back in too? Its cosmetic, fixed for future and it'll got away in a couple of cycles. I'm not going to do anything more here.

Bv1a-V, plus re-adding lost blank lines. (In reply to Mark Banner (:standard8) from comment #28) > Its cosmetic, fixed for future and it'll got away in a couple of cycles. I'm > not going to do anything more here. Future: agreed, it looks like we should now be ready for the next uplift :-) Cosmetic: not only, it also simplifies (context) updating both aurora and beta...

Comment on attachment 607250 [details] [diff] [review] (Bv1a-V-a13) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 30] http://hg.mozilla.org/releases/comm-aurora/rev/cfe6fdbff36d

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Aurora/1332243422.1332248085.18723.gz OS X 10.5 comm-aurora debug test mochitest-other on 2012/03/20 04:37:02 seamonkey2.10: verified.

Just a minor change + number increase.

Comment on attachment 607711 [details] [diff] [review] (Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36] Review of attachment 607711 [details] [diff] [review]: ----------------------------------------------------------------- Shipped 2.9 beta with that tag as well. So go for it.

Jens, please manually fix the "MOZILLA_REPO" line context for beta/2.9.

Comment on attachment 607711 [details] [diff] [review] (Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36] Mark, f? to let you know to sync' doit-central2aurora.sh.

Comment on attachment 607711 [details] [diff] [review] (Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36] http://hg.mozilla.org/releases/comm-aurora/rev/5e1ec73b4546 http://hg.mozilla.org/releases/comm-beta/rev/431700c61c93

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Aurora/1332816082.1332822290.19715.gz&fulltext=1 WINNT 5.2 comm-aurora debug test mochitest-other on 2012/03/26 19:41:22 { TEST-PASS | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_checkAddonCompatibility.js | extension JavaScript Debugger 0.9.89 should be compatible } http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Beta/1332846568.1332850586.10007.gz&fulltext=1 Linux comm-beta debug test mochitest-other on 2012/03/27 04:09:28 { TEST-PASS | chrome://mochitests/content/browser/suite/browser/test/browser_bug728651.js | JavaScript Debugger 0.9.89 should be compatible }

DOMi had l10n changes since its v2.0.10. I don't know whether that is a problem or not...

Callek, what about approvals for patch Dv1-DOMi? Ewong, I see SM 2.9b3 uses CHATZILLA_0_9_88_2_RELEASE. I planned to do that (here), yet could we actually get some synchronization and stop releasing what we have never built before?

I made it so that 2.9b3 shipped CZ 0.9.88.2 and I did that since .2 was a noticeable regression fix, so better than even waiting for this.

[Approval Request Comment] Resync' with comment 40.

Comment on attachment 614977 [details] [diff] [review] (Ev1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_2_RELEASE [Checkin: Comment 42] http://hg.mozilla.org/releases/comm-aurora/rev/0f053ea9bf9e http://hg.mozilla.org/releases/comm-beta/rev/d40a0933b16d

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] not touching 2.9 with it.

Comment on attachment 607711 [details] [diff] [review] (Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36] Updated, thanks: http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/rev/36ac3a2baed4

(In reply to Mark Banner (:standard8) from comment #44) > http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/rev/ > 36ac3a2baed4 Rather: http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/rev/95c97ff64cc9 "Update Chatzilla & Venkman revs as per bug 732749"

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] (In reply to Justin Wood (:Callek) from comment #43) > not touching 2.9 with it. Resetting for SM 2.10.

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] NB: DOMi 2.0.12 has been released (with no additional l10n changes) in the meantime, so let's upgrade to it.

Note: DOMi 2.0.12 has not yet been released. That will happen May 30. See bug 746784. The only changes that are allowed on the DOMI_2_0_12 branch over the next five weeks are l10n changes and, if anyone comes up with a fix concerning the problem in bug 688183/bug 727515. Since there were no string changes since 2.0.11, "l10n changes" really means bringing old localizations up to date. Greek will be added for sure.

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] As mentioned in comment 48 look at bug 746784. It would be good to come up with a way for beta/aurora automagically knowing which branch to pull from without having to keep bumping the number up in this file. For the moment this will do (until 30th May).

Note this will fix 2.10b1+, though not 2.11a2+. Yet let's do that first.

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] http://hg.mozilla.org/releases/comm-aurora/rev/96a0c6323876 http://hg.mozilla.org/releases/comm-beta/rev/a819fa504ee8

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Beta/1338450033.1338455488.1807.gz&fulltext=1 OS X 10.6 comm-beta debug test mochitest-other on 2012/05/31 00:40:33 seamonkey2.10(b3): verified.

[Approval Request Comment] Wrt strict compatibility, this is "required" for SM 2.11a2 and "optional" for SM 2.10b3+.

(In reply to Serge Gautherie (:sgautherie) from comment #0) > Then the new "MOZILLA-like" idea is to use moving aliases in the extension > repositories, like COMM_AURORA, COMM_BETA and COMM_RELEASE, and to shift > these (only) at each cycle. > I support this proposal. (In reply to Justin Wood (:Callek) from comment #3) > (In reply to Serge Gautherie (:sgautherie) from comment #0) > > Who can decide? (Callek? Ian? Council?) > > Any of the above? (In reply to Ian Neal from comment #49) > As mentioned in comment 48 look at bug 746784. It would be good to come up > with a way for beta/aurora automagically knowing which branch to pull from That would deserve a follow-up bug now. (This bug is eventually to catch-up with current extension releases only.) > without having to keep bumping the number up in this file. If we don't care too much about harder-to-track history, I already proposed a solution in comment 0 ... which is "independent" from DOMi (new) release process.

(In reply to Serge Gautherie (:sgautherie) from comment #54) > If we don't care too much about harder-to-track history, That means people would have to explicitly use existing 'SEAMONKEY_2_9_RELEASE'-like revisions to build obsolete releases. (I assume that should be enough.) Or, for more explicit history, client.py would have (for example) to parse http://mxr.mozilla.org/mozilla-central/source/config/milestone.txt and use tag/branch revisions like "COMM_<geckoVersion>". (I think that would be overkill.) NB: We will always need to update either comm-* or the extension repositories, yet it's assumed to be better to update data (= ext.repo.) than code (client.py) ;-|

Something really odd happened again in DOMi repo: "Added tag SEAMONKEY_2_10b3_BUILD1 for changeset DOMI_2_0_11_RELEASE." and "Added tag SEAMONKEY_2_10b3_RELEASE for changeset DOMI_2_0_11_RELEASE." are on 'DOMI_2_0_10' branch, which doesn't have 'DOMI_2_0_11_RELEASE' tag in its ancestry :-/ Callek, Ewong, could check+fix this?

(In reply to Serge Gautherie (:sgautherie) from comment #56) > Something really odd happened again in DOMi repo: > > "Added tag SEAMONKEY_2_10b3_BUILD1 for changeset DOMI_2_0_11_RELEASE." > and > "Added tag SEAMONKEY_2_10b3_RELEASE for changeset DOMI_2_0_11_RELEASE." > are on 'DOMI_2_0_10' branch, which doesn't have 'DOMI_2_0_11_RELEASE' tag in > its ancestry :-/ > > Callek, Ewong, could check+fix this? Ok, we did requesting all changes adding changesets adding manifests adding file changes added 1453 changesets with 5016 changes to 770 files (+41 heads) updating to branch default 540 files updated, 0 files merged, 0 files removed, 0 files unresolved 15 files updated, 0 files merged, 6 files removed, 0 files unresolved Updated to revision b6de3a5ce573ef015d0205070af30d3d1a9981f3. Which is the cset for 2.11, it was just a slight mistake in our configs which caused the tag to be on a weird branch. Luckily that didn't break anything this time, but even if we ended up shipping 2.10 I wouldn't have rebuilt, but I can verify we built with DOMi 2.11 so all is good, even if it looks funky

(In reply to Justin Wood (:Callek) from comment #57) > Which is the cset for 2.11, it was just a slight mistake in our configs I confirm SEAMONKEY_2_10b3_BUILD1 and SEAMONKEY_2_10b3_RELEASE tags were added to DOMI_2_0_11_RELEASE revision, as wanted. > which caused the tag to be on a weird branch. Luckily that didn't break > anything this time, but even if we ended up shipping 2.10 I wouldn't have > rebuilt, but I can verify we built with DOMi 2.11 so all is good, even if it > looks funky I won't insist on fixing the current situation :-| My main concern was that this doesn't happen again on next builds...

Comment on attachment 609749 [details] [diff] [review] (Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] Taken note.

I thought I had CCed myself on this already. I wrote a thing. bug 763506, comment 1.

Comment on attachment 628701 [details] [diff] [review] (Fv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_12' [Checkin: Comment 61] https://hg.mozilla.org/releases/comm-aurora/rev/67ce40b2b52d https://hg.mozilla.org/releases/comm-beta/rev/c3aa78c5cc03

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Aurora/1340660031.1340663040.27398.gz WINNT 5.2 comm-aurora debug test mochitest-other on 2012/06/25 14:33:51 { TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_checkAddonCompatibility.js | extension ChatZilla 0.9.88.2 should be compatible TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_checkAddonCompatibility.js | extension DOM Inspector 2.0.12 should be compatible TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/browser/browser_checkAddonCompatibility.js | extension JavaScript Debugger 0.9.89 should be compatible } which are expected atm :-| http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Beta/1340656889.1340660594.24088.gz WINNT 5.2 comm-beta debug test mochitest-other on 2012/06/25 13:41:29 passes tests. seamonkey2.12 and seamonkey2.11: verified. SeaMonkey is now packaging the latest extension versions :-)