NSPR releases and the faster Firefox release cadence

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

NSPR releases and the faster Firefox release cadence

Ted Mielczarek-2
I'm a little concerned with how we'll manage NSPR releases with the
faster Firefox release cadence. Historically, we have only taken
release versions of NSPR in release versions of Firefox, since doing
otherwise impairs Linux distributors' ability to link their Firefox
builds to their system NSPR. However, during development we've been
able to take snapshots of NSPR trunk into mozilla-central so that NSPR
changes that are necessary for Gecko/Firefox changes could be landed
without doing a full-blown NSPR release. With the faster release
cadence, this doesn't seem like a great idea, since our options
become:
1) Ship Firefox with a pre-release NSPR dependency
2) Back out the NSPR snapshot and all changes depending on it on aurora
3) Get a new NSPR released and landed on mozilla-central in <6 weeks

I'm not really sure what I want to ask here, just that I ran into this
situation while discussing bug 626035, which needs NSPR changes to
land in order for some mozilla-central changes to land. Unfortunately
I don't think we have the people-bandwidth to release NSPR every 6
weeks if necessary, and I'm not sure it's desirable even if we could.
Does anyone have any better ideas, or is this situation as described
not really a problem?

-Ted
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

timeless-3
On Tue, May 3, 2011 at 11:22 PM, Ted Mielczarek <[hidden email]> wrote:
> Does anyone have any better ideas, or is this situation as described
> not really a problem?

For MeeGo and certain other store based systems as well as other
things like Maemo, it seems likely that people will be producing
static binaries which don't use libraries. While this isn't very
friendly, the reality is that we aren't really advertising XULRunner
or reusability and the small price to pay for a few extra bytes which
happen to be PGO'd doesn't seem to so bad. It also means that we don't
force NSPR to publish early and we can enable it to get more testing
before it does get around to freezing.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Chris Coulson-2
On Tue, 2011-05-03 at 23:40 +0300, timeless wrote:

> On Tue, May 3, 2011 at 11:22 PM, Ted Mielczarek <[hidden email]> wrote:
> > Does anyone have any better ideas, or is this situation as described
> > not really a problem?
>
> For MeeGo and certain other store based systems as well as other
> things like Maemo, it seems likely that people will be producing
> static binaries which don't use libraries. While this isn't very
> friendly, the reality is that we aren't really advertising XULRunner
> or reusability and the small price to pay for a few extra bytes which
> happen to be PGO'd doesn't seem to so bad. It also means that we don't
> force NSPR to publish early and we can enable it to get more testing
> before it does get around to freezing.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
FWIW, we're already building Firefox in Ubuntu with all of the bundled
libraries (including NSPR) - partly, for this exact reason.

Regards
Chris

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Zack Weinberg-2
In reply to this post by Ted Mielczarek-2
On 2011-05-03 1:22 PM, Ted Mielczarek wrote:
> I'm a little concerned with how we'll manage NSPR releases with the
> faster Firefox release cadence. Historically, we have only taken
> release versions of NSPR in release versions of Firefox, since doing
> otherwise impairs Linux distributors' ability to link their Firefox
> builds to their system NSPR. However, during development we've been
> able to take snapshots of NSPR trunk into mozilla-central so that NSPR
> changes that are necessary for Gecko/Firefox changes could be landed
> without doing a full-blown NSPR release.

I hate to see us step even farther away from being a good Linux
distribution citizen.  However, my vote is for whichever option will
provide the smoothest, quickest path to not needing NSPR anymore.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Wan-Teh Chang-3
In reply to this post by Ted Mielczarek-2
Hi Ted,

It is not a problem to make a new NSPR release for Firefox every six weeks.

Six weeks are enough time to stabilize an NSPR release.  For the
changes that need more testing, we can wait until the beginning of a
new six-week cycle to check them in.

In recent history, NSPR activities tended to occur in bursts.  So
after the burst of activities caused by the Android port, NSPR may
become quiet again.

Wan-Teh
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Asa Dotzler-2
In reply to this post by Ted Mielczarek-2
On 5/3/2011 1:22 PM, Ted Mielczarek wrote:
> I'm a little concerned with how we'll manage NSPR releases with the
> faster Firefox release cadence. Historically, we have only taken
> release versions of NSPR in release versions of Firefox, since doing
> otherwise impairs Linux distributors' ability to link their Firefox
> builds to their system NSPR.

Why is it important that Linux distributions link to the system NSPR
when we're always going to be offering a newer and most likely a more
capable and secure version than they are?

I understand them wanting to be able to patch one library and have
everything just magically get fixed, but that's really only useful if
the app vendor isn't doing a better job at the patching and we certainly
should be.

I propose we simply require our patched NSPR for Firefox.

- A
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Mike Hommey
In reply to this post by Ted Mielczarek-2
On Tue, May 03, 2011 at 04:22:27PM -0400, Ted Mielczarek wrote:

> I'm a little concerned with how we'll manage NSPR releases with the
> faster Firefox release cadence. Historically, we have only taken
> release versions of NSPR in release versions of Firefox, since doing
> otherwise impairs Linux distributors' ability to link their Firefox
> builds to their system NSPR. However, during development we've been
> able to take snapshots of NSPR trunk into mozilla-central so that NSPR
> changes that are necessary for Gecko/Firefox changes could be landed
> without doing a full-blown NSPR release. With the faster release
> cadence, this doesn't seem like a great idea, since our options
> become:
> 1) Ship Firefox with a pre-release NSPR dependency
> 2) Back out the NSPR snapshot and all changes depending on it on aurora
> 3) Get a new NSPR released and landed on mozilla-central in <6 weeks
>
> I'm not really sure what I want to ask here, just that I ran into this
> situation while discussing bug 626035, which needs NSPR changes to
> land in order for some mozilla-central changes to land. Unfortunately
> I don't think we have the people-bandwidth to release NSPR every 6
> weeks if necessary, and I'm not sure it's desirable even if we could.
> Does anyone have any better ideas, or is this situation as described
> not really a problem?

Note that in this specific case, the NSPR changes are not required when
building against a system NSPR.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Mike Hommey
In reply to this post by Asa Dotzler-2
On Tue, May 03, 2011 at 08:56:57PM -0700, Asa Dotzler wrote:

> On 5/3/2011 1:22 PM, Ted Mielczarek wrote:
> >I'm a little concerned with how we'll manage NSPR releases with the
> >faster Firefox release cadence. Historically, we have only taken
> >release versions of NSPR in release versions of Firefox, since doing
> >otherwise impairs Linux distributors' ability to link their Firefox
> >builds to their system NSPR.
>
> Why is it important that Linux distributions link to the system NSPR
> when we're always going to be offering a newer and most likely a
> more capable and secure version than they are?
>
> I understand them wanting to be able to patch one library and have
> everything just magically get fixed, but that's really only useful
> if the app vendor isn't doing a better job at the patching and we
> certainly should be.

That's assuming the app vendor ships the latest and shiniest Firefox
(especially now with the new release process), which may not be the case.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Mike Hommey
In reply to this post by Zack Weinberg-2
On Tue, May 03, 2011 at 02:34:05PM -0700, Zack Weinberg wrote:

> On 2011-05-03 1:22 PM, Ted Mielczarek wrote:
> >I'm a little concerned with how we'll manage NSPR releases with the
> >faster Firefox release cadence. Historically, we have only taken
> >release versions of NSPR in release versions of Firefox, since doing
> >otherwise impairs Linux distributors' ability to link their Firefox
> >builds to their system NSPR. However, during development we've been
> >able to take snapshots of NSPR trunk into mozilla-central so that NSPR
> >changes that are necessary for Gecko/Firefox changes could be landed
> >without doing a full-blown NSPR release.
>
> I hate to see us step even farther away from being a good Linux
> distribution citizen.  However, my vote is for whichever option will
> provide the smoothest, quickest path to not needing NSPR anymore.

Considering NSS needs NSPR...

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Boris Zbarsky
In reply to this post by Zack Weinberg-2
On 5/4/11 3:53 AM, Mike Hommey wrote:
> Considering NSS needs NSPR...

Yes, that's one of the main reasons we're still using NSPR.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Robert Kaiser
In reply to this post by Asa Dotzler-2
Asa Dotzler schrieb:
> Why is it important that Linux distributions link to the system NSPR
> when we're always going to be offering a newer and most likely a more
> capable and secure version than they are?

One reason is that startup is faster when we use system libraries, at
least if something else has already loaded those libraries into memory.

The other thing to note is that most Linux users are not using various
often not well-done app-made update mechanisms like Windows and Mac
users are accustomed to, but a trusted, single, distribution-provided
install and update mechanism (which tends to have as fast a response and
update as our own, by the way) - that also means that the vendor
(distributor) who creates and ships those updates needs to patch and
deliver one library only once if all apps use it from a common place.
This is not about the app vendors doing better or worse jobs, this is
about a better and common update mechanism for the whole system instead
of app-provided piecemeal.

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! :)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: NSPR releases and the faster Firefox release cadence

Zack Weinberg-2
In reply to this post by Zack Weinberg-2
On 05/04/2011 12:53 AM, Mike Hommey wrote:
> On Tue, May 03, 2011 at 02:34:05PM -0700, Zack Weinberg wrote:
>> I hate to see us step even farther away from being a good Linux
>> distribution citizen.  However, my vote is for whichever option will
>> provide the smoothest, quickest path to not needing NSPR anymore.
>
> Considering NSS needs NSPR...

If we could get to the point where we *only* needed NSPR because NSS
used it, we'd be much better off than we are now -- and we'd probably
not be so tightly coupled to NSPR anymore, either.

(We should also be considering modernizing NSS, or replacing it with
botan, but I imagine that is itself a giant project.  I haven't ever
looked at the guts of NSS in detail.)

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning