trees orange, and that's OK for fx3rc1 shipping
Axel Hecht
we got another string removal landing thanks to bug 430217, and I'm
discussing with 1.9-drivers what to do about it. Right now, just leave
that thing alone, it won't impact our shipping anyway.
Possible remedies include:
- leaving things as is
- putting the strings back into en-US (with a localization note that
they're not used)
- me creating a patch to mass-remove them.
The latter might happen for RC1 or not, and it's going to be easier for
me if I don't have to include individual locales with this fixed, thus:
The Firefox 3 tree is frozen for shipping locales, and I'm not approving
fixes for this issue right now.
It's "ugh", but we'll get over it.
Axel
Ricardo Palomares Martínez
> we got another string removal landing thanks to bug 430217, and I'm
> discussing with 1.9-drivers what to do about it. Right now, just leave
> that thing alone, it won't impact our shipping anyway.
>
> Possible remedies include:
> - me creating a patch to mass-remove them.
>
> The latter might happen for RC1 or not, and it's going to be easier for
> me if I don't have to include individual locales with this fixed, thus:
>
> The Firefox 3 tree is frozen for shipping locales, and I'm not approving
> fixes for this issue right now.
Any news on this? I know I'm too conservative, but I'm refraining from
committing changes to SeaMonkey and Thunderbird just in case it could
disturb your search to prepare the mass commit for the above issue.
On a slightly different topic, I've checked-out en-US to get the
change in pipnss.properties, and I've got also a change in
dom.properties. Siarhei already commented on this [1], and you
commented in the bug [2], but it looks like no final position arose
about if we should just ignore these changes, file a bug to request
approval, wait until after Fx3 release... :-?
TIA
[1]
http://groups.google.com/group/mozilla.dev.planning/msg/9568537de2e57e8e
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=402181
Axel Hecht
> Axel Hecht escribió:
>> we got another string removal landing thanks to bug 430217, and I'm
>> discussing with 1.9-drivers what to do about it. Right now, just leave
>> that thing alone, it won't impact our shipping anyway.
>>
>> Possible remedies include:
>> (...)
>> - me creating a patch to mass-remove them.
>>
>> The latter might happen for RC1 or not, and it's going to be easier for
>> me if I don't have to include individual locales with this fixed, thus:
>>
>> The Firefox 3 tree is frozen for shipping locales, and I'm not approving
>> fixes for this issue right now.
>
>
> Any news on this? I know I'm too conservative, but I'm refraining from
> committing changes to SeaMonkey and Thunderbird just in case it could
> disturb your search to prepare the mass commit for the above issue.
Too conservative, but thanks. I have a bonsai query now which is just
looking at shipping locales and firefox-impact dirs. That's good enough
for me to see silence, or lack thereof.
> On a slightly different topic, I've checked-out en-US to get the
> change in pipnss.properties, and I've got also a change in
> dom.properties. Siarhei already commented on this [1], and you
> commented in the bug [2], but it looks like no final position arose
> about if we should just ignore these changes, file a bug to request
> approval, wait until after Fx3 release... :-?
>
For bug 402181 and dom.properties, please file a bug and attach a patch,
requesting approval1.9. Not sure when we're going to take it, in this
particular case I probably wouldn't even care so much if we pull RC1
with such a change or not.
For pipnss.properties, a follow-up bug for in "Others" to do a tree-wide
clean-up would probably be good. Mind filing that, depending on bug
430217? I won't approve per-locale patches for that one, though, that's
just too much noise for the win.
Axel
Robert Kaiser
> For pipnss.properties, a follow-up bug for in "Others" to do a tree-wide
> clean-up would probably be good. Mind filing that, depending on bug
> 430217? I won't approve per-locale patches for that one, though, that's
> just too much noise for the win.
You actually mean reporterOverlay.dtd?
Robert Kaiser
Axel Hecht
Yeah, sorry.
Axel
Ricardo Palomares Martinez
> Ricardo Palomares Martínez wrote:
>> On a slightly different topic, I've checked-out en-US to get the
>> change in pipnss.properties, and I've got also a change in
>> dom.properties. Siarhei already commented on this [1], and you
>> commented in the bug [2], but it looks like no final position arose
>> about if we should just ignore these changes, file a bug to request
>> approval, wait until after Fx3 release... :-?
>>
>
> For bug 402181 and dom.properties, please file a bug and attach a patch,
> requesting approval1.9. Not sure when we're going to take it, in this
> particular case I probably wouldn't even care so much if we pull RC1
> with such a change or not.
Sorry for the delay. Here it is:
https://bugzilla.mozilla.org/show_bug.cgi?id=432901
I'm not sure if that bug should block es-ES release tracker (415991).
> For pipnss.properties, a follow-up bug for in "Others" to do a tree-wide
> clean-up would probably be good. Mind filing that, depending on bug
> 430217? I won't approve per-locale patches for that one, though, that's
> just too much noise for the win.
wladow filed it (https://bugzilla.mozilla.org/show_bug.cgi?id=432059),
thanks, Vlado, but maybe you needed to be CCed? I've added you.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Axel Hecht
Hi all,
I landed Vlado's patch, trees should go back to green.
Please cvs update extensions/reporter/chrome/reporterOverlay.dtd, and
make sure that you resolve any cvs conflicts.
Thanks
Axel