[dojo-contributors] dojo roadmap

Mike Wilcox mwilcox at sitepen.com
Thu May 14 13:23:08 EDT 2009


But isn't this alleviated by Tom's plan? I would guess that DojoX and  
DijitX would be about 20-50% the size of the current DojoX.

Everything else becomes a plugin on its own release cycle. This helps  
dojo users too, who have trouble dealing with a DojoX package in a  
current release, even though it's fixed in the trunk.

Mike Wilcox
mwilcox at sitepen.com
http://www.sitepen.com
work: 650.968.8787 x218
cell:	  214.697.4872

On May 14, 2009, at 12:14 PM, Adam Peller wrote:

> One problem with one big release is coordination -- not really our
> strength :) and not something that scales well  We rarely have the
> same level of readiness across project.  We usually have spurts of
> activity as developers have time to work on their projects, and our
> releases are largely arbitrary where dojox or peripheral work is
> concerned.  At best, we release around dojo and dijit features and try
> to make sure nothing huge broke in dojox.  Delays in one section drag
> out the whole release and make it harder for us to push code out.  In
> reality, many of the dojox projects mightn not change all that much,
> even the stable, well-used ones, yet users are forced to deal with
> large tarballs with stuff they may not need, large changesets, etc.
>
> 2009/5/14 Tom Trenka <ttrenka at gmail.com>:
>> I think this is a fair argument but I should say that most of these  
>> things
>> are suggestions; I don't see any reason why releases could continue  
>> to be
>> decoupled if that's what the community thinks is best.
>> The main thing here for me is that we do a DojoX release as a  
>> single release
>> and not deal with the whole "package each subproject separately"  
>> kind of
>> thing.  Whether or not that release is tied to a Dojo Core release is
>> something I think we can figure out.
>> trt
>>
>> On Thu, May 14, 2009 at 11:51 AM, Adam Peller <peller at gmail.com>  
>> wrote:
>>>
>>> -1.  Far too aggressive.  I know I disagree with folks on this don't
>>> see the benefit of migrating more into core or coupling more into  
>>> the
>>> release process.  I think we need to break things out.  For  
>>> marketing
>>> and practical reasons, we need a very tiny base or core and  
>>> everything
>>> else should be separate (we call them dojox subprojects, but if it
>>> helps to call them plugins instead, so be it)  Just in the last  
>>> couple
>>> of days I've heard discussion about rewriting the grid, and also
>>> discussion over whether the dojox cometd project is redundant with a
>>> new codebase.  These were two of the candidates for migrating into  
>>> our
>>> main release.  As separate components, they can have a life of their
>>> own, still under the Dojo license and CLA agreement, with their own
>>> goals, release cycle, etc.
>>>
>>> -Adam
>>>
>>> 2009/5/14 Tom Trenka <ttrenka at gmail.com>:
>>>> I've been kicking around some ideas, and I think at this point  
>>>> I'd like
>>>> to
>>>> promote what many of you might consider to be radical changes.   
>>>> Please
>>>> bear
>>>> with me on this and recognize that what I'm proposing here is  
>>>> meant to
>>>> begin
>>>> some real discussions...right now, I would be considering this  
>>>> proposal
>>>> as a
>>>> (fairly) major reorganization aimed at the 1.5 milestone release.
>>>>  Probably
>>>> most would rather consider it for 2.0 but since our release  
>>>> cycles tend
>>>> to
>>>> be pushed way out, I think it's reasonable to consider this for an
>>>> earlier
>>>> major milestone...
>>>> 1.5: Promote DojoX to be a true first-class citizen in the  
>>>> Dojosphere.
>>>> This may seem like an odd thing to say, but allow me to explain.
>>>>  Currently,
>>>> DojoX is used for all sorts of different purposes--for some  
>>>> things, it's
>>>> a
>>>> breeding ground for eventual migration; for some, it's a  
>>>> playground; for
>>>> others, it's like a personal repo.
>>>> I would like this to change.
>>>> The goal here would be to couple DojoX releases with the Core  
>>>> (and not
>>>> Dijit, I'll get to that), so that the two projects are considered
>>>> congruent.
>>>>  This means that the idea of trying to package individual  
>>>> projects in
>>>> DojoX
>>>> is no longer a necessity.
>>>> In order for this to happen, I think we need to make the following
>>>> changes,
>>>> both directly to DojoX and also in the rules overseeing DojoX:
>>>> 1. Migrate the pieces in DojoX that should be migrated.
>>>> On my list of things here, the following should be migrated to  
>>>> Core:
>>>>  gfx,
>>>> dtl, portions of io, rpc and data; grid should be migrated to  
>>>> Dijit with
>>>> all
>>>> possible speed.
>>>> 2. Make decisions on what current parts of DojoX should remain, as
>>>> worthy
>>>> parts of a core release.
>>>> The criteria here is that whatever remains needs to have the  
>>>> following
>>>> attributes:
>>>> a. either in beta or stable.
>>>> b. serve a purpose that a typical Dojo consumer would need on a
>>>> semi-regular
>>>> basis.
>>>> c. having a focus that is part of the long term goals of the  
>>>> toolkit
>>>> itself.
>>>> d. is and continues to be under active development, if not entirely
>>>> stable.
>>>> On my short list here is FX, the Charting package, and (at least)
>>>> Cometd.
>>>>  What else ends up on this list is entirely up to discussion but  
>>>> I would
>>>> like to keep it short and solid; for example, I would consider  
>>>> Storage
>>>> to be
>>>> a candidate but I'm not sure about off, etc.
>>>> 3. Move everything else out of DojoX and out of the release cycle.
>>>> Before anyone starts saying "hey, what the hell", hear me out.
>>>> There are a lot of things sitting in DojoX currently that have  
>>>> only one
>>>> developer, is not under active development, serves only a single  
>>>> party's
>>>> needs, etc. etc.  Most of these projects, while some are very
>>>> interesting,
>>>> should really not be a part of a Dojo release cycle at all (and I  
>>>> think
>>>> this
>>>> is one of the reasons why we've been going back and forth on the  
>>>> whole
>>>> separate package thing), and so I think we should be moving them  
>>>> out of
>>>> DojoX altogether.  Things on this list (IMHO) include analytics,  
>>>> av,
>>>> wires,
>>>> sketch, collections, encoding, and more.
>>>> However, I don't think we should be losing any of these projects  
>>>> either,
>>>> so...
>>>>
>>>> 4. Take over the dojoc concept and rename it to something like  
>>>> "dplug",
>>>> "plug" or "plugins".
>>>> But I'm going to simplify this idea (after talking it over with  
>>>> Dustin);
>>>> what we basically do is this:
>>>> a.  allow anyone with current ownership of a DojoX project to  
>>>> choose how
>>>> they would like to maintain the code (i.e. whether they want to  
>>>> move to
>>>> a
>>>> different repo system or not).
>>>> b.  Provide a repo that is *not* on a release cycle; this would  
>>>> be what
>>>> is
>>>> currently the dojoc concept, but renamed to something like the  
>>>> above.
>>>> c.  With every Dojo release, provide an empty directory at the same
>>>> level as
>>>> dojo, dijit and dojox--named the above.
>>>> The idea here is to allow *anyone* to use that namespace as an  
>>>> automatic
>>>> way
>>>> of being able to drop plugins into an existing Dojo release, not  
>>>> have to
>>>> worry about registering a namespace, and being able to instantly  
>>>> go with
>>>> whatever code they want.  It'd also allow us to maintain a place  
>>>> where
>>>> projects that have lived under DojoX for a while can undergo active
>>>> development (if so desired) without having to be tied to a release
>>>> cycle.
>>>> It should also allow whoever to be able to do builds without a huge
>>>> amount
>>>> of extra pain.
>>>> -----------------
>>>> There are a few things that I have deliberately left out of this-- 
>>>> the
>>>> biggest one being anything that is currently in DojoX that is
>>>> widget-based.
>>>>  I have a proposal for this as well but I am unsure if it's the  
>>>> right
>>>> way to
>>>> go; however, I do feel that DojoX is no longer a place that widgets
>>>> should
>>>> be in and it should be congruent to Core and only Core.
>>>> To this end, I might suggest creating a DijitX project--which would
>>>> serve
>>>> the same purpose for Dijit as DojoX does for Core.  Anything
>>>> widget-based
>>>> that the Dijit team feels is a good add-on to Dijit without  
>>>> having to
>>>> satisfy the same stringent requirements can go in there.
>>>> In my mind though, the main thing is that anything in the  
>>>> streamlined
>>>> DojoX
>>>> doesn't have or wrap any of the Dijit infrastructure.
>>>> -----------------
>>>> While aggressive, I think that this kind of change is definitely  
>>>> do-able
>>>> for
>>>> the 1.5 release (since it should not radically affect the other two
>>>> projects); for backwards-compatibility, we can include simple  
>>>> stub files
>>>> in
>>>> DojoX with deprecation messages for existing users, and make sure  
>>>> that
>>>> users
>>>> of that codebase can find the new locations of their project  
>>>> dependency.
>>>> I'm proposing this idea because it seems to me like it kills  
>>>> several
>>>> birds
>>>> with one stone--
>>>> 1. We can clamp down on what goes into DojoX (i.e. no more  
>>>> playground)
>>>> 2. We can stop worrying about individual package building
>>>> 3. We can continue to couple DojoX to a Core release
>>>> 4. We can really start promoting the idea of the plugin as  
>>>> essential to
>>>> the
>>>> continuing evolvement of DTK
>>>> 5. We can provide a basic infrastructure for those plugins so that
>>>> writing
>>>> them is a simple matter of saying "call it plugin.foo and drop it  
>>>> in
>>>> here".
>>>> 6. The build system can pick up plugins by adding a couple of  
>>>> lines to a
>>>> specific profile (iirc).
>>>> -----------------
>>>> Thoughts, arguments, suggestions?
>>>> regards,
>>>> trt
>>>> On Sun, May 10, 2009 at 11:15 PM, Bill Keese <bill at dojotoolkit.org>
>>>> wrote:
>>>>>
>>>>> Hi Sam,
>>>>>
>>>>> I don't have anything new to add since the last time we talked  
>>>>> about
>>>>> the
>>>>> roadmap a few months ago, see:
>>>>>
>>>>> - http://article.gmane.org/gmane.comp.web.dojo.devel/9622/match=roadmap
>>>>> - http://thread.gmane.org/gmane.comp.web.dojo.devel/9752/ 
>>>>> focus=9783
>>>>> _______________________________________________
>>>>> dojo-contributors mailing list
>>>>> dojo-contributors at mail.dojotoolkit.org
>>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>
>>>>
>>>> _______________________________________________
>>>> dojo-contributors mailing list
>>>> dojo-contributors at mail.dojotoolkit.org
>>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>>
>>>>
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
>>
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
>>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>



More information about the dojo-contributors mailing list