Confirm
2,595
edits
Changes
m
→Special agenda from the last meeting (for reference)
* It was suggested that we set up own builders to become more independent of Mozilla. '''adriank''' already has a working build system based on Jenkins. '''Ratty''' and '''ewong''' would like to set up one based on buildbot. No decision needed right now but this needs to be worked out.
* A new build system should provide try builds and should us also enable doing automated tests again.
==== Discussion ====
''Ratty screwed up and didn't update the 2017-01-10 meeting with the notes. So here they are again. sumimasen, sumimasen, honto ni sumimasen.''
Benefits for 2.49ESR as opposed to whatever is comm-release:
* ESR will get security fixes for 12 months.
* After that we can cherry-pick and backport stuff. FRG thinks that will give us 18+ months on ESR-49.
* We want to keep XP/Vista support, plug-in support other than Flash, full themes and XUL overlay extensions for a bit longer.
* It'll give us some breathing space. We can even innovate and do some feature work. We could selectively back port feature work.
* But no string changes would be allowed on ESR.
** [Ratty] The way Thunderbird does releases on ESR and get new string changes is to do releases on comm-beta and then copy the new strings to their ESR-L10n.
* [Callek] I agree it gives some more breathing room around a release train, but as Thunderbird has noticed, doing it that way still means we need beta's, because we need to work with and track changes that are necessary for future, otherwise we're in a boat of "hey there was 100k changesets between this working esr and this broken one, what.
* [Ratty] For me personally the breaking point is removal of support for XUL extensions and "Full Themes". At this point I'm going to switch my focus to ESR [FRG] The same.
* '''Build System'''
** Basically we need a build system that is simple but allows lets us have localised extensions.
** [IanN] In an ideal world we would like to merge mozilla-ESR into comm-ESR so we have a unified repository.
** This would among other things, simplify the build process,
** '''jcranmer''' has been doing some testing in the Cypress twig repository but that work has stalled since jcranmer lost interest.
** [FRG] Whatever is decided should be decided with TB together. I don't think we will be able to do it alone.
** Will the build system we use depend on whether we join forces with TB? TB will continue to use buildbot, so the question whether we adapt to their buildbot configuration or they adapt to us.
** It would it be a good idea that we come up with a basic plan of what infra we need and finalize the structure and then let Callek have a looksee?
* '''Ratty''' is prepared to fork out some cash to get some independent infrastructure working.
* Q: what TB are going to do about infrastructure. [Ratty] They have hired a systems architect to do the planning for their new infrastructure.
* One issue that ewong is concerned about. since a lot of our current infra interact with moco-internal stuff (api tooltool and the upload servers to name a few).
* We need to be able to upload those nightlies to stage (archive.m.o) and the symbol server. And eventually we'll need to be able to upload data to "Balrog" (the update server) which we'd currently need to upload that data to our own update server.
** So we either ask them to whitelist those external ips or we duplicate the kind of setup they have.
** FRG asks if we could put a donation page into the SeaMonkey 2.48 first start page. Instead of the regular hello new release page we could redirect to another page on seamonkey-project.org.
=== Action Items ===
