Eventually we'll presumably move all of dojo's source code (including dojo
core and dijit) into github. I'd like that to happen SRTL, mainly because
I want to do the 1.x / 2.0 branching inside of git. (Some people will
argue that 2.0 should be a fresh start rather than a branch, but that's not
feasible for dijit, and IMO shouldn't even be done for dojo core. Because
we have to maintain 1.x for a long time, and thus merge changes between the
two branches for a long time.)

We clearly need to preserve all the history we have in SVN. Ideally, I
was hoping that we could move all the history to github, and drop SVN.
But it doesn't seem feasible, due to

- our plan to split up projects into different repositories (problematic
for commits that span repositories like
http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that in
our ancient history everything was mushed together in a single directory
http://bugs.dojotoolkit.org/browser/trunk)
- the SVN --> GIT conversion programs are lacking, not tracking things
like file copies (for example, see
https://github.com/dojo/dijit/commits/master/DropDownMenu.js which doesn't
explain that DropDownMenu.js was copied from Menu.js)

So if that's true, then I guess we need to keep a readonly copy of SVN
around forever :-(. Please correct me if I am (hopefully) incorrect on
this.

The other big issue (which I touched on in another mail) is about trac.
Some people will say that each github repository should have it's own bug
database (along with perhaps it's own reference doc, API doc, website,
etc.), but I don't think that's feasible in the short term. So, we end up
with bugs.dojotoolkit.org tracing bugs and changes across multiple github
repositories. And while there are trac plugin(s) for git I doubt any of
them handle this directly, so it will take some effort. I actually see
this as the biggest hurdle, as simply converting part of an SVN repository
to GIT is trivial, as listed in
http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410(although
it mangled the formatting).

So, what do others think, about the "how" and the "when" of the conversion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111223/277fc4db/attachment.htm

Search Discussions

  • Kitson Kelly at Dec 23, 2011 at 4:24 am
    It appears trac GitPlugin supports a multi-repository configuration:
    http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but it
    maybe worth looking at how we can integrate
    http://packages.dojotoolkit.org/and cpm into the whole situation so
    that trac can be "auto configured" to
    integrate additional repositories, because I think the admin overhead would
    be onerous.

    I think that is one of the challenges right now with trac, in my opinion,
    is that the codeset moves on, and maybe, possibly, we do enough admin on
    trac to keep it somewhat aligned, but usually don't.
    On 23 December 2011 02:14, Bill Keese wrote:

    Eventually we'll presumably move all of dojo's source code (including dojo
    core and dijit) into github. I'd like that to happen SRTL, mainly because
    I want to do the 1.x / 2.0 branching inside of git. (Some people will
    argue that 2.0 should be a fresh start rather than a branch, but that's not
    feasible for dijit, and IMO shouldn't even be done for dojo core. Because
    we have to maintain 1.x for a long time, and thus merge changes between the
    two branches for a long time.)

    We clearly need to preserve all the history we have in SVN. Ideally, I
    was hoping that we could move all the history to github, and drop SVN.
    But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories like
    http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that in
    our ancient history everything was mushed together in a single directory
    http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not tracking things
    like file copies (for example, see
    https://github.com/dojo/dijit/commits/master/DropDownMenu.js which
    doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy of SVN
    around forever :-(. Please correct me if I am (hopefully) incorrect on
    this.

    The other big issue (which I touched on in another mail) is about trac.
    Some people will say that each github repository should have it's own bug
    database (along with perhaps it's own reference doc, API doc, website,
    etc.), but I don't think that's feasible in the short term. So, we end up
    with bugs.dojotoolkit.org tracing bugs and changes across multiple github
    repositories. And while there are trac plugin(s) for git I doubt any of
    them handle this directly, so it will take some effort. I actually see
    this as the biggest hurdle, as simply converting part of an SVN repository
    to GIT is trivial, as listed in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410(although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the conversion?




    _______________________________________________
    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/20111223/1515f3e4/attachment.htm
  • Adam L. Peller at Dec 23, 2011 at 9:00 am
    I understand that we'll probably need to support existing projects on trac
    for a while, at least in transition, but I do think we should be looking
    for ways to get off of trac, or at least our single trac instance. I don't
    think we should be encouraging new projects to use trac. Each project
    ought to be able to provide a link to a bug tracking system (in the package
    metadata? the project website? both?) which would be easily discovered by
    using our site and the CPM tool.

    -Adam


    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    It appears trac GitPlugin supports a multi-repository configuration:
    http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but it
    maybe worth looking at how we can integrate
    http://packages.dojotoolkit.org/ and cpm into the whole situation so that
    trac can be "auto configured" to integrate additional repositories, because
    I think the admin overhead would be onerous.

    I think that is one of the challenges right now with trac, in my opinion,
    is that the codeset moves on, and maybe, possibly, we do enough admin on
    trac to keep it somewhat aligned, but usually don't.
    On 23 December 2011 02:14, Bill Keese wrote:

    Eventually we'll presumably move all of dojo's source code (including
    dojo core and dijit) into github. I'd like that to happen SRTL, mainly
    because I want to do the 1.x / 2.0 branching inside of git. (Some people
    will argue that 2.0 should be a fresh start rather than a branch, but
    that's not feasible for dijit, and IMO shouldn't even be done for dojo
    core. Because we have to maintain 1.x for a long time, and thus merge
    changes between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN. Ideally, I
    was hoping that we could move all the history to github, and drop SVN.
    But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories like
    http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that in
    our ancient history everything was mushed together in a single directory
    http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not tracking things
    like file copies (for example, see
    https://github.com/dojo/dijit/commits/master/DropDownMenu.js which
    doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy of SVN
    around forever :-(. Please correct me if I am (hopefully) incorrect on
    this.

    The other big issue (which I touched on in another mail) is about trac.
    Some people will say that each github repository should have it's own bug
    database (along with perhaps it's own reference doc, API doc, website,
    etc.), but I don't think that's feasible in the short term. So, we end up
    with bugs.dojotoolkit.org tracing bugs and changes across multiple
    github repositories. And while there are trac plugin(s) for git I doubt
    any of them handle this directly, so it will take some effort. I actually
    see this as the biggest hurdle, as simply converting part of an SVN
    repository to GIT is trivial, as listed in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410(although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?




    _______________________________________________
    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/20111223/9759fd8d/attachment.htm
  • Kitson Kelly at Dec 23, 2011 at 9:31 am
    Well, I think there should be at least a "framework" of which to work from.
    The CPM package specification already includes a link to a bug database,
    but I would suggested we at least have something that a package maintainer
    to plug into if they want to make it easy to be part of the wider
    community. While it is great we are getting away from a giant "dojox", one
    of the things that I have like about the community was that I have been
    able to make minor enhancements and do some fixes across a wide set of
    code. If I had to go across 20 different instances of 4-5 different bug
    tracking systems in order to try to contribute, I wouldn't have bothered in
    the first place.

    So while decentralisation has its merits, we do need to tread a fine line
    between that and disorganised.
    On 23 December 2011 14:00, Adam L. Peller wrote:

    I understand that we'll probably need to support existing projects on trac
    for a while, at least in transition, but I do think we should be looking
    for ways to get off of trac, or at least our single trac instance. I don't
    think we should be encouraging new projects to use trac. Each project
    ought to be able to provide a link to a bug tracking system (in the package
    metadata? the project website? both?) which would be easily discovered by
    using our site and the CPM tool.

    -Adam


    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    It appears trac GitPlugin supports a multi-repository configuration:
    http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but
    it maybe worth looking at how we can integrate
    http://packages.dojotoolkit.org/ and cpm into the whole situation so
    that trac can be "auto configured" to integrate additional repositories,
    because I think the admin overhead would be onerous.

    I think that is one of the challenges right now with trac, in my opinion,
    is that the codeset moves on, and maybe, possibly, we do enough admin on
    trac to keep it somewhat aligned, but usually don't.
    On 23 December 2011 02:14, Bill Keese wrote:

    Eventually we'll presumably move all of dojo's source code (including
    dojo core and dijit) into github. I'd like that to happen SRTL, mainly
    because I want to do the 1.x / 2.0 branching inside of git. (Some people
    will argue that 2.0 should be a fresh start rather than a branch, but
    that's not feasible for dijit, and IMO shouldn't even be done for dojo
    core. Because we have to maintain 1.x for a long time, and thus merge
    changes between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN. Ideally, I
    was hoping that we could move all the history to github, and drop SVN.
    But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories like
    http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that
    in our ancient history everything was mushed together in a single directory
    http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not tracking
    things like file copies (for example, see
    https://github.com/dojo/dijit/commits/master/DropDownMenu.js which
    doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy of SVN
    around forever :-(. Please correct me if I am (hopefully) incorrect on
    this.

    The other big issue (which I touched on in another mail) is about trac.
    Some people will say that each github repository should have it's own bug
    database (along with perhaps it's own reference doc, API doc, website,
    etc.), but I don't think that's feasible in the short term. So, we end up
    with bugs.dojotoolkit.org tracing bugs and changes across multiple
    github repositories. And while there are trac plugin(s) for git I doubt
    any of them handle this directly, so it will take some effort. I actually
    see this as the biggest hurdle, as simply converting part of an SVN
    repository to GIT is trivial, as listed in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410(although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?




    _______________________________________________
    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/20111223/5beda170/attachment-0001.htm
  • Rawld at Dec 31, 2011 at 3:35 pm

    On 12/23/2011 06:31 AM, Kitson Kelly wrote:
    Well, I think there should be at least a "framework" of which to work
    from. [snip]
    If I had to go across 20 different instances of 4-5 different bug
    tracking systems in order to try to contribute, I wouldn't have
    bothered in the first place.
    Agree 100%. Whatever we do must preserve project and community cohesion.

    --Rawld

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111231/2d78646a/attachment.htm
  • Adam L. Peller at Jan 1, 2012 at 9:56 pm
    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    Well, I think there should be at least a "framework" of which to work
    from. The CPM package specification already includes a link to a bug
    database, but I would suggested we at least have something that a package
    maintainer to plug into if they want to make it easy to be part of the
    wider community. While it is great we are getting away from a giant
    "dojox", one of the things that I have like about the community was that I
    have been able to make minor enhancements and do some fixes across a wide
    set of code. If I had to go across 20 different instances of 4-5 different
    bug tracking systems in order to try to contribute, I wouldn't have
    bothered in the first place.

    What sort of use cases we need to accommodate for bug tracking across
    multiple projects? I understand the need for all the 'core' stuff to be in
    a single place. Aside from the massive AMD migration, how common is it to
    make contributions across, say, multiple dojox subprojects? How common is
    it to have one particular checkin to span multiple subprojects?

    So while decentralisation has its merits, we do need to tread a fine line
    between that and disorganised.
    Yes, I agree there's a trade-off, but I don't think we can continue to
    force everyone down the exact same path for infrastructure and expect the
    community to thrive. Perhaps related code could end up in clusters which
    do conform to a particular bug reporting system (for example, widgets,
    which despite currently being in dojox.widget clearly need to be defined as
    independent projects) Perhaps it would be that "Dojo Foundation sponsored"
    code, whatever that means exactly, uses a particular bug tracking tool or
    instance?

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120101/1b1f7033/attachment.htm
  • Kitson Kelly at Jan 2, 2012 at 3:02 am

    On 2 January 2012 02:56, Adam L. Peller wrote:
    What sort of use cases we need to accommodate for bug tracking across
    multiple projects? I understand the need for all the 'core' stuff to be in
    a single place. Aside from the massive AMD migration, how common is it to
    make contributions across, say, multiple dojox subprojects? How common is
    it to have one particular checkin to span multiple subprojects?
    I know when I started to contribute, it was and has been random. I have
    had patches accepted into the parser, as well as updated a few DojoX
    components when I ran across them to AMD, but also updating and fixing the
    claro theme on some dojox widgets. In addition I have made a few
    contributions in other minor areas as well.

    Also, Trac has been the place to not only contribute, but to verify if I
    was actually experiencing a bug or not and find out if anyone else had as
    well. It has been the only place to get proper "support" and at least has
    felt like Dojo.

    While the work on dgrid has been exceptional, and I love the package, it is
    already feeling a bit like it is wandering off on its own. What if I find
    reason to contribute a minor enhancement, which I hope would be welcome,
    how do I go about having that considered?

    So while decentralisation has its merits, we do need to tread a fine line
    between that and disorganised.
    Yes, I agree there's a trade-off, but I don't think we can continue to
    force everyone down the exact same path for infrastructure and expect the
    community to thrive. Perhaps related code could end up in clusters which
    do conform to a particular bug reporting system (for example, widgets,
    which despite currently being in dojox.widget clearly need to be defined as
    independent projects) Perhaps it would be that "Dojo Foundation sponsored"
    code, whatever that means exactly, uses a particular bug tracking tool or
    instance?
    I hope I didn't mean to imply force. I meant to imply an "opt-in"
    framework. A "if you want to leverage the largest part of the community"
    sort of thing. I for example have been sitting on three widgets, two of
    which I think could be ready for prime time, but I will admit, I haven't
    move forward unleashing them on the world while I have waited to see how
    the package system works. Right now, in my mind this is where I am at:

    - Source Code - I am more familiar with SVN and need to learn about
    GitHub, because it is likely the "way forward".
    - Packaging - Need to learn more about CPM and how I get my package on
    the package website. Problem is I have installed CPM multiple times on my
    Mac, following the "simple instructions" and it fails with an error, and I
    can't be asked to try to figure out how I file a bug for it, because it is
    already something that is "off on its own".
    - Bug Tracking - This is my biggest "barrier" to entry at the moment. I
    am comfortable with a few, but currently, there is nothing I can "plug
    into" that will "work" with the rest of the community.
    - Test Automation - I need to learn more about DOH. That is my biggest
    "challenge" for prepping my code, in my opinion for Primetime. I would
    hate for the community to devolve into a bunch of hackers who don't worry
    about testing. While it is a pain, it should be a "requirement".
    - Documentation - I have contributed quite a few small chunks to the
    Dojo documentation and have my head "wrapped around" the markup, but there
    is no clear way to "plug it in" to the rest of community. As far as source
    code documentation, I know there has been a lot of debate about source code
    API documentation is broken rather extensively. Don't know what to do
    about that.
    - Coding Style - I think I have done it the Dojo way, but I am more then
    willing to take input and feedback from anyone (as well as code
    contributions).

    For me it is really important to feel I had the ability to at least
    "contribute". For me Dojo is far far far away from my day job and
    currently 100% of my time spent on Dojo is for my own personal
    gratification and edification. So it is even more important for me to
    contribute my stuff in a way that it has an opportunity of surviving
    without me, if it useful to others on its own merits. My personal
    hope/aspiration is that my code works its way into some popular software
    solution. It is purely ego points I am looking for.

    Without a "framework" to plug into, which has a relatively low barrier to
    entry, my potential contributions would never see the light of day, which
    seems very much not what Dojo is about.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/3de96e3d/attachment.htm
  • Mike Wilcox at Jan 2, 2012 at 10:24 am

    On Jan 2, 2012, at 2:02 AM, Kitson Kelly wrote:
    On 2 January 2012 02:56, Adam L. Peller wrote:
    Yes, I agree there's a trade-off, but I don't think we can continue to force everyone down the exact same path for infrastructure and expect the community to thrive.
    Isn't that the selling point of Dojo? We were pretty freaked out when we realized that we had documentation in several different places.

    It looks to me that everything is moving to GitHub, so as a Dojo consumer, I would expect this is where I would find the code, the instructions/documentation, and bug tracking. I think the offsite docs are acceptable because they would be (and are) so much more robust than what is on GitHub (unless GitHub ups the ante I would guess). I think Trac *could* be acceptable, but if I'm browsing the code in GitHub and have to go somewhere else to file the bug, that's already becoming to be a disconnect.

    Therefore, I would expect official Dojo extensions to:
    Be in GitHub
    Have a one page doc, in the form of a readme, on GitHub
    Have all of it's issue tracked on GitHub
    While they could possibly have more documentation on Dojo Campus, I don't see the need for that for small projects
    If these points were not the case, what would be the exception? Something is hosted in an Hg repo somewhere? I would have to learn and install Hg to get it?

    Mike

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/985cf2d0/attachment-0001.htm
  • Adam L. Peller at Jan 2, 2012 at 10:30 am
    2012/1/2 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    I hope I didn't mean to imply force. I meant to imply an "opt-in"
    framework.

    You're absolutely right, you never did imply forcing everyone onto a single
    framework, I just worry that if we don't remove all the dependencies we
    have today, we'll end up in the same trac instance with all the maintenance
    and scalability problems that go with it. If not trac, we'll pick some
    other tool and regret it some time later. I'd like to free ourselves of
    this burden. OTOH, you make excellent points about community norms.
    Perhaps we should encourage using certain tools that tend to work for us,
    but not forbid projects from using others. I'm fine with that. At a
    minimum, we need an exemplar set up for new projects, a pattern to follow,
    and we're not there yet. And yes, the barrier to entry must be as low as
    possible for contributors.

    I know when I started to contribute, it was and has been random. I have
    had patches accepted into the parser, as well as updated a few DojoX
    components when I ran across them to AMD, but also updating and fixing the
    claro theme on some dojox widgets. In addition I have made a few
    contributions in other minor areas as well.
    There's definitely a common thread across widget-derived code. Anything
    that has a dijit dependency shares code infrastructure and may want to use
    common tools as well. In terms of making contributions, nothing would be
    easier than keeping all widgets in a single SVN repository, but clearly
    that has problems for us -- the widgets must stick to a single release
    cycle, we can't scale well or even document well the varying levels of
    support, etc. This is a case where we not only need to break up the dojox
    repository, but in some cases like dojox.widget, we must break up some
    projects. That's going to have some cost to contributors.

    Also, Trac has been the place to not only contribute, but to verify if I
    was actually experiencing a bug or not and find out if anyone else had as
    well. It has been the only place to get proper "support" and at least has
    felt like Dojo.
    And it would continue to do so for the 'core' of Dojo, at least. I don't
    feel it has worked as well for dojox projects, some of which really do not
    have the same level of 'support'. Those bugs tend to pile up under 'tbd'
    and 'future' and make it more difficult to triage and manage the more
    critical core issues. But again, you make an excellent point about
    community. I hope there's a way we can make up this gap with web tools
    that point you to the right place for support.

    While the work on dgrid has been exceptional, and I love the package, it
    is already feeling a bit like it is wandering off on its own. What if I
    find reason to contribute a minor enhancement, which I hope would be
    welcome, how do I go about having that considered?
    To the extent that our projects all use git, you'd create a pull request.
    Would you also create a ticket to reference it? Not sure. These are
    things we'd have to work out and document, and the CPM directory would need
    to provide clear pointers to this sort of information on a per-project
    basis.

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/79ce8e22/attachment.htm
  • Mike Wilcox at Jan 2, 2012 at 10:42 am

    On Jan 2, 2012, at 2:02 AM, Kitson Kelly wrote:
    Source Code - I am more familiar with SVN and need to learn about GitHub, because it is likely the "way forward".
    Yes, I would think this should be a prerequisite for being a dojo contributor. And unfortunately, Git is a royal PITA for those of us who are not unix heads or repo administrators. Fortunately, GitHub released a GIT GUI which works quite well on a Mac. (and only Mac as near as I can tell)
    Packaging - Need to learn more about CPM and how I get my package on the package website. Problem is I have installed CPM multiple times on my Mac, following the "simple instructions" and it fails with an error, and I can't be asked to try to figure out how I file a bug for it, because it is already something that is "off on its own".
    Kris and Bryan added a fix so you can install that in a custom folder that is not usr/local which gives the Mac permissions problems. I think you still need to modify your .bash_profie yourself though. And it looks like it doesn't work with Node.js, and you have to leave it defaulting to Java for now.

    But you make a good point. CPM looks like the doorway to Dojo 2.0 - and it's currently bottlenecked by how much bandwidth Kris has to maintain it.
    Bug Tracking - This is my biggest "barrier" to entry at the moment. I am comfortable with a few, but currently, there is nothing I can "plug into" that will "work" with the rest of the community.
    If you mean for your own widgets - I would think GitHub's Issue Tracker would work. IMHO
    Test Automation - I need to learn more about DOH. That is my biggest "challenge" for prepping my code, in my opinion for Primetime. I would hate for the community to devolve into a bunch of hackers who don't worry about testing. While it is a pain, it should be a "requirement".
    I've never used testing in my DojoX projects and I don't think this makes the code less good. The problem with not using testing is it's harder on the committer, because you tend to not know your code was broken by low level changes until the last minute, or even after the fact, so you usual scramble to fix everything before a release. So I don't see this as a requirement. Plus, the idea of extensions is that versioning would be relaxed. Just because Dojo releases 2.5, it doesn't mean your extension automatically works with 2.5 on that date. Ideally it would, but your lack of update would not hold up the release.
    Documentation - I have contributed quite a few small chunks to the Dojo documentation and have my head "wrapped around" the markup, but there is no clear way to "plug it in" to the rest of community. As far as source code documentation, I know there has been a lot of debate about source code API documentation is broken rather extensively. Don't know what to do about that.
    On GitHub, if a page has a .md markdown extension, it will show as an HTML file. Now, if you can do that for more than one file, or if it always has to be "readme" I'm not sure.
    Coding Style - I think I have done it the Dojo way, but I am more then willing to take input and feedback from anyone (as well as code contributions).
    That would be easier moving forward because your code would live in a public repo and you would get free advice and style suggestions.
    So it is even more important for me to contribute my stuff in a way that it has an opportunity of surviving without me, if it useful to others on its own merits.
    That's a worthy goal, but hard to do. Most DojoX projects are maintained by one person. And many are orphans, which is the whole point of the extension plan.

    Mike Wilcox
    http://clubajax.org



    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/befddb35/attachment-0001.htm
  • Mike Wilcox at Jan 2, 2012 at 10:44 am

    On Jan 2, 2012, at 2:02 AM, Kitson Kelly wrote:
    Source Code - I am more familiar with SVN and need to learn about GitHub, because it is likely the "way forward".
    Yes, I would think this should be a prerequisite for being a dojo contributor. And unfortunately, Git is a royal PITA for those of us who are not unix heads or repo administrators. Fortunately, GitHub released a GIT GUI which works quite well on a Mac. (and only Mac as near as I can tell)
    Packaging - Need to learn more about CPM and how I get my package on the package website. Problem is I have installed CPM multiple times on my Mac, following the "simple instructions" and it fails with an error, and I can't be asked to try to figure out how I file a bug for it, because it is already something that is "off on its own".
    Kris and Bryan added a fix so you can install that in a custom folder that is not usr/local which gives the Mac permissions problems. I think you still need to modify your .bash_profie yourself though. And it looks like it doesn't work with Node.js, and you have to leave it defaulting to Java for now.

    But you make a good point. CPM looks like the doorway to Dojo 2.0 - and it's currently bottlenecked by how much bandwidth Kris has to maintain it.
    Bug Tracking - This is my biggest "barrier" to entry at the moment. I am comfortable with a few, but currently, there is nothing I can "plug into" that will "work" with the rest of the community.
    If you mean for your own widgets - I would think GitHub's Issue Tracker would work. IMHO
    Test Automation - I need to learn more about DOH. That is my biggest "challenge" for prepping my code, in my opinion for Primetime. I would hate for the community to devolve into a bunch of hackers who don't worry about testing. While it is a pain, it should be a "requirement".
    I've never used testing in my DojoX projects and I don't think this makes the code less good. The problem with not using testing is it's harder on the committer, because you tend to not know your code was broken by low level changes until the last minute, or even after the fact, so you usual scramble to fix everything before a release. So I don't see this as a requirement. Plus, the idea of extensions is that versioning would be relaxed. Just because Dojo releases 2.5, it doesn't mean your extension automatically works with 2.5 on that date. Ideally it would, but your lack of update would not hold up the release.
    Documentation - I have contributed quite a few small chunks to the Dojo documentation and have my head "wrapped around" the markup, but there is no clear way to "plug it in" to the rest of community. As far as source code documentation, I know there has been a lot of debate about source code API documentation is broken rather extensively. Don't know what to do about that.
    On GitHub, if a page has a .md markdown extension, it will show as an HTML file. Now, if you can do that for more than one file, or if it always has to be "readme" I'm not sure.
    Coding Style - I think I have done it the Dojo way, but I am more then willing to take input and feedback from anyone (as well as code contributions).
    That would be easier moving forward because your code would live in a public repo and you would get free advice and style suggestions.
    So it is even more important for me to contribute my stuff in a way that it has an opportunity of surviving without me, if it useful to others on its own merits.
    That's a worthy goal, but hard to do. Most DojoX projects are maintained by one person. And many are orphans, which is the whole point of the extension plan.

    Mike Wilcox
    http://clubajax.org


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/ad5ffd2e/attachment-0001.htm
  • Christophe Jolif at Jan 2, 2012 at 4:39 am
    Adam,

    Disclaimer: I'm not necessarily against spreading out the bug bases if
    that allows us to reach other objectives (see Dylan emails about
    objectives and how there are the first thing to look at), but I want
    to make sure this is clear we might be losing one of the Dojo's
    competitive point here.

    2012/1/2 Adam L. Peller <adam at peller.org>:
    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    What sort of use cases we need to accommodate for bug tracking across
    multiple projects? ?I understand the need for all the 'core' stuff to be in
    a single place. ?Aside from the massive AMD migration, how common is it to
    make contributions across, say, multiple dojox subprojects? ?How common is
    it to have one particular checkin to span multiple subprojects?
    You look here from a contributor standpoint ("How common is it to make
    contributions across"). I personally tried to look at it from a user
    standpoint. And I think one thing users like about Dojo (one of its
    strong point against competitors?) is that there is a common
    infrastructure (including bug base) our users can rely on and go to
    when they have an issue with a Dojo project whatever this project is.
    We would be losing this.

    Note that even if you concentrate on contributors, I think there are
    quite a lot of people contributing to several modules.
    So while decentralisation has its merits, we do need to tread a fine line
    between that and disorganised.

    Yes, I agree there's a trade-off, but I don't think we can continue to force
    everyone down the exact same path for infrastructure and expect the
    community to thrive. ?Perhaps related code could end up in clusters which do
    conform to a particular bug reporting system (for example, widgets, which
    despite currently being in dojox.widget clearly need to be defined as
    independent projects) ?Perhaps it would be that "Dojo Foundation sponsored"
    code, whatever that means exactly, uses a particular bug tracking tool or
    instance?
    Your last sentence seems to make sense to me. Projects that would be
    "blessed" and end up in the "Dojo foundation build" (or whatever it is
    called) could share the same infrastructure. While other projects
    would of course be free to rely on whatever they want to.

    --
    Christophe
  • Adam L. Peller at Jan 2, 2012 at 10:32 am

    On Mon, Jan 2, 2012 at 4:39 AM, Christophe Jolif wrote:

    You look here from a contributor standpoint ("How common is it to make
    contributions across"). I personally tried to look at it from a user
    standpoint. And I think one thing users like about Dojo (one of its
    strong point against competitors?) is that there is a common
    infrastructure (including bug base) our users can rely on and go to
    when they have an issue with a Dojo project whatever this project is.
    We would be losing this.
    True. I think you could also make an argument that splitting up the
    repository, trackers, and even to some extent the community has its
    benefits. Right now, to use dojox.charting, you really need to immerse
    yourself into all things Dojo. You need to be exposed to our entire bug
    base, download our entire codebase, etc. I suspect there are lots of
    people who just want a chart who are overwhelmed by this and turn to
    another library.

    How can we try to provide the best of both experiences?

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/a1b92ff0/attachment.htm
  • Christophe Jolif at Jan 2, 2012 at 10:59 am
    Adam,

    Yes. I agree that the contrary as well might be true. Indeed as you
    said for the users that just want a chart in their web app having to
    deal with the whole "Dojo" might be overwhelming. That's why I think
    splitting up the projects is good. That way someone that cares only
    about charting will not be overwhelmed. _However_ to keep people that
    need a full framework happy, having both:

    1/ a reasonable "stamped" distribution (with dojo, dijit and major
    dojox modules)
    2/ as well as consistent bug base, source system, and common
    documentation system between that major modules

    would help.

    Speaking in term of bug base, I think the ideal solution would be to
    have a bug tracking system used by all the "stamped" project and that
    would give either a full view on Dojo (including all bugs etc...) or a
    filtered view for a given set of projects.

    I don't know if Trac can do that? (the current "Component" field is a
    first step but far from being flexible enough).

    I know that JIRA (commercial) is capable of hosting several projects
    on an instance and one can request access to some of them and get a
    view of the bugs for the subset he is interested in.

    If github was providing an aggregate view of the issues of the github
    projects you subscribed to that would also help. But for now if you
    are interested in 10 "dojo" github project you need to go the 10
    issues list to deal with them...

    --
    Christophe

    2012/1/2 Adam L. Peller <adam at peller.org>:
    On Mon, Jan 2, 2012 at 4:39 AM, Christophe Jolif wrote:

    You look here from a contributor standpoint ("How common is it to make
    contributions across"). I personally tried to look at it ?from a user
    standpoint. And I think one thing users like about Dojo (one of its
    strong point against competitors?) is that there is a common
    infrastructure (including bug base) our users can rely on and go to
    when they have an issue with a Dojo project whatever this project is.
    We would be losing this.

    True. ?I think you could also make an argument that splitting up the
    repository, trackers, and even to some extent the community has its
    benefits. ?Right now, to use dojox.charting, you really need to immerse
    yourself into all things Dojo. ?You need to be exposed to our entire bug
    base, download our entire codebase, etc. ?I suspect there are lots of people
    who just want a chart who are overwhelmed by this and turn to another
    library.

    How can we try to provide the best of both experiences?

    -Adam

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at Jan 2, 2012 at 12:34 pm

    1/ a reasonable "stamped" distribution (with dojo, dijit and major
    dojox modules)
    2/ as well as consistent bug base, source system, and common
    documentation system between that major modules

    would help.

    Speaking in term of bug base, I think the ideal solution would be to
    have a bug tracking system used by all the "stamped" project and that
    would give either a full view on Dojo (including all bugs etc...) or a
    filtered view for a given set of projects.
    This is a good point to bring up; people who are grabbing a "distribution"
    have a right to expect to go to a single place to communicate with the
    people that created that distribution. However...where that distribution
    comes from and where the working copy of something actually exists can be
    two different things, and I think we're all working hard to make sure that
    where something exists contains *all* of the relevant info it needs to,
    right now via package.json. This includes references to documentation,
    tests and what testing system those tests were designed for, licensing, bug
    tracking, etc. In other words, if someone grabs a package and wants to
    know where to look for bug reports, the package should *tell* you that. No
    guessing.

    Anybody ever given any thought to the idea of providing some kind of bug
    aggregator that distributes messages to other places? I'm just throwing
    out ideas here and am definitely NOT suggesting that is the solution...

    -- Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/0b6a0469/attachment.htm
  • Colin Snover at Jan 2, 2012 at 12:45 pm

    On 02/01/2012 09:59, Christophe Jolif wrote:
    If github was providing an aggregate view of the issues of the github
    projects you subscribed to that would also help. But for now if you
    are interested in 10 "dojo" github project you need to go the 10
    issues list to deal with them...
    <https://github.com/dashboard/issues> shows all bugs from all repos that
    you own (including org repos), though it doesn?t currently show watched
    repos AFAIK, only watched issues. I imagine that a quick email to the GH
    folks would enable some additional improvement here.

    Also, <http://developer.github.com/v3/issues/> would allow some
    aggregation thing to be written if need be (though there is no push
    notification stuff for issues, which rather sucks, and would probably be
    another good thing to message GH about).
    On 02/01/2012 11:34, Tom Trenka wrote:
    Anybody ever given any thought to the idea of providing some kind of
    bug aggregator that distributes messages to other places? I'm just
    throwing out ideas here and am definitely NOT suggesting that is the
    solution...
    Yes. Launchpad does this.

    Personally, I am not convinced to go in either direction with the issue
    tracking. I agree sending people to a million different places is not
    great, but also, management of all these projects within a single issue
    tracker doesn?t seem great either. At least with most of the projects on
    GH, there?s only a single sign on, which makes it less crappy to deal
    with bug tracking.

    Cheers,

    --
    Colin Snover
    http://zetafleet.com
  • Rawld at Jan 2, 2012 at 2:16 pm
    The idea of Dojo--a large Javascript library--is mostly powerful
    precisely because of it's breadth. To dilute this by splintering the
    project would be a mistake. Instead, we ought to work to make it easier
    for it to become bigger while also making it easy to use just tiny
    parts. I think we're doing that.
    On 01/02/2012 07:32 AM, Adam L. Peller wrote:
    Right now, to use dojox.charting, you really need to immerse yourself
    into all things Dojo.
    Seems to me that has more to do with the way charting it put together
    than whether each project is totally separated.

    I think it's fine to divide dojox into independent repos; but to make
    them independent of dojo is a big mistake. It should be more a matter of
    [e.g.] elevating charting to the level of dijit, not moving charting off
    to its own corner of the world where even fewer potential customers will
    find it. By "level of dijit" I don't mean make it part of the dijit
    namespace or repo, but rather that it is just as much a part of Dojo
    (capital D) in every way as is dijit. Today, being part of dojox is
    often perceived--right or wrong--as being a second-class citizen.


    Other opinions:

    1. GitHub

    Using GitHub to publish projects and maintain central, authoritative
    *git* repos (remember, they are git repos, not GitHub repos) is fine.
    Using the toy issue tracking and some other features of GitHub would be
    a huge step backwards.


    2. Project Types:

    There should be different rules for "dojo-sanctioned" projects, compared
    to unaffiliated projects.

    Unaffiliated projects can use CPM, add the appropriate metadata...and
    they're done. To the max extent possible, dojo-sanctioned projects
    should be organized in a "one-stop-shop"

    * a single github account should hold all repos--the authoritative
    repos for each project

    * a single ticket tracker should be used for all projects (more below)

    * docs should be written so as to be aggregatable by a single doc
    aggregator

    * a single CI system should be employed, not sure of the future/use
    of DOH here...that's another discussion

    * src code style could be left to individual project owners; maybe it
    would turn out that we wouldn't sanction any projects that were grossly
    different than standard dojo style. But if a great project came along
    from some brilliant team that wanted to join dojo, would we really say
    "no, you use spaces instead of tabs" ....?

    We should make it easier to become a sanctioned project...and easier to
    de-sanction a project. Perhaps projects could have green-yellow-red status:

    * green: under dev, actively supported

    * yellow: projects that are trying to be put into the active
    status...we watch these and see how the owners behave for, say, a year.
    If there is interest, activity, appropriate behavior, then they become green

    * red: projects that are not being supported or otherwise behaving
    poorly. If project behavior doesn't change to go back to yellow, then
    they get removed...maybe to some grave yard...but they don't get the
    free marketing of being a dojo project.

    3. Issue Tracker:

    We can't let our bad experience with trac cause a bad decision going
    forward. A good issue tracker would have no problem handling 100x the
    traffic we get today. I don't understand the "scalability" problem
    that's been mentioned...assuming a good issue tracking system.


    --Rawld
  • Kitson Kelly at Jan 2, 2012 at 2:20 pm
    +1 on everything here. Essentially everything I was getting at. Thank you!
    On 2 January 2012 19:16, Rawld wrote:

    The idea of Dojo--a large Javascript library--is mostly powerful
    precisely because of it's breadth. To dilute this by splintering the
    project would be a mistake. Instead, we ought to work to make it easier
    for it to become bigger while also making it easy to use just tiny
    parts. I think we're doing that.
    On 01/02/2012 07:32 AM, Adam L. Peller wrote:
    Right now, to use dojox.charting, you really need to immerse yourself
    into all things Dojo.
    Seems to me that has more to do with the way charting it put together
    than whether each project is totally separated.

    I think it's fine to divide dojox into independent repos; but to make
    them independent of dojo is a big mistake. It should be more a matter of
    [e.g.] elevating charting to the level of dijit, not moving charting off
    to its own corner of the world where even fewer potential customers will
    find it. By "level of dijit" I don't mean make it part of the dijit
    namespace or repo, but rather that it is just as much a part of Dojo
    (capital D) in every way as is dijit. Today, being part of dojox is
    often perceived--right or wrong--as being a second-class citizen.


    Other opinions:

    1. GitHub

    Using GitHub to publish projects and maintain central, authoritative
    *git* repos (remember, they are git repos, not GitHub repos) is fine.
    Using the toy issue tracking and some other features of GitHub would be
    a huge step backwards.


    2. Project Types:

    There should be different rules for "dojo-sanctioned" projects, compared
    to unaffiliated projects.

    Unaffiliated projects can use CPM, add the appropriate metadata...and
    they're done. To the max extent possible, dojo-sanctioned projects
    should be organized in a "one-stop-shop"

    * a single github account should hold all repos--the authoritative
    repos for each project

    * a single ticket tracker should be used for all projects (more below)

    * docs should be written so as to be aggregatable by a single doc
    aggregator

    * a single CI system should be employed, not sure of the future/use
    of DOH here...that's another discussion

    * src code style could be left to individual project owners; maybe it
    would turn out that we wouldn't sanction any projects that were grossly
    different than standard dojo style. But if a great project came along
    from some brilliant team that wanted to join dojo, would we really say
    "no, you use spaces instead of tabs" ....?

    We should make it easier to become a sanctioned project...and easier to
    de-sanction a project. Perhaps projects could have green-yellow-red status:

    * green: under dev, actively supported

    * yellow: projects that are trying to be put into the active
    status...we watch these and see how the owners behave for, say, a year.
    If there is interest, activity, appropriate behavior, then they become
    green

    * red: projects that are not being supported or otherwise behaving
    poorly. If project behavior doesn't change to go back to yellow, then
    they get removed...maybe to some grave yard...but they don't get the
    free marketing of being a dojo project.

    3. Issue Tracker:

    We can't let our bad experience with trac cause a bad decision going
    forward. A good issue tracker would have no problem handling 100x the
    traffic we get today. I don't understand the "scalability" problem
    that's been mentioned...assuming a good issue tracking system.


    --Rawld
    _______________________________________________
    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/20120102/d4b52f19/attachment.htm
  • Tom Trenka at Jan 2, 2012 at 7:39 pm
    Inline, I will probably address Sasha's op-ed in a separate email.
    On Mon, Jan 2, 2012 at 1:16 PM, Rawld wrote:

    The idea of Dojo--a large Javascript library--is mostly powerful
    precisely because of it's breadth. To dilute this by splintering the
    project would be a mistake. Instead, we ought to work to make it easier
    for it to become bigger while also making it easy to use just tiny
    parts. I think we're doing that.
    That is the goal--make it easier to use tiny parts. More importantly,
    shift the focus *away* from "I need a large toolkit to do certain tasks"
    and to "I need to write a web-based mobile application that supports
    geography and charts. Where do I start?"

    (Could easily be said as "a collection of forms to handle logistics
    management using my Android phone". Doesn't matter, the point is shifting
    away from "look at all the great stuff supported by the Dojo Toolkit" and
    shifting towards "I have something I need to write quickly, efficiently and
    with some kind of focus.")

    In a lot of ways, *that's* the point of shifting to packages and package
    management.

    I think it's fine to divide dojox into independent repos; but to make
    them independent of dojo is a big mistake. It should be more a matter of
    [e.g.] elevating charting to the level of dijit, not moving charting off
    to its own corner of the world where even fewer potential customers will
    find it. By "level of dijit" I don't mean make it part of the dijit
    namespace or repo, but rather that it is just as much a part of Dojo
    (capital D) in every way as is dijit. Today, being part of dojox is
    often perceived--right or wrong--as being a second-class citizen.
    We have a lot of problems with the code that lives in DojoX. It has been,
    for a long time, a dumping ground. Accessible by anyone with commit privs
    to a single, monolithic repository with no granularity at all. I'll remind
    the list that *each and every person with SVN commit privs has the ability
    to both add and to wreck individual development efforts*. That may seem
    particularly paranoid and historically we have been pretty good about
    limiting any kind of damage from that, but at the same time DojoX has been
    offered as a place for interesting, experimental, possible contribution
    candidates to the two main packages always offered, dojo. and dijit.
    (period denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the hell
    out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.

    Other opinions:

    1. GitHub

    Using GitHub to publish projects and maintain central, authoritative
    *git* repos (remember, they are git repos, not GitHub repos) is fine.
    Using the toy issue tracking and some other features of GitHub would be
    a huge step backwards.
    You are assuming that the scope of said projects are large enough to
    warrant *not* using the toy issue tracking system, and that continuing to
    use a not-so-community supported bug tracking system is better. This is
    not intended to be an insult at all on our current systems; it is meant to
    be a reminder that it is (AFAIK) entirely supported in both maintenance and
    support costs by a single entity (AKA SitePen). That entity has done a
    great job to date (and continues to try to improve that), but at some point
    the *scope* of something needs to justify the support behind it.

    I suggested GitHub primarily because it is stable and has the kind of
    social interaction tools that promote community participation; one of my
    personal reasons is because historically we at DTK have been very *bad* at
    that social interaction, and a large part of the reason behind *that* is
    the monolithic infrastructure that we give out. No one is suggesting that
    dojo. and dijit. be broken up, and no one is suggesting that either project
    has to be. What we (I think) are looking for here is to address the lack
    of focus in distribution, the lack of maintenance and possibly dead code
    paths within DojoX, and encouraging other ways of contributing back that
    does not require "total dedication" as determined by single releases.

    Unaffiliated projects can use CPM, add the appropriate metadata...and
    they're done. To the max extent possible, dojo-sanctioned projects
    should be organized in a "one-stop-shop"
    I am clipping the rest of what Rawld said mostly for brevity. I agree with
    the majority of the sentiment but not with the proposed solutions.

    A "one stop shop" does NOT need to mean one issue tracker, one testing
    system, etc. What it needs to provide are the tools *as they pertain to
    whatever download they get". That means a clear structure, clear methods
    for finding typical information and above all *a clear download* (i.e.
    making decisions about what needs to be included with a potential
    Dojo/Dijit distribution, SANS DojoX). To me that means being a hell of a
    lot clearer about what The Dojo Toolkit really means (in a 2.0 context),
    and NOT confusing anyone by including tons of things such as a dead
    CheckboxList widget in a half-assed dojox.form project, or say a Wizard
    which seems like some people might like to have but is really not great
    quality at all.

    The goal is focus; focus on the best parts of the toolkit, the worst parts,
    minimizing a single point of distribution and infrastructure, and above all
    *selling* the damn thing. Make it easy, make it good, and when some parts
    of the code never receive any kind of love ABOVE ALL let us let them go in
    a way that does not say "these people decided they didn't like this
    anymore". That last part requires responsibility and not having a
    monolithic, singular, non-granular source repository (as well as bug
    tracking system), as well as a monolithic release cycle, dictating a
    working structure.

    -----
    A side note: when I watch this discussion (which is a good one), I see a
    trap that most good developers fall into; there's a lot of discussion about
    the choice and use of tools, and not much discussion about *why* the tools
    were chosen in the first place. Let's make a collective New Year's
    Resolution and talk about *what* we're shooting for, how that relates to
    making DTK the best JS toolkit for years to come, and how various tools
    might help (and I mean *help*) solve that.

    I'll shut up now.
    Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/a3946399/attachment.htm
  • Rawld at Jan 4, 2012 at 2:01 am
    On 01/02/2012 04:39 PM, Tom Trenka wrote:
    [snip]
    I think it's fine to divide dojox into independent repos; but to make
    them independent of dojo is a big mistake. It should be more a
    matter of
    [e.g.] elevating charting to the level of dijit, not moving
    charting off
    to its own corner of the world where even fewer potential
    customers will
    find it. By "level of dijit" I don't mean make it part of the dijit
    namespace or repo, but rather that it is just as much a part of Dojo
    (capital D) in every way as is dijit. Today, being part of dojox is
    often perceived--right or wrong--as being a second-class citizen.


    We have a lot of problems with the code that lives in DojoX. It has
    been, for a long time, a dumping ground. Accessible by anyone with
    commit privs to a single, monolithic repository with no granularity at
    all. I'll remind the list that *each and every person with SVN commit
    privs has the ability to both add and to wreck individual development
    efforts*. That may seem particularly paranoid and historically we
    have been pretty good about limiting any kind of damage from that, but
    at the same time DojoX has been offered as a place for interesting,
    experimental, possible contribution candidates to the two main
    packages always offered, dojo. and dijit. (period denotes the
    container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.
    Right. So we are agreeing, correct?
    Other opinions:

    1. GitHub

    Using GitHub to publish projects and maintain central, authoritative
    *git* repos (remember, they are git repos, not GitHub repos) is fine.
    Using the toy issue tracking and some other features of GitHub
    would be
    a huge step backwards.


    You are assuming that the scope of said projects are large enough to
    warrant *not* using the toy issue tracking system, and that continuing
    to use a not-so-community supported bug tracking system is better.
    This is not intended to be an insult at all on our current systems;
    it is meant to be a reminder that it is (AFAIK) entirely supported in
    both maintenance and support costs by a single entity (AKA SitePen).
    That entity has done a great job to date (and continues to try to
    improve that), but at some point the *scope* of something needs to
    justify the support behind it.
    An "affiliated" project, big or small, shouldn't be a burden on the
    <affiliated projects ticket system>...whatever that is.

    My main point is: one-stop shop for affiliated projects. To me, that
    means one GitHub account (assuming that's the choice) and one ticket
    system. It does not mean one repo, one release cycle, one src code
    style, or one doc system (although unified docs would be nice).
    I suggested GitHub primarily because it is stable and has the kind of
    social interaction tools that promote community participation; one of
    my personal reasons is because historically we at DTK have been very
    *bad* at that social interaction, and a large part of the reason
    behind *that* is the monolithic infrastructure that we give out. No
    one is suggesting that dojo. and dijit. be broken up, and no one is
    suggesting that either project has to be. What we (I think) are
    looking for here is to address the lack of focus in distribution, the
    lack of maintenance and possibly dead code paths within DojoX, and
    encouraging other ways of contributing back that does not require
    "total dedication" as determined by single releases.
    I have no problem with Git or GitHub (and wasn't trying to argue for
    another direction).
    Unaffiliated projects can use CPM, add the appropriate metadata...and
    they're done. To the max extent possible, dojo-sanctioned projects
    should be organized in a "one-stop-shop"


    I am clipping the rest of what Rawld said mostly for brevity. I agree
    with the majority of the sentiment but not with the proposed solutions.

    A "one stop shop" does NOT need to mean one issue tracker, one testing
    system, etc. What it needs to provide are the tools *as they pertain
    to whatever download they get". That means a clear structure, clear
    methods for finding typical information and above all *a clear
    download* (i.e. making decisions about what needs to be included with
    a potential Dojo/Dijit distribution, SANS DojoX). To me that means
    being a hell of a lot clearer about what The Dojo Toolkit really means
    (in a 2.0 context), and NOT confusing anyone by including tons of
    things such as a dead CheckboxList widget in a half-assed dojox.form
    project, or say a Wizard which seems like some people might like to
    have but is really not great quality at all.
    I agree that a dead CheckboxList widget should not be an affiliated
    project. I don't agree that instructions on how to use several different
    systems makes things better.

    The goal is focus; focus on the best parts of the toolkit, the worst
    parts, minimizing a single point of distribution and infrastructure,
    and above all *selling* the damn thing. Make it easy, make it good,
    and when some parts of the code never receive any kind of love ABOVE
    ALL let us let them go in a way that does not say "these people
    decided they didn't like this anymore". Agree
    That last part requires responsibility and not having a monolithic,
    singular, non-granular source repository (as well as bug tracking
    system), as well as a monolithic release cycle, dictating a working
    structure.
    I agree with respect to repos and release cycle.

    I disagree with respect to bug tracking. In a good ticket system, you
    just archive, tag, banish, whatever the set of tickets associated with a
    dead project and it's like they were never there....just like you
    destroy the repo from the Dojo github account. I think it would be
    extremely painful to have to log onto multiple ticket tracking systems.
    -----
    A side note: when I watch this discussion (which is a good one), I see
    a trap that most good developers fall into; there's a lot of
    discussion about the choice and use of tools, and not much discussion
    about *why* the tools were chosen in the first place. Let's make a
    collective New Year's Resolution and talk about *what* we're shooting
    for, how that relates to making DTK the best JS toolkit for years to
    come, and how various tools might help (and I mean *help*) solve that.
    This is an important point. One problem is that no existing software
    seems to meet our requirements for the ticket system/forum/mailing list
    (as Dylan outlined in another message).

    --Rawld

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120103/28183eab/attachment.htm
  • Sasha Firsov at Jan 4, 2012 at 11:28 am
    Sounds like you wanted DojoX to be stripped and cut apart from dojo toolkit.
    About integrity of toolkit a single reliable platform we spoken before.
    And burden of DojoX is the side effect of it. If any part of DojoX will
    be removed from common release, maintenance recurrent reviews you are
    concerned about, it will become outdated and not useful for "solid"
    distribution. Does DTK worth anything without DojoX? Not more than any
    another limited scope JS library. Remember that most complex and
    valuable dijits and data modules are still there?
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force
    making it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will
    become unaware of actual "framework" use needs. It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on its
    own. Until approved for long-term support in DojoX and eventually
    further. There are multiple projects have independent life based or
    extending dojo. Some are quite comparable by scale and some even larger.
    But all rely on current bundle and its integrity.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild. Yes, we are missing common 3-rd party
    "store" where everyone could offer own widget, framework, etc. With own
    license, life cycle and support. But please do not shift DojoX into same
    wild fruits bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha
    On 1/2/2012 4:39 PM, Tom Trenka wrote:
    We have a lot of problems with the code that lives in DojoX. It has
    been, for a long time, a dumping ground. Accessible by anyone with
    commit privs to a single, monolithic repository with no granularity at
    all. I'll remind the list that *each and every person with SVN commit
    privs has the ability to both add and to wreck individual development
    efforts*. That may seem particularly paranoid and historically we
    have been pretty good about limiting any kind of damage from that, but
    at the same time DojoX has been offered as a place for interesting,
    experimental, possible contribution candidates to the two main
    packages always offered, dojo. and dijit. (period denotes the
    container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 3861 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/f2aadc03/attachment.p7s
  • Tom Trenka at Jan 4, 2012 at 12:03 pm
    Sounds me like there are parts DojoX that you feel are important. Explain
    which parts might be? Part of problem is having good knowledge of things
    used from there.

    -- Tom

    2012/1/4 Sasha Firsov <suns at firsov.net>
    Sounds like you wanted DojoX to be stripped and cut apart from dojo
    toolkit.
    About integrity of toolkit a single reliable platform we spoken before.
    And burden of DojoX is the side effect of it. If any part of DojoX will be
    removed from common release, maintenance recurrent reviews you are
    concerned about, it will become outdated and not useful for "solid"
    distribution. Does DTK worth anything without DojoX? Not more than any
    another limited scope JS library. Remember that most complex and valuable
    dijits and data modules are still there?
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will become
    unaware of actual "framework" use needs. It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on its own.
    Until approved for long-term support in DojoX and eventually further. There
    are multiple projects have independent life based or extending dojo. Some
    are quite comparable by scale and some even larger. But all rely on current
    bundle and its integrity.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild. Yes, we are missing common 3-rd party
    "store" where everyone could offer own widget, framework, etc. With own
    license, life cycle and support. But please do not shift DojoX into same
    wild fruits bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha

    On 1/2/2012 4:39 PM, Tom Trenka wrote:

    We have a lot of problems with the code that lives in DojoX. It has
    been, for a long time, a dumping ground. Accessible by anyone with commit
    privs to a single, monolithic repository with no granularity at all. I'll
    remind the list that *each and every person with SVN commit privs has the
    ability to both add and to wreck individual development efforts*. That may
    seem particularly paranoid and historically we have been pretty good about
    limiting any kind of damage from that, but at the same time DojoX has been
    offered as a place for interesting, experimental, possible contribution
    candidates to the two main packages always offered, dojo. and dijit.
    (period denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.


    _______________________________________________
    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/20120104/6f7b38d3/attachment.htm
  • Jared Jurkiewicz at Jan 4, 2012 at 12:11 pm
    Two I can name right off that are pretty popular:

    dojox.editor

    dojox.layout.ContentPane (Probably used my 90% of apps).

    What happens to them?

    Sincerely,
    -- Jared Jurkiewicz

    2012/1/4 Tom Trenka <ttrenka at gmail.com>:
    Sounds me like there are parts DojoX that you feel are important. ?Explain
    which parts might be? ?Part of problem is having good knowledge of things
    used from there.

    -- Tom

    2012/1/4 Sasha Firsov <suns at firsov.net>
    Sounds like you wanted DojoX to be stripped and cut apart from dojo
    toolkit.
    About integrity of toolkit a single reliable platform we spoken before.
    And burden of DojoX is the side effect of it. If any part of DojoX will be
    removed from common release, maintenance recurrent reviews you are concerned
    about, it will become outdated and not useful for "solid" distribution. Does
    DTK worth anything without DojoX? Not more than any another limited scope JS
    library. Remember that most complex and valuable dijits and data modules are
    still there?
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will become
    unaware of actual "framework" use needs. It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on its own.
    Until approved for long-term support in DojoX and eventually further. There
    are multiple projects have independent life based or extending dojo. Some
    are quite comparable by scale and some even larger. But all rely on current
    bundle and its integrity.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild. Yes, we are missing common 3-rd party "store"
    where everyone could offer own widget, framework, etc. With own license,
    life cycle and support. But please do not shift DojoX into same wild fruits
    bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha

    On 1/2/2012 4:39 PM, Tom Trenka wrote:

    We have a lot of problems with the code that lives in DojoX. ?It has
    been, for a long time, a dumping ground. ?Accessible by anyone with commit
    privs to a single, monolithic repository with no granularity at all. ?I'll
    remind the list that *each and every person with SVN commit privs has the
    ability to both add and to wreck individual development efforts*. ?That may
    seem particularly paranoid and historically we have been pretty good about
    limiting any kind of damage from that, but at the same time DojoX has been
    offered as a place for interesting, experimental, possible contribution
    candidates to the two main packages always offered, dojo. and dijit. (period
    denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. ?Part of this
    discussion/effort is to help eliminate that confusion.



    _______________________________________________
    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
  • Adam L. Peller at Jan 4, 2012 at 12:57 pm
    Different things will be important to different people. Why can't they be
    on equal footing and have a tool that lets you choose packages, filtered or
    sorted by feature, popularity, ratings, etc? I'd expect that grid and
    charting, if broken out and marketed properly without the baggage of all of
    DojoX would be among the most popular projects in DojoX today. Some of the
    widgets might be as well. dojox.widget, layout, form and editor are
    examples of DojoX subprojects which ought to be broken out into many,
    independent packages. I suppose it's up to the authors how to factor them.

    -Adam
    On Wed, Jan 4, 2012 at 12:11 PM, Jared Jurkiewicz wrote:

    Two I can name right off that are pretty popular:

    dojox.editor

    dojox.layout.ContentPane (Probably used my 90% of apps).

    What happens to them?

    Sincerely,
    -- Jared Jurkiewicz

    2012/1/4 Tom Trenka <ttrenka at gmail.com>:
    Sounds me like there are parts DojoX that you feel are important. Explain
    which parts might be? Part of problem is having good knowledge of things
    used from there.

    -- Tom

    2012/1/4 Sasha Firsov <suns at firsov.net>
    Sounds like you wanted DojoX to be stripped and cut apart from dojo
    toolkit.
    About integrity of toolkit a single reliable platform we spoken before.
    And burden of DojoX is the side effect of it. If any part of DojoX will
    be
    removed from common release, maintenance recurrent reviews you are
    concerned
    about, it will become outdated and not useful for "solid" distribution.
    Does
    DTK worth anything without DojoX? Not more than any another limited
    scope JS
    library. Remember that most complex and valuable dijits and data
    modules are
    still there?
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force
    making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will
    become
    unaware of actual "framework" use needs. It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on its
    own.
    Until approved for long-term support in DojoX and eventually further.
    There
    are multiple projects have independent life based or extending dojo.
    Some
    are quite comparable by scale and some even larger. But all rely on
    current
    bundle and its integrity.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild. Yes, we are missing common 3-rd party
    "store"
    where everyone could offer own widget, framework, etc. With own license,
    life cycle and support. But please do not shift DojoX into same wild
    fruits
    bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha

    On 1/2/2012 4:39 PM, Tom Trenka wrote:

    We have a lot of problems with the code that lives in DojoX. It has
    been, for a long time, a dumping ground. Accessible by anyone with
    commit
    privs to a single, monolithic repository with no granularity at all.
    I'll
    remind the list that *each and every person with SVN commit privs has
    the
    ability to both add and to wreck individual development efforts*.
    That may
    seem particularly paranoid and historically we have been pretty good
    about
    limiting any kind of damage from that, but at the same time DojoX has
    been
    offered as a place for interesting, experimental, possible contribution
    candidates to the two main packages always offered, dojo. and dijit.
    (period
    denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.



    _______________________________________________
    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/20120104/b16b7ff5/attachment-0001.htm
  • Revin Guillen at Jan 4, 2012 at 1:11 pm
    (I'm replying to nobody in particular here, just to the recent direction of discussion)

    I think by and large at this point, people are accustomed to having package repositories available for their platforms, as opposed to kitchen sink releases. So for all the benefits of a giant cohesive package, it seems the market has spoken that letting people piece things together themselves is good enough. If our discovery tools are good enough to allow frequently used and updated projects to bubble up to the top, then I think the problem will end up taking care of itself.

    I've never heard of actual toolkit users talk about DojoX's inclusion in particular as a benefit; however, I *have* had plenty of conversations where people love the batteries included style of the core and Dijit. I've even had people tell me they deliberately stay away from DojoX because they need the promises Dijit makes (a11y et al), and DojoX doesn't always have it (and there isn't always the expertise available to update things within the team).

    I've also had plenty of conversations where I try to convince people that the Dojo ecosystem is far more reliable than the Wild West ecosystem that jQuery's tooling can sometimes be, but I don't think I've ever been completely successful, because it always comes down to, e.g., "well, there's jQuery UI if you need widgets," or, "there are tons of plugins and we've always been able to find what we need." From a marketing perspective, the benefits of a large tested kitchen sink just get ... lost :-/ You end up in a situation where you don't know you need what we have until you've gone without it and felt the pain, *then* discovered it. People in that situation are often instant converts.

    Anyway, TL;DR: this is pretty rambling, but there's pain ahead no matter what we do, so I favor breaking everything up. The benefits outweigh the pain, IMHO. Where it matters, we can tag packages as "IP clean" or something similar.


    Revin

    On Jan 4, 2012, at Jan 4 | 9:57 AM, Adam L. Peller wrote:

    Different things will be important to different people. Why can't they be on equal footing and have a tool that lets you choose packages, filtered or sorted by feature, popularity, ratings, etc? I'd expect that grid and charting, if broken out and marketed properly without the baggage of all of DojoX would be among the most popular projects in DojoX today. Some of the widgets might be as well. dojox.widget, layout, form and editor are examples of DojoX subprojects which ought to be broken out into many, independent packages. I suppose it's up to the authors how to factor them.

    -Adam

    On Wed, Jan 4, 2012 at 12:11 PM, Jared Jurkiewicz wrote:
    Two I can name right off that are pretty popular:

    dojox.editor

    dojox.layout.ContentPane (Probably used my 90% of apps).

    What happens to them?

    Sincerely,
    -- Jared Jurkiewicz

    2012/1/4 Tom Trenka <ttrenka at gmail.com>:
    Sounds me like there are parts DojoX that you feel are important. Explain
    which parts might be? Part of problem is having good knowledge of things
    used from there.

    -- Tom

    2012/1/4 Sasha Firsov <suns at firsov.net>
    Sounds like you wanted DojoX to be stripped and cut apart from dojo
    toolkit.
    About integrity of toolkit a single reliable platform we spoken before.
    And burden of DojoX is the side effect of it. If any part of DojoX will be
    removed from common release, maintenance recurrent reviews you are concerned
    about, it will become outdated and not useful for "solid" distribution. Does
    DTK worth anything without DojoX? Not more than any another limited scope JS
    library. Remember that most complex and valuable dijits and data modules are
    still there?
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will become
    unaware of actual "framework" use needs. It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on its own.
    Until approved for long-term support in DojoX and eventually further. There
    are multiple projects have independent life based or extending dojo. Some
    are quite comparable by scale and some even larger. But all rely on current
    bundle and its integrity.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild. Yes, we are missing common 3-rd party "store"
    where everyone could offer own widget, framework, etc. With own license,
    life cycle and support. But please do not shift DojoX into same wild fruits
    bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha

    On 1/2/2012 4:39 PM, Tom Trenka wrote:

    We have a lot of problems with the code that lives in DojoX. It has
    been, for a long time, a dumping ground. Accessible by anyone with commit
    privs to a single, monolithic repository with no granularity at all. I'll
    remind the list that *each and every person with SVN commit privs has the
    ability to both add and to wreck individual development efforts*. That may
    seem particularly paranoid and historically we have been pretty good about
    limiting any kind of damage from that, but at the same time DojoX has been
    offered as a place for interesting, experimental, possible contribution
    candidates to the two main packages always offered, dojo. and dijit. (period
    denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to confuse the
    hell out of your typical consumer of the distribution. Part of this
    discussion/effort is to help eliminate that confusion.



    _______________________________________________
    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
  • Sasha Firsov at Jan 4, 2012 at 2:37 pm
    ContentPane became a parent for dozen of other widgets and has lifespan
    almost as dojo itself. Surely it makes a CP a dijit candidate with
    shifting to group DTK ownership support.
    Similarly grid and tree became a root branches.

    By popularity of use editor, color picker, grid also need to have VIP
    treatment. But I guess very few DojoX modules are not subject for VIP :)
    On 1/4/2012 9:11 AM, Jared Jurkiewicz wrote:
    Two I can name right off that are pretty popular:

    dojox.editor

    dojox.layout.ContentPane (Probably used my 90% of apps).

    What happens to them?

    Sincerely,
    -- Jared Jurkiewicz

    2012/1/4 Tom Trenka<ttrenka at gmail.com>:
    Sounds me like there are parts DojoX that you feel are important. Explain
    which parts might be? Part of problem is having good knowledge of things
    used from there.

    -- Tom

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 3861 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/f454a157/attachment.p7s
  • Kitson Kelly at Jan 4, 2012 at 12:11 pm
    Being a sort of empirical man, it might be an idea to grep the webserver
    logs for hits against the reference pages and/or the API pages to get a
    sense of where the community is at looking.
    On 4 January 2012 17:03, Tom Trenka wrote:

    Sounds me like there are parts DojoX that you feel are important. Explain
    which parts might be? Part of problem is having good knowledge of things
    used from there.

    -- Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/69b09be7/attachment.htm
  • Sasha Firsov at Jan 4, 2012 at 2:14 pm
    I am talking about influence of "dead" in your vision modules rather
    particular interest in few.
    Even abandoned projects are still subject for support. On user group,
    during browser upgrades, etc. By the fact of own existence remaining
    code from core and dijit follow some discipline with dependencies in
    mind. It sets the approach to changes on another, more serious and
    complex project level. Which is making dojo distinct from jQuery.

    Regarding exact modules of DojoX I could confirm the use a good half of
    them. See, before project is accepted to DojoX it passes certain level
    of acceptance. Which in my mind is( and should be) sufficient to treat
    project as part of DTK. That filter makes a difference between jQuery
    plugins and DojoX.

    Note, that jQuery and often EXT quite often coexist with DTK. Seen it in
    multi-million projects. And selection of wild jQuery stuff not a subject
    to compete with.
    DojoX which you named as unreliable and bad, in reality became way more
    valuable than zillions of wild widgets. Obviously for price.
    Sounds me like there are parts DojoX that you feel are important.
    Explain which parts might be? Part of problem is having good
    knowledge of things used from there.

    -- Tom
    From the question follow that you are open to separate more valuable
    from less. Does it mean that less valuable should be excluded from
    maintenance and support?

    I have been for free market in real life. Natural selection is a good
    thing. Projects without interest and support should die. But my guts
    telling if DTK will go that way it will degrade to the level of
    collection curious but almost useless projects. Planning and performing
    in project stuff which do not attract anyone in person is still needed.
    If DTK do not have resources to support reliable DojoX, web or source
    control it is a separate talk. The value and cost should be in mind of
    all but still separate of each other.

    Most frequent DojoX in my case: tree, grid, store, dialog, calendar,
    most of layout. Which does not make others like 3D charts less valuable.
    The completeness of set is more important then presence of particular
    widget.

    Sasha
    2012/1/4 Sasha Firsov <suns at firsov.net <mailto:suns at firsov.net>>

    Sounds like you wanted DojoX to be stripped and cut apart from
    dojo toolkit.
    About integrity of toolkit a single reliable platform we spoken
    before. And burden of DojoX is the side effect of it. If any part
    of DojoX will be removed from common release, maintenance
    recurrent reviews you are concerned about, it will become outdated
    and not useful for "solid" distribution. Does DTK worth anything
    without DojoX? Not more than any another limited scope JS library.
    Remember that most complex and valuable dijits and data modules
    are still there?
    Yes, it is kind of playground, but just due to tights with whole
    DTK it makes the platform. Cross-code-dijit-dojox involvement is
    the force making it stable. Cut off any part and system will shift
    to quite narrow self-contained package set. Requirements, design,
    support, etc. will become unaware of actual "framework" use needs.
    It is recipe for extinction.

    Besides, git cloning has been approved to be a good place to have
    unsupported projects playground. There project could easy live on
    its own. Until approved for long-term support in DojoX and
    eventually further. There are multiple projects have independent
    life based or extending dojo. Some are quite comparable by scale
    and some even larger. But all rely on current bundle and its
    integrity.

    In the chain of maturity DojoX is the last trusted module set
    border for DTK customers. Beyond is wild. Yes, we are missing
    common 3-rd party "store" where everyone could offer own widget,
    framework, etc. With own license, life cycle and support. But
    please do not shift DojoX into same wild fruits bucket.

    Way stronger similar arguments applicable to dojo and dijit.
    Sasha


    On 1/2/2012 4:39 PM, Tom Trenka wrote:

    We have a lot of problems with the code that lives in DojoX.
    It has been, for a long time, a dumping ground. Accessible
    by anyone with commit privs to a single, monolithic repository
    with no granularity at all. I'll remind the list that *each
    and every person with SVN commit privs has the ability to both
    add and to wreck individual development efforts*. That may
    seem particularly paranoid and historically we have been
    pretty good about limiting any kind of damage from that, but
    at the same time DojoX has been offered as a place for
    interesting, experimental, possible contribution candidates to
    the two main packages always offered, dojo. and dijit. (period
    denotes the container and not the end of a sentence).

    After 5 years, there is a lot in DojoX that only serves to
    confuse the hell out of your typical consumer of the
    distribution. Part of this discussion/effort is to help
    eliminate that confusion.




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto: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/20120104/38b5fccf/attachment-0001.htm
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 3861 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/38b5fccf/attachment-0001.p7s
  • Adam L. Peller at Jan 4, 2012 at 12:53 pm
    2012/1/4 Sasha Firsov <suns at firsov.net>
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will become
    unaware of actual "framework" use needs. It is recipe for extinction.
    I strongly disagree. Lumping all of our projects together in a single
    release as we do today is the recipe for extinction. The JQuery community
    doesn't do any of this, and they do not appear to be in danger of
    extinction. (I'm arguing we can have it both ways by flagging projects as
    supporting "Dojo Foundation" policies or under Dojo Foundation ownership)
    Stable, well-supported APIs in core should require less coupling in our
    development process, not more. dojox/* does not have to be a playground,
    and I continue to see no good reason why 'mature' or 'popular' parts of
    dojox need to migrate into a single "framework" tarball.

    I know there's simplicity in the model that says everything in that huge
    download follows a single convention, but it's just not tenable long term.
    It's already hurt our credibility when it comes to the timing and quality
    of our releases. Most of all, treating Dojo as one giant entity may be
    popular with a few, but I think it has generally been a negative and held
    Dojo back in market share. It furthers the misconception that Dojo is too
    big, too slow, too complicated and does nothing to leverage the modularity
    we've developed all of these years.

    In the chain of maturity DojoX is the last trusted module set border for
    DTK customers. Beyond is wild.

    Most of DojoX is already wild, so as a brand, it's worthless. DojoX was
    never more than a temporary place where we could let the community grow
    until we had better tools.

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/56ab909c/attachment.htm
  • Dylan Schiemann at Jan 4, 2012 at 1:10 pm
    I suggest making a list of decisions here so we're not debating the same
    things forever.

    For example:

    * separate release schedule for modules/extensions: yes
    * separate committer pools: yes
    * ability to roll out small or unified releases: yes
    * ability to view documentation for all of my Dojo code, dojo modules,
    and my own custom code in some manner: ideal
    * web site promotion of important modules/extensions: yes
    * IP/ownership licensing and maturity of each module: stored in metadata
    file
    * source control: flexible per project, provided we preserve a way to
    easily roll things back up
    * bug tracking: I believe we need to pick one bug tracking system, that
    supports subprojects. People have enough trouble now finding the
    existence of trac. It's going to suck when they try to figure out if a
    bug is really dgrid or a dojo dependency, and aren't sure where to report it
    * forums, mailing lists, and discussions: would be nice to fix this
    problem, which will only grow with many subprojects
    * testing: ideally have continuous integration and have a way to pull in
    as many third-party modules and extensions as possible into this
    * commit history preservation in migration: TBD

    etc.

    Can someone start a doc with all of these things to decide, because
    we're quickly losing focus on what's been decided, what we're trying to
    decide, etc.

    Regards,
    - -Dylan

    on 1/4/12 10:53 AM (GMT-07:00) Adam L. Peller said the following:
    2012/1/4 Sasha Firsov <suns at firsov.net <mailto:suns at firsov.net>>

    Yes, it is kind of playground, but just due to tights with whole DTK
    it makes the platform. Cross-code-dijit-dojox involvement is the
    force making it stable. Cut off any part and system will shift to
    quite narrow self-contained package set. Requirements, design,
    support, etc. will become unaware of actual "framework" use needs.
    It is recipe for extinction.


    I strongly disagree. Lumping all of our projects together in a single
    release as we do today is the recipe for extinction. The JQuery
    community doesn't do any of this, and they do not appear to be in danger
    of extinction. (I'm arguing we can have it both ways by flagging
    projects as supporting "Dojo Foundation" policies or under Dojo
    Foundation ownership) Stable, well-supported APIs in core should
    require less coupling in our development process, not more. dojox/*
    does not have to be a playground, and I continue to see no good reason
    why 'mature' or 'popular' parts of dojox need to migrate into a single
    "framework" tarball.

    I know there's simplicity in the model that says everything in that huge
    download follows a single convention, but it's just not tenable long
    term. It's already hurt our credibility when it comes to the timing and
    quality of our releases. Most of all, treating Dojo as one giant entity
    may be popular with a few, but I think it has generally been a negative
    and held Dojo back in market share. It furthers the misconception that
    Dojo is too big, too slow, too complicated and does nothing to leverage
    the modularity we've developed all of these years.

    In the chain of maturity DojoX is the last trusted module set border
    for DTK customers. Beyond is wild.


    Most of DojoX is already wild, so as a brand, it's worthless. DojoX was
    never more than a temporary place where we could let the community grow
    until we had better tools.

    -Adam


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Colin Snover at Jan 4, 2012 at 1:10 pm

    On 04/01/2012 11:53, Adam L. Peller wrote:
    2012/1/4 Sasha Firsov <suns at firsov.net <mailto:suns at firsov.net>>

    Yes, it is kind of playground, but just due to tights with whole
    DTK it makes the platform. Cross-code-dijit-dojox involvement is
    the force making it stable. Cut off any part and system will shift
    to quite narrow self-contained package set. Requirements, design,
    support, etc. will become unaware of actual "framework" use needs.
    It is recipe for extinction.


    I strongly disagree. Lumping all of our projects together in a single
    release as we do today is the recipe for extinction. The JQuery
    community doesn't do any of this, and they do not appear to be in
    danger of extinction. (I'm arguing we can have it both ways by
    flagging projects as supporting "Dojo Foundation" policies or under
    Dojo Foundation ownership) Stable, well-supported APIs in core should
    require less coupling in our development process, not more. dojox/*
    does not have to be a playground, and I continue to see no good reason
    why 'mature' or 'popular' parts of dojox need to migrate into a single
    "framework" tarball.
    This is somewhat of a dangerous comparison to make. If Dojo were to
    simply do everything like jQuery, there would no longer be any reason
    for people to use Dojo. Some of these differences /do/ provide value to
    certain people. I know there have been cases where decision-makers have
    decided to use Dojo over other less monolithic libraries specifically
    because everything was bundled and released together at once. We need to
    make sure that the benefits of whatever change we make here outweigh the
    negatives.

    I am pretty sure that these changes will be good as well, but I just
    wanted to make sure we avoid falling into the trap of saying "party X
    does this, so can we". The fact of the matter is that it's extremely
    unlikely that Dojo will ever come close to having the gross number of
    users as jQuery, so we need to be smart about managing the project in
    the context of /our/ userbase (which is mostly professional developers,
    versus jQuery's base which is filled with many more hobbyists and
    tinkerers) and make decisions that best represent their interests. :)

    Cheers,

    --
    Colin Snover
    http://zetafleet.com

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/deaa66ba/attachment.htm
  • Rawld at Jan 4, 2012 at 1:25 pm

    On 01/04/2012 09:53 AM, Adam L. Peller wrote:
    2012/1/4 Sasha Firsov <suns at firsov.net <mailto:suns at firsov.net>>

    Yes, it is kind of playground, but just due to tights with whole
    DTK it makes the platform. Cross-code-dijit-dojox involvement is
    the force making it stable. Cut off any part and system will shift
    to quite narrow self-contained package set. Requirements, design,
    support, etc. will become unaware of actual "framework" use needs.
    It is recipe for extinction.


    I strongly disagree. Lumping all of our projects together in a single
    release as we do today is the recipe for extinction.
    Right. Agree. But there are alternatives to completely splintering (and
    I'm not saying that you are saying there are no such alternatives).

    Why can't we:

    1. Split the dojox tree into appropriate, independent projects.
    Basically follow Tom's advice.

    2. Decide which of those projects we wish to affiliate with Dojo
    (those that basically work, are supported, and have a project leader).
    Put these projects under a Dojo Foundation GitHub account, one repo per
    project. dojo and dijit also exist as such.

    3. Agree that ever project (including dojo and dijit) have
    independent release cycles. Probably many will have releases timed with
    dojo and/or dijit, but this is individual project leader's decision.

    4. Keep the single trac database for the ticket system on all
    affiliated projects.

    <><><><>END OF PHASE ONE<><><><><>

    Next tackle ticket/email/forum problems.

    As for abandoned projects: freeze at there current form in the last
    release and we never mention them again. If someone wants to resurrect
    one of those, they can update them to work with the current releases of
    any dependent projects and then lobby for inclusion as a dojo foundation
    project under an yellow/incubator status (as described in my previous msg).

    --Rawld

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120104/c0c0ce03/attachment-0001.htm
  • Adam L. Peller at Jan 4, 2012 at 1:37 pm
    Yeah, I think we're mostly in agreement. Definitely with you on 1-3...
    I'm not opposed to using our trac instance for some small set of projects
    besides core, if that's what people really want to do, I just didn't think
    we should mandate it, even for foundation projects... perhaps it would be
    used for some subset of what's "Dojo Foundation" sponsored? Should we
    require dgrid to start using trac, for example?

    2012/1/4 Rawld <rgill at altoviso.com>
    **
    On 01/04/2012 09:53 AM, Adam L. Peller wrote:

    2012/1/4 Sasha Firsov <suns at firsov.net>
    Yes, it is kind of playground, but just due to tights with whole DTK it
    makes the platform. Cross-code-dijit-dojox involvement is the force making
    it stable. Cut off any part and system will shift to quite narrow
    self-contained package set. Requirements, design, support, etc. will become
    unaware of actual "framework" use needs. It is recipe for extinction.
    I strongly disagree. Lumping all of our projects together in a single
    release as we do today is the recipe for extinction.


    Right. Agree. But there are alternatives to completely splintering (and
    I'm not saying that you are saying there are no such alternatives).

    Why can't we:

    1. Split the dojox tree into appropriate, independent projects.
    Basically follow Tom's advice.

    2. Decide which of those projects we wish to affiliate with Dojo (those
    that basically work, are supported, and have a project leader). Put these
    projects under a Dojo Foundation GitHub account, one repo per project. dojo
    and dijit also exist as such.

    3. Agree that ever project (including dojo and dijit) have independent
    release cycles. Probably many will have releases timed with dojo and/or
    dijit, but this is individual project leader's decision.

    4. Keep the single trac database for the ticket system on all affiliated
    projects.

    <><><><>END OF PHASE ONE<><><><><>

    Next tackle ticket/email/forum problems.

    As for abandoned projects: freeze at there current form in the last
    release and we never mention them again. If someone wants to resurrect one
    of those, they can update them to work with the current releases of any
    dependent projects and then lobby for inclusion as a dojo foundation
    project under an yellow/incubator status (as described in my previous msg).

    --Rawld


    _______________________________________________
    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/20120104/534e0ed0/attachment.htm
  • Bill Keese at Dec 28, 2011 at 6:46 pm
    Interesting, thanks for the link.

    The documentation I read lists how github will make a restful call to a
    specified (unpublished) trac URL every time there's a checkin, to notify
    trac of the new commit, so it can update the specified tickets (ex: "fixes
    #1234") with the info.

    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk>
    It appears trac GitPlugin supports a multi-repository configuration:
    http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but it
    maybe worth looking at how we can integrate
    http://packages.dojotoolkit.org/ and cpm into the whole situation so that
    trac can be "auto configured" to integrate additional repositories, because
    I think the admin overhead would be onerous.

    I think that is one of the challenges right now with trac, in my opinion,
    is that the codeset moves on, and maybe, possibly, we do enough admin on
    trac to keep it somewhat aligned, but usually don't.
    On 23 December 2011 02:14, Bill Keese wrote:

    Eventually we'll presumably move all of dojo's source code (including
    dojo core and dijit) into github. I'd like that to happen SRTL, mainly
    because I want to do the 1.x / 2.0 branching inside of git. (Some people
    will argue that 2.0 should be a fresh start rather than a branch, but
    that's not feasible for dijit, and IMO shouldn't even be done for dojo
    core. Because we have to maintain 1.x for a long time, and thus merge
    changes between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN. Ideally, I
    was hoping that we could move all the history to github, and drop SVN.
    But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories like
    http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that in
    our ancient history everything was mushed together in a single directory
    http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not tracking things
    like file copies (for example, see
    https://github.com/dojo/dijit/commits/master/DropDownMenu.js which
    doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy of SVN
    around forever :-(. Please correct me if I am (hopefully) incorrect on
    this.

    The other big issue (which I touched on in another mail) is about trac.
    Some people will say that each github repository should have it's own bug
    database (along with perhaps it's own reference doc, API doc, website,
    etc.), but I don't think that's feasible in the short term. So, we end up
    with bugs.dojotoolkit.org tracing bugs and changes across multiple
    github repositories. And while there are trac plugin(s) for git I doubt
    any of them handle this directly, so it will take some effort. I actually
    see this as the biggest hurdle, as simply converting part of an SVN
    repository to GIT is trivial, as listed in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410(although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?




    _______________________________________________
    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/20111229/aa483341/attachment.htm
  • Dylan Schiemann at Dec 28, 2011 at 7:37 pm
    In my opinion, switching to github is the right time to switch away from
    trac to https://www.chiliproject.org/ (the much improved fork of
    redmine). It does a really solid job of supporting multiple and
    sub-projects, etc.

    Anyway, I don't think trac is really the best option for us going
    forward, but I don't think we need to debate that now. My main point is
    that I don't think we should be thinking trac is our only option, nor
    should the way it works limit what we do.

    Regards,
    - -Dylan

    on 12/28/11 4:46 PM (GMT-07:00) Bill Keese said the following:
    Interesting, thanks for the link.

    The documentation I read lists how github will make a restful call to a
    specified (unpublished) trac URL every time there's a checkin, to notify
    trac of the new commit, so it can update the specified tickets (ex:
    "fixes #1234") with the info.

    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk
    <mailto:kitson.kelly at asseverate.co.uk>>

    It appears trac GitPlugin supports a multi-repository
    configuration: http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but
    it maybe worth looking at how we can
    integrate http://packages.dojotoolkit.org/ and cpm into the whole
    situation so that trac can be "auto configured" to integrate
    additional repositories, because I think the admin overhead would be
    onerous.

    I think that is one of the challenges right now with trac, in my
    opinion, is that the codeset moves on, and maybe, possibly, we do
    enough admin on trac to keep it somewhat aligned, but usually don't.

    On 23 December 2011 02:14, Bill Keese <bill at dojotoolkit.org
    wrote:

    Eventually we'll presumably move all of dojo's source code
    (including dojo core and dijit) into github. I'd like that to
    happen SRTL, mainly because I want to do the 1.x / 2.0 branching
    inside of git. (Some people will argue that 2.0 should be a
    fresh start rather than a branch, but that's not feasible for
    dijit, and IMO shouldn't even be done for dojo core. Because
    we have to maintain 1.x for a long time, and thus merge changes
    between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN.
    Ideally, I was hoping that we could move all the history to
    github, and drop SVN. But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories
    like http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that
    fact that in our ancient history everything was mushed together
    in a single directory http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not
    tracking things like file copies (for example,
    see https://github.com/dojo/dijit/commits/master/DropDownMenu.js
    which doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy
    of SVN around forever :-(. Please correct me if I am
    (hopefully) incorrect on this.

    The other big issue (which I touched on in another mail) is
    about trac. Some people will say that each github repository
    should have it's own bug database (along with perhaps it's own
    reference doc, API doc, website, etc.), but I don't think that's
    feasible in the short term. So, we end up with
    bugs.dojotoolkit.org <http://bugs.dojotoolkit.org> tracing bugs
    and changes across multiple github repositories. And while
    there are trac plugin(s) for git I doubt any of them handle this
    directly, so it will take some effort. I actually see this as
    the biggest hurdle, as simply converting part of an SVN
    repository to GIT is trivial, as listed
    in http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410
    (although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto: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
  • Kitson Kelly at Dec 29, 2011 at 5:42 pm
    I was wondering too if Trac was a sacred cow. I assume the biggest
    barrier/challenge would be migration, though at least for Redmine,
    migration is relatively simple from Trac.

    I guess why Chili Project over Redmine? My fear is that right now Chili
    Project has a significant less support and development community than
    Redmine. Do you know the reason for the fork?

    Personally, I have always like Mantis, which is as feature rich as you
    would like, supports customised lifecycle and is easy for end-users to use,
    but I can't comment on its github integration.
    On 29 December 2011 00:37, Dylan Schiemann wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    In my opinion, switching to github is the right time to switch away from
    trac to https://www.chiliproject.org/ (the much improved fork of
    redmine). It does a really solid job of supporting multiple and
    sub-projects, etc.

    Anyway, I don't think trac is really the best option for us going
    forward, but I don't think we need to debate that now. My main point is
    that I don't think we should be thinking trac is our only option, nor
    should the way it works limit what we do.

    Regards,
    - -Dylan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111229/f7557282/attachment.htm
  • Dylan Schiemann at Dec 30, 2011 at 7:55 am
    https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork

    on 12/29/11 3:42 PM (GMT-07:00) Kitson Kelly said the following:
    I was wondering too if Trac was a sacred cow. I assume the biggest
    barrier/challenge would be migration, though at least for Redmine,
    migration is relatively simple from Trac.

    I guess why Chili Project over Redmine? My fear is that right now Chili
    Project has a significant less support and development community than
    Redmine. Do you know the reason for the fork?

    Personally, I have always like Mantis, which is as feature rich as you
    would like, supports customised lifecycle and is easy for end-users to
    use, but I can't comment on its github integration.

    On 29 December 2011 00:37, Dylan Schiemann <dylan at dojotoolkit.org
    wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    In my opinion, switching to github is the right time to switch away from
    trac to https://www.chiliproject.org/ (the much improved fork of
    redmine). It does a really solid job of supporting multiple and
    sub-projects, etc.

    Anyway, I don't think trac is really the best option for us going
    forward, but I don't think we need to debate that now. My main point is
    that I don't think we should be thinking trac is our only option, nor
    should the way it works limit what we do.

    Regards,
    - -Dylan

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 2, 2012 at 4:27 am
    We've talked about switching bug databases before, although that was back
    before we fixed all the trac problems we were having. (Now it's working
    perfectly.)

    I don't have a strong opinion about what bug database we use, *but* I'm
    trying to scope the SVN --> git migration to be small enough that we
    actually do it, rather than a colossal project like 2.0, which we talk
    about for years. So, I'm reluctant to double the scope of the project
    unless there's no other way.

    On Thu, Dec 29, 2011 at 9:37 AM, Dylan Schiemann wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    In my opinion, switching to github is the right time to switch away from
    trac to https://www.chiliproject.org/ (the much improved fork of
    redmine). It does a really solid job of supporting multiple and
    sub-projects, etc.

    Anyway, I don't think trac is really the best option for us going
    forward, but I don't think we need to debate that now. My main point is
    that I don't think we should be thinking trac is our only option, nor
    should the way it works limit what we do.

    Regards,
    - -Dylan

    on 12/28/11 4:46 PM (GMT-07:00) Bill Keese said the following:
    Interesting, thanks for the link.

    The documentation I read lists how github will make a restful call to a
    specified (unpublished) trac URL every time there's a checkin, to notify
    trac of the new commit, so it can update the specified tickets (ex:
    "fixes #1234") with the info.

    2011/12/23 Kitson Kelly <kitson.kelly at asseverate.co.uk
    <mailto:kitson.kelly at asseverate.co.uk>>

    It appears trac GitPlugin supports a multi-repository
    configuration:
    http://trac-hacks.org/wiki/GitPlugin#Multi-RepositoryConfiguration but
    it maybe worth looking at how we can
    integrate http://packages.dojotoolkit.org/ and cpm into the whole
    situation so that trac can be "auto configured" to integrate
    additional repositories, because I think the admin overhead would be
    onerous.

    I think that is one of the challenges right now with trac, in my
    opinion, is that the codeset moves on, and maybe, possibly, we do
    enough admin on trac to keep it somewhat aligned, but usually don't.

    On 23 December 2011 02:14, Bill Keese <bill at dojotoolkit.org
    wrote:

    Eventually we'll presumably move all of dojo's source code
    (including dojo core and dijit) into github. I'd like that to
    happen SRTL, mainly because I want to do the 1.x / 2.0 branching
    inside of git. (Some people will argue that 2.0 should be a
    fresh start rather than a branch, but that's not feasible for
    dijit, and IMO shouldn't even be done for dojo core. Because
    we have to maintain 1.x for a long time, and thus merge changes
    between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN.
    Ideally, I was hoping that we could move all the history to
    github, and drop SVN. But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories
    like http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that
    fact that in our ancient history everything was mushed together
    in a single directory http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not
    tracking things like file copies (for example,
    see https://github.com/dojo/dijit/commits/master/DropDownMenu.js
    which doesn't explain that DropDownMenu.js was copied from Menu.js)
    So if that's true, then I guess we need to keep a readonly copy
    of SVN around forever :-(. Please correct me if I am
    (hopefully) incorrect on this.

    The other big issue (which I touched on in another mail) is
    about trac. Some people will say that each github repository
    should have it's own bug database (along with perhaps it's own
    reference doc, API doc, website, etc.), but I don't think that's
    feasible in the short term. So, we end up with
    bugs.dojotoolkit.org <http://bugs.dojotoolkit.org> tracing bugs
    and changes across multiple github repositories. And while
    there are trac plugin(s) for git I doubt any of them handle this
    directly, so it will take some effort. I actually see this as
    the biggest hurdle, as simply converting part of an SVN
    repository to GIT is trivial, as listed
    in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410
    (although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto: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
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk77tl8ACgkQ1E2HcBNypM5x1QCfXaqxgZf+/l9cVrDcyHPq1hK9
    YnYAn0Zm+mhx2T4Lx4iQE1mxmMzoX1Bm
    ÙQy
    -----END PGP SIGNATURE-----
    _______________________________________________
    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/20120102/7f082cc0/attachment-0001.htm
  • Sasha Firsov at Jan 2, 2012 at 6:58 pm
    Need to go from thread root level.
    There is common misconception (most comments are lead from) on what SVN
    vs git and matching bug tracking systems could serve. Will try to back
    SVN and restore its real value.

    The strongest winner point of SVN is treating subfolders and tagged
    content as separate subprojects( repositories, change history,
    tagging,etc). Contributors are working in its own scope, file bugs and
    commit there. Track and SVN well supporting those.

    Another thing, dojo have not used all power of SVN +track to have points
    of migration to git covered. Literally there is NO argument which could
    not be implemented by SVN better than in git. From sub-project
    separation to offline commits.

    I would love to share each individual features and make comparative
    review, but it is counted as well-known and still looks as dark matter
    in our threads.

    Now to the point which none competitive DVCS could provide.
    I would place as #1 the ability to treat any (either subfolder, branch
    or set of files/revisions marked by TAG) as subproject.
    "Release 1.8" tag is floating on commits approved to release, serving as
    extraction mark for everyone. Head is always in-progress and not meant
    for inter-module use. But still easy available if several modules are
    in-progress and need common work. If changes are too invasive, branching
    is at your disposal. The argument "git is better" is not relevant here
    as soon as same actions are doable.

    Tracking system. Separation of subprojects on bug and change control
    system is also too radical. Categories and tagging are part as version
    control as track system. And sub-ticket is not new approach either. No
    need for absolute insulation at all. It could be done smarter way still
    keeping in same project.

    Dev-t flows. For some reason development lifecycle and process
    streamline never appeared in VSC discussions. The convenience of regular
    contributor, user and finally release manager is important as much as
    pugilistic decisions on what to use:
    - contributors. SVN allows to have "head" as working space directly if
    few contributors on the module and in the change request-associated
    branch if insulation needed. Automatic branch creation for approved
    change request should be part of track customization: ticket created and
    functional SVN URL attached. Extra click and instead of tag, the branch
    insulates content with URL on ticket.
    - User. Having ability to refer to last approved release(same as CDN
    logic). Dependencies supported by URL and checkout without pooling
    unused modules. History only for folder. And so on.
    - Integrator. Testing+Release management.

    Each flow could be polished to perfect, but so far only SVN given best
    compromise between all.

    All of above could live in single repository, exposing proper "views"
    (as tags or branches URLs) to match use needs. Only necessary modules
    could be extracted along with dependencies(using TAG), no JS or config
    is needed, just SVN URL. SVN is universe of content separation.
    Grouping, inclusion, referencing is polished there.

    People behind. I do understand integrator people who pushing git or
    another DVCS. From release management it looks easier. But toolkit is
    about features and people committing and using them. Common interest
    should overcome the "special" of release management. All developers are
    familiar with SVN and most with Track. What is missing is proper for
    large scale project use of such tools. But going git way will shift
    audience to geeky one. So toolkit will become place for linux-nested
    nerds. I doubt SVN easiness should be sacrificed.

    Sasha

    PS. Offline commits with SVN. Need a bit of handy work. Create local(for
    offline use) HG repo with reference to your SVN branch. Allows
    transparently pull&push each individual commit to SVN. TortoiseHG should
    be sufficient for task.

    PPS. There is no need to sacrifice SVN in favor of DVCS. Bitbucket had
    configuration of HG and SVN sync-ed together. Users could choose
    whatever is convenient.
    In my case it was selected due this dual interface capabilities.
    Contributors also could use the dual system but with some restriction
    during final commit. Kind of headache for release manager, but choosing
    straight SVN as primary approach would work even with dual interface.

    On 12/22/2011 6:14 PM, Bill Keese wrote:
    Eventually we'll presumably move all of dojo's source code (including
    dojo core and dijit) into github. I'd like that to happen SRTL,
    mainly because I want to do the 1.x / 2.0 branching inside of git.
    (Some people will argue that 2.0 should be a fresh start rather than a
    branch, but that's not feasible for dijit, and IMO shouldn't even be
    done for dojo core. Because we have to maintain 1.x for a long time,
    and thus merge changes between the two branches for a long time.)

    We clearly need to preserve all the history we have in SVN. Ideally,
    I was hoping that we could move all the history to github, and drop
    SVN. But it doesn't seem feasible, due to

    - our plan to split up projects into different repositories
    (problematic for commits that span repositories like
    http://bugs.dojotoolkit.org/changeset/23032/dojo, plus that fact that
    in our ancient history everything was mushed together in a single
    directory http://bugs.dojotoolkit.org/browser/trunk)
    - the SVN --> GIT conversion programs are lacking, not tracking
    things like file copies (for example, see
    https://github.com/dojo/dijit/commits/master/DropDownMenu.js which
    doesn't explain that DropDownMenu.js was copied from Menu.js)

    So if that's true, then I guess we need to keep a readonly copy of SVN
    around forever :-(. Please correct me if I am (hopefully) incorrect
    on this.

    The other big issue (which I touched on in another mail) is about
    trac. Some people will say that each github repository should have
    it's own bug database (along with perhaps it's own reference doc, API
    doc, website, etc.), but I don't think that's feasible in the short
    term. So, we end up with bugs.dojotoolkit.org
    <http://bugs.dojotoolkit.org> tracing bugs and changes across multiple
    github repositories. And while there are trac plugin(s) for git I
    doubt any of them handle this directly, so it will take some effort.
    I actually see this as the biggest hurdle, as simply converting part
    of an SVN repository to GIT is trivial, as listed in
    http://thread.gmane.org/gmane.comp.web.dojo.devel/16372/focus410
    (although it mangled the formatting).

    So, what do others think, about the "how" and the "when" of the
    conversion?





    _______________________________________________
    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/20120102/cacc0e07/attachment-0001.htm
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 3861 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120102/cacc0e07/attachment-0001.p7s

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedDec 22, '11 at 9:14p
activeJan 4, '12 at 2:37p
posts39
users12
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase