Can we design a new source release process?

[Dave Mandelin]

This is prompted by Andre Klapper asking me about a new source release in Bugzilla.

I think the previous source release was largely the work of Wes Garland. I think it was quite a bit of work to put it together, especially the release notes, and I don't know that Wes has time for that any more. It's also hard for paid staff to have time for source releases.

So what can we do? If someone wants to volunteer to just do it the old way, that's cool, but I feel we don't have a sustainable process that fits in with normal development. I'm more interested in finding a way to make the job easier:

- One part of a source release is to apply some patches that various embeddings need. We should just land those to the main tree.

- Another is to package things up into a tarball: the js directory, maybe minus a bit of itself, plus mfbt or something like that. We should be able to create a make target to do that, and then get it tested automatically.

- Last is the release notes, and this is the hard part. Some of the work could be automated in theory by generating API docs off the source, but we don't currently have any capability do to that and it would be a fair amount of work [1]. Jeff suggested that API changes get documented in a draft release notes as they are made. It sounds reasonable, but it would be extra work and an extra thing to remember.

Did I miss anything? Any other ideas on release notes? Also, how often should we put out a source release? If the process is largely automatic, we could do it along with each Firefox release. Is that too often?

Dave

[1] But also very cool, if someone would like to take a crack at it. Actually, I'm not even convinced it's that hard, having made some simple systems like that myself. Integrating with MDN seems like the hard part.

[Miles]

Has any progress been made on this?
We embed Spidermonkey in our software (finite element pre and post processing software) and from my point of view it has been fantastic to have spidermonkey available to embed and use. Obviously it is in our interest to try to help somehow...
Looking at the date of the 1.8.5 release tarball on the ftp site that's now over 18 months old.
As I'm embedding spidermonkey rather than hacking on Spidermonkey/FF it's difficult to know whether there have been any significant changes since the 1.8.5 release and whether we should be trying to use a newer version or whether we should stick with the 1.8.5 release. I try to follow the newsgroups a bit but it's difficult to know what is important (are the changes since the 1.8.5 release documented anywhere or is this part of the problem!)...
How often should releases be done?
The problem is though that I'm not sure what I can do to help. I'm based in the UK so it's hard to talk on IRC as it seems that most people are in a differnt timezone. I've got some scope to spend a limited amount of time to help but I can't guarantee when that will be. It could end up being quite random but it would be good to try.
Is there anything I could help with?

[Josh Matthews]

On 01/10/2013 02:11 PM, Miles wrote:
> Has any progress been made on this?
> We embed Spidermonkey in our software (finite element pre and post processing software) and from my point of view it has been fantastic to have spidermonkey available to embed and use. Obviously it is in our interest to try to help somehow...
> Looking at the date of the 1.8.5 release tarball on the ftp site that's now over 18 months old.
> As I'm embedding spidermonkey rather than hacking on Spidermonkey/FF it's difficult to know whether there have been any significant changes since the 1.8.5 release and whether we should be trying to use a newer version or whether we should stick with the 1.8.5 release. I try to follow the newsgroups a bit but it's difficult to know what is important (are the changes since the 1.8.5 release documented anywhere or is this part of the problem!)...
> How often should releases be done?
> The problem is though that I'm not sure what I can do to help. I'm based in the UK so it's hard to talk on IRC as it seems that most people are in a differnt timezone. I've got some scope to spend a limited amount of time to help but I can't guarantee when that will be. It could end up being quite random but it would be good to try.
> Is there anything I could help with?
>

https://bugzilla.mozilla.org/show_bug.cgi?id=517765 is a nice roundup of
a bunch of the work that was identified.

Cheers,
Josh

[Tom Schuster]

Hi Miles,

don't worry about IRC. We are usually more quiet around European
hours, but when you ask a question there should always be somebody
there to answer. Of course the later the better. Just join #jsapi.

Cheers,
Tom

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

[Wes Garland]

The Lion's share of the source release process is indeed preparing the
documentation which documents what has changed from release. This is
particularly true these days given the awesome pace of Spidermonkey
development.

I wonder if we could remove that requirement entirely with the help of the
documentation team? jsapi developers seem to pretty good about documenting
new APIs, maybe we could get the Wiki guys to add a magic page which says
"Here are all the things which have been tagged as changing in version XXX".

Then we're just left with applying standalone-oriented patches and
coordinating with the distro guys etc for testing. Not so bad, especially
if we drop support for non-threadsafe builds.

It would be nice have designate community members who are willing to run
smoke tests on release candidates, since the Moz testing infrastructure
won't.

Wes

> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102