create mozilla.dev.tech.js-engine.internals for JS internals

RESOLVED FIXED

Status

mozilla.org
Discussion Forums
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Paul Biggar, Assigned: justdave)

Tracking

Details

(Reporter)

Description

8 years ago
The JS team has no mailing list. It needs one.

Name: dev-tech-js-monkeys

Description: Discussion about development of the JS engine, and its internals (note that dev-tech-js-engine should be used for discussion of the JS API, and for users of the js-engine, including embedders).

Admin: If admin-ing is a thankless task, I can do it. If it's an earned mark of esteem and respect, then sayrer or brendan should do it.



Meta stuff:

  To preempt questions of why dev-tech-js-engine is unsuitable: you would think that's what the list is for, but no-one actually uses it that way. Its actually only used to communicate with _users_ of the js engine. Perhaps an ideal solution would be to fix this, but my experience with online communities tells me that this has never actually worked in practice. Hence a new list.

  I hope I don't have to justify why we need such a list, but just in case: currently, the team members communicate by emailing other members directly. Occasionally people are forgotten, external contributors can't see what's going on, etc.
(Reporter)

Updated

8 years ago
Summary: create mailing list for JS internals? → create mailing list for JS internals
Sounds like you want a newsgroup + mailing list.
Assignee: server-ops → gerv
Component: Server Operations → Discussion Forums
QA Contact: mrz → justdave
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)
> Sounds like you want a newsgroup + mailing list.

Sure. Do we want a google group too? (It seems spammy, but the other mailing lists have one, right?)

Comment 3

8 years ago
What's wrong with the existing mozilla.dev.tech.js-engine list? I really think we'd be better off trying to use the existing list before segregating the traffic even further, unless there have been problems (although as a member of that list, I haven't noticed problems).
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> What's wrong with the existing mozilla.dev.tech.js-engine list? I really think

See comment #0
>   To preempt questions of why dev-tech-js-engine is unsuitable: you would think
> that's what the list is for, but no-one actually uses it that way. Its actually
> only used to communicate with _users_ of the js engine. Perhaps an ideal
> solution would be to fix this, but my experience with online communities tells
> me that this has never actually worked in practice. Hence a new list.

Basically, that list has established itself as a low-traffic list for communicating with users of the JS engine. We want a medium- to high-traffic list for a separate purpose (internals only discussion).
Random thought: are there any new systems that might be useful for this? Mailing lists seem pretty archaic to me, although for this kind of discussion old-school mail quoting seems pretty powerful, and a decent archive would take care of most of the rest. Still, I like trying new stuff. :-)
(In reply to comment #2)
> Do we want a google group too? (It seems spammy, but the other mailing
> lists have one, right?)

That problem is being taken care of in bug 598060.
m.d.t.js-engine is used for several purposes, but the last plan (sayrer helped drive people to agreement) had everyone using it for arbitrary discussions. Has that broken down? If so, were there ad-hoc mail threads cc'ing people by hand? I haven't noticed an uptick in the low-level background radiation.

Really don't want another mailing list. Google groups spam aside, it does not seem "broke" enough to be worth a fix that means more mail message copying and (bad) searching.

/be
(Reporter)

Comment 8

8 years ago
(In reply to comment #7)
> m.d.t.js-engine is used for several purposes, but the last plan (sayrer helped
> drive people to agreement) had everyone using it for arbitrary discussions. Has
> that broken down? If so, were there ad-hoc mail threads cc'ing people by hand?
> I haven't noticed an uptick in the low-level background radiation.

In the 2 1/2 months I've been on m.d.t.js-engine there have been exactly zero discussions about internals. The only thing close are announcements about changes to internals, but that's a very different thing.

I didn't know about sayre's agreement, but it's clear no-one uses m.d.t.js-e for this. I have a few emails where there is just a list of JS team recipients, not that many (sayre sent one incidentally). I assume I'm just not being CCed on them. Obviously I can't tell for sure, but the alternative is that JS people simply don't communicate by email. I find this hard to believe, but if true, we have a different problem.

I certainly think it is broke, I wouldn't have filed this otherwise. cdleary and I have been chatting for a few months about how little visibility there is on what's going on in the JS team, even for people who work there. This is a step toward fixing it.
We could use a js-team-and-not-just-the-paid-peers list, I agree. Whether we need a just-the-paid-peers-and-new-hires list is up to sayrer and not this bug.

If we saw lots of ad-hoc mail threads on internals, I'd find the case for a new list stronger. But I suspect that most "internals" discussions happen on IRC and in bugs. Do we really need mail too? More IRC persistence, OTOH...

/be
(In reply to comment #9)
> We could use a js-team-and-not-just-the-paid-peers list, I agree.

But that is not an internals list if the idea is to keep putting out discussions where anyone (all the new recruits in our future, especially) can see them. A new list just makes another place to miss, I think. So I'd rather we stick with IRC (with permalogs), mail, and m.d.t.js-engine. But I could be missing something. I'll shut up and let others comment.

/be
I guess bugzilla is the current main communications channel for JS internals. Is it not sufficient? What we would do on a mailing list that we don't do here?

There are a few private emails every now and then, but they are usually for things that are 1/4-baked or are only of interest to a small number of people.
(In reply to comment #11)
> I guess bugzilla is the current main communications channel for JS internals.
> Is it not sufficient? What we would do on a mailing list that we don't do here?

I think the problem with leaving everything to bugzilla is that bug comments don't lend themselves to high level reflection, analysis, and discussion. Bugs are supposed to be silos for people that roughly understand a problem to be fixed. It doesn't seem like typical usage to go into a specific bug with subsystem X and ask higher-level questions about subsystem X.

We have a tendency to leave little gold nuggets in bug comments and see bursts of comprehensive explanations in IRC -- they're awesome when you happen to come by them, but I think we could have a slightly better protocol that spreads the love a bit more:

When you feel like giving a near-context-independent explanation of something, send it to a mailing list (or whatever more interesting broadcast technology) and reference that explanation from the bug/IRC chat. You've effectively forked the high level (and potentially off-topic) followup discussion to another thread but directly linked the pertinent information to the bug.

This approach also lowers the barrier to getting information "out there" in a place people can comment on -- our wiki isn't particularly low overhead, but plaintext email is cheap.

*shrug*
I agree there are nuggets lost in bugs and IRC logs (or not logged). This is indeed a problem.

But I question whether these would all migrate to email. Better to log all #jsapi (and #jslang) and curate the best-of collections.

Ditto bugs (I have a saved bugmail corpus I "curate" in a low-rent, who-let-the-janitor-pick-the-art sense, but it helps me find stuff, like where I keep explaining that OOM happens and we can't fail hard on it [yet]...).

/be
(In reply to comment #13)
> Better to log all
> #jsapi (and #jslang) and curate the best-of collections.

Thinking imaginatively, the ideal would be a searchable "haveweexplainedityet.com" you could submit tagged blurbs to (from IRC or a bug comment) and ask for clarifications on. Maybe we can just use bugs tagged [omg-learning-jse] to this effect?

It's otherwise hard to get the asking-for-clarification feature from stale bug comments, except on IRC, which is a largely synchronous mode of communication (i.e. can suck for interacting with people in other time zones).
(In reply to comment #13)
> I agree there are nuggets lost in bugs and IRC logs (or not logged). This is
> indeed a problem.
> 
> But I question whether these would all migrate to email. Better to log all
> #jsapi (and #jslang) and curate the best-of collections.
> 
> Ditto bugs (I have a saved bugmail corpus I "curate" in a low-rent,
> who-let-the-janitor-pick-the-art sense, but it helps me find stuff, like where
> I keep explaining that OOM happens and we can't fail hard on it [yet]...).

It seems that if we had good search over bugzilla and archived IRC logs, it would be a lot easier to find these things. Can we expose bugzilla to Google search?
(Reporter)

Comment 16

8 years ago
(In reply to comment #11)
> There are a few private emails every now and then, but they are usually for
> things that are 1/4-baked or are only of interest to a small number of people.

Things that are 1/4 baked and only of interest to a small number of people are exactly the things that we want in a mailing list. If I could get people to write down their lunchtime conversations I would.


> I guess bugzilla is the current main communications channel for JS internals.
> Is it not sufficient? What we would do on a mailing list that we don't do here?

Bugzilla is good, I like the workflow. However, its good for mostly just one thing: adding a bug says "I, or someone, should do this at some point". I would wager that the majority of discussions in an open source project do not fall into this template. Here is a small sample:

 - how does X work?
 - why is X like this?
 - I have a hairbrained scheme for X, why is this stupid? (see bug 606198)
 - there is a talk on X soon (in practice, these are sent to all@mozilla.com I think).
 - have people seen the way lua do X?
 - what's the progress on X?
 - can we make X a high priority?
 - OMG we just crossed a line on AWFY
 - here is my tool X to help us.
 - please stop doing X or I will hunt you down


To be honest, I can't believe this is even up for discussion. Every open source project in the history of the world has a mailing list; its basically the first thing you do. If we don't use it, fine we don't use it, we can deprecate/delete/ignore it later.
(In reply to comment #16)
>  - have people seen the way lua do X?

We do file bugs on that. E.g., bug 549515.

>  - what's the progress on X?
>  - can we make X a high priority?
>  - I have a hairbrained scheme for X, why is this stupid? (see bug 606198)

Those would usually be bugzilla comments.

>  - there is a talk on X soon (in practice, these are sent to all@mozilla.com I
> think).

Yes.

>  - how does X work?
>  - why is X like this?

These are exactly the things that fall through the cracks. Some kind of "priceless wisdom repository" like Brendan has would seem to the thing here. It'd be nice if we had a simple tool where you could send it an email or some text with a title and tags and it would be archived and googlable.

>  - OMG we just crossed a line on AWFY

Twitter.

>  - here is my tool X to help us.

Mailing list seems ideal for this. When I do this I want to email everyone in JS-land and it's easy to mess up collecting the names by hand.

>  - please stop doing X or I will hunt you down

Interesting. Mailing list might be good for that, too.

> To be honest, I can't believe this is even up for discussion. Every open 
> source project in the history of the world has a mailing list; its basically 
> the first thing you do. If we don't use it, fine we don't use it, we can
> deprecate/delete/ignore it later.

I resist mainly because I think of email as an annoying, rather limited tool. I think it's good mostly for short asynchronous communications to one person or a small number of people that should arrive, be acted upon, and discarded promptly. In a JS group communications context, that seems to be mostly for announcements.

For general discussion, I think of web forums as being generally better. They are good for talking to many people, they have quoting, they can also have links and graphics, and most important, they are searchable. IMO newsgroups are just an obsolete version of that. Forums are also not bad for info repositories--they can have categories for that and sticky threads. 

Only problem with forums is that one of Brendan's original comments was not wanting an extra "thing" to check, which I kind of worry about too. But I guess forums can email you notifications, so it would show up in the inbox but not have all the limits of email.
(Reporter)

Comment 18

8 years ago
(In reply to comment #15)
> It seems that if we had good search over bugzilla and archived IRC logs, it
> would be a lot easier to find these things. Can we expose bugzilla to Google
> search?

I would love this. However, it wouldn't solve the problem.


There are different forms of communication, and each one constrains us in some way. We currently use blogs, bugzilla, IRC, twitter, BBQ Fridays, private email, work weeks, the summit. Each format not only affects how we think when we communicate in it, but what we actually choose to communicate. IRC is great for short questions and short answers. Twitter is good for broadcasting achievements. Bugzilla is good to discuss a single-minded task and one developer's progress towards it. Etc. Mailing lists are good for team-wide in-depth discussion, for announcements which don't fit into 140 characters (which is 98% of them).
(Reporter)

Comment 19

8 years ago
(In reply to comment #17)
> >  - what's the progress on X?
> >  - can we make X a high priority?
> >  - I have a hairbrained scheme for X, why is this stupid? (see bug 606198)
> 
> Those would usually be bugzilla comments.

Bugzilla is very unsuited for this. It only works if X is exactly one bug, if you know where that bug is (bugzilla is impenetrable).


> >  - there is a talk on X soon (in practice, these are sent to all@mozilla.com I
> > think).
> 
> Yes.

This leaves out external contributors.


> I resist mainly because I think of email as an annoying, rather limited tool. I
> think it's good mostly for short asynchronous communications to one person or a
> small number of people that should arrive, be acted upon, and discarded
> promptly. In a JS group communications context, that seems to be mostly for
> announcements.

Sure, all tools have their limitations. I think we have to balance this against how limited we are by not having a mailing list.

 
> For general discussion, I think of web forums as being generally better. They
> are good for talking to many people, they have quoting, they can also have
> links and graphics, and most important, they are searchable. IMO newsgroups are
> just an obsolete version of that. Forums are also not bad for info
> repositories--they can have categories for that and sticky threads. 

I don't understand, mailing lists have everything above (since at least 2004 - you have gmail right?) Sticky threads can be approximated by a FAQ, either sent out periodically or linked from the MDC page.

Other than that, I would argue that forums are significantly inferior. However, I don't want to get into this. There isn't a proposal for forums (and I'd rather we didn't make one, a competing proposal will kill both).
(In reply to comment #14)
> (In reply to comment #13)
> > Better to log all
> > #jsapi (and #jslang) and curate the best-of collections.
> 
> Thinking imaginatively, the ideal would be a searchable
> "haveweexplainedityet.com" you could submit tagged blurbs to (from IRC or a bug
> comment) and ask for clarifications on. Maybe we can just use bugs tagged
> [omg-learning-jse] to this effect?

How does http://quotes.burntelectrons.org/ work? Would more people helping put content on it and rank the content help?

/be
(In reply to comment #16)
> To be honest, I can't believe this is even up for discussion. Every open source
> project in the history of the world has a mailing list; its basically the first
> thing you do.

We've had a jseng or js-engine list/group forever, so this is not "up for discussion". The issue is making *another* list, probably a crappy mailman one, yet another place to search for interesting messages lost in the long tail.

> If we don't use it, fine we don't use it, we can
> deprecate/delete/ignore it later.

I'm still in favor of people using m.d.t.js-engine more for exploratory posts.

/be
OMG, Google Groups has lost it again. Spam as far as the eyes can see:

http://groups.google.com/group/mozilla.dev.tech.js-engine/topics

Ok, what are our server-side forum options?

The problem of curating best-of lists still remains.

/be
http://ejohn.org/blog/google-groups-is-dead/

See the comments where a Google Groups PM tries some un-good (inviting jresig to join a closed next-gen preview program -- which by now should have been released, btw, but the spam is worse than ever) damage control and gets rightly flamed for it.

/be
(In reply to comment #19)
> > >  - there is a talk on X soon (in practice, these are sent to all@mozilla.com I
> > > think).
> > 
> > Yes.
> 
> This leaves out external contributors.

We video public talks for broadcast on Air Mozilla to let everyone see them in non-real time.

/be
(In reply to comment #20)
> How does http://quotes.burntelectrons.org/ work? Would more people helping put
> content on it and rank the content help?

It would be nice to avoid bootstrapping another system with decent search, tagging, email notification, and other desirable features. Bugzilla can do this now, we just need to agree on a tag -- seems like a low-overhead and low-latency solution to this issue. Is there some reason we shouldn't use bugzilla?
Bugzilla (a) doesn't capture IRC logs; (b) has a '90s, pre-Ajax, painfully modal and high-latency search interaction design and implementation.

/be
Jesse says http://quotes.burntelectrons.org/ is just for funny quotes.

Thinking of launching my server-side career with sammy.js front end talking to a nodejs back end interfacing to bugzilla, email, irc, and twitter...

/be
(Reporter)

Comment 28

8 years ago
(In reply to comment #21)
> We've had a jseng or js-engine list/group forever, so this is not "up for
> discussion". The issue is making *another* list, probably a crappy mailman one,
> yet another place to search for interesting messages lost in the long tail.

The jseng list, whether by intent or not, is a user list. If it were to be named according to how it's actually used, it would be called "spidermonkey-users".


> > If we don't use it, fine we don't use it, we can
> > deprecate/delete/ignore it later.
> 
> I'm still in favor of people using m.d.t.js-engine more for exploratory posts.

Me too, but I don't think this will happen. I've been studying online community for a few years now, and even started a company based on the topic. The number one rule of online community is that you can't change a community's behaviour. We won't be able to change how that list works. In fact, we won't even be able to change how _we_ work with that list. Every time we post to it, we'll think "that list is full of embedders, and they don't care about my [work week schedule|how V8 uses PICs|that Paul just joined the team|etc]". And so, we won't post to it, or at least won't post to it much. I think proof of this is that you've said we already have the OK to post to that list, and yet we don't.

If I thought we'd use the list, I'd be pestering people to post to it. But it won't happen, and that's why I've proposed the new list.
(Reporter)

Comment 29

8 years ago
(In reply to comment #22)
> The problem of curating best-of lists still remains.

A great idea. Perhaps a simple wiki page, hung off https://developer.mozilla.org/en/spidermonkey?
Paul, having gone blind looking at the sewer of spam flooding m.d.t.js-engine, I give -- you are right, even if it weren't spammy, it would be an API users' list more than anything else, but now it is hopelessly polluted.

But mailman lists suck. I think we want something else. I've cc'ed folks who know about better options includling server-side forum software that may actually be deployed already on mozilla.org.

/be
(Reporter)

Comment 31

8 years ago
(In reply to comment #30)
> Paul, having gone blind looking at the sewer of spam flooding m.d.t.js-engine,
> I give -- you are right, even if it weren't spammy, it would be an API users'
> list more than anything else, but now it is hopelessly polluted.

:)

 
> But mailman lists suck. I think we want something else. I've cc'ed folks who
> know about better options includling server-side forum software that may
> actually be deployed already on mozilla.org.

I do think a mailing list is exactly what we need, given what I think we should use it for (see comment 16). But I'm open to hearing other suggestions.
(In reply to comment #26)
> Bugzilla (a) doesn't capture IRC logs; (b) has a '90s, pre-Ajax, painfully
> modal and high-latency search interaction design and implementation.

To address point (a), you can just make a "learning bug" titled, "How does X work?" and copy/paste the IRC chat log contents if somebody deems it valuable. We already open some bugs like this. It would capture the logs as well as any other copy-n-paste-with-editing system could.

WRT (b), I think we should just pick a solution that works now and kick it out the door. Sure, Bugzilla search can be improved for general productivity increases at Mozilla; however, people are already necessarily tied into that system. No reason for us to try a workaround when we already sink-or-swim by the usefulness of that feature.

I'd prefer Bugzilla to a mailing list. Just my two bits... I've already passed by bikeshedding quota here.
(In reply to comment #31)
> > But mailman lists suck. I think we want something else. I've cc'ed folks who
> > know about better options includling server-side forum software that may
> > actually be deployed already on mozilla.org.
> 
> I do think a mailing list is exactly what we need, given what I think we should
> use it for (see comment 16). But I'm open to hearing other suggestions.

Comment 16 has nothing about mailman's deficiencies, or the general problem of copying messages with long-term utility all over creation, intermixed with short term and noise messages, for each and every one of us to then have to crawl over with search terms such as "OOM" and "PIC", trying to separate the wheat from the chaff.

A wiki doesn't curate itself, so I'm really looking for (a) curators who can do the job; (b) decent linkability (mailman lacks this); (c) wiki markdown that does not suck (I like dokuwiki but it seems to be dying).

A wiki with curators, etc., plus mail (but not mailman): maybe. But you have to do more than comment 16 to sell this.

/be
(In reply to comment #32)
> (In reply to comment #26)
> > Bugzilla (a) doesn't capture IRC logs; (b) has a '90s, pre-Ajax, painfully
> > modal and high-latency search interaction design and implementation.
> 
> To address point (a), you can just make a "learning bug" titled, "How does X
> work?" and copy/paste the IRC chat log contents if somebody deems it valuable.
> We already open some bugs like this. It would capture the logs as well as any
> other copy-n-paste-with-editing system could.

Nothing prevents this, you said we have some like this already. Let's lean into it until something breaks or it wins. If it breaks, draw conclusions we can act on to do something else?

> WRT (b), I think we should just pick a solution that works now and kick it out
> the door. Sure, Bugzilla search can be improved for general productivity
> increases at Mozilla;

This seems never to happen. I think we passed on a consultancy that wanted to take a swing at it. I'm not holding my breath, although I may do something myself (because really, we engineering-hacker-types and not some mythical other group or "type" will have to hack our own tools, as ever, to get what we really want; this goes back to original bugzilla, tinderbox, etc.).

> however, people are already necessarily tied into that
> system.

The MySQL database can have other front ends.

> I'd prefer Bugzilla to a mailing list. Just my two bits... I've already passed
> by bikeshedding quota here.

I hear ya, on both points. I'm shutting up again, hoping we get something from Deb or Gerv on the forum front.

/be
The only web forum software I know of that we currently deploy anywhere is phpbb, which is used for the AMO Developer Hub:

https://forums.addons.mozilla.org/

Fligtar might have some feedback about that system one way or another -- like most things, it has its quirks.

One thing about phpbb is that it is really suited to fairly high traffic and normally is configured with multiple forums, which it doesn't sound like you need.  On the other hand, there might be other lists/groups looking for a new home as well.

If phpbb is overkill, there's a simpler system called "Vanilla Forum" that's back under active development and looks really very good: http://vanillaforums.org/
(Reporter)

Comment 36

8 years ago
(In reply to comment #33)
> (b) decent linkability (mailman lacks this);

I agree this is important. Is it possible to set our mailman up to do this well? Ideally, each email would have its canonical URL in the footer. Are archives turned off on mailman, since we use Google groups? Why do we use Google Groups, (apart from the fact that the other mailing lists are doing it)?



> A wiki doesn't curate itself, so I'm really looking for
> (a) curators who can do the job;
> (c) wiki markdown that does not suck (I like dokuwiki but it seems to be dying).
> A wiki with curators, etc., plus mail (but not mailman): maybe. But you have to
> do more than comment 16 to sell this.

Sure, mailman isn't good for curating information, but that's not the problem this bug is trying to solve. I think we should open a different bug for the "information curation" problem, which I agree needs work. I don't think it will be solved by changing from a mailing list to an online forum (which additionally comes with its own problems, and I feel will cause it not to be used).
Re: comment 36: yes, you want a mailing list and hope to go from there. I'm arguing that is to path-dependent and we could easily end up with yet another mailman-style list and nothing better. That seems almost worse than what we have right now: bugs and IRC.

You're right that bugs are not email, but email is not so much better for threaded discussions and archiving that we want both in any form. In particular we need something better than mailman as instantiated on mail.mozilla.org.

Forums are an unknown area, but whatever their problems if they had mail gateway capability then the might be a superset of mail, with better linking, archiving, search, curator support (ranking, social stuff).

/be
(Reporter)

Comment 38

8 years ago
(In reply to comment #37)
> Re: comment 36: yes, you want a mailing list and hope to go from there. I'm

Sort of. I think the problem we have is solved by a mailing list. I recognize that there are some things that mailman isnt great at, and I'll split these into two sets:

- things that can be fixed relatively easily (turn off google groups, file some bugs to twiddle with some settings)
  - linking
  - archiving
  - search

- things that are not so easy:
  - curator support
  - ranking
  - social stuff

These latter three are ill-defined. What social stuff do we need? What ranking do we need? For curator support, you mean you want to curate the nuggets of information that are spread over different media?

Why exactly do we need curator support? (I'm not saying we don't, I just want to figure out exactly what you're thinking. Is it for noobs, or part of your workflow, etc?)
> - things that can be fixed relatively easily (turn off google groups, file some
> bugs to twiddle with some settings)
>   - linking
>   - archiving
>   - search

Unless you know more about mailman or uprev fixes that we lack, it cannot be tweaked to fix these problems.

We have mailman archives that miss messages, mangle some badly (each paragraph in a format=flowed MIME part runs in one long horizontal plain text presentation, or even data loss [examples not in my archives, but I've complained to Aravind in the past]).

The archives are badly organized and hyperlinked, only by "Thread" but really by Month, or Date, or Sender. No modern threading, just lame and lossy '90s style threading (Netscape 2 did much better).

The archives create the "parachute problem" Jakob Nielsen has cited, where you have to dive in from 20,000 feet, and if you miss, you go get in another plane, go back up, and skydive again.

Google site: search works better than the built-in search. But no threading and bad formatting and splitting of threads across months, not to mention the format=flowed problem, don't improve due to site searchability. Oddly, I've found stuff via the nabble.com archive of es-discuss that Google misses -- possibly just data loss or corruption (mentioned above in [brackets]) in mailman's archiver, but I've never had time to dig.

Linking: is there a way to get mailman to put each message's short-enough link in the footer? Not AFAIK. Isn't the archiving done asynchronously and after the list has been updated, i.e., the link cannot be precomputed easily?

/be
Another spin on this: mail is dying, slowly. It'll be around for centuries, I'm sure -- on the (STL, since we are in the Slow Zone and the Singularity has been postponed indefinitely :-P) starships to Alpha Centauri along with JS and twitter (I am not kidding). But it will be an archaic transport and gateway hack at that point, I'm betting.

We should go with a web interface first, mail gateway second. Going the other way guarantees you won't get any of the six desiderata listed in comment 38:

  - linking
  - archiving
  - search
  - curator support
  - ranking
  - social stuff

/be
What do you mean by a "mail gateway", and how high of a priority is it?

Neither phpbb nor Vanilla web forums have "post by email" features or plugins that I've found, but both can be configured to send mail notifications/messages for new posts or discussions.
(Reporter)

Comment 42

8 years ago
(In reply to comment #39)

OK, I hadn't realized mailman has all these problems. Are we in a position to use something else for mailing lists.

(In reply to comment #40)
> Another spin on this: mail is dying, slowly.

Perhaps, but (ignoring implementation issues with mailman) it remains the gold standard for OSS discussion. Everyone who would use the lists understands how to behave, the social etiquette, how to quote, etc. 

 
> We should go with a web interface first, mail gateway second. Going the other
> way guarantees you won't get any of the six desiderata listed in comment 38:

I'm very much of the opposite persuasion. A web interface introduces a high cost for users: knowing about it, logging in, a new password, a new interface, having to check it (or open a new page from within your mail client).

I would of course agree with a web interface if we required something we cannot get from a mailing list:
 
>   - linking
>   - archiving
>   - search

These are mailman problems, not mailing list problems.

>   - curator support
>   - ranking
>   - social stuff

Can you be more specific on what these actually are (see my questions in comment 38)? I don't see how these have anything to do with the problem I'm trying to solve here.
(In reply to comment #42)
> (In reply to comment #39)
> 
> OK, I hadn't realized mailman has all these problems.

Noted (see below).

> Are we in a position to use something else for mailing lists.

http://en.wikipedia.org/wiki/Electronic_mailing_list

MajorDomo seems to have faded behind mailman.

> I'm very much of the opposite persuasion. A web interface introduces a high
> cost for users: knowing about it, logging in, a new password,

LDAP.

> a new interface,

Web, it's usually point and click.

> having to check it (or open a new page from within your mail client).

Mail gateway.

> I would of course agree with a web interface if we required something we cannot
> get from a mailing list:
> 
> >   - linking
> >   - archiving
> >   - search
> 
> These are mailman problems, not mailing list problems.

You just acknowledged you did not know these were problems at all, never mind mailman problems. Now you are asserting there's other mailing-list software that solves them. Pray tell what, specifically?

Our last answer was Google Groups (listed in the wikipedia page). It failed.

We use mailman too, but suffer the problems I've taken too much time to write about with specific details here.

> >   - curator support
> >   - ranking
> >   - social stuff
> 
> Can you be more specific on what these actually are (see my questions in
> comment 38)? I don't see how these have anything to do with the problem I'm
> trying to solve here.

I've been specific.

You are not acknowledging my point that if you divide-and-conquer and do only email for now, you'll get IT to make another mailman list, which will make another distributed mess with externalities or simply deferred costs that we'd like to avoid.

I'm suggesting we try something different to give more weight to all six of these mailman pain points: linking, archiving, searching, curating, ranking, social. "Social"if it means anything must mean identity by which to compute default ranking and do some automated best-of curating via reputation, although explicit ranking has its place too.

I'm not asking for the moon. I'd take something that has decent web app UI and APIs but uses mail as its primary, so long as it can pre-generate perma-links for each message and put them in a footer. And it threads properly (not subject threading!). And so on, but I don't want to rehash my criticisms of mailman.

Again, what is that hypothetical something?

No one has yet said. I don't know. Seems like server-side forum software could be useful -- maybe, maybe not. Another thought: perhaps nabble.com or something like it could be cloned or used, and subscribed to the list (even a mailman list), and solve some of the six problems. Anyone know more?

In order to move this bug forward, I think *you* need to be specific. What are you proposing, that is mail-based but not a mailman list, that does not have the mailman problems I've specified?

/be
Wow, this has been a fast-moving discussion. :-)

The spam problem in the current groups is known; there is a plan to fix it:
https://wiki.mozilla.org/Discussion_Forums/Proposal
(I'm surprised Brendan doesn't know about it; it's been in .governance, .planning and on Planet in my blog posts.) 

The current status is in bug 598060. We switched over four groups on a trial basis this week. Giganews and Google are having some problems implementing something which should be fairly simple, but justdave is chasing them. When we spoke on the phone, Mitchell was keen to make this happen, so I expect to see traction - but feel free to apply more pressure to IT if you have leverage to exert. 

With these changes, we hope to turn the current forums back into usable places to work again. I would ask people to let the dust settle on this and see if it fixes the problem before giving the existing forums up as lost.

With regard to archiving etc.: the reason we have all three of mailing lists/Google Groups/newsgroups is that none of the three mechanisms provides all the features on its own. Given the (to me amazing) incredible multi-year fail of the mailman team to build an archive interface that would be at home in the 2000s, let alone the 2010s, Google Groups is used for linking, archive and search, and I think it does the job well. (I haven't seen the problems Brendan seems to be seeing.) People who like to use a web interface post that way too. Other people prefer the push nature of mailing lists, or the well segregated and ordered nature of newsgroups. 

I agree with Paul that web-only interfaces suck. People have thrown away all of the advantages of e.g. newsgroups for pushed, segregated, threaded discussion to gain the momentary advantage of not needing a client dedicated to a particular task. <sigh> Perhaps its a combination of browser failure and web-based discussion forum UI failure (again, a fail almost as big as mailman's), but web-based forums still mostly don't even have the concept of marking a message as read, let alone a thread!

Brendan said:
> I'm not asking for the moon. I'd take something that has decent web app UI and
> APIs but uses mail as its primary

If such a thing existed, we'd use it like a shot (we could create newsgroups using things like gmane). But for my mind, no-one has a decent web app UI for discussion. The best is Google Groups, and their UI isn't open source. Ideally, someone would fix mailman's archive UI. Of course, we can bolt new UIs onto things by writing a web API, but you can't bolt on better search.

I agree that the current implementation of discussion forums at Mozilla doesn't have the "social stuff", but I think the problems you are describing in relation to that are not discussion forum problems, they are information capture problems. 

To return finally to the subject of this bug: I have no opinion on whether you guys need another list, although I agree with Paul's point about it being hard to change the nature of communities which already exist.

Gerv
(In reply to comment #44)
> Wow, this has been a fast-moving discussion. :-)
> 
> The spam problem in the current groups is known; there is a plan to fix it:
> https://wiki.mozilla.org/Discussion_Forums/Proposal
> (I'm surprised Brendan doesn't know about it; it's been in .governance,
> .planning and on Planet in my blog posts.) 

(I tuned out in order to focus on other priorities. I'm not sure you'll avoid the mailman message-mangling problems, but you may have tested already. Other nits and concerns in the separate bug.)

> The current status is in bug 598060. We switched over four groups on a trial
> basis this week. Giganews and Google are having some problems implementing
> something which should be fairly simple, but justdave is chasing them.

Surprise, surprise.

> When we
> spoke on the phone, Mitchell was keen to make this happen, so I expect to see
> traction - but feel free to apply more pressure to IT if you have leverage to
> exert. 

It's not our IT that I would worry about pressuring.

> With these changes, we hope to turn the current forums back into usable places
> to work again.

The archives are pretty polluted. Also, to get back to Paul's point, m.d.t.js-engine is really m.d.t.jsapi-users, and we should probably rename it. For this bug we'd then want m.d.t.js-internals, and I'm pretty sure moderation would be better than no moderation (but I'm not volunteering to be a moderator).

> Given the (to me amazing) incredible multi-year
> fail of the mailman team to build an archive interface that would be at home in
> the 2000s, let alone the 2010s, Google Groups is used for linking, archive and
> search, and I think it does the job well. (I haven't seen the problems Brendan
> seems to be seeing.)

I was complaining about mailman archiving/linking/search, not Google Groups. I can complain about GG too, mainly for overlong and impenetrable links, but the intertwinglyg, searchability, and (ignoring spam pollution, which is a non-ignorable problem!) archive presentations are much better than mailman's.

> If such a thing existed, we'd use it like a shot (we could create newsgroups
> using things like gmane). But for my mind, no-one has a decent web app UI for
> discussion. The best is Google Groups, and their UI isn't open source. 

What became of your nabble.com option? Did anyone investigate it at all?

> I agree that the current implementation of discussion forums at Mozilla doesn't
> have the "social stuff", but I think the problems you are describing in
> relation to that are not discussion forum problems, they are information
> capture problems. 

Fair enough -- if we had decent links/search/archiving, the rest could be added value via other web interfaces.

> To return finally to the subject of this bug: I have no opinion on whether you
> guys need another list, although I agree with Paul's point about it being hard
> to change the nature of communities which already exist.

Yes, Paul is right. So could we have a m.d.t.js-internals list pretty quickly using your new scheme?

/be
I'm not in love with any of the names mentioned, or the js-engine name. Without going overboard, we could use the USENET hierarchy harder:

m.d.t.js.api
m.d.t.js.internals

and cross-cutting issues cross-post with followups set to .internals.

Plurals are a problem in such names (and database rows, etc.), so possibly the ".internals" name is just wrong. Could use .js.engine or .js.impl -- latter to match the brevity of .api. Bikeshed a bit with the JS team and #jsapi regulars including Wes, strive for consensus. I'm done.

/be
Sorry, I lied: one more thing (not to play fakesteve), Rhino and Narcissus people have used m.d.t.js-engine and its predecessor, but Rhino really wants its own group. Perhaps it has one and I have forgotten about that, or I have missed the announcement?

Dave Herman pulled the mailman trigger on a narcissus list, which has no traffic other than initial posts, so we'll see how that goes. Devil-we-know.

/be
This bug is an unmitigated disaster.  It's pretty much completely full of perfect-is-the-enemy-of-good and stop energy.  Rather than find or implement the perfect way to discuss JS engine internals (the "nugget" tangent is interesting but still is one), can we just pick something we've worked with before, either newsgroup or newsgroup plus mailman, and run with it?

Producing the architecture for discussion in the twenty-fourth century is much less important than just being able to discuss engine internals, especially as concerns this bug's complaint.  And it doesn't seem to me that tying up a bunch of core JS hackers' in discussion here is at all productive, if we each are extremely unlikely to invest significant time in implementing any potential solution (if there really are none at present).
(In reply to comment #47)
> Rhino really wants its own group. Perhaps it has one and I have forgotten
> about that, or I have missed the announcement?

m.d.t.js-engine.rhino
(In reply to comment #48)
> This bug is an unmitigated disaster.

Your comment is noisy grandstanding.

> It's pretty much completely full of perfect-is-the-enemy-of-good

As is well known, I'm not a perfectionist. Meanwhile others (presumably you are attacking me, not cdleary) have argued for more bugzilla, less email. If you wanted a mailman list so badly, where were you? Not waiting for pbiggar all the past many years.

And now look at what Gerv et al. have come up with: a better plan, already under way, which is not "just mailman."

Since Gerv's plan is predicated on the plain fact that mailman by itself is not good enough, but mailman by itself is exactly what fixing this bug as filed would have used, ergo "stop energy" was needed. So stop bad plans, start and continue good plans, and cut the platitudes and grandstanding noise comments.

/be
(Reporter)

Comment 51

8 years ago
(In reply to comment #45)
> Yes, Paul is right. So could we have a m.d.t.js-internals list pretty quickly
> using your new scheme?

Ok, we have consensus that we're getting a new list!!

So now we just need to argue on its name. This could go on forever, so I'm setting arbitrary limits and choosing the best option myself [1] at the deadline, which is 4am PDT on Wednesday morning.

Option 1:

  The simplest option. We create a new list, and name it m.d.t.js-internals. We'll do this if I've heard no argument by the deadline.

Option 2:

  We create a new list with a better name that m.d.t.js-internals. We'll do this if someone's got a name that's clearly better than m.d.t.js-internals, and is willing to champion it.

Option 3:

  We rename m.d.t.js-engine to m.d.t.js.api and create the new list as m.d.t.js.internals (or a better name). This means a possibly backwards incompatible change to the old list. We'll do this if (1) someone champions the change, (2) brings it to m.d.t.js.api and gets agreement, and (3) gets approval from the server overlords that this is allowable and a good idea. This may take longer than the deadline, so speak up before then if you intend to do all this, and we can put a few more days on the clock.


OK, let the bikeshedding begin. I'll see you Wednesday.


[1] I'm new here and so I'm not the best chooser. If you'd prefer to choose the name, contact me off-bug.
David Ascher pointed out privately that "internals" connotes inside-Mozilla employer/employee stuff. OTOH "engine" is taken and I have no idea how hard it would be to rename/forward to "api-users". How about "implementation"? (Implied "js-" prefix as ever.)

/be
(In reply to comment #50)
> Your comment is noisy grandstanding.

Disagree.  I was observing that forty-odd comments said little of value and that we should *do* rather than discuss without advancing.

> If you wanted a mailman list so badly

I do not.  I simply want something -- whatever it is -- without having to wait for an improvement that may not be as fast in coming as just reusing existing, proven infrastructure.

I should probably not have said "either newsgroup or newsgroup plus mailman", because that appears to have suggested I had one preferred system (mailman, by your interpretation).  What I really wanted was a half-decent existing system could get running with the minimum of effort.  Whatever particular system that is, I don't care.  Whether it's mailman, Google groups, or either plus mailman, does not matter in the slightest to me.

> where were you? Not waiting for pbiggar all the past many years.

Yes, I was -- I will admit to this.  I had not yet become annoyed enough to *act* upon that dissatisfaction (just as we all delay filing some bugs just because we've become too accustomed, sometimes unconsciously, to working around them).  It took the new wheel, not inured to squeakiness, to actually lead to action.

Gerv's promised-land solution solves the problem of spam.  Hurray!  But I do not think it is "the better plan" that fully addresses this bug because it does not solve the problem as originally stated: that we need a new [discussion forum of some sort] because "no-one actually uses [mdt.js-engine] that way".  The groups spam phenomenon is relatively new.  It isn't the reason I personally have not used mdt.js-engine.  I don't think it's the whole reason others have avoided mdt.js-engine.  I really do think we need a new "forum" (again, whatever it is I don't care, as long as we don't spin wheels here without getting something now) for JS hackers, that is not conflated with a list for embedders.

To reiterate: I am absolutely happy to discuss improvements after getting an initial cut done.  But I believe there are implementation discussions we could be having now in a laser-focused discussion forum solely for engine internals, without waiting on Google and/or Giganews to act, but even then still having the split-focus issue to contend with.
Way too many words in comment 53. Way too many for the content. In particular, laser-focused JS internals talk goes in bugs for now, we have more than enough blockers for this release. No way is lack of a mailman internals list a blocker that stops other work from happening.

To rehash the obvious: creating just a mailman list now to avoid working on a Gerv-et-al. mailman front end to a new Google / Giganews group soon is a bad plan because it will be a short-lived data coffin. No migration.

And what's the rush? Unless you are applying "stop energy" to Gerv's plan, it will happen and the new group will be implemented using that plan.

/be
To be clear: mailman/Google/Giganews groups are available now; that's what all the existing groups are. We are just working on reconfiguring them so all incoming messages come to us first, so we can apply our own spam reduction algorithms and software rather than relying on Google and/or Giganews.

If you want such a group now, you can have one (bikeshed on the name and get back to me). The mailman part arrives as soon as IT starts work on the bug, the other parts maybe 24 hours later - it's a pretty quick process. But if you want to wait until we've fixed the spam problem, so even the start of your archives are spam-free, come back in a few weeks.

BTW, in terms of picking the name, as keeper of the namespace, the mozilla.dev.tech hierarchy seems like the right place. .js-internals, .js-dev, or .js-somethingelse would all be fine.

At your service,

Gerv
(Reporter)

Comment 56

8 years ago
Brendan mentions the a problem with -internals. I suggested that because the project's I've been involved in in the past (GCC, PHP, phc) all name or refer to their groups as "internals". However, there is no history of doing that in Mozilla-land, so perhaps we can't rely on that understanding. I think Brendan's problem (implies Mozilla-insider status) has some validity.

js-dev is nice.

"JS Hackers" is good. I had been thinking about it, and waldo's post mentioned that phrase explicitly. This could be m.d.t.js-engine.hackers or m.d.t.js-hackers.


I think the Mozilla hierarchy is already quite inconsistent, so I don't think its a good idea to worry about preserving it too much, except that m.d.t is probably a good prefix for the newsgroup.


Gerv: Is the mailman name tied to the newsgroup prefix? Can we have, for example, js-internals@mozilla.org and also m.d.t.js-engine.internals?
(In reply to comment #56)
> I think the Mozilla hierarchy is already quite inconsistent, 

Really? I'm rather pleased with how consistent I've managed to keep it. <shrug>

> Gerv: Is the mailman name tied to the newsgroup prefix? Can we have, for
> example, js-internals@mozilla.org and also m.d.t.js-engine.internals?

Aliasing is technically possible, but only today I asked one group who were making a new list not to do that. The reason is that some automated tools (like the one which generates http://www.mozilla.org/about/forums/ , for example) rely on the names for the different parts having a fixed relationship to each other. So the longer name is going to be used in at least some places and by some people, and if you have two names, it could cause all sorts of confusion, both for humans and for software.

Gerv
(Reporter)

Comment 58

8 years ago
(In reply to comment #57)
> (In reply to comment #56)
> > I think the Mozilla hierarchy is already quite inconsistent, 
> 
> Really? I'm rather pleased with how consistent I've managed to keep it. <shrug>

You're right, I misspoke. I should have said 'slightly'. Apologies.


> > Gerv: Is the mailman name tied to the newsgroup prefix? Can we have, for
> > example, js-internals@mozilla.org and also m.d.t.js-engine.internals?
> 
> Aliasing is technically possible, but only today I asked one group who were
> making a new list not to do that. The reason is that some automated tools (like
> the one which generates http://www.mozilla.org/about/forums/ , for example)
> rely on the names for the different parts having a fixed relationship to each
> other. So the longer name is going to be used in at least some places and by
> some people, and if you have two names, it could cause all sorts of confusion,
> both for humans and for software.

OK, we'll keep the names together. It isn't a huge burden for people to type the full email address out.
Brendan, this conversation is going nowhere fast, and I don't know why, and I'm not sure I'm going to be able to figure out why.

But let me ask a question one last time to see if I can figure out where you're coming from, and maybe your answer will help me.  Why is not-mailman-for-discussion the hill to die on?  I could understand if mailman were truly awful, but it isn't -- it's not great, but it does a passable job, more or less.  All the existing Mozilla discussions use it, in concert with Google Groups.  es5?-discuss uses it.  We could live with ugly styling (where's this discussion happening? ;-) ).  The mis-formatting issues could be ameliorated with a touch of stylesheet love.  The migration path from it to the new system is straightforward, because it's no different from the migration path for everything else.  What made this argument so important as to spread it over four days and forty-four comments before Gerv arrived with a proposal, when an existing solution is not utterly, completely unpalatable?  This is the core issue I have with this bug, that still has me completely confused by it.
I'd be mildly leery of js-devs and js-hackers attracting people who hack in JS rather than on the interpreter, which I think was the etymology of the jsengine name in the first place.  js-interpreter?
pbiggar: credit for insider-fear goes to david-ascher.

jwalden: mailman is not what we're doing, so there's not much point in rehashing how it makes another data coffin where any good answers, bug links, IRC quotes, etc. will be lost or mangled in a crappy archive. Then we'll need to repeat the cleanup and re-link or migrate. But since we are not going to just make a mailman list, I don't know why we're talking about this any longer.

dmose: Hello, jits! It's not just an "interpreter".

The js-dev precedent is python-dev: http://mail.python.org/mailman/listinfo/python-dev. But js-dev is a bit short and generic. All js engines? Rhino? V8? Yeah, as with python-dev we need a red-letter warning that developers writing in Python do not want this list, but can we do better?

If js-engine is the API users list, can we rename it? We could for example move it down to js-engine.api, and have js-engine.dev for what this bug wants. The full names are too long, though.

/be
Not sure about renaming lists; I suspect that might be a bit tricky. Easier just to create a new one, automatically migrate the mailing list users, and post messages telling the news and GG ones to resubscribe to the new thing. I think we've done that before once or twice.

Gerv
(Reporter)

Comment 63

8 years ago
(In reply to comment #60)
> I'd be mildly leery of js-devs and js-hackers attracting people who hack in JS
> rather than on the interpreter, which I think was the etymology of the jsengine
> name in the first place.  js-interpreter?

Makes sense, but js-engine.hackers or js-engine.devs would probably work. That said, names of the other groups tend to discuss what goes on there, for example "planning", "platform [development]", "crypto[graphy stuff]", "evangelism", rather than the people in it ("devs", "hackers").
(Reporter)

Comment 64

8 years ago
My original suggestions, which was mostly unserious, was js-monkeys, where monkeys are spidermonkey, tracemonkey and now jaegermonkey. The name isn't great because it's opaque, but of course not to its intended recipients. It's looking more attractive now considering the problems with the other names.
(Reporter)

Comment 65

8 years ago
(In reply to comment #61)
> If js-engine is the API users list, can we rename it? We could for example move
> it down to js-engine.api, and have js-engine.dev for what this bug wants. 

Its nice naming, but backwards incompatible. If we're going to do this, it needs an executive decision.

> The full names are too long, though.

Are they? Presumably people add the mailing list to their contacts, and bookmark the group, so it's a once-off cost. I don't think we're scaring anyone off with a long name.
(Reporter)

Comment 66

8 years ago
OK, I think the right choice here is m.d.t.js-engine.internals. We can't change the jsapi list's name, -dev doesn't send the right 'internals hackers here only' message, but I think 'internals' does. It also keeps with the general scheme of naming the lists after what is discussed in them, rather than who the list targets. Note that "internals" are not the same as "internal", and it's neither a plural, nor a Mozilla-only signal, though there still remains the possibility of people getting this wrong. Still, I think its a small problem, and there are small problems with each suggested name.
(Reporter)

Comment 67

8 years ago
Ok, Gerv, back to you now I think:

Mailing list: dev-tech-js-enginge-internals
Newsgroup: mozilla.dev.tech.js-engine.internals

Description: Discussion about development of the JS engine, and its internals
(note that dev-tech-js-engine should be used for discussion of the JS API, and
for users of the js-engine, including embedders).

Admin: I can do it.
Over to server ops to implement comment 67 (without the typo ;-).

Gerv
Assignee: gerv → server-ops
Component: Discussion Forums → Server Operations
QA Contact: justdave → mrz
Assignee: server-ops → justdave
Component: Server Operations → Discussion Forums
QA Contact: mrz → justdave
(Reporter)

Comment 69

8 years ago
Ping?
(Reporter)

Comment 70

8 years ago
Can I check on the status of this?
List created, filed ticket with Giganews for newsgroup creation, and google group shortly after
Assignee: justdave → jlazaro
Whiteboard: [list created, emailed giganews for newsgroup creation]
Whiteboard: [list created, emailed giganews for newsgroup creation] → list and newsgroup created, escalating to google for groups creation]
Assignee: jlazaro → justdave
Whiteboard: list and newsgroup created, escalating to google for groups creation] → [list and newsgroup created, escalating to google for groups creation]
(Reporter)

Comment 72

8 years ago
Is there anyway to chase this up with google? There's currrently no group AFAICT.
(Reporter)

Comment 73

8 years ago
Where do I file a bug to get this listed on https://www.mozilla.org/about/forums/?
Paul: I just did it (wait 30 minutes to see it).

Gerv
(Reporter)

Comment 75

8 years ago
(In reply to comment #74)
> Paul: I just did it (wait 30 minutes to see it).

Thanks! But I don't see it. (I take it you mean you added it to /about/forums/?)
(Reporter)

Comment 77

8 years ago
(In reply to comment #76)
> Ah, checkin failed due to conflict. Now present:
> https://www.mozilla.org/about/forums/#dev-tech-js-engine-internals

Thanks!


Only thing left in this bug is for Google to start archives. How do I chase that up?
(In reply to comment #77)
> Only thing left in this bug is for Google to start archives. How do I chase
> that up?

Now if only we knew that... :-|

Gerv
Google Group creation got picked up Tuesday night.  Group exists now. :)
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [list and newsgroup created, escalating to google for groups creation]
I'm not sure it does:

http://groups.google.com/groups/search?q=mozilla.dev.tech.js-engine.internals&btnG=Search&sitesearch=

Gerv
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: create mailing list for JS internals → create mozilla.dev.tech.js-engine.internals for JS internals
It does:

http://groups.google.com/group/mozilla.dev.tech.js-engine.internals/topics

You don't find anything searching for it because there's no messages in it yet.  You got CCed on my email to Google earlier asking if they could backfill the old messages.
I is doing it wrong.

Gerv
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.