MPL 2 upgrade - logistical questions

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

MPL 2 upgrade - logistical questions

Gervase Markham
Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
codebases to use it. The plan is here:
    https://wiki.mozilla.org/MPL_Upgrade
Simply put, I want to run a (reasonably complex) script over various
trees to change/add the license blocks, and check in the result.

There are several questions I would currently like input on:

1) After running the relicensing scripts, what can I do to try and make
   sure I haven't broken anything?

I am changing and adding to thousands of files. While the script tries
to take care of obvious gotchas (e.g. it won't add a licensing comment
before an <xml> declaration), there is a risk that I might break some
file. My current plan is to build Firefox and Thunderbird and
push-to-try, run all tests and wait for it to go green. (I'll make sure
this works beforehand, and do it again on the day.) Is there more I can do?

2) The MPL 2 upgrade will touch a large proportion of files in the
   tree - tens of thousands. When is the best time to make the change?

As well as changing already-licensed files to the new, shorter
boilerplate, we will be adding boilerplate to files which lack it.
(We've been wanting to do that for years, but the old boilerplate had
various fields to be filled in which could not be done automatically.)
So many, many files will be touched.

This means that we will want to do it with the tree closed, at a
well-publicised time, so people can take steps as necessary to make sure
it doesn't break their patches any more than it has to.

Would it be good to do this immediately after a tree migration? If so,
the next one is on January 31st. Assuming my wife hasn't had our baby by
then (he is due January 29th), that would be an OK day for me.

Or, if it doesn't matter too much when it happens, as long as it's
well-publicised, a couple of weeks from now would be good for me too.

I'd be doing it during the day UK time, which is between around 1am and
9am PST.

3) Which trees should we be running this against?

The https://wiki.mozilla.org/MPL_Upgrade page has a list, but it
includes text like "Any active labs projects using the MPL" - is someone
able to expand that for me? Or tell me any trees I've missed?

Are there trees hosted elsewhere (e.g. on Github) which need relicensing?

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

Re: MPL 2 upgrade - logistical questions

davidascher
> Are there trees hosted elsewhere (e.g. on Github) which need relicensing?

Most likely!

I don't think it's reasonable to expect one person to tackle all of
the codebases.  I would instead suggest that we file bugs/issues on
all projects saying "upgrade to MPL 2", and make that responsibility
be with the individual project drivers.  Even the bug-filing task
probably should be parallelized.

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

Re: MPL 2 upgrade - logistical questions

Dao-6
In reply to this post by Gervase Markham
On 04.01.2012 19:29, Gervase Markham wrote:
> 1) After running the relicensing scripts, what can I do to try and make
>     sure I haven't broken anything?
>
> I am changing and adding to thousands of files. While the script tries
> to take care of obvious gotchas (e.g. it won't add a licensing comment
> before an<xml>  declaration), there is a risk that I might break some
> file. My current plan is to build Firefox and Thunderbird and
> push-to-try, run all tests and wait for it to go green. (I'll make sure
> this works beforehand, and do it again on the day.) Is there more I can do?

Are you going to request review from module owners?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Benjamin Smedberg
In reply to this post by Gervase Markham
On 1/4/2012 1:29 PM, Gervase Markham wrote:
> Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
> codebases to use it. The plan is here:
>      https://wiki.mozilla.org/MPL_Upgrade
> Simply put, I want to run a (reasonably complex) script over various
> trees to change/add the license blocks, and check in the result.
The wiki doesn't mention NSPR, which is also still in CVS
> 2) The MPL 2 upgrade will touch a large proportion of files in the
>     tree - tens of thousands. When is the best time to make the change?
I don't think it matters. The chances of this causing significant merge
conflict are very close to 0.
>
> As well as changing already-licensed files to the new, shorter
> boilerplate, we will be adding boilerplate to files which lack it.
In general I think this is a good thing, except for the many tests which
we explicitly want in the public domain rather than licensed. Will the
script avoid modifying the test files?

I also think that we should treat each project/tree as a separate thing
to do: there isn't any need to relicense NSPR/NSS at the same time as
mozilla-central, is there?

--BDS

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

Re: MPL 2 upgrade - logistical questions

Benjamin Smedberg
In reply to this post by Dao-6
On 1/4/2012 2:23 PM, Dao wrote:

> On 04.01.2012 19:29, Gervase Markham wrote:
>> 1) After running the relicensing scripts, what can I do to try and make
>>     sure I haven't broken anything?
>>
>> I am changing and adding to thousands of files. While the script tries
>> to take care of obvious gotchas (e.g. it won't add a licensing comment
>> before an<xml>  declaration), there is a risk that I might break some
>> file. My current plan is to build Firefox and Thunderbird and
>> push-to-try, run all tests and wait for it to go green. (I'll make sure
>> this works beforehand, and do it again on the day.) Is there more I
>> can do?
>
> Are you going to request review from module owners?
I hope not, this kind of treewide change is really a policy decision,
basically impossible to actually review (as a patch at least), and
getting a bunch of signoffs would in general not improve the process.

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

Re: MPL 2 upgrade - logistical questions

Ehsan Akhgari
In reply to this post by Benjamin Smedberg
On Wed, Jan 4, 2012 at 2:25 PM, Benjamin Smedberg <[hidden email]>wrote:

> On 1/4/2012 1:29 PM, Gervase Markham wrote:
>
>> Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
>> codebases to use it. The plan is here:
>>     https://wiki.mozilla.org/MPL_**Upgrade<https://wiki.mozilla.org/MPL_Upgrade>
>> Simply put, I want to run a (reasonably complex) script over various
>> trees to change/add the license blocks, and check in the result.
>>
> The wiki doesn't mention NSPR, which is also still in CVS
>

I'm not sure if you want to do this for the aurora and beta channels as
well.


>  2) The MPL 2 upgrade will touch a large proportion of files in the
>>    tree - tens of thousands. When is the best time to make the change?
>>
> I don't think it matters. The chances of this causing significant merge
> conflict are very close to 0.
>

+1.  But it would be nice to document how to run the script for people who
have patches adding new files to the tree...

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

Re: MPL 2 upgrade - logistical questions

Dao-6
In reply to this post by Dao-6
On 04.01.2012 20:27, Benjamin Smedberg wrote:

> On 1/4/2012 2:23 PM, Dao wrote:
>> On 04.01.2012 19:29, Gervase Markham wrote:
>>> 1) After running the relicensing scripts, what can I do to try and make
>>> sure I haven't broken anything?
>>>
>>> I am changing and adding to thousands of files. While the script tries
>>> to take care of obvious gotchas (e.g. it won't add a licensing comment
>>> before an<xml> declaration), there is a risk that I might break some
>>> file. My current plan is to build Firefox and Thunderbird and
>>> push-to-try, run all tests and wait for it to go green. (I'll make sure
>>> this works beforehand, and do it again on the day.) Is there more I
>>> can do?
>>
>> Are you going to request review from module owners?
> I hope not, this kind of treewide change is really a policy decision,
> basically impossible to actually review (as a patch at least), and
> getting a bunch of signoffs would in general not improve the process.

The intent wasn't to improve the process, but to make sure the changes
are correct, since Gerv seemed to be concerned that he could break
something.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Justin Wood (Callek)-2
In reply to this post by Gervase Markham
Gervase Markham wrote:

> 1) After running the relicensing scripts, what can I do to try and make
>     sure I haven't broken anything?

An additional build that could be helpful to try building is SeaMonkey.
(tests are in a state of flux at the moment, so trying to decipher which
ones are bad to break and which ones were already broken should not land
on you)

I would note though, that Thunderbird getting built/tested should catch
nearly all cases that would break suite, the suggestion to build suite
is just an extra "happy if you ensure" not a "I think we should require
this.

> 3) Which trees should we be running this against?
>

Just to address this, m-i and m-c should be done at once, but this can
be simplified by having someone (you if need be) merge both ways with
m-i after the trees are closed (so m-c and m-i are identical) then apply
your script to m-c, then push that same change to m-i.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Myk Melez
In reply to this post by Ehsan Akhgari
On 2012-01-04 11:37, Ehsan Akhgari wrote:
> I'm not sure if you want to do this for the aurora and beta channels as
> well.
The Q&A section of the MPL Upgrade document suggests the aurora, beta,
and release branches will be relicensed via merges from the relicensed
central branch.

https://wiki.mozilla.org/MPL_Upgrade#There.27s_some_files_in_the_tree_which_are_still_MPL_1.1.21_What_do_I_do.3F

-myk

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

Re: MPL 2 upgrade - logistical questions

Axel Hecht
In reply to this post by Gervase Markham
For l10n, we should split the effort into one bunch actually working on
central, and the rest working on aurora.

We'll also need to reach out to the tool ecosystem to make sure we're
not getting all regressed.

The other way to go about it is to just not do this on our side at
first. Many tools actually use the en-US files as template, and thus
will get the relicense magic through their tool chain (ugh, IMHO).

We could then pick up the rest (or let folks opt-in to get migrated or
migrate themselves) after a cycle or two/three.

Axel

On 04.01.12 19:29, Gervase Markham wrote:

> Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
> codebases to use it. The plan is here:
>      https://wiki.mozilla.org/MPL_Upgrade
> Simply put, I want to run a (reasonably complex) script over various
> trees to change/add the license blocks, and check in the result.
>
> There are several questions I would currently like input on:
>
> 1) After running the relicensing scripts, what can I do to try and make
>     sure I haven't broken anything?
>
> I am changing and adding to thousands of files. While the script tries
> to take care of obvious gotchas (e.g. it won't add a licensing comment
> before an<xml>  declaration), there is a risk that I might break some
> file. My current plan is to build Firefox and Thunderbird and
> push-to-try, run all tests and wait for it to go green. (I'll make sure
> this works beforehand, and do it again on the day.) Is there more I can do?
>
> 2) The MPL 2 upgrade will touch a large proportion of files in the
>     tree - tens of thousands. When is the best time to make the change?
>
> As well as changing already-licensed files to the new, shorter
> boilerplate, we will be adding boilerplate to files which lack it.
> (We've been wanting to do that for years, but the old boilerplate had
> various fields to be filled in which could not be done automatically.)
> So many, many files will be touched.
>
> This means that we will want to do it with the tree closed, at a
> well-publicised time, so people can take steps as necessary to make sure
> it doesn't break their patches any more than it has to.
>
> Would it be good to do this immediately after a tree migration? If so,
> the next one is on January 31st. Assuming my wife hasn't had our baby by
> then (he is due January 29th), that would be an OK day for me.
>
> Or, if it doesn't matter too much when it happens, as long as it's
> well-publicised, a couple of weeks from now would be good for me too.
>
> I'd be doing it during the day UK time, which is between around 1am and
> 9am PST.
>
> 3) Which trees should we be running this against?
>
> The https://wiki.mozilla.org/MPL_Upgrade page has a list, but it
> includes text like "Any active labs projects using the MPL" - is someone
> able to expand that for me? Or tell me any trees I've missed?
>
> Are there trees hosted elsewhere (e.g. on Github) which need relicensing?
>
> Gerv

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

Re: MPL 2 upgrade - logistical questions

Karl Tomlinson-4
In reply to this post by Gervase Markham
One thing that may complicate things is external projects using
the older MPL licence that are imported into Mozilla project
trees.  (Perhaps you've already thought about this, but I'm
raising it to check.)

I think ideally these would be best left unaltered and hopefully
we'll eventually pick up the new licence when we update from
upstream.

Determining which files are from external projects may be the hard
part.  I know there are at least gfx/cairo/cairo, NSS, and NSPR in
mozilla-central.

This may be particularly tricky if adding licences to files that
have no headers.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Mats Palmgren
In reply to this post by Gervase Markham
On 01/04/2012 07:29 PM, Gervase Markham wrote:
> we will be adding boilerplate to files which lack it.

Also to test files?  that sounds risky since it would change
the DOM and break some tests, or make them not test what they
are supposed to test.

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

Re: MPL 2 upgrade - logistical questions

Mike Hommey
In reply to this post by Benjamin Smedberg
On Wed, Jan 04, 2012 at 02:25:11PM -0500, Benjamin Smedberg wrote:

> On 1/4/2012 1:29 PM, Gervase Markham wrote:
> >Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
> >codebases to use it. The plan is here:
> >     https://wiki.mozilla.org/MPL_Upgrade
> >Simply put, I want to run a (reasonably complex) script over various
> >trees to change/add the license blocks, and check in the result.
> The wiki doesn't mention NSPR, which is also still in CVS
> >2) The MPL 2 upgrade will touch a large proportion of files in the
> >    tree - tens of thousands. When is the best time to make the change?
> I don't think it matters. The chances of this causing significant
> merge conflict are very close to 0.
> >
> >As well as changing already-licensed files to the new, shorter
> >boilerplate, we will be adding boilerplate to files which lack it.
> In general I think this is a good thing, except for the many tests
> which we explicitly want in the public domain rather than licensed.

You actually can't put things in "the public domain". You can use very
liberal licenses (more than the MPL) but you can't give up on copyright.
Public domain only applies to works which copyright has expired (which,
at the rate of things, won't ever happen again).

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

Re: MPL 2 upgrade - logistical questions

Mike Hommey
In reply to this post by Gervase Markham
On Wed, Jan 04, 2012 at 06:29:13PM +0000, Gervase Markham wrote:
> Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
> codebases to use it. The plan is here:
>     https://wiki.mozilla.org/MPL_Upgrade

Can new code that is going to be checked in in the coming weeks before
the "great relicensing" use the MPL 2.0 boilerplate already?

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

Re: MPL 2 upgrade - logistical questions

Justin Wood (Callek)-2
In reply to this post by Benjamin Smedberg
Mike Hommey wrote:

> On Wed, Jan 04, 2012 at 02:25:11PM -0500, Benjamin Smedberg wrote:
>> On 1/4/2012 1:29 PM, Gervase Markham wrote:
>>> Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
>>> codebases to use it. The plan is here:
>>>      https://wiki.mozilla.org/MPL_Upgrade
>>> Simply put, I want to run a (reasonably complex) script over various
>>> trees to change/add the license blocks, and check in the result.
>> The wiki doesn't mention NSPR, which is also still in CVS
>>> 2) The MPL 2 upgrade will touch a large proportion of files in the
>>>     tree - tens of thousands. When is the best time to make the change?
>> I don't think it matters. The chances of this causing significant
>> merge conflict are very close to 0.
>>>
>>> As well as changing already-licensed files to the new, shorter
>>> boilerplate, we will be adding boilerplate to files which lack it.
>> In general I think this is a good thing, except for the many tests
>> which we explicitly want in the public domain rather than licensed.
>
> You actually can't put things in "the public domain". You can use very
> liberal licenses (more than the MPL) but you can't give up on copyright.
> Public domain only applies to works which copyright has expired (which,
> at the rate of things, won't ever happen again).

Umm, yes, you can donate your work to the public domain. You essentially
give anyone rights to do whatever they want with your contribution.
(including yourself fwiw).

--
~Justin Wood (Callek)

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

Re: MPL 2 upgrade - logistical questions

Henri Sivonen
In reply to this post by Gervase Markham
> I am changing and adding to thousands of files. While the script tries
> to take care of obvious gotchas (e.g. it won't add a licensing comment
> before an <xml> declaration)

Not sure which of these count as obvious, so I'm mentioning the
following points just in case, because I have seen breakage
previously:
 * It's unsafe to add license headers to HTML test files that don't
have them already, because the DOM changes and a test script might
assume a particular DOM shape.
 * It's unsafe to add or modify a license header to an HTML file above
<meta charset=foo>, because doing so might push the meta over the
1024-byte boundary.
 * It's unsafe to add a license header above CSS @charset.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Axel Hecht-2
In reply to this post by Gervase Markham
On 05.01.12 12:31, Henri Sivonen wrote:

>> I am changing and adding to thousands of files. While the script tries
>> to take care of obvious gotchas (e.g. it won't add a licensing comment
>> before an<xml>  declaration)
>
> Not sure which of these count as obvious, so I'm mentioning the
> following points just in case, because I have seen breakage
> previously:
>   * It's unsafe to add license headers to HTML test files that don't
> have them already, because the DOM changes and a test script might
> assume a particular DOM shape.
>   * It's unsafe to add or modify a license header to an HTML file above
> <meta charset=foo>, because doing so might push the meta over the
> 1024-byte boundary.

Modifying an existing license header should just drastically shorten it,
can that cause problems?

Axel

>   * It's unsafe to add a license header above CSS @charset.
>

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

Re: MPL 2 upgrade - logistical questions

Henri Sivonen
On Thu, Jan 5, 2012 at 2:12 PM, Axel Hecht <[hidden email]> wrote:
>>  * It's unsafe to add or modify a license header to an HTML file above
>> <meta charset=foo>, because doing so might push the meta over the
>> 1024-byte boundary.
>
> Modifying an existing license header should just drastically shorten it, can
> that cause problems?

Shortening shouldn't cause problems. (Unless problems are pre-existing
and the file depends on the problems being present, but that's
unlikely.)

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Joshua Cranmer-2
In reply to this post by Justin Wood (Callek)-2
On 1/5/2012 2:51 AM, Justin Wood (Callek) wrote:

> Mike Hommey wrote:
>> You actually can't put things in "the public domain". You can use very
>> liberal licenses (more than the MPL) but you can't give up on copyright.
>> Public domain only applies to works which copyright has expired (which,
>> at the rate of things, won't ever happen again).
>
> Umm, yes, you can donate your work to the public domain. You
> essentially give anyone rights to do whatever they want with your
> contribution. (including yourself fwiw).
>
I have heard that there is serious doubt by experts as to whether or not
it is truly legal to release work into the public domain and not
copyright them. However, an explicit statement that you relinquish any
rights you hold over copyright may suffice in practice.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: MPL 2 upgrade - logistical questions

Philip Chee
In reply to this post by Benjamin Smedberg
On Thu, 5 Jan 2012 09:05:14 +0100, Mike Hommey wrote:

> On Wed, Jan 04, 2012 at 02:25:11PM -0500, Benjamin Smedberg wrote:
>> On 1/4/2012 1:29 PM, Gervase Markham wrote:
>> >Now that the MPL 2 has shipped, I am working on upgrading the Mozilla
>> >codebases to use it. The plan is here:
>> >     https://wiki.mozilla.org/MPL_Upgrade
>> >Simply put, I want to run a (reasonably complex) script over various
>> >trees to change/add the license blocks, and check in the result.
>> The wiki doesn't mention NSPR, which is also still in CVS
>> >2) The MPL 2 upgrade will touch a large proportion of files in the
>> >    tree - tens of thousands. When is the best time to make the change?
>> I don't think it matters. The chances of this causing significant
>> merge conflict are very close to 0.
>> >
>> >As well as changing already-licensed files to the new, shorter
>> >boilerplate, we will be adding boilerplate to files which lack it.
>> In general I think this is a good thing, except for the many tests
>> which we explicitly want in the public domain rather than licensed.
>
> You actually can't put things in "the public domain". You can use very
> liberal licenses (more than the MPL) but you can't give up on copyright.
> Public domain only applies to works which copyright has expired (which,
> at the rate of things, won't ever happen again).

You can make a public domain grant for example using Creative Commons
Zero or the Unlicence. SQLite is public domain for example.

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234