Closed Bug 1191007 Opened 9 years ago Closed 9 years ago

Disable 'xpinstall.signatures.required' by default in developer edition.

Categories

(DevTools :: General, defect)

defect
Not set
normal

Tracking

(firefox42 affected)

RESOLVED DUPLICATE of bug 1203584
Tracking Status
firefox42 --- affected

People

(Reporter: canuckistani, Unassigned)

References

Details

(Keywords: DevAdvocacy)

I think we should flip 'xpinstall.signatures.required' by default in developer edition to make it easier for developers to do two things:

1. more easily iterate on add-ons while they are developing
2. create and run add-ons with very narrow use cases without having to touch AMO.
At the moment, it's also blocking simulator installs in WebIDE since they aren't yet signed (see bug 1190973).  We may find a work around for that particular part, not sure yet.
See Also: → 1190966
Should it be also by default in nightly? Nightly is kinda "risky" and people assume that.
see also bug 1190834 for Gaia
(In reply to Erwann Mest from comment #2)
> Should it be also by default in nightly? Nightly is kinda "risky" and people
> assume that.

I'm not sure about that - the purpose of nightly is mostly testing recent changes, right? I think I would want most prefs to be 'stock' in this case, but perhaps it's enough to just revert back to warning.

Dev Edition on the other hand can be modified for the developer use case, and this bug I think fits very well into that.
Mossop, any opinion on whether we should proceed with this change?
Flags: needinfo?(dtownsend)
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> Mossop, any opinion on whether we should proceed with this change?

I don't think we should do this, but it's Kev's call really.
Flags: needinfo?(dtownsend) → needinfo?(kev)
(In reply to Dave Townsend [:mossop] from comment #6)
> (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> > Mossop, any opinion on whether we should proceed with this change?
> 
> I don't think we should do this, but it's Kev's call really.

ISTR that when we starting talking about developer edition, one of the reasons was so we could do exactly this--flip preferences to make things easier for developers.  Why would we not do this?
What about nightly? I always have to verify if this option is ticked off.
(In reply to Nathan Froyd [:froydnj] from comment #7)
> (In reply to Dave Townsend [:mossop] from comment #6)
> > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> > > Mossop, any opinion on whether we should proceed with this change?
> > 
> > I don't think we should do this, but it's Kev's call really.
> 
> ISTR that when we starting talking about developer edition, one of the
> reasons was so we could do exactly this--flip preferences to make things
> easier for developers.  Why would we not do this?

One reason is that Dev Edition is still in the test path for changes we bring in (Nightly->Dev->Beta->Release), and getting feedback on impacts (and making people aware of changes as they are made) as those changes progress is valuable. Having the pref on in Nightly and Developer, for example, made people aware of changes that had been discussed since early in the year, but were missed by some of the people it directly affected. An aside, but a relevant one, do people feel that Dev Edition shouldn't be part of the test chain, and should this not be considered? 

The other, bigger (for me) reason is that Dev Edition will keep the preference, where Firefox will not (it will be ignored starting  w/44), and signing will be enforced. It's important for Developers to understand that, and my preference would be to leave it enabled so that disabling signing is something that is actively done, and leads to discovery of the preference required to do that. I'm not bound to that, but I'd like to understand if the hassle of finding and flipping the pref justifies it, or if there's a better way to raise awareness of changes we make.
Strong +1 from DevRel on this based on user feedback.

1. Shipping DevEdition with this set to "false" is consistent with other prefs, like chrome debugging, that ship by default in DevEdition and are designed to facilitate development.

2. Given our target demographic for DevEdition, providing the ability to intentionally install unsigned add-ons seems warranted. Plus, there is still a warning prompt when `xpinstall.signatures.required` is false, which avoids unintentional installation of unsigned add-ons.

> do people feel that Dev Edition shouldn't be part of the test chain

Subjectively, I'd love to see more product differentiation for DevEdition. Keeping it tightly bound to the test chain constrains the ways in which we can modify the to attract developers and power users.
Keywords: DevAdvocacy
(In reply to Kev Needham [:kev] from comment #9)
> (In reply to Nathan Froyd [:froydnj] from comment #7)
> > (In reply to Dave Townsend [:mossop] from comment #6)
> > > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #5)
> > > > Mossop, any opinion on whether we should proceed with this change?
> > > 
> > > I don't think we should do this, but it's Kev's call really.
> > 
> > ISTR that when we starting talking about developer edition, one of the
> > reasons was so we could do exactly this--flip preferences to make things
> > easier for developers.  Why would we not do this?
> 
> One reason is that Dev Edition is still in the test path for changes we
> bring in (Nightly->Dev->Beta->Release), and getting feedback on impacts (and
> making people aware of changes as they are made) as those changes progress
> is valuable. Having the pref on in Nightly and Developer, for example, made
> people aware of changes that had been discussed since early in the year, but
> were missed by some of the people it directly affected. An aside, but a
> relevant one, do people feel that Dev Edition shouldn't be part of the test
> chain, and should this not be considered? 

Stromgly disagree. Having the signing warning preserved without enforcement is enough.

> The other, bigger (for me) reason is that Dev Edition will keep the
> preference, where Firefox will not (it will be ignored starting  w/44), and
> signing will be enforced. It's important for Developers to understand that,
> and my preference would be to leave it enabled so that disabling signing is
> something that is actively done, and leads to discovery of the preference
> required to do that. I'm not bound to that, but I'd like to understand if
> the hassle of finding and flipping the pref justifies it, or if there's a
> better way to raise awareness of changes we make.

Again, I think warning about unsigned addons is enough here. Dev Edition need to be friendlier to developers, and a key capability I need to preserve is the ability for developers to create one-off addons to customize Firefox to their purposes.

We're not going to solve ongoing awkwardness with DE's role in the train model in this bug, but I am open to a larger discussion. DE is in it's current place in our release process because it was relatively simple to do. I've been mildly unhappy about the need to preserve new policy-oriented changes like this one through the train cycle, but I assert my right to define the experience in Dev Edition once the feature leaves the train to beta.
Hrm, I was just reminded that eventually we'll have something like chrome's load-from-a-directory workflow. Assuming that, most of my arguments are invalid.

I think there are other gaps here, especially if developers want to run automated tests on their addon code on check-in, o something like travis. Communities like ember/react that have cross-browser extensions that change rapidly are my main concern, we need to get out of these projects' way.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(kev)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.