headers
Colin Snover | 9 Feb 21:34

Reference guide updated

Hi everyone,

The reference guide has been updated with the latest from the 1.7 branch
as well as to add links to the documentation feedback form. Please
report back if you notice any issues after this update.

Thanks,

--

-- 
Colin Snover
http://zetafleet.com
Permalink | Reply | 2 comments |
headers
Colin Snover | 9 Feb 18:15

dojotoolkit.org blog admin section now protected by HTTP Auth

Hi everyone,

In order to provide an additional layer of security against hypothetical
future WordPress exploits, the admin section of the dtk.org blog is now
protected by HTTP Auth. The HTTP Auth uses your DF login; WP itself
continues to use a separate login.

Thanks,

--

-- 
Colin Snover
http://zetafleet.com
Permalink | Reply | 0 comments |
headers
Tom Trenka | 9 Feb 16:25
Picon

The Road to 2.0: Determining distribution contents

Morning all--


At last night's Dojo meeting, the topic of "what should included within a distribution/distributions of the Dojo Toolkit" was discussed.  Unlike previous discussions (which focused primarily on what tools are needed/what absolutely is required within a distribution), this discussion was intended to begin deciding what "dojo-release-2.0.tar.gz" et al actually contains.

A summary of ideas:

1) Distribution(s) of 2.0+ are essentially marketing tools for the Dojo Toolkit, in that what they contain should tell a clear "story" of what the Dojo Toolkit is and why someone would want to choose it over other options.

2) Unit testing and documentation is a MUST; this means that before we can create a 2.0 distribution,we MUST have ways of aggregating documentation out of individual packages, including assembling content for reference guides and API documentation.  Christophe Jolif has begun experimenting with ways of accomplishing this using his treemap package (at https://github.com/cjolif/dojo-treemap/wiki ) as a test bed.  I am looking into the various unit testing systems that are out there before coming back to DOH and seeing how we can make that a first-class product (i.e. standalone).

3) Since everything in 2.0+ will be package-based, the following ideas were floated as "releases":

3a) Several distributions containing different packages that are "pluggable", based on the separations/features at http://dojotoolkit.org/features . This would mean that there is one main distribution (the Dojo Core essentially), and then several "add-on" distributions such as (names are arbitrary):
  • desktop (aka Dijit + some version of a Grid)
  • mobile
  • visualization (charting, gauges, geo)
  • mvc/app
  • tools (essentially our current /util but probably just DOH and the build system, maybe doc assembly tools)
...the general idea being that a developer would grab the core distribution and then whatever add-ons they were looking to develop with.

3b) In addition to the above, an "assemble your own distribution" tool would be a very nice-to-have feature; this would probably do something similar to http://packages.dojofoundation.org where one can find a list of packages available, and have the server assemble a tarball/gzip on the fly.

3c) ...and/or there could be our typical kitchen sink release.

NEXT STEPS
1) Decide on what kind of distribution(s) should be taking place (i.e. take the add-on approach or continue with kitchen-sink approach)
2) Decide on what exactly will be in said distributions
3) Begin developing the methods/tools needed

If we have a very good idea of how we're going to be distributing the toolkit at 2.0, we can begin to restructure ourselves so that we can better meet those goals.  For instance, if we decide on the "add-on" approach, we can break ourselves up into smaller teams (each with a lead of some sort) based on the particular add-on (just a thought).

Also, we're going to definitely need a release team (not just a release manager); when these distros are to be assembled, the release team will need to:
1) collect all packages
2) unit-test all packages
3) assemble documentation from packages into one
4) create release notes (one would hope this would be part of the previous step)
5) give it a stamp of approval

...before saying "add-on X" is ready for release.  As usual, there can always be a beta/RC period during which some of these steps may happen.

Lastly, Dylan brought up once again the need for a unified bug tracking system; based on experiences so far with dgrid (another major project that is intended to be a test bed for the packages concept), the github tracker is confusing people because they don't know whether something is a dgrid bug or a DTK one.  If we are going to have a unified bug tracker, we should really take a look at systems like https://www.chiliproject.org/ (the current fork of Redmine)--because it allows people to set up multiple projects within it.  Obviously other suggestions are welcome, but I think that having everything as a single project (a la Trac) is killing us.

As always, thoughts...suggestions...other ideas...are more than welcome!

Cheers--
Tom

PS As a personal opinion, one thing that I *do* thing should happen sooner than later is the promotion of dojox.gfx to the Dojo core.  Having a way of doing cross-browser graphics should really be a core feature and not something sort of hidden within DojoX...
_______________________________________________
dojo-contributors mailing list
dojo-contributors <at> mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Permalink | Reply | 7 comments |
headers
Colin Snover | 9 Feb 01:19

livedocs notice update

Hi everyone,

Tonight I finally managed to update the wiki at livedocs to have the
newer bolder warning about the content, so we can start our two week
test on ML traffic incorrectly referencing stuff from livedocs from
today to see how it goes. I also started adding documentation about
rstWiki to the docs so there is at least some documentation there now
about how to update the thing now at developer/rstwiki.

Cheers,

--

-- 
Colin Snover
http://zetafleet.com
Permalink | Reply | 0 comments |
headers
Karl Tiedt | 8 Feb 22:18
Picon
Gravatar

Interesting build conundrum caused by Back compat code

I spoke to Bill about this on IRC yesterday and found out that there
was major push to get this code added to files like
AccordionContainer.js

	// Back compat w/1.6, remove for 2.0
	if(!kernel.isAsync){
		ready(0, function(){
			var requires = ["dijit/layout/AccordionPane"];
			require(requires);	// use indirection so modules not rolled into a build
		});
	}

This poses an interesting problem (at least in our case -- maybe its
an edge case).

We are testing a legacy application that will be upgraded to 1.7 AMD
in pieces... so we are running a 1.6 Application against 1.7 src... in
our Profile we include AccordionContainer (this works great)

However, due to the code block above, if we do not also include
AccordionPane in our profile...it generates a require() quest and THEN
we also have to include dojo.require in our profile build...

Why should backwards compatibility force extraneous (deprecated) code
into a build just to avoid these requests? (in our case we delete all
unused files from our production code to conserve space on the
hardware that runs it)
Note: this also applies to dojo.dnd.Source forcing requires of
AutoSource and Target

If there is a simple flag to fix this... I have been unable to find
it... I have tried setting dojo-loader:0 in staticHasFeatures (since
its part of what contributes to kernel.isAsync -- this causes the
loader to break entirely

This problem and a change in how CSS @imports are handled have been
our 2 biggest blockers so far...

I can appreciate the need for backwards compat... but this does not
feel right... and considering backwards compat hasnt been 100% to
begin with, I cant see these few issues being any worse than previous
deviations (As long as they are documented in the same way that
dijit._base and dijit._Widget changes have been....)

-Karl Tiedt
Permalink | Reply | 3 comments |
headers
ben hockey | 8 Feb 20:08
Picon
Gravatar

bulk triage

i've been looking into how to bulk triage some of our older bugs.  colin 
has shown me how its possible to do a batch modify of tickets that match 
a certain criteria.  i was thinking of setting a status of pending for 
all tickets that have been inactive for more than 12 months.  at the 
same time, i would add a comment to mention that the ticket has been 
inactive for a long time and if no action is taken within 14 days, the 
ticket will automatically be closed.  then in 14 days time, those 
tickets will be automatically closed by trac-o-bot if nobody acts on them.

any concerns about this kind of bulk nudge for inactive tickets?

to get an idea of which tickets would be affected (and how many) take a 
look at

http://bugs.dojotoolkit.org/query?status=assigned&status=new&status=open&status=pending&status=reopened&changetime=..12+months+ago&col=id&col=summary&col=changetime&col=status&col=type&col=priority&col=milestone&col=component&desc=1&order=changetime

<http://bugs.dojotoolkit.org/query?status=assigned&status=new&status=open&status=pending&status=reopened&changetime=..12+months+ago&col=id&col=summary&col=changetime&col=status&col=type&col=priority&col=milestone&col=component&desc=1&order=changetime> 
and adjust the time in the Modified section.  inactivity of more than 12 
months would affect 736 tickets which is more than 1/3rd of our active 
tickets.

let me know if you think there is a better time frame than 12 months of 
inactivity.  i think that bill sometimes intentionally holds open some 
tickets for 2.0 and so some of those may be affected but hopefully we 
can find a balance that hits a lot of stale tickets without making it 
too annoying for tickets that are intentionally still open.

thanks,

ben...
Permalink | Reply | 11 comments |
headers
Karl Tiedt | 7 Feb 19:55
Picon
Gravatar

[GSOC 2012] Summer of Code is upon us

Howdy everyone,
      As we all know, it is fast approaching the time of year where
Google hosts their annual Summer of Code event. Below you will see a
very short list (2 items) of things we need from the community and our
contributors to help carry this program forward for 2012.

What we need from you:

    volunteers for project mentors

    Who can mentor? active community members and contributors - we
look forward to hearing from you (previously only 1 community member
has ever participated in this capacity, lets bolster those #s) -- keep
in mind it does involve a fair amount of time and patience - and
intimate knowledge of Dojo (stating the obvious)

          http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs#eligibility_mentors

    Proposal suggestions:

          While students are encouraged to propose ideas they want to
work on within our project, it is important for us to have a solid
list of projects for students who may not be intimately familiar with
Dojo to choose from. These projects can be just about anything code
related (no documentation writing). Obviously with the current state
of the Web, HTML5 and CSS transitions are the hot topics.

 Over the next week I encourage you all to submit proposal
ideas/suggestions/recommendations. They need to be fairly detailed so
we can be clear what the expectations are for the proposal. Over the
next few days I will be compiling a list of recent discussions that
would fit into this criteria. Please submit any proposal ideas to the
dojo-interest mailing list for maximum visibility and opportunity at
discussing any short comings or uncertainties in the proposals.

Note: It may not be possible to include every proposal, and not every
proposal that does make it to the final list will not be guaranteeing
it will get worked on. This will all depend on the final say from
Google about how many students we receive and what proposals students
are interested in.

Thanks,
-Karl Tiedt
Permalink | Reply | 1 comment |
headers
Bill Keese | 7 Feb 12:40
Favicon
Gravatar

drop FF3.6 for 1.8?

FF3.6 is marked as EOL for April 24, before we release Dojo 1.8   And actually when I start FF3.6 today it already says in big letters:

URGENT!
Your version of Firefox is no longer protected against online attacks.
Get the upgrade - it’s fast and free! 


So, we talked about dropping support for FF3.6 in Dojo 1.9, but how about dropping support in Dojo 1.8?

I mention this because I asked Kris for some new dojo/on features (see http://bugs.dojotoolkit.org/ticket/14728) and it seems silly to spend effort supporting EOL'd browsers.
_______________________________________________
dojo-contributors mailing list
dojo-contributors <at> mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Permalink | Reply | 14 comments |
headers
Bill Keese | 7 Feb 12:18
Favicon
Gravatar

1.7.2 release

From the meeting last week, we are aiming for a release candidate for 1.7.2 on Feb 10, this Friday.

Please check the http://bugs.dojotoolkit.org/report/98 for tickets belonging to you.
_______________________________________________
dojo-contributors mailing list
dojo-contributors <at> mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Permalink | Reply | 0 comments |
headers
Christophe Jolif | 6 Feb 11:39
Picon
Gravatar

build regression & 1.7.2

Hi Rawid & all,

This the 2nd time I encounter someone facing this regression:

http://bugs.dojotoolkit.org/ticket/14169

Rawid do you have any hope this might get fixed in the 1.7.2 or a
later dot release? Per our "rules" as a regression I suppose it should
fixed in a dot release not waiting for 1.8?

Thanks,
--

-- 
Christophe
Permalink | Reply | 1 comment |
headers
Christophe Jolif | 6 Feb 10:46
Picon
Gravatar

API doc tool suggestion

Hi all,

Something I'm really missing in the API doc is the ability to mark a
given API as having been introduced in a particular version of Dojo
(or of my component if we think in 2.0 terms). Something similar to
the @since tag in javadoc. This is very useful for people working on
several projects relying on different version of Dojo. Obviously today
the can switch from API do 1.x to API doc 1.y. But it always nice to
have in a given doc a sense of when something was introduced. This is
also I think very useful for ourselves. As we plan to work on the API
doc tool this release I was wondering if this is something we could
introduce in the tool?

By the way I have been experimenting with publishing isolated
documentation of a given component on its github (trying to experiment
for standalone hosting in 2.0, even though I would myself probably
advocate having the doc standing together). See:

https://github.com/cjolif/dojo-treemap/wiki

It uses github wiki to host the reference manual (but I'm loosing all
the nice features of the livedocs wiki like ability to run examples,
also even if using github ReST format I had to modify some of my
formatting) and github pages to host the API guide (generated
statically as pure HTML using modified version of Dojo API doc tool).

Thanks,
--

-- 
Christophe
Permalink | Reply | 1 comment |

Gmane