70753 - [XUL1.0] Tracking bug for XUL 1.0 changes

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P2)

Description

[David Hyatt]

Yup.

Comment 1

[Peter Trudelle]

->mozilla1.0

Comment 2

[David Hyatt]

For those following this bug, no XUL syntax changes that result in incompatible
syntax will be allowed to land before the 0.8.1 freeze.  If you do produce
patches, hang on to them until then.  We need to wait for the new mailnews front
end to come in from the branch before we check in any of these changes.

Comment 3

[Mark Olson]

Two things:
Based on the coordination issues encountered with 70747 and 70746 (documented
mostly in bug 70746), I'd suggest some guidelines be set for coordinating with
commercial for XUL syntax landings.  Maybe once a XUL syntax change gets an r
and sr we can give commercial folks n number of days to catch up before landing?
 Also, what about external users that will be impacted?  Should npm.xpfe be
considered a wide enough distribution for warnings when these changes are imminent?

I'm not sure 1.0 is the right target if the recommended vendor branch milestone
is still 0.9.  Mozilla's XUL is already incompatible with Netscape's 6.0x
releases, it would be a real bummer to have several sets of incompatibilities
between 6.0x, whatever branches from 0.9, and mozilla 1.0...  Thoughts?

Comment 4

[Brendan Eich [:brendan]]

maolson: commercial can't mean just netscape.com's commercial build.  There are
lots of organizations, for-profit commercial or not, who depend on XUL standards
set by trunk cvs.mozilla.org code changes.  Coordinating all of these is hard,
and will slow down XUL evolution something fierce.

OTOH, the larger "XUL community" can't take much more incompatible change, IMO.
e.g., chatzilla now must fork to support Netscape 6/mozilla0.[678] and the new
label-based mozilla0.9.

Anyway, blake's changes were circling for weeks, as I understand it.  What value
of n (for n days) did you have in mind?

I think vendors can base betas on 0.9 provided we don't make *significant*
incompatible changes after this and before 1.0.  Maybe hyatt can prognosticate
on the likelihood of such.  Small changes are tricky; I'm not sure how to define
significant.  In my experience with JS, some changes are too obscure to affect
enough people to prevent the change from being made ASAP.

/be

Comment 5

[prass]

I totally agree with Maolson's suggestion. "n" can be a matter of 1 day in the 
least. It is just giving us a heads up when the landing is happening. In 
the 70736, 70737 case, Blake and Mao still coordinated it with us on the day of 
landing. Otherwise, AIM would have been in a really bad shape today.

Either posting to xpfe the plan to landing or sending a mail to 
seamonkey-internal will be greatly appreaciated. It just doesnt make sense to 
just catch up with the landings after it is done and just making the changes 
without testing.  (Although in this particular case, we did just that and things 
worked so nicely. Cant expect every change to be so well implemented though!)

Just my two cents. Thanks! 

Comment 6

[Jason Kersey]

Nominating for mozilla 0.9.  I think this stuff should be in in time for the .9
milestone, so we can have time to catch problems between .9 and 1.0.  Checking
in major syntax changes after .9 seems to me to be a bad idea, as .9 to 1.0
should be a ramp-down time, and a time to find any problems caused by the changes.  

As far as the Commercial vs. mozilla issue, I think we were a bit behind on what
was going on with this, and will make the effort to keep up.  If mao, blake, and
others could give us even a day to test the changes, and get up to speed on each
landing, it would be greatly appriciated.  I know this is not required, nor
should it be, but it would be very much appriciated.  I want to thank blake and
mao again, in public, for their help with getting AIM and the rest of commercial
up to speed.  Without it, we would not even have comm. builds to test the
changes on today.

Comment 7

[Peter Lairo]

Please keep in mind that one of these XUL thingies is keeping the Themes on
x.themes.org from installing (working):(

For that reason alone, I suggest: nsCatFood and mozilla0.9.1

Comment 8

[Peter Trudelle]

cc self, Added as blocker of MachV schedule tracking bug (102472), added meta
keyword, set Priority P2.  Need to finish spec, flesh out remaining tasks, get
r= for spec and plan.

Comment 9

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 10

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 11

[selmer (gone)]

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 12

[John Morrison]

-> move tracking bug to mozilla1.0.1 to get it off radar (although me 
personally is having difficulty in keeping the variety of keywords, radars, and 
other tracking systems straight. At one point, a 'meta' keyword would keep 
this off some queries, but anyways...).

Comment 13

[[e-mail]]

What about bug 132831? Suitable for nominating here?

Comment 14

[Håkan Waara]

Seems like this tracking bug is now fixed. All of its dependencies are fixed
(except for one bug, but that's not a API change and was mis-added to this bug,
AFAIK).  

Any objections to marking it FIXED?

Comment 15

[Peter Trudelle]

Tracking bugs don't fit the definition of 'fixed'.  resolving as wfm.