Karl Tiedt | 8 Feb 20:07 2016

Google Summer of Code 2016

[note: dojo-contribs is BCC'd in this email so that replies only go to *one* list]

Dylan is hoping to get several of our projects into GSoC this year under the jQuery Foundation application, I am reaching out on behalf of Dylan and Jörn (from jQuery Foundation) as an intermediary for our community, to gauge interest in mentors both from our contributors and our users, as when we were active in GSoC we did have a handful of users that like to be actively involved.

If you are interested in participating, in any capacity, please let us know. We will need mentors, Dojo specific project ideas and of course students once we get to that point.

As always, if you have questions or concerns, feel free to ping me directly at any time on this account.

-Karl Tiedt

dojo-contributors mailing list
Dylan Schiemann | 23 Jan 13:23 2016

Dojo 1.11 release plan

We're very close to the Dojo 1.11 release. We have a few remaining
issues that we would like to land (
), but we could release without any of these changes if we had to.

Ideally we would get automated testing working again so we can finally
setup continuous integration (work on this has been ongoing in a
branch), and get the versions of Closure Compiler and Rhino updated so
that builds can run faster.

We're setting a deadline of January 31st to land any fixes for Dojo 1.11
Release Candidate 1, and then we'll plan to do the build and release
candidate shortly thereafter, and finish any updates to the
documentation and website before we release 1.11. At the same time we
will also be releasing updates to 1.10 and earlier releases with any
backported changes.

Thanks for the large number of pull requests and fixes that have made
their way into this release. Please let me know if you have any questions.


Dylan Schiemann
SitePen, Inc.
Dojo, Intern, and ES6/TypeScript workshops in the US, Canada, and
Europe: http://www.sitepen.com/workshops/


dojo-contributors mailing list

Kitson Kelly | 5 Jan 15:49 2016

Weekly Design Meeting


Trying to bring a bit of renewed life/organisation to the weekly design meetings.  I have produced an agenda for today's meeting and will take notes and update post the discussion.


dojo-contributors mailing list
Bill Keese | 14 Oct 10:06 2015

Re: Edge

I updated dijit to more-or-less work on Edge.  Unfortunately I can't test it thoroughly because Edge (like Chrome) has disabled Java, so the doh.robot tests won't run.

FWIW, despite the marketing hype, Edge is very much the next version of IE.   I went through all the open IE-specific dijit bug database tickets, and IIRC every bug that happens on IE11 is also happening on Edge.


dojo-contributors mailing list
Christophe Jolif | 2 Oct 16:43 2015


Some more updates on Edge (core)

- I'm not able to make intern tests run against Microsoft WebDriver
for Edge. Maybe I messed up with the setup but I also see errors like
"command not supported", so I'm not sure the driver is fully ready
yet... If anyone has made this working please let me know... (this is
preventing me to run any of the "functional" tests).

- When I run intern tests in the browser itself (so only unit tests) I
see no regression (except the dom-style.get() width issue that we
already knew about). However all the parser tests are failing, but
they were already failing in IE11 so no regression... (and I suspect
there is no actual issue just that the test is not correctly setup to
run in IE/Edge in browser). I guess someone might want to look into
this, especially if we want to release 1.11, better have all tests
passing even if no regression.

- When I run DOH (the remaining ones and the ones from 1.10) no
regression however this test: test_scroll.html probably needs to also
ignore edge when it tests quirks iframe in strict documents as it is
already ignored IE >=9 and Trident. (see:
This is in the test not in the lib, so I guess this is ok to ignore it
that way using sniff.

- firebug showing up while it should not (see Bill's mail)

- https://bugs.dojotoolkit.org/ticket/18725 (width issue). As I think
Colin suggested, just removing the has() test and having a single code
branch should be working on all browsers and is passing the tests on
all browsers I tested with. Bill has committed the fix (still needs to
be backported).


dojo-contributors mailing list

Bill Keese | 2 Oct 12:01 2015

remove firebug lite?

The firebug lite console is (unwantedly) showing up in Edge.

Should we just remove firebug lite completely?  It seems useless nowadays.

Alternately I could change the logic for when firebug lite is instantiated, but I don't know what I would change it to; The test to NOT instantiate firebug lite is currently:

has("ff") || // Firefox has Firebug
has("chrome") || // Chrome 3+ has a console
has("safari") || // Safari 4 has a console
isNewIE || // Has the new IE console
window.firebug || // Testing for mozilla firebug lite
(typeof console != "undefined" && console.firebug) || //The firebug console
dojo.config.useCustomLogger || // Allow custom loggers
has("air") // isDebug triggers AIRInsector, not Firebug

dojo-contributors mailing list
Dylan Schiemann | 1 Oct 13:33 2015

Dojo 1.x roadmap

# Dojo 1.11

Some of you may have noticed my initial flurry of landing pull requests
and closing tickets over the past couple of weeks. This was sparked by
desire to get our 1.11 release out the door relatively soon, and to
assess where we are. Most of our efforts this year have been towards
Dojo 2 as 1.x is stable, but we still of course have a strong commitment
to our 1.x users.

The main driver for the 1.11 release is the introduction of a flat
theme, which is under active development at
https://github.com/dojo/themes (screenshot at
). Beyond this, there are many contributions that have been made since
1.10 was released. As many of these as possible have been backported to
1.10, 1.9, 1.8, and 1.7, though it's been several months since we've
done an updated set of releases. As we have done with recent releases,
we will release updates to anything with updates at the time we do the
next release.

For the immediate release, I've started collating a list of tickets that
I feel should either be fixed or at least decided on in the 1.11 timeline at
. If any of these are assigned to you, I would ask if you could please
review them in the next two weeks and say the following:
* I plan to fix it (keep the ticket assigned to you)
* I don't think this should be fixed (note this, and reassign to dylan)
* It would be nice to fix, but someone else should fix it (note this,
and reassign to dylan)

>From there, I'll determine a release date based on the tickets we should
fix for this release. If you do not have tickets assigned to you and
would like to get involved, please respond to this email or find me on IRC.

# 1.x release schedule

My plan is to formalize the release schedule a bit more than we have
historically. Obviously if we need a minor release for emergency
reasons, we will make one, but otherwise, we're going to plan on the

* Fall 2015: Dojo 1.11 and various updates to 1.10, 1.9, 1.8, and 1.7
* Winter 2016: Dojo 1.11.1, 1.10.6, etc., if needed
* Spring 2016: Dojo 1.11.2, 1.10.7, etc., if needed
* Summer 2016: Dojo 1.11.3, 1.10.8, etc., if needed
* Fall 2016: Dojo 1.12, 1.11.4, 1.10.8, etc.

The main distinction between what goes into the next release vs. what is
backported is if it introduces new functionality or not.

This release schedule is in parallel to whatever the Dojo 2 release
schedule becomes.

# 1.x ticket triage

Given that Dojo 2 is planning to use the issue tracking systems provided
by GitHub, I think we need to do a significant purge of Trac to make it
manageable. After my recent efforts to close tickets and some help from
other committers, we're down to 1362 tickets that are categorized as

* 1.11 or earlier backports (84 tickets)
* 1.12 (16 tickets)
* 2.0 (107 tickets)
* future (276 tickets)
* tbd (868 tickets)

This is a challenge, as it makes it nearly impossible for anyone to wrap
their head around it all. What I would like to do is as follows:

* Triage the 2.0, future and tbd tickets
* Anything that has not been touched in at least 2 years and does not
look easy or urgent and does not contain a patch or pull request should
be set to patchwelcome and closed
	* Anything that does seem easy or urgent should be set to 1.11 or 1.12
	* Anything that is clearly marked for Dojo 2 should be evaluated and
moved into the proposal or spec or ticket system for that project, if it
remains relevant
* For issues that are less than two years since their last activity,
decide on a milestone or decide if we're just not going to get to it,
and make the same decision tree as above.

If someone has taken the time to create a patch or pull request, we
should see if that is still relevant. If it's a good patch, let's find a
way to land it. If it is a bad patch, or requires major rework or breaks
backwars compat, then let's see if the person who opened it is still

In general, I would like to see issues fixed in areas that are essential
to Dojo 1.x usage, e.g:
* Important core APIs (e.g. request, on, query, store)
* Important Dijit issues
* More widely used DojoX modules (e.g. gfx, charting, mobile, and
perhaps others)
* Build system
* Themes
* General browser compatibility items (e.g. support for Edge, iOS9)
* Documentation
* Clean-up "lazy" sniffing tests, replace with better feature tests

These are the things that are most widely used or causing maintenance
issues, so we want to leave a stable foundation for our user base. And
to make our ticket system manageable, ideally I would like to get the
number of active open tickets down to under 200 within a month, and know
that each ticket that remains open has a clear plan for how to move
forward with it.

Also, many tickets are currently assigned to inactive contributors. I
plan to change the defaults for anyone who has not committed something
in the past year, and bulk reassign those tickets to me for now. Please
let me know if an exception should be made for you.

# Getting involved

I know that Dojo 1.x is not as sexy or exciting as it was a few years
ago, and that many people are more interested now in Dojo 2.x. Our
resources are finite. That said, if you would like to lend a hand and
help in these efforts, please let me know. Please let me know if there's
anything wrong with this plan. I plan to turn this into a blog post
within a week so it's formalized somewhere.


Dylan Schiemann
SitePen, Inc.
Dojo, Intern, and ES6/TypeScript workshops in the US, Canada, and
Europe: http://www.sitepen.com/workshops/


dojo-contributors mailing list

Christophe Jolif | 19 Sep 12:16 2015


Hi all,

We have been doing some testing with Edge. Things work pretty well
however investigating an issue in core
(https://bugs.dojotoolkit.org/ticket/17962 hitting again), I realize
that has("chrome") is truthy. And has("ie"), has("trident") are
undefined (which probably explains why #17962 is hitting again as it
would probably require the same code path as ie & trident...).

Should we now had a 3 Microsoft "has" flag... that is adding has("edge") ?

I think we need to decide on this pretty quickly to avoid the story of
IE11 where people started relying on has("ie") being thruthy and then
we changed that...


dojo-contributors mailing list

Rene Rubalcava | 10 Sep 20:59 2015

Dojo2 i18n in a commonjs environment

I wasn't sure where to ask this, so I figured the list was a good spot.

I've been testing out Dojo2 repos for future dev and I'm very happy to see the ability to use it in mixed environments, AMD and node, so far the parts that are built are working pretty well.

I was looking over the proposal for i18n at the roadmap

The Promise based APIin i18n  is really attractive for our future projects. Right now, the internal getJson method only has 2 valid paths. Node and AMD. However, if someone is using browserify to build their projects, i18n will fail with an "Unknown loader" error.

Would it be ok to provide a third path that allows a CommonJS non-node environment like browserify outputs? This would would probably look identical to the AMD path to pull in dojo-core/request, but I'm not totally sure yet.


- Rene

dojo-contributors mailing list
Kitson Kelly | 2 Sep 10:27 2015

Dojo 2

As some of you may know, I recently joined SitePen as CTO. I have had a relatively long history with Dojo, first starting to utilise it in about 2008 and becoming a committer in April of 2012. For several years I had little time for the Dojo community because of my work obligations, but it was never far from my heart. As I decided to make a career change, it appeared that SitePen needed someone like me and so they offered me a role and I joined.

During my time as a community member and committer, I prided myself in having luxury of not having a commercial need or agenda. Obviously joining SitePen might lead some to assume that I will lose that objectivity. I have thought a lot about that, while I have other duties, joining SitePen is allowing me the opportunity to continue to be passionate about something I dearly love. So it will come with its commercial realities, but I hope I can continue to balance that objectively.

I will admit I have seen the Dojo community struggle over the last few years. People, I feel rightfully so, are openly questioning “is Dojo dead?” or “is there a need anymore for Dojo 2?” In private I have had several people say the same things. I have done a lot of thinking about this myself over the past few weeks and I have come to a conclusion.

Dojo is not dead. There is a need for Dojo, maybe more now than even in 2004 during the great browser wars. I personally believe we have entered the browser cold wars, where there is a quiet arms escalation. Everyone arrives at a neutral point with platitudes of agreement but then return to their bunkers and move forward with their own vision for the web. I can understand, collaboration is challenging, especially for us software engineers. Peter-Paul Koch recently called for a moratorium on new web features in Stop Pushing the web forward. He was then resoundingly accused of being “chicken little”. While I don’t entirely agree with him, he has some valid points of the feature arms escalation that is ensuing and the ability to keep up with it.

I recently discovered a blog post from Jason Fried in 2007 which said “the people who buy enterprise software aren’t the people who use enterprise software.” It was part of why he said Enterprise Software “sucks”. I believe there are other factors, but the enterprise is plagued with poor software and I don’t think any of the large “popular” frameworks understand that space well and don’t focus on it enough. That is one of the things though that Dojo 1 has had a lot of strength in and it is something that I think Dojo 2 can excel in.

Another point I feel I have to bring up is that many of the Dojo committers and contributors have wandered off. The reasons have been various but I can firmly attest that collaboration is hard for engineers. Some of you I suspect left in part because you felt it was futile. It has been part of my personal objectives though to try to give this a try again. I know many of you have felt hugely passionate about Dojo, even against wave and wave of your colleagues questioning why you would ever utilise Dojo.

I say let’s get the band back together and do something truly awesome.

3 Point Plan for Dojo 2

  1. Build the Vision - Let’s build this from the “front” to the back. I think one of the things we have struggled with is what sort of problems does Dojo 2 really need to solve. Some are the same as those from years gone by, some are new.

  2. Dissect the Vision - Let’s use that vision as a way to guide and give context for the parts of Dojo 2.

  3. Build/Integrate the Parts - One of the flexibilities of Dojo 2 has always been a bit of “bring your own” and in a rich world that JavaScript has become over the years, we don’t have to solve every problem ourselves. We need to challenge ourselves to see how much of the wider open-source world we can harness.

Hopefully most people noticed that there has been work on Dojo 2 over the last few months. This doesn’t throw any of that away, but I think will give us a bit of the direction and context we have been struggling with. Maybe we will have to revisit some of the proposals, maybe not.

Who wants to come along on this journey with me? Respond to me here, or feel free privately at me <at> kitsonkelly.com.



dojo-contributors mailing list
Dylan Schiemann | 1 Sep 17:40 2015

Dojo Foundation news

As some of you may already know, we've decided to merge the Dojo
Foundation with the jQuery Foundation. It's been announced via press
release at
and other places.

I've had a number of questions already asking what this means for the
Dojo Toolkit, Dojo Foundation, and various projects. Here are some quick

* What's happening exactly?

We decided to merge our foundations. We have aligned interests in
improving the open web, and both of our foundations have a growing
number of projects. We want to encourage collaboration over reinventing
the wheel, and we wanted to have more say in the direction of the open
web which is more difficult to do when with smaller numbers. We felt
that these are things we could better achieve together.

We've talked for years about doing something like this with jQuery, and
we've had discussions on and off for over two years about this current

Logistically, we're merging into the jQuery Foundation. From a practical
perspective, we needed to pick one foundation, as it would frankly cost
more in time and effort to start a new foundation without adding value.
The jQuery Foundation has a structure in place with officers that
actively run the foundation, and a better structure overall, so it
seemed to be the obvious choice to me and our board.

* What does this mean for the Dojo Toolkit?

In the short term, nothing will change. In the medium term, we are
hoping to collaborate more across other projects. For example, Dojo 2 is
already leveraging the jQuery globalize project as a foundation for our
i18n package, and a jQuery team member recently added qUnit test syntax
support to Intern 3.

In an increasingly fragmented community, we hope to do more things like
this to collaborate, while understanding that Dojo and jQuery are two
very different toolkits with different target audiences.

It will also mean that people with Dojo and jQuery foundation CLAs will
be able to contribute to projects within both foundations.

* What will the new foundation be called?

We are actively working on a new name that reflects our shared mission.
Picking a great name is difficult, and we didn't want that to block this
announcement. So if you have a suggestion, let us know!

* What does this mean for other projects?

The jQuery Foundation has been more successful than the Dojo Foundation
at raising funds through donations. The foundation uses a significant
portion of these funds to sponsor independent development efforts on
various projects. So, for Dojo Foundation projects, this should mean
increased funding opportunities to help fund some development efforts.
There are more details to sort out on this, so expect a follow-up email
on the specifics in the future.

I'm sure there are other questions, but I wanted to send out something
quickly. Let me know if you have any questions!


dojo-contributors mailing list