AMO blocklist updates should be treated as regular code changes
Ehsan Akhgari
lest twice.
This is problematic since those changes are landed as DONTBUILD by a
bot, without any bug # or author information, so when they break the
tree, their breakage is attributed to other stuff, and most people don't
know who to ping and what to do, and if we have to end up backing out
such a changeset, we don't have any good way of notifying the people
responsible (i.e., reopening the bug).
I think these code changes should stop being treated specially when they
have been proven to not deserve this special treatment at least twice so
far. I've filed bug 637444 to stop landing those updates automatically
as DONTBUILD changes.
Cheers,
Ehsan
Christian Legnitto
Perhaps we need to flip it around and land in tree first and then update the live block? That seems less than ideal as it introduces potential regressions and testing complexities into the process.
And before people say get rid of the in product blocklist, remember that it is our last defense if someone is crashing on startup before an updated blocklist can be downloaded.
Thanks,
Christian
> _______________________________________________
> dev-tree-management mailing list
> dev-tree-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tree-management
Ehsan Akhgari
> I don't understand....the blocklist should be what is already live for our users anyway, correct? If there is breakage in the tree it means that (possibly) there is breakage for real users. I think requiring manual merges is just going to cause the shipped and server side blocklist to diverge.
Joe has filed bug 637413, and that _might_ be all that is needed to fix
our test suite to not be dependent on the blocklist entries we ship in
the product. Joe, would that solve all of the potential issues with our
tests breaking because of blocklist updates?
Ehsan
Joe Drew
That'll fix the extension manager tests, but if there are tests outside
of the extension manager that break sometimes (I have no idea if that's
the case, but I can imagine for example the Flash version on our test
machines being out of date and blocked, breaking lots of things), it
won't fix them.
Joe
Ehsan Akhgari
In that case, we need to move in the direction of landing the blocklist
updates manually and test those updates on the try server before landing.
Cheers,
Ehsan
Ben Hearsum
> On 11-02-28 5:09 PM, Joe Drew wrote:
>> On 2011-02-28 7:55 PM, Ehsan Akhgari wrote:
>>> On 11-02-28 1:42 PM, Christian Legnitto wrote:
>>>> I don't understand....the blocklist should be what is already live for
>>>> our users anyway, correct? If there is breakage in the tree it means
>>>> that (possibly) there is breakage for real users. I think requiring
>>>> manual merges is just going to cause the shipped and server side
>>>> blocklist to diverge.
>>>
>>> Joe has filed bug 637413, and that _might_ be all that is needed to fix
>>> our test suite to not be dependent on the blocklist entries we ship in
>>> the product. Joe, would that solve all of the potential issues with our
>>> tests breaking because of blocklist updates?
>>
>> That'll fix the extension manager tests, but if there are tests outside
>> of the extension manager that break sometimes (I have no idea if that's
>> the case, but I can imagine for example the Flash version on our test
>> machines being out of date and blocked, breaking lots of things), it
>> won't fix them.
Do tests have to depend on the version of the blocklist that we're
shipping? Can tests use a different one, that's known not to change, for
their purposes?
Also, if there's a way to override the blocklist through replacing it
locally, a pref, etc., we could look at doing that. It has the downside
of us testing a slightly different version than what we ship, but the
blocklist changes from time to time anyways, so it's not like that
scenario is entirely unrealistic.
It sucks that we ship users an outdated blocklist because of this.
Ben Hearsum
> On 11-02-28 5:09 PM, Joe Drew wrote:
>> On 2011-02-28 7:55 PM, Ehsan Akhgari wrote:
>>> On 11-02-28 1:42 PM, Christian Legnitto wrote:
>>>> I don't understand....the blocklist should be what is already live for
>>>> our users anyway, correct? If there is breakage in the tree it means
>>>> that (possibly) there is breakage for real users. I think requiring
>>>> manual merges is just going to cause the shipped and server side
>>>> blocklist to diverge.
>>>
>>> Joe has filed bug 637413, and that _might_ be all that is needed to fix
>>> our test suite to not be dependent on the blocklist entries we ship in
>>> the product. Joe, would that solve all of the potential issues with our
>>> tests breaking because of blocklist updates?
>>
>> That'll fix the extension manager tests, but if there are tests outside
>> of the extension manager that break sometimes (I have no idea if that's
>> the case, but I can imagine for example the Flash version on our test
>> machines being out of date and blocked, breaking lots of things), it
>> won't fix them.
Do tests have to depend on the version of the blocklist that we're
Blair McBride
> Also, if there's a way to override the blocklist through replacing it
> locally, a pref, etc.,
Doable via the extensions.blocklist.url pref.
- Blair
Ehsan Akhgari
> On 1/03/2011 6:13 p.m., Ben Hearsum wrote:
>> locally, a pref, etc.,
>
Please note that these problems happen with the in-tree blocklist. The
blocklist we download from the web is an entirely different issue.
Ehsan
Robert Kaiser
> Please note that these problems happen with the in-tree blocklist. The
> blocklist we download from the web is an entirely different issue.
They ought to be the same. Users who install a release for the first
time are vulnerable to problems that the in-tree blocklist leaves open
until their build lazily updates to the one downloaded from the web - if
their build even has access to downloading it (which might not always be
the case in intranets, etc.).
For this reason, anything we have in the downloaded list that is not in
the in-tree list is IMHO a high-importance bug and I cheer the RelEng
team for closing that gap. I also think a good test ought to not be
dependent on a certain in-tree blocklist.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community needs answers to. And most of the time,
I even appreciate irony and fun! :)