This is not yet a proposal for a vote, but an idea I've been considering.

With the addition of General Interface to the Dojo Foundation, I think
it would be very beneficial for the Dojo Foundation to have a separate
Utilities project.

In my rough concept, things like ShrinkSafe and doh would move to this
project, along with some of the testing tools that were created for
cometd, and some of the General Interface utilities that have some
overlapping functionality. The tools would need to be as project
agnostic as makes sense, and would be encouraged to be used with any
appropriate project.

Please let me know your thoughts and ideas, and if it makes sense, I'll
plan to formalize this into something to vote on in the near future.

Also unrelated, github and bzr seem to be taking the world by storm as a
better way to work together. I'm wondering if we should setup github or
bzr repos for our projects, but still maintain trunk in svn, if that
even makes sense. My thought process is that there's probably an easier
and better way for people to create patches and manage branches as they
write code beyond private branches.

Regards,
- -Dylan

Search Discussions

  • Eugene Lazutkin at Mar 15, 2009 at 1:33 pm
    (repost --- apparently my @dojotoolkit address doesn't work for the
    dojo-contributors list)

    +1 on the separate utilities.

    +1 on github --- if we are to continue maintaining the svn repositories,
    I feel that git has the best tools to work with it (git-svn, which comes
    standard with git).
    --
    Eugene Lazutkin
    http://lazutkin.com/

    On Sun, 2009-03-15 at 10:20 -0700, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    Foundation mailing list
    Foundation at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/foundation
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: This is a digitally signed message part
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090315/defc5ccd/attachment.sig
  • Alex Russell at Mar 15, 2009 at 1:55 pm

    On Mar 15, 2009, at 10:33 AM, Eugene Lazutkin wrote:

    (repost --- apparently my @dojotoolkit address doesn't work for the
    dojo-contributors list)

    +1 on the separate utilities.
    +1 on separate utilities
    +1 on github --- if we are to continue maintaining the svn
    repositories,
    I feel that git has the best tools to work with it (git-svn, which
    comes
    standard with git).

    - -1 on github and git in general. I realize that all the cool kids are
    doing it, but Dojo has evolved to forge agreement, not to make
    disagreement cheap. I want local commits in SVN, but the fundamental
    thesis of DVCS is simply wrong for something like the Foundation.

    Regards

    - --
    Alex Russell
    slightlyoff at google.com
    alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
  • Dylan Schiemann at Mar 16, 2009 at 3:45 am

    Alex Russell wrote:
    On Mar 15, 2009, at 10:33 AM, Eugene Lazutkin wrote:

    (repost --- apparently my @dojotoolkit address doesn't work for the
    dojo-contributors list)
    +1 on the separate utilities.
    +1 on separate utilities
    +1 on github --- if we are to continue maintaining the svn
    repositories,
    I feel that git has the best tools to work with it (git-svn, which
    comes
    standard with git).

    -1 on github and git in general. I realize that all the cool kids are
    doing it, but Dojo has evolved to forge agreement, not to make
    disagreement cheap. I want local commits in SVN, but the fundamental
    thesis of DVCS is simply wrong for something like the Foundation.
    Potential pros in my mind with github:

    * easier to work with patches (historically we've been not so great
    about bit rot and patches)
    * easier to work with branches (we're not great about branching major
    changes)
    * social features around contributing and collaborating (I know, this
    sounds nebulous, but it is a great way for new people to get involved
    with Dojo

    I'm not sure I buy the argument that it makes disagreement cheap, as
    we've always made it pretty cheap to disagree. ;) I think there's
    potential to make it easier to show different approaches and then come
    to a resolution, and would argue that it expedites resolution.

    I think it's worth at least exploring, and I'd definitely like to hear
    from Peter Higgins and others who have been using it for other things.
    While I appreciate the potential social ramifications of changing a tool
    we use, I'd like to strongly consider why it is benefiting other
    projects and if it can benefit us, as is the case with any other tool
    that's getting highly favorable reviews from people we trust.

    Regards,
    - -Dylan
  • Alex Russell at Mar 16, 2009 at 6:29 am
    [ snip ]
    +1 on github --- if we are to continue maintaining the svn
    repositories,
    I feel that git has the best tools to work with it (git-svn, which
    comes
    standard with git).

    -1 on github and git in general. I realize that all the cool kids are
    doing it, but Dojo has evolved to forge agreement, not to make
    disagreement cheap. I want local commits in SVN, but the fundamental
    thesis of DVCS is simply wrong for something like the Foundation.
    Potential pros in my mind with github:

    * easier to work with patches (historically we've been not so great
    about bit rot and patches)
    git doesn't solve the "it's hard to get eyes on patches" problem.
    That's a social thing, and it's just a much a social thing w/ git as
    it is w/ svn. This is a +0.

    * easier to work with branches (we're not great about branching major
    changes)
    Agreed. But we've made this hard on ourselves too by not using a sane
    SVN layout. Git won't magically fix that any more than just fixing our
    SVN layout would. -0.
    * social features around contributing and collaborating (I know, this
    sounds nebulous, but it is a great way for new people to get involved
    with Dojo
    I'll buy that the ease of creating clones might feel liberating w/
    git, and that SVN is squarely in the past since it doesn't deal w/
    CL's and have local commits. These are personal frustrations of mine,
    but they're not outweighed by:

    * having bug tracking integration w/ the SCM in both directoins
    * being able to enforce pre/post commit hooks
    * the significantly simpler "who gave you this code?" chain in most
    situations w/ SVN vs. git.
    I'm not sure I buy the argument that it makes disagreement cheap, as
    we've always made it pretty cheap to disagree. ;)
    We've made it expensive to carry disagreements forward. Forks are
    disagreements that you don't have the social graces to work through.
    Making long-term disagreement expensive is a good and healthy thing.
    Compromise is the essence of what Dojo is. Many things are hard, and
    they require tradeoffs. Dojo makes informed tradeoffs. We do that by
    creating a fora where people *need* to come to agreement, and our
    current SCM has our back there.
    I think there's
    potential to make it easier to show different approaches and then come
    to a resolution, and would argue that it expedites resolution.
    I'll buy that. But we don't need github for that. Individuals can
    already git-svn wrap our current tree to get that effect.

    Regards
    I think it's worth at least exploring, and I'd definitely like to hear
    from Peter Higgins and others who have been using it for other things.
    While I appreciate the potential social ramifications of changing a
    tool
    we use, I'd like to strongly consider why it is benefiting other
    projects and if it can benefit us, as is the case with any other tool
    that's getting highly favorable reviews from people we trust.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm+A6kACgkQ8nLgh/JJsxF7AwCgkI8AJDz/+ChUH0BUtsIykG/S
    MxkAniQb45pR+sMYDZVBI2njVLvI0E8H
    =rVYA
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    - --
    Alex Russell
    slightlyoff at google.com
    alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
  • Peter E Higgins at Mar 16, 2009 at 10:30 am

    Dylan Schiemann wrote:
    Alex Russell wrote:
    On Mar 15, 2009, at 10:33 AM, Eugene Lazutkin wrote:

    (repost --- apparently my @dojotoolkit address doesn't work for the
    dojo-contributors list)
    +1 on the separate utilities.
    +1 on separate utilities
    +1 on separate utilities. Would love to see shrinksafe in particular
    exposed. How to get them out of dojo svn but not cause too much
    heartache for us consume them again (doh, shrinksafe, docscripts
    especially).
    I think it's worth at least exploring, and I'd definitely like to hear
    from Peter Higgins and others who have been using it for other things.
    While I appreciate the potential social ramifications of changing a tool
    we use, I'd like to strongly consider why it is benefiting other
    projects and if it can benefit us, as is the case with any other tool
    that's getting highly favorable reviews from people we trust.
    I'm only using it in one place, and am finding it very unfamiliar. I am
    not _really_ using any of the features provided by git, though know some
    folks are and do. John Locke, for instance, maintains a git repo of Dojo
    trunk already for his stuff. My remarks mirror those of Bryan's: DVCS of
    any kind isn't going to lower our barrier to entry, and will just cause
    us to focus resources on a migration rather than the things which are
    working substandard to begin with.

    Regards,
    Peter
    Regards,
    -Dylan
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    --
    Peter E Higgins
    Dojo Project Lead : http://dojotoolkit.org
  • Dylan Schiemann at Mar 19, 2009 at 7:23 pm
    FYI, based on everyone's feedback, I'm going to summarize:

    -1 on github and git in general
    +1 on providing docs for people wanting to use such tools on top of our
    svn setup
    0 on Utilities as a separate project... we'll revisit this in the future
    if/when it makes sense
    +1 on marketing utilities as standalone useful projects.

    Regards,
    -Dylan

    Dylan Schiemann wrote:
    Alex Russell wrote:
    On Mar 15, 2009, at 10:33 AM, Eugene Lazutkin wrote:

    (repost --- apparently my @dojotoolkit address doesn't work for the
    dojo-contributors list)
    +1 on the separate utilities.
    +1 on separate utilities
    +1 on github --- if we are to continue maintaining the svn
    repositories,
    I feel that git has the best tools to work with it (git-svn, which
    comes
    standard with git).
    -1 on github and git in general. I realize that all the cool kids are
    doing it, but Dojo has evolved to forge agreement, not to make
    disagreement cheap. I want local commits in SVN, but the fundamental
    thesis of DVCS is simply wrong for something like the Foundation.
    Potential pros in my mind with github:

    * easier to work with patches (historically we've been not so great
    about bit rot and patches)
    * easier to work with branches (we're not great about branching major
    changes)
    * social features around contributing and collaborating (I know, this
    sounds nebulous, but it is a great way for new people to get involved
    with Dojo

    I'm not sure I buy the argument that it makes disagreement cheap, as
    we've always made it pretty cheap to disagree. ;) I think there's
    potential to make it easier to show different approaches and then come
    to a resolution, and would argue that it expedites resolution.

    I think it's worth at least exploring, and I'd definitely like to hear
    from Peter Higgins and others who have been using it for other things.
    While I appreciate the potential social ramifications of changing a tool
    we use, I'd like to strongly consider why it is benefiting other
    projects and if it can benefit us, as is the case with any other tool
    that's getting highly favorable reviews from people we trust.

    Regards,
    -Dylan
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Wolfram Kriesing at Mar 15, 2009 at 2:06 pm
    I am also +1 for utilities.
    Just look at "dools" what we thought to be "dojo tools"
    http://code.google.com/p/dools/source/browse/#svn/trunk/dools
    that was the idea behind it, having a tools/utilities
    namespace. I am currently converting the api docs viewer
    to be in there. (Reflection and ApiTree, which are parts
    of the api viewer are already there.)

    By having dojo utilities you probably mean more than just
    a namespace in the javascript land, parallel to dojo, dijit and
    dojox, right?

    Richard Bondi had even been discussing a couple of possible
    names (though mostly api docs related), for the time being
    we prefered dools, since it is most general.
    http://code.google.com/p/dools/issues/detail?id=5
    Though I like "done" :-)

    +0 on git ... i rather use it as a local tool, the project under
    svn is perfectly fine, it keeps the barrier of entry low.

    --
    cu

    Wolfram

    http://uxebu.com - the AJAX experts
    You need AJAX, RIA, JavaScript and all this modern stuff? We got it!


    On Sun, Mar 15, 2009 at 6:20 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. ?The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. ?I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. ?My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at Mar 15, 2009 at 2:24 pm
    +1 on it being a separate project, DTK-agnostic.
    I have no opinion on using Github, though I think something like Google Code
    may be a good place for it to live. My understanding also is that we're at
    a point where we're in dire need of mirrors for all of the downloads, so
    this might be a good thread to start that discussion as well.

    regards,
    trt
    On Sun, Mar 15, 2009 at 1:06 PM, Wolfram Kriesing wrote:

    I am also +1 for utilities.
    Just look at "dools" what we thought to be "dojo tools"
    http://code.google.com/p/dools/source/browse/#svn/trunk/dools
    that was the idea behind it, having a tools/utilities
    namespace. I am currently converting the api docs viewer
    to be in there. (Reflection and ApiTree, which are parts
    of the api viewer are already there.)

    By having dojo utilities you probably mean more than just
    a namespace in the javascript land, parallel to dojo, dijit and
    dojox, right?

    Richard Bondi had even been discussing a couple of possible
    names (though mostly api docs related), for the time being
    we prefered dools, since it is most general.
    http://code.google.com/p/dools/issues/detail?id=5
    Though I like "done" :-)

    +0 on git ... i rather use it as a local tool, the project under
    svn is perfectly fine, it keeps the barrier of entry low.

    --
    cu

    Wolfram

    http://uxebu.com - the AJAX experts
    You need AJAX, RIA, JavaScript and all this modern stuff? We got it!


    On Sun, Mar 15, 2009 at 6:20 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    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/20090315/75cd9405/attachment-0001.htm
  • Adam Peller at Mar 15, 2009 at 9:58 pm
    Perhaps just as important -- I think we need to have our most popular
    utilities, like ShrinkSafe, on their own release cycles. I'm not sure
    how that relates to the actual source control location, but it does
    make sense to enforce the idea that these utilities are generally
    Dojo-independent.

    -Adam
    On Sun, Mar 15, 2009 at 1:20 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. ?The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. ?I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. ?My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    Foundation mailing list
    Foundation at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/foundation
  • Wolfram Kriesing at Mar 16, 2009 at 6:23 am
    I had just thought of another name for the tools/utilities project
    djools
    somehow a mixture of dojo+tools and close to "jewels" :-)
    (We have not been 1000% convinced by "dools" so we
    were constantly thinking of something better.)

    just thinking out loud :-)

    Wolfram
  • Bryan Forbes at Mar 16, 2009 at 10:15 am
    +1 on making the utilities separate.

    ----1 on git/bzr/darcs/mercurial/insert random dvcs here (reasoning
    follows)

    First, git != github. github is like launchpad (bzr) or google code
    (svn). git is the tool :). Now that I have those ridiculous semantics
    out of the way...

    As it stands today, I don't think git is ready for our project. We want
    the barrier of entry low and I feel that git doesn't provide that. I
    don't want to get into a flame war (I really don't), but when coming
    from a subversion background and mindsent git can be quite confusing...
    especially the commands.

    Full disclosure: I love bzr. However, I am not suggesting we move
    everything to launchpad. Keeping everything in subversion means that
    everyone can use whatever tool they want: git+git-svn, bzr+bzr-svn, and
    I think mercurial has their own svn bridge. For instance, I use bzr
    +bzr-svn to develop new grid features. And, IIRC, Eugene uses git
    +git-svn to do his Dojo work. Using this approach, we keep the barrier
    of entry low for those that don't "get" DVCS and allow those of us that
    love it to use it.

    One thing I think we should do is provide tutorials on how to use the
    DVCS tools with our current repo setup and start getting feedback from
    the community on which tool they think are easiest to use. No need to
    mirror anything on github/launchpad.

    Regards,
    -Bryan
    On Sun, 2009-03-15 at 10:20 -0700, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    --
    ======================================================================
    Bryan Forbes
    bryan at reigndropsfall.net
    http://www.reigndropsfall.net

    "It does not take a majority to prevail, but rather an irate, tireless
    minority keen to set brush fires in people's minds."
    - Samuel Adams, an architect of the Constitution

    Key fingerprint = 3D7D B728 713A BB7B B8B1 5B61 3888 17E0 70CA 0F3D
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: This is a digitally signed message part
    Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090316/c5a72b54/attachment.sig
  • Wolfram Kriesing at Mar 16, 2009 at 10:34 am
    2009/3/16 Bryan Forbes <bryan at reigndropsfall.net>:
    +1 on making the utilities separate.

    ----1 on git/bzr/darcs/mercurial/insert random dvcs here (reasoning
    follows)

    First, git != github. ?github is like launchpad (bzr) or google code
    (svn). ?git is the tool :). ?Now that I have those ridiculous semantics
    out of the way...

    As it stands today, I don't think git is ready for our project. ?We want
    the barrier of entry low and I feel that git doesn't provide that. ?I
    don't want to get into a flame war (I really don't), but when coming
    from a subversion background and mindsent git can be quite confusing...
    especially the commands.

    Full disclosure: I love bzr. ?However, I am not suggesting we move
    everything to launchpad. ?Keeping everything in subversion means that
    everyone can use whatever tool they want: git+git-svn, bzr+bzr-svn, and
    I think mercurial has their own svn bridge. ?For instance, I use bzr
    +bzr-svn to develop new grid features. ?And, IIRC, Eugene uses git
    +git-svn to do his Dojo work. ?Using this approach, we keep the barrier
    of entry low for those that don't "get" DVCS and allow those of us that
    love it to use it.

    One thing I think we should do is provide tutorials on how to use the
    DVCS tools with our current repo setup and start getting feedback from
    the community on which tool they think are easiest to use. ?No need to
    mirror anything on github/launchpad.
    +1 on everything, esp. keeing the barrier low!
    Regards,
    -Bryan
    On Sun, 2009-03-15 at 10:20 -0700, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. ?The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. ?I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. ?My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    --
    ======================================================================
    Bryan Forbes
    bryan at reigndropsfall.net
    http://www.reigndropsfall.net

    "It does not take a majority to prevail, but rather an irate, tireless
    minority keen to set brush fires in people's minds."
    ? ? ? ?- Samuel Adams, an architect of the Constitution

    Key fingerprint = 3D7D B728 713A BB7B B8B1 ?5B61 3888 17E0 70CA 0F3D

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • James Burke at Mar 16, 2009 at 12:41 pm
    -1 Separate utilities project. It is not clear to me that this buys us
    anything. The main issue is more of a marketing/packaging issue vs.
    repository: we need to broadcast and bundle the utilities as separate
    deliverables, probably through the website. Where the source is hosted
    does not really matter. If the marketing/packaging issue is solved,
    then it may make sense to look at where the source is hosted, but it
    is a secondary concern.

    Plus in the near term, it puts more work on a person wanting to work
    with our source and/or do custom builds, since they will need to pull
    from multiple places. For the long term, I would like our build tool
    smart enough to download code so we do not have to even deliver dijit
    or dojox with a standard src build, but that is not in place yet.
    Maybe once that works we can look at pulling the code somewhere else.

    -1 DVCS, for the reasons that Bryan and Alex gave. SVN is lowest
    common denominator, it works for us, and people can use their favorite
    DVCS to work on Dojo if they like -- we do not have to jump into that
    religious debate. Documenting how to use a DVCS with our SVN might be
    useful. Integrating patches, doing branches is more of human issue vs.
    source control provider issue in our case.

    James
    On Sun, Mar 15, 2009 at 10:20 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    This is not yet a proposal for a vote, but an idea I've been considering.

    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.

    In my rough concept, things like ShrinkSafe and doh would move to this
    project, along with some of the testing tools that were created for
    cometd, and some of the General Interface utilities that have some
    overlapping functionality. ?The tools would need to be as project
    agnostic as makes sense, and would be encouraged to be used with any
    appropriate project.

    Please let me know your thoughts and ideas, and if it makes sense, I'll
    plan to formalize this into something to vote on in the near future.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. ?I'm wondering if we should setup github or
    bzr repos for our projects, but still maintain trunk in svn, if that
    even makes sense. ?My thought process is that there's probably an easier
    and better way for people to create patches and manage branches as they
    write code beyond private branches.

    Regards,
    - -Dylan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.10 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iEYEARECAAYFAkm9OMsACgkQ8nLgh/JJsxF2uQCfaBkXPurNh+bM1SOfJUABEu6Z
    AdEAnj+PWbw/6SqxuFW+tshcMaNuFt3X
    =Yj0h
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Sam foster at Mar 16, 2009 at 4:50 pm

    On Mon, Mar 16, 2009 at 4:41 PM, James Burke wrote:
    -1 Separate utilities project. It is not clear to me that this buys us
    anything. The main issue is more of a marketing/packaging issue vs.
    repository: we need to broadcast and bundle the utilities as separate
    deliverables, probably through the website. Where the source is hosted
    does not really matter. If the marketing/packaging issue is solved,
    then it may make sense to look at where the source is hosted, but it
    is a secondary concern.
    Well put, you have my -1 on seperate utilities too - for the immediate
    term at least.
    We talked a while back about creating sub-sites (or at least landing
    pages) for the different projects within the toolkit, and this I think
    was one of the things that we felt more comfortable doing with a new
    site architecture and django rather than drupal. Where the source
    lives shouldnt matter. We can make downloads available wherever we
    want, in whatever context. The proposal seems to be to have the svn
    repo layout stand-in for good IA, which shouldnt be necessary.

    /Sam
  • Bill Keese at Mar 16, 2009 at 11:03 pm

    Dylan Schiemann wrote:
    With the addition of General Interface to the Dojo Foundation, I think
    it would be very beneficial for the Dojo Foundation to have a separate
    Utilities project.
    I would say to split things now if the GI guys (or some other project)
    wants to use DOH/shrinksafe.

    Otherwise (as usual) I would say that for the time being, we shouldn't
    create more IT headaches for ourselves, being that we have so many already.

    Also unrelated, github and bzr seem to be taking the world by storm as a
    better way to work together. I'm wondering if we should setup github or
    bzr repos for our projects...
    I don't know enough to respond to this. I've looked up git and bazaar
    and (like every other software tool/library) the websites say that they
    are the greatest thing since sliced bread, but I can't get a feel for
    what (if anything) is really different from a user's perspective.

    If the main issue is speed, then SVN is fast enough for me. If the main
    issue is better branching/merging, I'd need to see an example of how
    it's really different (again, from a user's perspective).
  • Marcin Lulek at Mar 17, 2009 at 5:28 am
    -1 on github,

    i would rather suggest +1 for mercurial and bitbucket.

    there are 2 big reasons for this, very good windows support and good eclipse
    plugin support.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090317/6dc609ad/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedMar 15, '09 at 1:20p
activeMar 19, '09 at 7:23p
posts17
users12
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase