[dojo-contributors] dojo roadmap

Tom Trenka ttrenka at gmail.com
Thu May 14 12:58:25 EDT 2009

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090514/799731bb/attachment-0001.htm 

More information about the dojo-contributors mailing list