[dojo-contributors] Dojo Utilities?

Chris Mitchell ccmitchellusa at gmail.com
Thu Mar 10 15:51:24 EST 2011


@Tom - There are a number of applications (tools) that have been distributed
with Dojo toolkit in the past,

   - Doc to OAA metadata tool
   - API Doc tool
   - CLDR build tool
   - Shrinksafe

I really don't view James application (tool) any different than these.

Again, I'm agreeing that it makes sense to separate these tools out going
toward Dojo into Dojo Foundation owned, individually run projects.  All of
the current code was contributed to Dojo Foundation under CLA which
maintains Dojo Foundations copyrights and standards on pedigree and quality
wherever possible.

@Kris - It's not that a distributed version control system allows forking
that is the problem here.  The problem I'm trying to point out is that
putting CLA'd code contributed to the foundation in individual's (or
corporate's) github accounts goes against the whole notion of contributing
the code to the foundation in the first place under CLA.  Sure, IBM is very
capable of creating its own corporate account to hold all of our code
contributes, and we could just as easily place those contributions under
under an IBM open source LICENSE, but we would prefer not to do that, and
instead contribute it to the Dojo Foundation, in a neutral 503c(6) org in a
place that the foundation ensures will keeps the code that's been
contributed available as people come and go from the community, so that it
can live on without dependency on our account.

I just want to make sure we have a plan for how companies can continue get a
full distro containing the founddation contributed pieces as they've been
able to do it in the past, with the quality they expect not just around
code, but tests, docs, etc. There are many companies that need to pull the
aggregate distro, and not just pieces.

Regarding the backend architecture of these applications, it does matter to
some degree, in terms of tool chain dependencies.  If I need to get Ruby,
Python, Java, PHP, and whatever latest and greatest scripting language in
order to do basic internationalization, build api docs for my code, optimize
my code, and test my code, there's huge complexity involved and we'd be
failing our users. Of course, that's not the case... we've made technology
decisions when building these tools to reduce the tool chain dependencies to
our users.  When we separate off projects, I would hope we could give some
guidance as to what's expected when providing tools for Dojo, so that the
tools can be easily used with others.  This cross-tool project guidance is
outside the scope of package metadata spec.

I'm not trying to debate the merit of which dojox projects should live and
die.  As you say, that will happen on it's own over time.

I like the goal of splitting these out assuming we can keep quality control
in place and not leave ourselves, or any  customers to having to go find all
the pieces themselves, do the testing, etc. that we've been doing for them
in the past.

-Chris

On Thu, Mar 10, 2011 at 1:09 PM, Tom Trenka <ttrenka at gmail.com> wrote:

> I would agree.  This is much more of an application and much less
> something that would be distributed as part of a toolkit or framework,
> so it would be easier to release as standalone and let the Dojo
> community promote it separately.
>
> I do have thoughts about the other things mentioned on this thread,
> but at the moment I'm trying to focus and will respond later, if
> that's ok.
>
> Regards--
> Tom
>
> 2011/3/10 Adam L. Peller <adam at peller.org>:
> > All good questions.  ttrenka can correct me if I'm wrong, but I don't
> think
> > the package structure applies to webapps like this so much, so perhaps
> > James' project is an opportunity to explore the github
> infrastructure/access
> > control issues and ease our way into this, without worrying about other
> > issues of drag and dependencies just yet.
> >
> > 2011/3/10 Chris Mitchell <ccmitchellusa at gmail.com>
> >>
> >> ok with goal of "breaking out pieces of our repository", but there are
> >> some things that need to be ironed out ahead of time...
> >> -Chris
> >>
> >> 1) Is this new GitHub project going on James' personal github account?
>  If
> >> so, this will be a problem...if James were to go away for whatever
> reason
> >> (not that  that will happen any time soon).   I hear there is a Dojo
> >> Foundation account that can be used... Where are the details for how we
> can
> >> establish GitHub projects maintained under this account.
> >> 2) The Web Builder is new code that hasn't existed in dojo before, so
> it's
> >> easy  easier to break out as it's own thing now.  It has client side
> parts
> >> that can follow the package metadata spec from Ttrenka, but what are
> >> considerations for package structure of the server pieces (Java-based)
> in
> >> this case.
> >> 3) For existing project's already part of Dojo distro's, for example gfx
> >> that we want to split out to github, I believe we need to address (1)
> above,
> >> and mandate that the separating packages follow ttrenka's package
> metadata
> >> format.  We really need an exemplar project here, that illustrates how
> >> developers should structure docs, tests, licenses, etc. so that
> Dojo.next
> >> can be aggregated back together--not just from a JS module perspective.
> >> Until an exemplar project is put together and an example of how the
> >> extracted git projects can be re-aggregated to form Dojo.next, we should
> be
> >> very careful...other wise Dojo WILL fragment, losing the value it's
> built up
> >> to companies in the past.
> >>    a) Docs need to be structured (phiggins' work should help here, but
> >> guidelines still need to be written) so that they can be pulled together
> >> into a reference guide. I don't think James' project is the one to use
> for
> >> this because of (2)).
> >>    b) We need to be able to run tests across sanctioned projects as a
> >> whole, to ensure the separated modules continue work properly together.
> >> 4) If we don't have the ability to pull separated projects back together
> >> (3), it will be untenable for companies (like IBM) to do the legal work
> >> necessary to make Dojo's pedigree the quality it needs to be for
> enterprise
> >> customers.  This is not a small amount of work, but is something the OSS
> >> community needs to be aware of in terms of downstream consumption in
> large
> >> companies...it is important to continue to maintain our quality around
> >> pedigree when things split out, and doing this on an aggregate distro is
> the
> >> only feasible way right now.
> >> -Chris
> >>
> >>
> >> 2011/3/10 Adam L. Peller <adam at peller.org>
> >>>
> >>> So I've always been +1 on breaking out pieces of our repository, and
> >>> utils seems to be a great place to start.  Not only would it enable a
> >>> separate development and release cycle, but it would help bring down
> the
> >>> size and complexity of our distribution.  There are many web developers
> who
> >>> would feel overwhelmed by other languages and technologies besides
> html/css,
> >>> and this particular app can ultimately be provided "in the cloud", in
> which
> >>> case many developers would not require the source at all, so I think
> this is
> >>> a great candidate.
> >>> -Adam
> >>>
> >>> On Tue, Mar 8, 2011 at 6:34 AM, James Thomas <jthomas.uk at gmail.com>
> >>> wrote:
> >>>>
> >>>> I'm very close to reaching a stage where the Web Builder can be
> >>>> released externally, both a hosted version and the entire source code.
> >>>> The source code lives in a private github repository and the release
> >>>> plan was going to be making the repo public, rather than committing it
> >>>> to the actual Dojo SVN "utils" directory. Do people have any
> >>>> objections to this?
> >>>>
> >>>> I very much see this project as being a member of our awesome Dojo
> >>>> Utilities but given we want to break away DojoX from being under
> >>>> centralised source control in the future, I didn't think adding
> >>>> another large project to SVN seemed appropriate.
> >>>>
> >>>> Do we think that other tools might be broken out like this in the
> >>>> future, like the new doc tools?
> >>>>
> >>>> I don't have many definite answers I'm afraid but wanted to bring it
> >>>> up anyway.....
> >>>> --
> >>>> Regards,
> >>>> James Thomas
> >>>> _______________________________________________
> >>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110310/4e023436/attachment-0001.htm 


More information about the dojo-contributors mailing list