meeting starts in 30 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-06-27

meeting starts in 7 minutes - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-06-27

Hi rsx11m

hi rsx11m

hi frg IanN

hi

Hi njsg

ditto

meeting time - wiki.mozilla.org/SeaMonkey/StatusMeetings/2021-06-27

oops

Who's taking minutes?

me

thanks frg

Nominees for Friends of the Fish Tank?

hrosik and buc for the logger and WG9s for his cool patch rename script

seconded

Action Items

Nothing new from me. Need to do a cleanup for the website

wrt libera. Ony typo at least

But not really an action item.

frg: and there's been movement on the logbot too

IanN yes I am not sure we should publish yet because the cert issue?

frg: true, work in progress...

When that's sorted out, it'll have to be updated in the wiki (as some templates have a link to the now-old logbot)

frg: typo in announcement - "more just use you[r] favorite search engine"

hi WaltS48

rsx11m yes this one. Call me slacker. Wanted to do it for a few days now.

Hi WaltS48

oh, ok - thought you've missed it ;-)

In the wiki, some IRC links have already been updated, I changed some and Rainer changed others.

hi WaltS48

The url only works good in 2.53.8b1+ too.

Greetings, been playing on Windows.

hi WaltS48

there is at least one article with links to freenode that is now protected, so it can't be easily edited, at least not by non-admins

njsg current link or outdated? Maybe unlink the article then?

frg: you may want to add port 6697 explicitly, older cZ versions default to 9999 for irsc

frg: some links are actually still irc:, not ircs:, it's probably something else to change; (most of the time I just replaced the server name in the URL)

frg: this one wiki.mozilla.org/IRC

Status of the SeaMonkey Infrastructure

ewong: is still working on changes to the infra

Nothing from me. Will update compiler for 2.53.9. Maybe tackle switch to clang 11 for mac then too.

njsg seems they do no longer want irc: As of March 2020, IRC.mozilla.org has been permanently decommissioned

Would ignore it and unlink if linked from our pages.

Any news about updates?

hi i am here for a little while

Seemed to work fine other than for 2.53.7 en-US.

Hi again WG9s

frg: it does not seem to be linked by any page with "SeaMonkey" in the title

frg: I believe ewong was trying to automate the upload and update process

njsg then I would rest the case. Is marked outdated and I suspect no one will look there.

rust 1.53 is out I think

Yes. We could use it for the next release if we want to. By then should be in the release channel.

Status of the SeaMonkey Source Tree

All building I think.

Has the recent c-c breakage been oficially remedied?

Forgot the bug number.

frg: the webidl thing?

mapi?

IanN yes

frg: yep, we had a fix accepted then the whole thing got changed anyway

well after the 10th enhancement we will probably at the old code again :)

true, what with the change in Windows 11

Anyway 2.53 has a ton of new backports. Is this still source tree or already release?

gitlab is broken becuase of web components usage. Like mozilla they seem to follow the leader into the abyss :)

:S

Fixes it for now. I think JustOff should get the next FotFT award.

Need to get PerformanceObserver backported too. I don't know why this is really needed for production code but seems to pop up more and more. Waterfox already has it.

more fun for you frg

Release Train

Bug 1386021 so most of it is in probably.

2.53.8 is done. Just needs to be uploaded.

hopefully this coming week

If I understand correctly ewong wants to do it together with enabling updates.

Just need to make sure that no pre 2.53 users get updated. I think njsg recently tested and that was the case.

frg: we also need to make sure symbols are uploaded

IanN yes unless they kill our access first. Thought it was July?

Becuase of extensive l10n changes I already filed a bug for 2.53.9 Bug 1717528

Just so that we can sort it out early.

frg: yes, though it seems TB are also having problems getting a suitable alternative (bug 1608971)

Also please test the current unofficial builds for exntension and devtools breakage. I am going thru the mozilla patch queue for stylo and webext changes among others and if I pick a bad patch this might break things. Bad as in "lets remove things becuase we don't care about the past"

IanN well it will be fun when this get changed to be more like telemetry. But central is already broken for us so watch me don't care :)

Not a new, improved way to do those things?

WaltS48 crash reports?

WaltS48: new and improved way number 346

It is basically google breakpad so worst case for us I could pluck a crash report apart manually.

At least on Windows :)

frg: sort of, but mozilla forked it

Yes

Anyway release train. I have my hands full and not being able to do much with 2.57 currently. But given that 2.53 and 2.57 become colser every day not that important.

^closer

Extension Tracking

IanN I think you have fun with cZ

:?

frg: yes, adding all sorts of bits and pieces

native SASL support

8-)

Now that we more or less integrated the code do we need a third_party directory for license stuff?

frg: where's that?

c-c has a comm\third_party

but also some license stuff in mail.

frg: 7zip?

comm\mail\base\content\overrides\app-license.html

Maybe something to discuss later.

yup

2.Next, Planning, Feature List and Roundtable

BAU

bau++

keeping on keeping on

Hello! Since rust 1.53 was mentioned previously, I just wanted to report that compiling 2.53.9 beta1 pre on Arch Linux with rust 1.53 and clang 12 (and using system-nss -- thanks for the patch!) worked fine.

two steps forward one back :)

teruna thanks for confirming. nss is still unsupported. Seems they didn't change internal structures but need to go thru the bugs to be sure. But only after 78 is discontinued.

teruna: thanks

AOB?

too hot here currently

only 17C here today

24C and a bit muggy.

anyway, thanks for your time everyone, next meeting in 2 weeks time, same bat channel, same bat time

yepp

same new bat channel

28C and 55% humidity here

new and improved ;-)

this was the first meeting on the brand new network, right?

tomman: correct

tomman yes. Was planned later but freenode had other plans.

idiots

someone found the "self destruct" button :-/

for the nth time

ok, falling back asleep now

bye!

nn rsx11m

They are now in the freenode zone. Reminds me of the Greater East Asia Co-Prosperity Sphere which ended the same way. With a bang...

actually the freenode digital autonomous zone

see you next time

see you

"everything grayed out is copied without translating"

...except that's not how this works

Pontoon seems to highlight in gray odd stuff, like raw XML or strange punctuation

yet there is this es-AR maintainer that interprets it as "copy it verbatim"

most of my translations (mainly from stuff like <command-arguments>) got reverted

wiki.mozilla.org/L10n:Teams:es-AR/Style_Guide their style guide says nothing about that supposedly "grayed out" text

If the es-AR cZ locale ends sucking, don't blame me :/

to be fair, this doesn't make a new contributor feel comfortable, but then, it's not my first rodeo

tomman we can always put it in our l10n if it sucks and you and unable to push a correction.

frg_Away: I need to look for proper communication channels with the maintainers, that's for sure

better know what's the proper criteria instead of getting my improvements reverted by clear machine-translation or Spanglish crap

tomman The current pushes are here hg.mozilla.org/l10n-central/es-AR

Maybe ask one of the two doing them for advice?

worst case grab the source files change them and send them to me. I will put them in 2.53 and 2.57 then. Just need to be careful when I or IanN_Away sync new stuff.

Wanted.

A tarball, 278Mb, xzipped, a source inside.

The finder will be the first to receive information about new errors in it. :)

Quickest way is to get it from gitlab.com/seamonkey-project/seamon…ey-2.53-mozilla/-/tree/2_53_8_final and the comm dir from gitlab.com/seamonkey-project/seamonkey-2.53-comm/-/tree/2_53_8_final

frg: Yep, it is suitable for individuals. But the distributions want the same tarball (bit to bit) as will be published in the official upstream. So we are compelled to wait for, and then our users wait one or two weeks while the new update is in the "testing" distro branches. And only then you will know about new bugs... :)

Star Trek has the answer: A difference which makes no difference is no difference

The release was done with this source code bit by bit.

Well, sha sum matches as well? (Including timestamps etc.)

It is surely possible to create tarball with the *same" source, but because of different timestamps, different file order, different program to create tar and xz, the final sha sum will be changed. Which is not allowed bu the distros' policies. It is the reason why the final tarball is wanted right now.

wtf

shouldn't the hashes that matter are from the actual tarball contents?

tomman: another timestamps, another order of files etc. can lead to dirrerence in the checksums.

I get that (metadata changes of course will lead to distinct tarball hashes), but are we shouldn't be looking at the actual contents?

to be fair, distros policies sometimes are ridiculously rigid in that sense

tomman: These are rules that have been formed over the years. Apparently there is a reason for this. All the successful distros have such ones.

frg: Well, I've prepared "a final form" tarballs from the gitlab code. Just to check whether it differs with the future "official" ones... buc.me/tmp-2.53.8

It's sad that no one except me and WG9s has the ability to upload anything on a controlled server. :( Especially considering that this happens in the context of a classic "open source" project. Something goes wrong. And it is actually toxic. (Me is angry and going to walk).

tomman Seems ### DO NOT LOCALIZE THE *.params STRINGS ### is not observed in es-AR.

Oh, those aren't meant to be localized? Oops~

Although someone had started localizing those before me

Any specific reason of why those should not be translated? Will break something, or it's matter of consistency across locales?

(IMO I would localize them as those are user-facing help text most of the cases, but that doesn't seem the general rule)

I didn't look in the code that deep yet but from the comment the strings are used to actually create the commands. So something the irc server will never understand. I think they should be removed from the locale code aor at least moved into a separate file but something for later.

tomman There are a bunch of access keys different in central too compared to 2.53 but I don't sync them. Last time I did IanN_Away had nightmares :) They need to be checked all if they are acutally correct and not duplicates. I can try to do a diff later if you want to take a look.

+# ChatZilla uses cmd.<command name>.* to construct the command's help,

+# parameters and any UI labels. For the command to continue to function, the

+# *.params entries MUST NOT BE CHANGED. Hopefully in the future you will be

+# able to localize these items as well.

+#

+### DO NOT LOCALIZE THE *.params STRINGS ###

Well, gotta revert those here then

it means we would be shipping not only a sucky locale, but also a broken cZ too!

Curiously enough some of my wrongly-localized params have been already approved!

I really need to get in touch with the other maintainers here to avoid making an (even bigger) mess

Well you already mentioned locale.authors = XXX REEMPLACE ESTE VALOR CON UNA LISTA DE NOMBRES SEPARADA POR PUNTO Y COMAS PARA sU EQUIPO DE LOCALIZACIÓN XXX too :)

that was a completely pointless reversal, indeed

I'm gonna to backport bug 1712498, bug 1713458 and bug 1713467 to downstream's 2.53.8, since it implements the second proposal from bug 1619108 (irc link behaviour) in a most complete way (and since the initial change was already in downstream's 2.53.7). Pls stop me now if for some reason this is clearly a bad idea.

XXX;REEMPLACE;ESTE;VALOR;CON;UNA;LISTA;DE;NOMBRES;SEPARADA;POR;PUNTO;Y;COMAS;PARA;sU;EQUIPO;DE;LOCALIZACIÓN;XXX

there, fixed it

buc They are not yet reviewed. I am going thru them right now and don't expect generel problems but i would wait.

Personally I am a non fan of the change becuase opens links in a background tab with my configuration here and not switching focus. But formally correct behaviour just not liking it in cZ.

^general

frg: If something is wrong with them, I believe it will be reported in our testing cycle (one week). Or nobody uses cZ here... :)

IanN_Away: with Sm 2.53.9b1pre I can login by SASL _only_ by disabling it in cZ_sasl and enabling it in prefs. If I try to enable it in the plugin and disable it in the prefs (to keep it the way it used to work) I get interferences from the builtin code and login fails with "Invalid username or password".

tonymec|away I think this is expected if I understood IanN_Away right.

the plugin is not compatible.

tonymec|away: I've added a

oops

wrong button return instead of backspace

tonymec|away: i've added some patches that do allow a plugin to now be uninstalled

buc In general I am not fan of including unreviewed code. We have the unofficial versions for letting these bake until ready.

frg: Unreviewed by whom?

Either way, this is another kind of responsibility.

If our user uses the free Linux distro -- most likely he needs new features "as soon as possible", and he understands that the distro itself is "without a guarantee" and he is ready to make bug reports. Otherwise, he buys a commercial version (aka RHEL) for money, where everything will be rechecked in the most paranoid way.

So if you're selling a product for money (or planning to do so in the future), bury the change in your corporate graduation department. If it's a free product, it's not common practice to postpone user-friendly changes for no apparent reason.

Just need to decide whether it is a free product or not.

buc I am out if the corporate graduation department for 6 months now and don't miss it. It is just that we have a review process and the code you include may not be the final code. And even a free product needs organization. As usual this is not personal but we see differently here.

frg: "the code you include may not be the final code" -- It is OpenSource -- any code is THE final code for you as soon as it appears in your hands. IOW, it is your decision whether consider it as good and "final" (for your particular needs).

It may not the official final code. I can play with words all day long and don't get nowhere. :)

Everything that the upstream considers final and correct is only the opinion of specific (primary) developers. It is not a marketing policy towards consumers. :)

I'm just trying to explain why decisions, responsibilities, and downstream's points of view may differ from upstream ones. And this is a common practice (a lot of distro packages have backports from future versions).

buc I know. It is not a problem in this case but these are non final (by our definition) patches. It is a bit different if I am taking a patch from a future version or a draft for me.

Certainly I read the patches. A kind of mental test. :) Do not look like a draft. So I consider them quite ready (under my personal responsibility).

Anyway, such a backporting spoils nothing for an upstream. You can always say "use the official version from our site".

But someone will become a little bit happier due to the fact that the feature they need appeared a couple of months earlier.

(especially who do not have the possibility to donate to the project. ;) )

buc It is not a problem with these but might be with others. When I do reviews in earnest I find problems despite running the version for some time. So does IanN and the others. The maybe rough ones are labeled WIP anyway and these are not.