Last Comment Bug 732749 - client.py: review SeaMonkey policy about which extension revisions are packaged
: client.py: review SeaMonkey policy about which extension revisions are packaged
Status: RESOLVED FIXED
[fixed in SM2.8: Av1-CZ; SM2.9: Bv1a-...
:
Product: SeaMonkey
Classification: Client Software
Component: Build Config (show other bugs)
: Trunk
: All All
: P2 major (vote)
: seamonkey2.12
Assigned To: Serge Gautherie (:sgautherie)
:
Mentors:
http://mxr.mozilla.org/comm-central/s...
Depends on: DOMi2.0.11 cZ_0.9.88.1 Venkman_0.9.89 736346 748634
Blocks: 763506 768320 768338 768340
  Show dependency treegraph
 
Reported: 2012-03-03 17:21 PST by Serge Gautherie (:sgautherie)
Modified: 2012-10-02 06:07 PDT (History)
8 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
wontfix
fixed
verified
verified
verified
verified


Attachments
(Av1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_1_RELEASE [Checkin: Comment 6] (899 bytes, patch)
2012-03-04 06:13 PST, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
bugspam.Callek: approval‑comm‑release-
Details | Diff | Splinter Review
(Bv1-V) client.py: Upgrade VENKMAN_REV to '65ad515ebba6' (833 bytes, patch)
2012-03-12 10:46 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
bugspam.Callek: approval‑comm‑release-
Details | Diff | Splinter Review
(Bv1a-V) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 22] (846 bytes, patch)
2012-03-18 00:22 PDT, Serge Gautherie (:sgautherie)
no flags Details | Diff | Splinter Review
(Bv1a-V-a13) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 30] (850 bytes, patch)
2012-03-19 12:18 PDT, Serge Gautherie (:sgautherie)
no flags Details | Diff | Splinter Review
(Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36] (853 bytes, patch)
2012-03-20 14:03 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
Details | Diff | Splinter Review
(Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51] (947 bytes, patch)
2012-03-27 09:33 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
iann_bugzilla: approval‑comm‑aurora+
iann_bugzilla: approval‑comm‑beta+
Details | Diff | Splinter Review
(Ev1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_2_RELEASE [Checkin: Comment 42] (911 bytes, patch)
2012-04-13 18:05 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
Details | Diff | Splinter Review
(Fv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_12' [Checkin: Comment 61] (939 bytes, patch)
2012-05-31 06:36 PDT, Serge Gautherie (:sgautherie)
bugspam.Callek: review+
bugspam.Callek: approval‑comm‑aurora+
bugspam.Callek: approval‑comm‑beta+
Details | Diff | Splinter Review

Description Serge Gautherie (:sgautherie) 2012-03-03 17:21:55 PST
[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?)
Comment 1 Serge Gautherie (:sgautherie) 2012-03-04 06:13:45 PST
Created attachment 602713 [details] [diff] [review]
(Av1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_1_RELEASE [Checkin: Comment 6]

*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 2 Justin Wood (:Callek) 2012-03-04 12:38:49 PST
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.
Comment 3 Justin Wood (:Callek) 2012-03-04 12:46:04 PST
(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?
Comment 4 Jens Hatlak (:InvisibleSmiley) 2012-03-04 13:11:58 PST
(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.
Comment 5 Serge Gautherie (:sgautherie) 2012-03-04 13:25:29 PST
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 6 Jens Hatlak (:InvisibleSmiley) 2012-03-04 13:37:54 PST
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
Comment 7 Serge Gautherie (:sgautherie) 2012-03-04 13:55:50 PST
(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.
Comment 8 Mark Banner (:standard8) (afk until 26th July) 2012-03-05 00:54:53 PST
(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.
Comment 9 Jens Hatlak (:InvisibleSmiley) 2012-03-05 01:35:30 PST
(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.
Comment 10 Mark Banner (:standard8) (afk until 26th July) 2012-03-05 01:59:32 PST
(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.
Comment 11 Serge Gautherie (:sgautherie) 2012-03-05 04:41:12 PST
(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?
Comment 12 Mark Banner (:standard8) (afk until 26th July) 2012-03-05 05:13:40 PST
(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.
Comment 13 Justin Wood (:Callek) 2012-03-05 14:35:31 PST
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.
Comment 14 Serge Gautherie (:sgautherie) 2012-03-06 07:42:37 PST
(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.
Comment 15 Serge Gautherie (:sgautherie) 2012-03-06 07:52:04 PST
(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.
Comment 16 Serge Gautherie (:sgautherie) 2012-03-12 10:46:15 PDT
Created attachment 605003 [details] [diff] [review]
(Bv1-V) client.py: Upgrade VENKMAN_REV to '65ad515ebba6'

(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.
Comment 17 Serge Gautherie (:sgautherie) 2012-03-14 20:59:43 PDT
"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?
Comment 18 Mark Banner (:standard8) (afk until 26th July) 2012-03-16 02:19:55 PDT
(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 19 Serge Gautherie (:sgautherie) 2012-03-16 13:34:04 PDT
Comment on attachment 605003 [details] [diff] [review]
(Bv1-V) client.py: Upgrade VENKMAN_REV to '65ad515ebba6'

Whoever reviews this first.
Comment 20 Justin Wood (:Callek) 2012-03-17 23:27:36 PDT
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.
Comment 21 Serge Gautherie (:sgautherie) 2012-03-18 00:22:39 PDT
Created attachment 606947 [details] [diff] [review]
(Bv1a-V) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 22]

Bv1-V, with comment 20 suggestion(s).
Comment 22 Jens Hatlak (:InvisibleSmiley) 2012-03-18 02:06:34 PDT
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.]
Comment 23 Serge Gautherie (:sgautherie) 2012-03-18 13:58:24 PDT
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.
Comment 24 Serge Gautherie (:sgautherie) 2012-03-18 21:48:37 PDT
(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 25 Serge Gautherie (:sgautherie) 2012-03-18 21:55:41 PDT
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.
Comment 26 Serge Gautherie (:sgautherie) 2012-03-18 22:11:19 PDT
(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 27 Mark Banner (:standard8) (afk until 26th July) 2012-03-19 03:50:03 PDT
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
Comment 28 Mark Banner (:standard8) (afk until 26th July) 2012-03-19 03:53:40 PDT
(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.
Comment 29 Serge Gautherie (:sgautherie) 2012-03-19 12:18:23 PDT
Created attachment 607250 [details] [diff] [review]
(Bv1a-V-a13) client.py: Upgrade VENKMAN_REV to 'b6a784fb2a54' [Checkin: Comment 30]

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 30 Jens Hatlak (:InvisibleSmiley) 2012-03-19 13:37:34 PDT
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
Comment 31 Serge Gautherie (:sgautherie) 2012-03-20 06:02:30 PDT
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.
Comment 32 Serge Gautherie (:sgautherie) 2012-03-20 14:03:03 PDT
Created attachment 607711 [details] [diff] [review]
(Cv1-V) client.py: Upgrade VENKMAN_REV to 'VENKMAN_RELEASE_0_9_89' [Checkin: Comment 36]

Just a minor change + number increase.
Comment 33 Justin Wood (:Callek) 2012-03-24 14:57:55 PDT
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.
Comment 34 Serge Gautherie (:sgautherie) 2012-03-24 19:20:26 PDT
Jens, please manually fix the "MOZILLA_REPO" line context for beta/2.9.
Comment 35 Serge Gautherie (:sgautherie) 2012-03-24 19:22:29 PDT
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 36 Jens Hatlak (:InvisibleSmiley) 2012-03-26 11:30:25 PDT
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
Comment 37 Serge Gautherie (:sgautherie) 2012-03-27 08:30:35 PDT
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
}
Comment 38 Serge Gautherie (:sgautherie) 2012-03-27 09:33:02 PDT
Created attachment 609749 [details] [diff] [review]
(Dv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_11_RELEASE' [Checkin: Comment 51]

DOMi had l10n changes since its v2.0.10.
I don't know whether that is a problem or not...
Comment 39 Serge Gautherie (:sgautherie) 2012-04-12 07:21:57 PDT
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?
Comment 40 Justin Wood (:Callek) 2012-04-12 09:49:51 PDT
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.
Comment 41 Serge Gautherie (:sgautherie) 2012-04-13 18:05:31 PDT
Created attachment 614977 [details] [diff] [review]
(Ev1-CZ) client.py: Upgrade to CHATZILLA_0_9_88_2_RELEASE [Checkin: Comment 42]

[Approval Request Comment]
Resync' with comment 40.
Comment 42 Jens Hatlak (:InvisibleSmiley) 2012-04-15 13:55:15 PDT
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 43 Justin Wood (:Callek) 2012-04-22 21:15:32 PDT
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 44 Mark Banner (:standard8) (afk until 26th July) 2012-04-24 07:23:39 PDT
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
Comment 45 Serge Gautherie (:sgautherie) 2012-04-24 08:20:01 PDT
(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 46 Serge Gautherie (:sgautherie) 2012-04-24 14:32:47 PDT
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 47 Serge Gautherie (:sgautherie) 2012-04-24 19:18:09 PDT
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.
Comment 48 Colby Russell :crussell (no longer Mozilla-ing) 2012-04-25 08:13:47 PDT
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 49 Ian Neal 2012-05-15 14:37:46 PDT
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).
Comment 50 Serge Gautherie (:sgautherie) 2012-05-15 20:19:15 PDT
Note this will fix 2.10b1+, though not 2.11a2+. Yet let's do that first.
Comment 51 Jens Hatlak (:InvisibleSmiley) 2012-05-30 13:05:57 PDT
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
Comment 52 Serge Gautherie (:sgautherie) 2012-05-31 05:40:59 PDT
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.
Comment 53 Serge Gautherie (:sgautherie) 2012-05-31 06:36:04 PDT
Created attachment 628701 [details] [diff] [review]
(Fv1-DOMi) client.py: Upgrade INSPECTOR_REV to 'DOMI_2_0_12' [Checkin: Comment 61]

[Approval Request Comment]
Wrt strict compatibility, this is "required" for SM 2.11a2 and "optional" for SM 2.10b3+.
Comment 54 Serge Gautherie (:sgautherie) 2012-05-31 07:04:34 PDT
(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.
Comment 55 Serge Gautherie (:sgautherie) 2012-05-31 07:41:36 PDT
(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) ;-|
Comment 56 Serge Gautherie (:sgautherie) 2012-06-01 01:49:11 PDT
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?
Comment 57 Justin Wood (:Callek) 2012-06-01 08:21:18 PDT
(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
Comment 58 Serge Gautherie (:sgautherie) 2012-06-01 08:34:35 PDT
(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 59 Mark Banner (:standard8) (afk until 26th July) 2012-06-04 13:04:30 PDT
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.
Comment 60 Colby Russell :crussell (no longer Mozilla-ing) 2012-06-13 12:50:06 PDT
I thought I had CCed myself on this already.  I wrote a thing.  bug 763506, comment 1.
Comment 61 Ryan VanderMeulen [:RyanVM] 2012-06-25 07:08:59 PDT
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
Comment 62 Serge Gautherie (:sgautherie) 2012-06-25 21:27:28 PDT
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 :-)

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