Infrastructure status for week ending September 3rd
I apologize for the delay on this email. Usually I send it on Monday,
and that was Labor Day in Canada and the USA so I decided to take the
whole day and go outside and enjoy some of the last vestiges of nice
weather in the pacific northwest before the rainpocalypse is upon us :)
This week:
- AMO situation has been resolved with a plan, Mozilla is going to
host an instance of addons-server for us. The code will be a fork
completely under our control. This temporary site will also include
all Seamonkey add-ons, not just Thunderbird ones.
o That doesn't mean we'll be hosting Seamonkey add-ons in the
future once we move on from this site.
o This tables the data export for issue for some time(3-6 months),
since we aren't exporting any data from Mozilla servers, all
current add-ons will be listed.
o Only developer accounts, add-ons compatible with Thunderbird or
Seamonkey, and themes that meet the same condition will be migrated.
o This means reviews won't be migrated, nor will collections, but
we only have two collections and they are hardly used so this
isn't super relevant. The loss of review data is somewhat
unfortunate, and I've pushed back a little on this so we'll see
about it.
o Download and usage stats should be migrated unless there are
major technical problems with this.
o Jorgev(product manager) from the AMO team and I are working on a
document that lists all the requirements for our instance.
I will be posting more about this. We'll probably need some help from
the community to do reviews and stuff during times when a lot of add-ons
need to be updated(Thunderbird 59?) and stuff.
Other than the above:
- Fixed a few minor website bugs as usual.
- Worked on setting up memcached and elasticsearch containers on
linodes for our future AMO host. This work will probably go on hold
now that we have confirmed Mozilla will be hosting a temporary site
for us. - Started working on setting up pontoon for localization of the
website...also opened a conversation with the Mozilla webdev team
about this. We're going to need localization support and it would be
nice if we can be listed on pontoon.mozilla.org even while
maintaining our own l10n repos and code. I'd prefer not to maintain
a pontoon instance and it's much easier for localizers if they can
continue going to one place for this, but this may not be acceptable
to Mozilla so we'll see. This needs to be resolved because when
Thunderbird is removed from mozilla.org strings won't be localizable
on pontoon.mozilla.org anymore as things stand, which will impact
our ability to localize any (string) changes we make to the website,
unless they use strings that have already been translated.
One of the issues that we have been wrestling with is privacy
restrictions that Mozilla imposes on us, as we (Thunderbird) are not
MoCo employees, and therefore have restricted access to some data, such
as the email addresses of the addon developers. We are also concerned
about what happens when post-gecko57 changes break most of our addons,
about whether we would be able to get a third party to fix the addon
(license permitting) and still maintain automatic updates, in the case
of a non-responsive developer.
Have the rights to data access been resolved in conjunction with this
fork, or will Mozilla continue to restrict our ability to access data
and set policy on addons?
:rkent
On 9/6/2017 12:14 AM, Andrei Hajdukewycz wrote:
I apologize for the delay on this email. Usually I send it on Monday,
and that was Labor Day in Canada and the USA so I decided to take the
whole day and go outside and enjoy some of the last vestiges of nice
weather in the pacific northwest before the rainpocalypse is upon us :)
This week:
- AMO situation has been resolved with a plan, Mozilla is going to
host an instance of addons-server for us. The code will be a fork
completely under our control. This temporary site will also
include all Seamonkey add-ons, not just Thunderbird ones.
o That doesn't mean we'll be hosting Seamonkey add-ons in the
future once we move on from this site.
o This tables the data export for issue for some time(3-6
months), since we aren't exporting any data from Mozilla
servers, all current add-ons will be listed.
o Only developer accounts, add-ons compatible with Thunderbird
or Seamonkey, and themes that meet the same condition will be
migrated.
o This means reviews won't be migrated, nor will collections,
but we only have two collections and they are hardly used so
this isn't super relevant. The loss of review data is somewhat
unfortunate, and I've pushed back a little on this so we'll
see about it.
o Download and usage stats should be migrated unless there are
major technical problems with this.
o Jorgev(product manager) from the AMO team and I are working on
a document that lists all the requirements for our instance.
I will be posting more about this. We'll probably need some help from
the community to do reviews and stuff during times when a lot of
add-ons need to be updated(Thunderbird 59?) and stuff.
On 2017-09-06 4:15 PM, R Kent James wrote:
One of the issues that we have been wrestling with is privacy
restrictions that Mozilla imposes on us, as we (Thunderbird) are not
MoCo employees, and therefore have restricted access to some data,
such as the email addresses of the addon developers. We are also
concerned about what happens when post-gecko57 changes break most of
our addons, about whether we would be able to get a third party to fix
the addon (license permitting) and still maintain automatic updates,
in the case of a non-responsive developer.
Have the rights to data access been resolved in conjunction with this
fork, or will Mozilla continue to restrict our ability to access data
and set policy on addons?
No, Mozilla's policy on this hasn't changed. One of the reasons for
allowing them to host is so we don't have to worry about those issues
yet. Since Philipp and I are Mozilla employees, and the data is still
going to be hosted on Mozilla servers, they can just import everything
including developer emails to a site we have admin access to. We still
can't have those emails for our own TB-hosted site without developer
opt-in, but we're going to ask developers to opt-in and the temporary
Mozilla site will operate for probably around 6 months, giving plenty of
time for developers to respond and for us to contact anyone running
particularly popular add-ons who hasn't responded.
In general, what we can do with add-on code is license dependent, as you
said. If an add-on developer opts in, we will receive all their account
data, add-on data, and add-on code(in the form of all the xpis they've
uploaded to AMO). And thus we'll be able to do anything we want to their
account and code that their license allows.
If an add-on is open source, and the developer does not respond to the
opt-in, we can still import that add-on to our future TB hosted site,
but we have no way to verify ownership if that person comes along later,
since we won't have their email, any way of allowing them access to
their old account, upload history, usage stats, etc on the site would be
a completely manual admin process.
In general, any add-on we import to our future site will work for
automatic updates, whether or not the developer opts-in. The only case
of breakage is if the developer does not opt-in, and their add-on is not
open source or has some kind of very restrictive license. In that case,
we cannot import anything and can't touch their code, obviously.
The above addresses what's legal and within Mozilla policy, so if we
want to maintain or update open source add-ons that have been abandoned
and their license allows a third party to distribute derivative code, we
can do that and Mozilla doesn't have a problem with it.
Personally I feel that if an add-on is sufficiently abandoned that the
developer does not respond to a 6-month opt-in window, even if the
add-on is open source, we should not update it and should allow it to
die, unless MAYBE It's one of our top 50 add-ons with tens or hundreds
of thousands of daily users. If it's something small... well if there is
sufficient demand for that functionality, perhaps it will encourage
someone to step up and develop a new add-on or maintain the old one. But
there are many hundreds of add-ons with less than 1,000 users. If
they're completely abandoned, spending any of our resources propping
them up doesn't seem worthwhile.
On 9/7/17 1:40 AM, Andrei Hajdukewycz wrote:
On 2017-09-06 4:15 PM, R Kent James wrote:
Personally I feel that if an add-on is sufficiently abandoned that the
developer does not respond to a 6-month opt-in window, even if the
add-on is open source, we should not update it and should allow it to
die, unless MAYBE It's one of our top 50 add-ons with tens or hundreds
of thousands of daily users. If it's something small... well if there
is sufficient demand for that functionality, perhaps it will encourage
someone to step up and develop a new add-on or maintain the old one.
But there are many hundreds of add-ons with less than 1,000 users. If
they're completely abandoned, spending any of our resources propping
them up doesn't seem worthwhile.
I think this was talked about in another thread I can't find right now
as well, what we do with add-ons that are broken. There was sentiment
that we should be picking up the pieces, but I don't agree to that.
First of all, we don't want to get into the business of picking up
pieces for add-on developers because that may work as a safety net.
Also, there is the question on how to do this fairly so that other
developers don't feel discriminated.
Ultimately, I think developers are responsible for their add-ons, and
all we can and should be doing is outreach for top add-ons that are
having trouble updating.
Philipp
On 9/7/17 2:16 PM, Philipp Kewisch wrote:
On 9/7/17 1:40 AM, Andrei Hajdukewycz wrote:
On 2017-09-06 4:15 PM, R Kent James wrote:
Personally I feel that if an add-on is sufficiently abandoned that the
developer does not respond to a 6-month opt-in window, even if the
add-on is open source, we should not update it and should allow it to
die, unless MAYBE It's one of our top 50 add-ons with tens or hundreds
of thousands of daily users. If it's something small... well if there
is sufficient demand for that functionality, perhaps it will encourage
someone to step up and develop a new add-on or maintain the old one.
But there are many hundreds of add-ons with less than 1,000 users. If
they're completely abandoned, spending any of our resources propping
them up doesn't seem worthwhile.
I think this was talked about in another thread I can't find right now
as well, what we do with add-ons that are broken. There was sentiment
that we should be picking up the pieces, but I don't agree to that.
First of all, we don't want to get into the business of picking up
pieces for add-on developers because that may work as a safety net.
Also, there is the question on how to do this fairly so that other
developers don't feel discriminated.
Ultimately, I think developers are responsible for their add-ons, and
all we can and should be doing is outreach for top add-ons that are
having trouble updating.
These are my thoughts as well.
-Magnus