Closed Bug 1267273 Opened 4 years ago Closed 4 years ago

Bug 777732 modified idls without reving UUIDs

Categories

(MailNews Core :: Composition, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: clokep, Unassigned)

References

Details

Ran into this while doing the aurora merge:

remote: *************************** ERROR ***************************
remote: Push rejected because the following IDL interfaces were
remote: modified without changing the UUID:
remote:   - nsIMsgCompose in changeset 158bced7b129
remote:   - nsIMsgComposeService in changeset 158bced7b129
remote: 
remote: To update the UUID for all of the above interfaces and their
remote: descendants, run:
remote:   ./mach update-uuids nsIMsgCompose nsIMsgComposeService
remote: 
remote: If you intentionally want to keep the current UUID, include
remote: 'IGNORE IDL' in the commit message.
remote: *************************************************************

If you rev this please upstream to aurora.
Flags: needinfo?(mozilla)
Also, I'm curious why I'm hitting this only for comm-aurora and people didn't run into this for comm-central? Anyone have an idea who I'd needinfo about that?
Also, talking to release drivers for Firefox...this shouldn't be a thing anymore as binary extensions are no longer allowed.

What is our policy about this? If it matches Firefox, why is this hook still running on c-a? If it doesn't match Firefox, why is this hook NOT running on c-c?
No idea. I landed https://hg.mozilla.org/comm-central/rev/158bced7b129 myself and didn't run into problems.

There's been a lot of discussion on dev-platform about *not* changing the UUID:
https://groups.google.com/d/msg/mozilla.dev.platform/HE1_qZhPj1I/rElS7KjXAQAJ
https://groups.google.com/d/msg/mozilla.dev.platform/n6qBpyxoI6I/4qxwFvBOAgAJ

Could you fix it by adding 'IGNORE IDL' in the commit message?

Your message to thunderbird-drivers said that you're done, so you must have pushed through somehow.
Flags: needinfo?(mozilla)
Yes, there's a workaround I used ("a=release" is a magic string for uplifts), see http://hg.mozilla.org/releases/comm-aurora/rev/2146667144bc
I used to think ba=something ("binary approval") would make it work, and I see that in some Firefox merge related commits. It may actually just match the a= pattern though.

revving was indeed removed for m-* repos, I think we should do the same and remove any hooks if they exist.
Kent, do you have an opinion here? I could rev the UUID of nsIMsgCompose.idl and nsIMsgComposeService.idl on trunk (TB 49) and uplift to Aurora (TB 48). That would fix the omission.

That's a five minute job. Otherwise it's a WONTFIX.
Flags: needinfo?(rkent)
We have not had any specific agreements on this, but I am working under the assumption that binary extensions will no longer be supported in Thunderbird after version 45. Note that, in contrast to FF, we still are doing binary extensions in Thunderbird 45.

I will be monitoring mozilla-esr45 checkins, and plan to do variant patches if needed to continue our binary extension support in esr45 even though the FF folks are allowed to checkin breaking patches into mozilla-esr45. This process is marginal for esr45, hence my assumption that it will be completely untenable for esr52.

But for checkins to comm repos post-45, there is no real requirement to keep rolling UUIDs for changes.
Flags: needinfo?(rkent)
Thanks for the info Kent!
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
But we should fix the bit that gives you trouble during the uplifts, right?
Yes, I need to poke people about that. I'll file a separate bug for that.
(In reply to Patrick Cloke [:clokep] from comment #10)
> Yes, I need to poke people about that. I'll file a separate bug for that.

This was done in bug 1268161.
You need to log in before you can comment on or make changes to this bug.