Hi all,

I recently started trying to come up with an approach for converting some
DojoX projects to true anonymous AMD packages, installable with CPM, and
I'd like to propose the following:

1) If you are a DojoX project owner, create new repositories at Github for
just the project you own;
2) Convert said project to true anonymous AMD; in other words, no
dojo.setObject, no setting of global (though namespaced) variables, etc.
3) Include the basic format as found at
https://github.com/kriszyp/commonjs-package-template including README.md,
doc and test directories.
4) If you co-own a project, invite anyone to your repo as a collaborator
(you can find the options under Admin in your repo).
5) Use github's Issues for bug tracking on it.

(Anything else?)

I've begun this process with dojox.collections; you can find the initial
repo at https://github.com/ttrenka/dx-collections (note that I have not
done any docs or tests yet.) Eventually I will contacting Kris about
getting the package registered and working with CPM, but this is a start.
Since I own a number of very stable DojoX projects, I will be slowly
porting other projects over in the next month or so, which anyone can use
as a guide/template for doing their own thing.

A few notes as I'm working through this:
1) Any pull requests I receive for any of these projects will have to have
some way of verifying that the person issuing the pull request has signed a
CLA and the code in the request satisfies those conditions. At this point
I'm not sure how to do that outside of manually verifying the person.
2) Similarly, we'll need a way of marking a package as CLA-certified, if
applicable. I know Kris has something that is marking certain packages at
packages.dojofoundation.org that way but I'm not sure what it is. Kris?
3) For now, I'm sticking with a "dx-[project]" naming convention. This is
not to say that it would be required, but it seems to be working pretty
well for me at this point.

I'd like to get the ball rolling with these conversions as part of the 1.8
development process, so that we can start finding/discovering any potential
issues that we might run across (hence the reason I'm starting this now and
announcing it). Does anyone have any objections, thoughts, etc.?

Cheers--
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111220/ca684d1c/attachment.htm

Search Discussions

  • Ben hockey at Dec 20, 2011 at 11:35 am
    i have a slightly tangential question that i've been looking for an
    appropriate time to ask...

    it seems we're adding new components to dojox (calendar, tree widget,
    etc) at the same time as we're trying to not do that anymore. in my
    opinion, dgrid is a good example of the way forward for new components
    that would have previously been added to dojox. is there a reason we're
    adding components to dojox rather than having them follow the same path
    as dgrid? i'm not opposed to the specific components but am just trying
    to make sure that we're being consistent with our approach. adding some
    components but not others and at the same time moving some out makes for
    a confusing story to anybody looking at dojox. is there some guiding
    principle here that makes the story simpler to explain or do we need to
    be more consistent in our approach?

    thanks,

    ben...
    On 12/20/2011 11:22 AM, Tom Trenka wrote:
    Hi all,

    I recently started trying to come up with an approach for converting
    some DojoX projects to true anonymous AMD packages, installable with
    CPM, and I'd like to propose the following:

    1) If you are a DojoX project owner, create new repositories at Github
    for just the project you own;
    2) Convert said project to true anonymous AMD; in other words, no
    dojo.setObject, no setting of global (though namespaced) variables, etc.
    3) Include the basic format as found at
    https://github.com/kriszyp/commonjs-package-template including
    README.md, doc and test directories.
    4) If you co-own a project, invite anyone to your repo as a
    collaborator (you can find the options under Admin in your repo).
    5) Use github's Issues for bug tracking on it.

    (Anything else?)

    I've begun this process with dojox.collections; you can find the
    initial repo at https://github.com/ttrenka/dx-collections (note that I
    have not done any docs or tests yet.) Eventually I will contacting
    Kris about getting the package registered and working with CPM, but
    this is a start. Since I own a number of very stable DojoX projects,
    I will be slowly porting other projects over in the next month or so,
    which anyone can use as a guide/template for doing their own thing.

    A few notes as I'm working through this:
    1) Any pull requests I receive for any of these projects will have to
    have some way of verifying that the person issuing the pull request
    has signed a CLA and the code in the request satisfies those
    conditions. At this point I'm not sure how to do that outside of
    manually verifying the person.
    2) Similarly, we'll need a way of marking a package as CLA-certified,
    if applicable. I know Kris has something that is marking certain
    packages at packages.dojofoundation.org
    <http://packages.dojofoundation.org> that way but I'm not sure what it
    is. Kris?
    3) For now, I'm sticking with a "dx-[project]" naming convention.
    This is not to say that it would be required, but it seems to be
    working pretty well for me at this point.

    I'd like to get the ball rolling with these conversions as part of the
    1.8 development process, so that we can start finding/discovering any
    potential issues that we might run across (hence the reason I'm
    starting this now and announcing it). Does anyone have any
    objections, thoughts, etc.?

    Cheers--
    Tom


    _______________________________________________
    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/20111220/190074d8/attachment-0001.htm
  • Christophe Jolif at Dec 20, 2011 at 11:45 am
    Ben,

    On one hand I agree we should experiment the 2.0 way of doing things,
    on the other hand if we want our users to really benefit from these
    new components before 2.0 having them in dojox is really the only way
    to go for me. Otherwise because of the issues I mentioned in my
    previous mail I think they will lack key integration point at
    documentation level etc...

    --
    Christophe

    2011/12/20 ben hockey <neonstalwart at gmail.com>:
    i have a slightly tangential question that i've been looking for an
    appropriate time to ask...

    it seems we're adding new components to dojox (calendar, tree widget, etc)
    at the same time as we're trying to not do that anymore.? in my opinion,
    dgrid is a good example of the way forward for new components that would
    have previously been added to dojox.? is there a reason we're adding
    components to dojox rather than having them follow the same path as dgrid?
    i'm not opposed to the specific components but am just trying to make sure
    that we're being consistent with our approach.? adding some components but
    not others and at the same time moving some out makes for a confusing story
    to anybody looking at dojox.? is there some guiding principle here that
    makes the story simpler to explain or do we need to be more consistent in
    our approach?

    thanks,

    ben...


    On 12/20/2011 11:22 AM, Tom Trenka wrote:

    Hi all,

    I recently started trying to come up with an approach for converting some
    DojoX projects to true anonymous AMD packages, installable with CPM, and I'd
    like to propose the following:

    1) If you are a DojoX project owner, create new repositories at Github for
    just the project you own;
    2) Convert said project to true anonymous AMD; in other words, no
    dojo.setObject, no setting of global (though namespaced) variables, etc.
    3) Include the basic format as found
    at?https://github.com/kriszyp/commonjs-package-template including README.md,
    doc and test directories.
    4) If you co-own a project, invite anyone to your repo as a collaborator
    (you can find the options under Admin in your repo).
    5) Use github's Issues for bug tracking on it.

    (Anything else?)

    I've begun this process with dojox.collections; you can find the initial
    repo at?https://github.com/ttrenka/dx-collections (note that I have not done
    any docs or tests yet.) ?Eventually I will contacting Kris about getting the
    package registered and working with CPM, but this is a start. ?Since I own a
    number of very stable DojoX projects, I will be slowly porting other
    projects over in the next month or so, which anyone can use as a
    guide/template for doing their own thing.

    A few notes as I'm working through this:
    1) Any pull requests I receive for any of these projects will have to have
    some way of verifying that the person issuing the pull request has signed a
    CLA and the code in the request satisfies those conditions. ?At this point
    I'm not sure how to do that outside of manually verifying the person.
    2) Similarly, we'll need a way of marking a package as CLA-certified, if
    applicable. ?I know Kris has something that is marking certain packages at
    packages.dojofoundation.org that way but I'm not sure what it is. ?Kris?
    3) For now, I'm sticking with a "dx-[project]" naming convention. ?This is
    not to say that it would be required, but it seems to be working pretty well
    for me at this point.

    I'd like to get the ball rolling with these conversions as part of the 1.8
    development process, so that we can start finding/discovering any potential
    issues that we might run across (hence the reason I'm starting this now and
    announcing it). ?Does anyone have any objections, thoughts, etc.?

    Cheers--
    Tom


    _______________________________________________
    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 Dec 20, 2011 at 2:23 pm
    Encouraging (opt-in) migration for current dojox projects now is the right
    thing to do.

    2011/12/20 ben hockey <neonstalwart at gmail.com>
    it seems we're adding new components to dojox (calendar, tree widget, etc)
    at the same time as we're trying to not do that anymore. in my opinion,
    dgrid is a good example of the way forward for new components that would
    have previously been added to dojox. is there a reason we're adding
    components to dojox rather than having them follow the same path as dgrid?
    Inertia, perhaps. We haven't yet figured out how to redirect bugs, or more
    importantly, to direct the community to these new projects. I suspect
    people feel they'd be missing out if they weren't a part of the
    unsustainable 'kitchen sink' releases we've been doing. To fix that, I
    believe we need to give priority to CPM in our new site design, structure
    the site such that it gives reference points for each project which can be
    treated as independent sites and referenced from package JSON. Then, we
    need to give the packages.dojotoolkit.org site a little UI love to make it
    themed, filtered, and provide a "detail" view so users can see basic
    information like a description and pointers to all the essential
    information besides download: promotional materials, documentation, bug
    reporting, etc.

    Whether individual projects choose to keep "dojox" as part of their brand
    would be an individual decision. I suspect the term would die off over
    time. The dojox namespace would eventually die off, too, with full AMD,
    but for many existing projects I suspect it will be kept around for
    back-compat. I don't see any reason to enforce any naming patterns here.
    The important information regarding CLA, license and support should all be
    in the package metadata.

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111220/8b5605e0/attachment.htm
  • Christophe Jolif at Dec 20, 2011 at 11:37 am
    Hi Tom,

    Thanks for your effort!

    I think we should indeed make significant progress on that effort
    during 1.8 timeframe so that we are fully ready when we start 2.0 to
    do the actual migration and not be caught by problems we did not think
    about.

    However I would like to check with you that the intent is indeed just
    to do a real life testing and that the packages in questions will
    still be part of dojox in their regular format for 1.8? (I don't see
    any other option because of compatibility, but I check just in case
    ;))

    For the naming as there is a d(ojo)grid why not keeping that and
    having the dcollections, dgauges etc..?

    The main problem I foresee with that move is related to Dojo
    infrastructure. For issue management, ok we can imagine using github
    issues for each project that shouldn't be too bad (even if I must
    admit I still prefer trac). But what about documentation both API and
    reference? One of the great advantage of Dojo is to give a single
    entry point for the users and if each package documentation is managed
    and hosted differently we will lost them. I think we should define for
    all these projects a way to have their API & reference documentation
    hosted by Dojo and I don't think there is anything in that area yet?
    The same issue applies to build system. How to make sure one can
    easily build his application with distributed package?

    --
    Christophe

    2011/12/20 Tom Trenka <ttrenka at gmail.com>:
    Hi all,

    I recently started trying to come up with an approach for converting some
    DojoX projects to true anonymous AMD packages, installable with CPM, and I'd
    like to propose the following:

    1) If you are a DojoX project owner, create new repositories at Github for
    just the project you own;
    2) Convert said project to true anonymous AMD; in other words, no
    dojo.setObject, no setting of global (though namespaced) variables, etc.
    3) Include the basic format as found
    at?https://github.com/kriszyp/commonjs-package-template including README.md,
    doc and test directories.
    4) If you co-own a project, invite anyone to your repo as a collaborator
    (you can find the options under Admin in your repo).
    5) Use github's Issues for bug tracking on it.

    (Anything else?)

    I've begun this process with dojox.collections; you can find the initial
    repo at?https://github.com/ttrenka/dx-collections (note that I have not done
    any docs or tests yet.) ?Eventually I will contacting Kris about getting the
    package registered and working with CPM, but this is a start. ?Since I own a
    number of very stable DojoX projects, I will be slowly porting other
    projects over in the next month or so, which anyone can use as a
    guide/template for doing their own thing.

    A few notes as I'm working through this:
    1) Any pull requests I receive for any of these projects will have to have
    some way of verifying that the person issuing the pull request has signed a
    CLA and the code in the request satisfies those conditions. ?At this point
    I'm not sure how to do that outside of manually verifying the person.
    2) Similarly, we'll need a way of marking a package as CLA-certified, if
    applicable. ?I know Kris has something that is marking certain packages at
    packages.dojofoundation.org that way but I'm not sure what it is. ?Kris?
    3) For now, I'm sticking with a "dx-[project]" naming convention. ?This is
    not to say that it would be required, but it seems to be working pretty well
    for me at this point.

    I'd like to get the ball rolling with these conversions as part of the 1.8
    development process, so that we can start finding/discovering any potential
    issues that we might run across (hence the reason I'm starting this now and
    announcing it). ?Does anyone have any objections, thoughts, etc.?

    Cheers--
    Tom

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Tom Trenka at Dec 20, 2011 at 11:52 am
    These are good questions, and why I'm starting this dialogue now (at least
    in time for tomorrow's meeting)...

    As far as packages that are currently in DojoX, I think they will remain
    (in their current form) in DojoX for at least a 1.8 release. However, I'd
    suggest that active development take place in your repo of choice, and that
    shifting things into DojoX at this point is probably not a great idea--but
    if it has to be done, it should be done in the few weeks leading up to a
    beta, as opposed to trying to actively develop in two places. I would also
    assume that for now, this decision is up to the developer.

    I also think we're going to need to add deprecated messages (or something
    to that effect) stating that the project will no longer be developed under
    the DojoX namespace, possibly with a link to where it *is* being actively
    worked on.

    Inline otherwise.

    For the naming as there is a d(ojo)grid why not keeping that and
    having the dcollections, dgauges etc..?
    I had started with just "collections" and then "dcollections", and frankly
    I didn't like the name. "dx-collections" seems a little better to me (for
    my purposes), because it implies the dojox aspect of the project name.
    dgrid was never intended to be a DojoX project (AFAIK), and so the naming
    for that was easier.

    I am not proposing that we stick to this naming convention; I'm just
    suggesting it for anyone to use. The actual name of the repo is really up
    to the owner of the project.

    The main problem I foresee with that move is related to Dojo
    infrastructure. For issue management, ok we can imagine using github
    issues for each project that shouldn't be too bad (even if I must
    admit I still prefer trac). But what about documentation both API and
    reference? One of the great advantage of Dojo is to give a single
    entry point for the users and if each package documentation is managed
    and hosted differently we will lost them. I think we should define for
    all these projects a way to have their API & reference documentation
    hosted by Dojo and I don't think there is anything in that area yet?
    The same issue applies to build system. How to make sure one can
    easily build his application with distributed package?
    We've stated before that the choice of repo location et al is really up to
    what CPM is capable of pulling, and what the owner prefers. However, I
    think issue tracking will be much more manageable for smaller projects
    (such as what mostly lives in DojoX); in addition, since each
    project/package ends up being owned by someone, the number of committers
    with direct access to the code is much more limited than it is with the
    "free-for-all" that our current SVN repo allows for. I think we'll come to
    appreciate the granularity and community feel that Github offers.

    As far as DTK itself goes, we're going to need a plan going forward as to
    what a distribution actually entails, and base documentation hosted at
    dtk.org based on that plan. My thought on this was that creating a version
    of DTK 2.0+ will eventually become more of a collection process of select
    packages and bundling them together more than anything else; at that point,
    the actual "DTK" entity becomes more of a marketing decision than a
    behemoth rendering off a single SVN repo. I'd expect that Dojo (base and
    core), Dijit and select current DojoX projects (such as gfx, charting and
    grid) would be included in a distribution/release, and most of the other
    "projects" currently in DojoX would be spun off with directions (at DTK) on
    where to grab it, how to install it, or download it directly from
    dtk.org--in the manner of http://packages.dojofoundation.org/ . This
    speaks to Ben's question, and why I'm suggesting that we start developing
    outside of the SVN repo in preparation for this move.

    Hope that helps explain things?

    Cheers--
    Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111220/c3399509/attachment.htm
  • Tom Trenka at Dec 20, 2011 at 12:14 pm
    An addendum to the last email...

    I think that inevitably, questions will begin to come up such as "yeah, but
    what about Dojo Mobile? What about Dojo Application? These are important
    to the marketability and promotion of the Dojo Toolkit, but you're
    proposing to spin them off and not place them in an eventual DTK 2.0
    distribution??? What are you, mad?"...

    (OK, I'm making the last part up a little but not much.)

    WRT to projects such as these, I think we're going to need to be heavily
    promoting both CPM and any package download tool to be placed at
    dtk.orgfor a 2.0 release. The fact of the matter is that (if anyone
    has tried out
    CPM with a package that defines dependencies) we *should* have the ability
    to make using projects like these as painless as possible, with the
    dependency management that CPM is working towards. In other words, let me
    give you an example.

    -----
    Use case:
    I am Joe Developer, working out of Jakarta, and I've been tasked with
    creating a mobile application using Dojo Mobile. How do I get set up with
    that?

    Answer:
    I find a main page on dtk.org talking about Dojo Mobile (note that I am not
    assuming that I have any of the Dojo Toolkit downloaded and installed at
    this point). Said page says "You want to create your application using
    Dojo Mobile? Click here."

    I click. I get something that is focused on Dojo Mobile without mentioning
    any dependencies. I follow the instructions to grab Dojo Mobile using CPM,
    which would probably look something like:
    cpm install dmobile master
    CPM reads the package.json file included with the dmobile package, and
    automatically downloads and installs any dependencies--and checks to see if
    said dependencies are up to date. In the end, I have three directories
    chock full of code in my project: the dmobile package, the dojo package,
    and the dijit package.
  • Christophe Jolif at Dec 20, 2011 at 12:31 pm
    Tom,

    Thanks for the quick answer. See below.

    2011/12/20 Tom Trenka <ttrenka at gmail.com>:
    I am not proposing that we stick to this naming convention; I'm just
    suggesting it for anyone to use. ?The actual name of the repo is really up
    to the owner of the project.
    The main problem I foresee with that move is related to Dojo
    infrastructure. For issue management, ok we can imagine using github
    issues for each project that shouldn't be too bad (even if I must
    admit I still prefer trac). But what about documentation both API and
    reference? One of the great advantage of Dojo is to give a single
    entry point for the users and if each package documentation is managed
    and hosted differently we will lost them. I think we should define for
    all these projects a way to have their API & reference documentation
    hosted by Dojo and I don't think there is anything in that area yet?
    The same issue applies to build system. How to make sure one can
    easily build his application with distributed package?

    We've stated before that the choice of repo location et al is really up to
    what CPM is capable of pulling, and what the owner prefers. ?However, I
    think issue tracking will be much more manageable for smaller projects (such
    as what mostly lives in DojoX); in addition, since each project/package ends
    up being owned by someone, the number of committers with direct access to
    the code is much more limited than it is with the "free-for-all" that our
    current SVN repo allows for. ?I think we'll come to appreciate the
    granularity and community feel that Github offers.

    As far as DTK itself goes, we're going to need a plan going forward as to
    what a distribution actually entails, and base documentation hosted at
    dtk.org based on that plan. ?My thought on this was that creating a version
    of DTK 2.0+ will eventually become more of a collection process of select
    packages and bundling them together more than anything else; at that point,
    the actual "DTK" entity becomes more of a marketing decision than a behemoth
    rendering off a single SVN repo. ?I'd expect that Dojo (base and core),
    Dijit and select current DojoX projects (such as gfx, charting and grid)
    would be included in a distribution/release, and most of the other
    "projects" currently in DojoX would be spun off with directions (at DTK) on
    where to grab it, how to install it, or download it directly from
    dtk.org--in the manner of http://packages.dojofoundation.org/ . ?This speaks
    to Ben's question, and why I'm suggesting that we start developing outside
    of the SVN repo in preparation for this move.

    Hope that helps explain things?
    Yes more or less. I think we should keep in mind merging the approved
    projects will come to a cost (like merging documentations etc..) if we
    want to provide something that has a bit more added value than just
    "stamping" the various projects. Also from a developer point of view,
    I realize that each project will have to do his own nightly builds,
    host his own documentation while these tasks used be shared across the
    projects and that might be quite costly to implement on each
    individual project.... This must not be forgotten...

    --
    Christophe
  • Tom Trenka at Dec 20, 2011 at 12:37 pm
    Keep them coming Christophe. All of what you are talking about are exactly
    the kinds of questions that I think need to be asked.

    -- Tom

    P.S. Personally speaking, I don't find nightly builds to be nearly as
    useful as one might expect; certainly that's a bonus for a developer who is
    constantly concerned about the effects of what a build might do to the
    state of current code, but I've found (for the most part) that maintaining
    code against a nightly build tends to be a waste of time--since is a build
    is really a mechanism for delivery and not something really facilitates the
    process of development.

    I've always felt that you develop against the raw code as opposed to
    something that is supposed to help optimize the final product, you end up
    with a better app. But that's my personal opinion and not one normally
    shared...
    On Tue, Dec 20, 2011 at 11:31 AM, Christophe Jolif wrote:

    Tom,

    Thanks for the quick answer. See below.

    2011/12/20 Tom Trenka <ttrenka at gmail.com>:
    I am not proposing that we stick to this naming convention; I'm just
    suggesting it for anyone to use. The actual name of the repo is really up
    to the owner of the project.
    The main problem I foresee with that move is related to Dojo
    infrastructure. For issue management, ok we can imagine using github
    issues for each project that shouldn't be too bad (even if I must
    admit I still prefer trac). But what about documentation both API and
    reference? One of the great advantage of Dojo is to give a single
    entry point for the users and if each package documentation is managed
    and hosted differently we will lost them. I think we should define for
    all these projects a way to have their API & reference documentation
    hosted by Dojo and I don't think there is anything in that area yet?
    The same issue applies to build system. How to make sure one can
    easily build his application with distributed package?

    We've stated before that the choice of repo location et al is really up to
    what CPM is capable of pulling, and what the owner prefers. However, I
    think issue tracking will be much more manageable for smaller projects (such
    as what mostly lives in DojoX); in addition, since each project/package ends
    up being owned by someone, the number of committers with direct access to
    the code is much more limited than it is with the "free-for-all" that our
    current SVN repo allows for. I think we'll come to appreciate the
    granularity and community feel that Github offers.

    As far as DTK itself goes, we're going to need a plan going forward as to
    what a distribution actually entails, and base documentation hosted at
    dtk.org based on that plan. My thought on this was that creating a version
    of DTK 2.0+ will eventually become more of a collection process of select
    packages and bundling them together more than anything else; at that point,
    the actual "DTK" entity becomes more of a marketing decision than a behemoth
    rendering off a single SVN repo. I'd expect that Dojo (base and core),
    Dijit and select current DojoX projects (such as gfx, charting and grid)
    would be included in a distribution/release, and most of the other
    "projects" currently in DojoX would be spun off with directions (at DTK) on
    where to grab it, how to install it, or download it directly from
    dtk.org--in the manner of http://packages.dojofoundation.org/ . This speaks
    to Ben's question, and why I'm suggesting that we start developing outside
    of the SVN repo in preparation for this move.

    Hope that helps explain things?
    Yes more or less. I think we should keep in mind merging the approved
    projects will come to a cost (like merging documentations etc..) if we
    want to provide something that has a bit more added value than just
    "stamping" the various projects. Also from a developer point of view,
    I realize that each project will have to do his own nightly builds,
    host his own documentation while these tasks used be shared across the
    projects and that might be quite costly to implement on each
    individual project.... This must not be forgotten...

    --
    Christophe
    _______________________________________________
    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/20111220/5f8b7455/attachment.htm
  • Dylan Schiemann at Dec 20, 2011 at 12:39 pm
    Let's step back and look at our goals:

    * Streamlined modules and source code
    * More active contributors and experts maintaining their modules
    * Easy to assemble, build, use, deploy (including to CDNs), optimize
    * Coherent, consistent, well-documented APIs
    * Clean IP
    * Independent release cycles
    * Tested, polished code
    * Easy to market

    Please add the goals I'm forgetting and missing.

    The proposal to just start putting stuff into github is probably the
    wrong approach until we sort out the details of how we name things and
    pull them all back together.

    I believe we're going to need many things:

    * CI testing framework to pull in all commits and test unit, functional,
    and performance tests
    * Guidelines for API and documentation best practices

    Basically, put together an excellent explanation for how to create our
    Dojo modules, answer the lengthy list of FAQ that's likely to come up,
    and then do it.

    We'll also need to handle determining what the official github master is
    for each module, and if someone falls off the face of the earth,
    determining which fork wins. Alternatively, "official" dojo modules
    could live inside a Dojo project with project committers having access
    (or whatever other mechanism is made easiest by github).

    Can we put together a list of questions and answers somewhere and work
    through the points? I'm sure most of this will get lost in the mailing
    list otherwise.

    Regards,
    - -Dylan

    on 12/20/11 10:31 AM (GMT-07:00) Christophe Jolif said the following:
    Tom,

    Thanks for the quick answer. See below.

    2011/12/20 Tom Trenka <ttrenka at gmail.com>:
    I am not proposing that we stick to this naming convention; I'm just
    suggesting it for anyone to use. The actual name of the repo is really up
    to the owner of the project.
    The main problem I foresee with that move is related to Dojo
    infrastructure. For issue management, ok we can imagine using github
    issues for each project that shouldn't be too bad (even if I must
    admit I still prefer trac). But what about documentation both API and
    reference? One of the great advantage of Dojo is to give a single
    entry point for the users and if each package documentation is managed
    and hosted differently we will lost them. I think we should define for
    all these projects a way to have their API & reference documentation
    hosted by Dojo and I don't think there is anything in that area yet?
    The same issue applies to build system. How to make sure one can
    easily build his application with distributed package?
    We've stated before that the choice of repo location et al is really up to
    what CPM is capable of pulling, and what the owner prefers. However, I
    think issue tracking will be much more manageable for smaller projects (such
    as what mostly lives in DojoX); in addition, since each project/package ends
    up being owned by someone, the number of committers with direct access to
    the code is much more limited than it is with the "free-for-all" that our
    current SVN repo allows for. I think we'll come to appreciate the
    granularity and community feel that Github offers.

    As far as DTK itself goes, we're going to need a plan going forward as to
    what a distribution actually entails, and base documentation hosted at
    dtk.org based on that plan. My thought on this was that creating a version
    of DTK 2.0+ will eventually become more of a collection process of select
    packages and bundling them together more than anything else; at that point,
    the actual "DTK" entity becomes more of a marketing decision than a behemoth
    rendering off a single SVN repo. I'd expect that Dojo (base and core),
    Dijit and select current DojoX projects (such as gfx, charting and grid)
    would be included in a distribution/release, and most of the other
    "projects" currently in DojoX would be spun off with directions (at DTK) on
    where to grab it, how to install it, or download it directly from
    dtk.org--in the manner of http://packages.dojofoundation.org/ . This speaks
    to Ben's question, and why I'm suggesting that we start developing outside
    of the SVN repo in preparation for this move.

    Hope that helps explain things?
    Yes more or less. I think we should keep in mind merging the approved
    projects will come to a cost (like merging documentations etc..) if we
    want to provide something that has a bit more added value than just
    "stamping" the various projects. Also from a developer point of view,
    I realize that each project will have to do his own nightly builds,
    host his own documentation while these tasks used be shared across the
    projects and that might be quite costly to implement on each
    individual project.... This must not be forgotten...
  • Adam L. Peller at Dec 20, 2011 at 2:48 pm

    On Tue, Dec 20, 2011 at 12:39 PM, Dylan Schiemann wrote:

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

    Let's step back and look at our goals:

    * Streamlined modules and source code
    * More active contributors and experts maintaining their modules
    * Easy to assemble, build, use, deploy (including to CDNs), optimize
    * Coherent, consistent, well-documented APIs
    * Clean IP
    * Independent release cycles
    * Tested, polished code
    * Easy to market

    Please add the goals I'm forgetting and missing.
    Some of the goals I'd like to see are scalability -- making our development
    process, and our releases, more manageable -- and to encourage more
    participation. One way to achieve this is to spin off these projects and
    make them more independent. API consistency within a project is one thing,
    but trying to keep every Dojo project ever developed, even those blessed by
    the foundation, using the same style rules is not something I see as a
    goal. I'm not sure to what degree this would apply to testing mechanisms
    or even documentation, though Tom's suggestion that we have some subset of
    these projects act as a distribution, similar to the old DojoX, could
    enforce Foundation practices on a limited scale.

    -Adam
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111220/331cf0ee/attachment.htm
  • Tom Trenka at Dec 20, 2011 at 3:43 pm

    I'm not sure to what degree this would apply to testing mechanisms or even
    documentation, though Tom's suggestion that we have some subset of these
    projects act as a distribution, similar to the old DojoX, could enforce
    Foundation practices on a limited scale.

    Maybe it'd help if I expanded on this just a little...Dojo Toolkit releases
    will always be determined by a smaller group than the overall contributors
    (although the contributors have the strongest say in it). But this smaller
    group (which has been somewhat ad hoc to date) is perfectly capable of
    saying something like "this is what is REQUIRED, in our minds, for
    something to be called the Dojo Toolkit". It would be up to this group to
    pick out a package/set of packages and say "we want to distribute this, but
    you need to do X to keep it up to the same standards as the base packages".

    I think that's pretty good motivation to make sure that things like API
    docs, tests et al are up to snuff. Think of it as the stick holding the
    carrot, if you will.

    -- Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111220/d599616b/attachment.htm
  • Adam L. Peller at Dec 20, 2011 at 4:46 pm
    I'm not sure we'd even publish a single entity called the Dojo Toolkit
    anymore. There might be ad hoc distributions, official or unofficial, and
    even that could change over time. A distribution would really just be a
    shortcut for using the CPM tool anyway.

    2011/12/20 Tom Trenka <ttrenka at gmail.com>
    I'm not sure to what degree this would apply to testing mechanisms or even
    documentation, though Tom's suggestion that we have some subset of these
    projects act as a distribution, similar to the old DojoX, could enforce
    Foundation practices on a limited scale.

    Maybe it'd help if I expanded on this just a little...Dojo Toolkit
    releases will always be determined by a smaller group than the overall
    contributors (although the contributors have the strongest say in it). But
    this smaller group (which has been somewhat ad hoc to date) is perfectly
    capable of saying something like "this is what is REQUIRED, in our minds,
    for something to be called the Dojo Toolkit". It would be up to this group
    to pick out a package/set of packages and say "we want to distribute this,
    but you need to do X to keep it up to the same standards as the base
    packages".

    I think that's pretty good motivation to make sure that things like API
    docs, tests et al are up to snuff. Think of it as the stick holding the
    carrot, if you will.

    -- Tom

    _______________________________________________
    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/20111220/4864c8f8/attachment.htm
  • Adam L. Peller at Dec 20, 2011 at 5:08 pm
    Too radical? Perhaps. To try to clarify my last statement, I don't think
    the goal is to build a single tarball or coordinate a single distribution
    and call it the Dojo Toolkit. We could/should mark projects that say "this
    is supported by the dojo foundation" (perhaps the same thing as saying this
    is part of the Dojo Toolkit) but that's just metadata and represents a
    support statement rather than a distribution path or development process.
    On Tue, Dec 20, 2011 at 4:46 PM, Adam L. Peller wrote:

    I'm not sure we'd even publish a single entity called the Dojo Toolkit
    anymore. There might be ad hoc distributions, official or unofficial, and
    even that could change over time. A distribution would really just be a
    shortcut for using the CPM tool anyway.

    2011/12/20 Tom Trenka <ttrenka at gmail.com>
    I'm not sure to what degree this would apply to testing mechanisms or
    even documentation, though Tom's suggestion that we have some subset of
    these projects act as a distribution, similar to the old DojoX, could
    enforce Foundation practices on a limited scale.

    Maybe it'd help if I expanded on this just a little...Dojo Toolkit
    releases will always be determined by a smaller group than the overall
    contributors (although the contributors have the strongest say in it). But
    this smaller group (which has been somewhat ad hoc to date) is perfectly
    capable of saying something like "this is what is REQUIRED, in our minds,
    for something to be called the Dojo Toolkit". It would be up to this group
    to pick out a package/set of packages and say "we want to distribute this,
    but you need to do X to keep it up to the same standards as the base
    packages".

    I think that's pretty good motivation to make sure that things like API
    docs, tests et al are up to snuff. Think of it as the stick holding the
    carrot, if you will.

    -- Tom

    _______________________________________________
    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/20111220/c04ec380/attachment-0001.htm
  • Dylan Schiemann at Dec 20, 2011 at 6:02 pm
    Too radical, yes.

    Think of it as Linux/Unix vs. Mac. Yes, Mac OS X builds upon a bunch of
    modules, and advanced users can update/revise those modules as they see
    fit. But they don't impose that on all of their users.

    So we build the right core, but we should still have coherent releases
    where a reasonable set of functionality is tested, documented, and
    deployed together. It's one of the main things that long-time Dojo users
    like about Dojo.

    Or perhaps another analogy would be building blocks to duplos to legos
    to model kits to a science lab. AMD is somewhere on the level of lego
    users or model kit users.

    Regards,
    - -Dylan

    on 12/20/11 3:08 PM (GMT-07:00) Adam L. Peller said the following:
    Too radical? Perhaps. To try to clarify my last statement, I don't
    think the goal is to build a single tarball or coordinate a single
    distribution and call it the Dojo Toolkit. We could/should mark
    projects that say "this is supported by the dojo foundation" (perhaps
    the same thing as saying this is part of the Dojo Toolkit) but that's
    just metadata and represents a support statement rather than a
    distribution path or development process.

    On Tue, Dec 20, 2011 at 4:46 PM, Adam L. Peller <adam at peller.org
    wrote:

    I'm not sure we'd even publish a single entity called the Dojo
    Toolkit anymore. There might be ad hoc distributions, official or
    unofficial, and even that could change over time. A distribution
    would really just be a shortcut for using the CPM tool anyway.

    2011/12/20 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I'm not sure to what degree this would apply to testing
    mechanisms or even documentation, though Tom's suggestion
    that we have some subset of these projects act as a
    distribution, similar to the old DojoX, could enforce
    Foundation practices on a limited scale.


    Maybe it'd help if I expanded on this just a little...Dojo
    Toolkit releases will always be determined by a smaller group
    than the overall contributors (although the contributors have
    the strongest say in it). But this smaller group (which has
    been somewhat ad hoc to date) is perfectly capable of saying
    something like "this is what is REQUIRED, in our minds, for
    something to be called the Dojo Toolkit". It would be up to
    this group to pick out a package/set of packages and say "we
    want to distribute this, but you need to do X to keep it up to
    the same standards as the base packages".

    I think that's pretty good motivation to make sure that things
    like API docs, tests et al are up to snuff. Think of it as the
    stick holding the carrot, if you will.

    -- Tom

    _______________________________________________
    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
  • Adam L. Peller at Dec 20, 2011 at 10:33 pm
    And for your analogy, I think the current dojo.* space makes a lot of sense
    to bundle into a Dojo Toolkit OS X, complete with testing and consistent
    APIs. Bill may argue that Dijit does as well. But most (all?) dojox
    projects don't belong in that bucket, in my opinion. Doing so will stifle
    growth and continue to be out of balance with our release cycle and limited
    management capabilities.

    -Adam
    On Tue, Dec 20, 2011 at 6:02 PM, Dylan Schiemann wrote:

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

    Too radical, yes.

    Think of it as Linux/Unix vs. Mac. Yes, Mac OS X builds upon a bunch of
    modules, and advanced users can update/revise those modules as they see
    fit. But they don't impose that on all of their users.

    So we build the right core, but we should still have coherent releases
    where a reasonable set of functionality is tested, documented, and
    deployed together. It's one of the main things that long-time Dojo users
    like about Dojo.

    Or perhaps another analogy would be building blocks to duplos to legos
    to model kits to a science lab. AMD is somewhere on the level of lego
    users or model kit users.

    Regards,
    - -Dylan

    on 12/20/11 3:08 PM (GMT-07:00) Adam L. Peller said the following:
    Too radical? Perhaps. To try to clarify my last statement, I don't
    think the goal is to build a single tarball or coordinate a single
    distribution and call it the Dojo Toolkit. We could/should mark
    projects that say "this is supported by the dojo foundation" (perhaps
    the same thing as saying this is part of the Dojo Toolkit) but that's
    just metadata and represents a support statement rather than a
    distribution path or development process.

    On Tue, Dec 20, 2011 at 4:46 PM, Adam L. Peller <adam at peller.org
    wrote:

    I'm not sure we'd even publish a single entity called the Dojo
    Toolkit anymore. There might be ad hoc distributions, official or
    unofficial, and even that could change over time. A distribution
    would really just be a shortcut for using the CPM tool anyway.

    2011/12/20 Tom Trenka <ttrenka at gmail.com <mailto:ttrenka at gmail.com>>

    I'm not sure to what degree this would apply to testing
    mechanisms or even documentation, though Tom's suggestion
    that we have some subset of these projects act as a
    distribution, similar to the old DojoX, could enforce
    Foundation practices on a limited scale.


    Maybe it'd help if I expanded on this just a little...Dojo
    Toolkit releases will always be determined by a smaller group
    than the overall contributors (although the contributors have
    the strongest say in it). But this smaller group (which has
    been somewhat ad hoc to date) is perfectly capable of saying
    something like "this is what is REQUIRED, in our minds, for
    something to be called the Dojo Toolkit". It would be up to
    this group to pick out a package/set of packages and say "we
    want to distribute this, but you need to do X to keep it up to
    the same standards as the base packages".

    I think that's pretty good motivation to make sure that things
    like API docs, tests et al are up to snuff. Think of it as the
    stick holding the carrot, if you will.

    -- Tom

    _______________________________________________
    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/

    iEYEARECAAYFAk7xFAEACgkQ1E2HcBNypM4glgCgnjJ2tXbN69BGq5tNV1Ig2SPz
    DxsAoJLjivzeIwBdn9f1hNg9LRdcqRIg
    =vwaq
    -----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/20111220/66b06450/attachment.htm
  • Tom Trenka at Dec 21, 2011 at 10:26 am

    So we build the right core, but we should still have coherent releases
    where a reasonable set of functionality is tested, documented, and
    deployed together. It's one of the main things that long-time Dojo users
    like about Dojo.

    Or perhaps another analogy would be building blocks to duplos to legos
    to model kits to a science lab. AMD is somewhere on the level of lego
    users or model kit users.
    Following up on this...if AMD modules are the legos, then releases of the
    Dojo Toolkit are the lego kits you can buy at the store to build, say, a
    Millennium Falcon. And at the same time we allow people to put together
    their own lego kits.

    To me, that's #WINNING right there =)

    -- Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111221/bed4915b/attachment.htm
  • Bill Keese at Dec 20, 2011 at 6:55 pm
    I have the same qualms that Dylan mentioned, but if you are going to move
    DojoX projects to github, the two things I ask are:

    1) Don't make two copies of every dojox project. In other words, move the
    code to github rather than copying it and leaving a deprecation warning in
    the SVN version.

    2) Don't lose the revision history of each project


    Why? Because many DojoX projects may seem stable, but they are still
    going to need many revisions before the 2.0 release, if for nothing else
    than to match the 2.0 changes in Dojo core (ex: changing all references to
    dojo/_base/... to dojo/???, converting dojo.connect() to dojo.on(), ...).

    For those that don't know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that exists in
    github but is still available through the Dojo distribution. It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets (
    http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals link.

    All the DojoX code is already in github, at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a new
    https://github.com/ttrenka/dx-collections project, clone from
    https://github.com/dojo/dojox/tree/master/collections, and then do the
    svn:external thing like dojox.app ?

    As a side note, when it comes time to make 2.0, we should be branching the
    code, not creating a new copy. Some projects are more stable than
    others, but there will be concurrent development between 1.x and 2.0, and
    branches make that much easier, especially according to the git fanboys.


    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    Hi all,

    I recently started trying to come up with an approach for converting some
    DojoX projects to true anonymous AMD packages, installable with CPM, and
    I'd like to propose the following:

    1) If you are a DojoX project owner, create new repositories at Github for
    just the project you own;
    2) Convert said project to true anonymous AMD; in other words, no
    dojo.setObject, no setting of global (though namespaced) variables, etc.
    3) Include the basic format as found at
    https://github.com/kriszyp/commonjs-package-template including README.md,
    doc and test directories.
    4) If you co-own a project, invite anyone to your repo as a collaborator
    (you can find the options under Admin in your repo).
    5) Use github's Issues for bug tracking on it.

    (Anything else?)

    I've begun this process with dojox.collections; you can find the initial
    repo at https://github.com/ttrenka/dx-collections (note that I have not
    done any docs or tests yet.) Eventually I will contacting Kris about
    getting the package registered and working with CPM, but this is a start.
    Since I own a number of very stable DojoX projects, I will be slowly
    porting other projects over in the next month or so, which anyone can use
    as a guide/template for doing their own thing.

    A few notes as I'm working through this:
    1) Any pull requests I receive for any of these projects will have to have
    some way of verifying that the person issuing the pull request has signed a
    CLA and the code in the request satisfies those conditions. At this point
    I'm not sure how to do that outside of manually verifying the person.
    2) Similarly, we'll need a way of marking a package as CLA-certified, if
    applicable. I know Kris has something that is marking certain packages at
    packages.dojofoundation.org that way but I'm not sure what it is. Kris?
    3) For now, I'm sticking with a "dx-[project]" naming convention. This is
    not to say that it would be required, but it seems to be working pretty
    well for me at this point.

    I'd like to get the ball rolling with these conversions as part of the 1.8
    development process, so that we can start finding/discovering any potential
    issues that we might run across (hence the reason I'm starting this now and
    announcing it). Does anyone have any objections, thoughts, etc.?

    Cheers--
    Tom

    _______________________________________________
    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/20111221/bb62bd14/attachment.htm
  • Adam L. Peller at Dec 20, 2011 at 10:29 pm
    That all sounds great. The svn:externals link sounds like an excellent
    migration path between our kitchen sink-style 1.x releases and the new
    github/packages world. However, I'd like to make sure that there's a
    proper way to access the new projects that we actively promote going
    forward, rather than rely on the "deprecated" mechanism of going through
    our 1.x repository and tarballs. There should be a packages repository
    centrally located on our new site that makes it easy not just to find
    dojox_application, but also its documentation and tickets (which may or may
    not reside on *.dojotoolkit.org)

    -Adam

    2011/12/20 Bill Keese <bill at dojotoolkit.org>
    I have the same qualms that Dylan mentioned, but if you are going to move
    DojoX projects to github, the two things I ask are:

    1) Don't make two copies of every dojox project. In other words, move
    the code to github rather than copying it and leaving a deprecation warning
    in the SVN version.

    2) Don't lose the revision history of each project


    Why? Because many DojoX projects may seem stable, but they are still
    going to need many revisions before the 2.0 release, if for nothing else
    than to match the 2.0 changes in Dojo core (ex: changing all references to
    dojo/_base/... to dojo/???, converting dojo.connect() to dojo.on(), ...).

    For those that don't know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that exists in
    github but is still available through the Dojo distribution. It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets (
    http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals link.

    All the DojoX code is already in github, at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a new
    https://github.com/ttrenka/dx-collections project, clone from
    https://github.com/dojo/dojox/tree/master/collections, and then do the
    svn:external thing like dojox.app ?

    As a side note, when it comes time to make 2.0, we should be branching the
    code, not creating a new copy. Some projects are more stable than
    others, but there will be concurrent development between 1.x and 2.0, and
    branches make that much easier, especially according to the git fanboys.


    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    Hi all,

    I recently started trying to come up with an approach for converting some
    DojoX projects to true anonymous AMD packages, installable with CPM, and
    I'd like to propose the following:

    1) If you are a DojoX project owner, create new repositories at Github
    for just the project you own;
    2) Convert said project to true anonymous AMD; in other words, no
    dojo.setObject, no setting of global (though namespaced) variables, etc.
    3) Include the basic format as found at
    https://github.com/kriszyp/commonjs-package-template including
    README.md, doc and test directories.
    4) If you co-own a project, invite anyone to your repo as a collaborator
    (you can find the options under Admin in your repo).
    5) Use github's Issues for bug tracking on it.

    (Anything else?)

    I've begun this process with dojox.collections; you can find the initial
    repo at https://github.com/ttrenka/dx-collections (note that I have not
    done any docs or tests yet.) Eventually I will contacting Kris about
    getting the package registered and working with CPM, but this is a start.
    Since I own a number of very stable DojoX projects, I will be slowly
    porting other projects over in the next month or so, which anyone can use
    as a guide/template for doing their own thing.

    A few notes as I'm working through this:
    1) Any pull requests I receive for any of these projects will have to
    have some way of verifying that the person issuing the pull request has
    signed a CLA and the code in the request satisfies those conditions. At
    this point I'm not sure how to do that outside of manually verifying the
    person.
    2) Similarly, we'll need a way of marking a package as CLA-certified, if
    applicable. I know Kris has something that is marking certain packages at
    packages.dojofoundation.org that way but I'm not sure what it is. Kris?
    3) For now, I'm sticking with a "dx-[project]" naming convention. This
    is not to say that it would be required, but it seems to be working pretty
    well for me at this point.

    I'd like to get the ball rolling with these conversions as part of the
    1.8 development process, so that we can start finding/discovering any
    potential issues that we might run across (hence the reason I'm starting
    this now and announcing it). Does anyone have any objections, thoughts,
    etc.?

    Cheers--
    Tom

    _______________________________________________
    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/20111220/a7187dc0/attachment-0001.htm
  • Christophe Jolif at Dec 21, 2011 at 3:44 am
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't know,?https://github.com/dmachi/dojox_application?is
    our first example of a "DojoX project" (whatever that means) that exists in
    github but is still available through the Dojo distribution. ? ?It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals link.

    All the DojoX code is already in github, at?https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new?https://github.com/ttrenka/dx-collections?project, clone
    from??https://github.com/dojo/dojox/tree/master/collections, and then do the
    svn:external thing like dojox.app??
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe
  • Christophe Jolif at Dec 21, 2011 at 3:55 am
    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.
    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't know,?https://github.com/dmachi/dojox_application?is
    our first example of a "DojoX project" (whatever that means) that exists in
    github but is still available through the Dojo distribution. ? ?It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals link.

    All the DojoX code is already in github, at?https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new?https://github.com/ttrenka/dx-collections?project, clone
    from??https://github.com/dojo/dojox/tree/master/collections, and then do the
    svn:external thing like dojox.app??
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


    --
    Christophe
  • Bill Keese at Dec 21, 2011 at 4:00 am
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than
    a frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code on
    that dojox_application 1.7 branch, which is still wrong.

    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif wrote:

    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.
    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals
    link.
    All the DojoX code is already in github, at
    https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


    --
    Christophe
    _______________________________________________
    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/20111221/825b1a63/attachment-0001.htm
  • Christophe Jolif at Dec 21, 2011 at 4:16 am
    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder),?checking out?tags/release-1.7.0 will return the latest code on that
    dojox_application 1.7 branch, which is still wrong.

    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif wrote:

    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). ?Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know,?https://github.com/dmachi/dojox_application?is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. ? ?It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals
    link.

    All the DojoX code is already in github,
    at?https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new?https://github.com/ttrenka/dx-collections?project, clone
    from??https://github.com/dojo/dojox/tree/master/collections, and then
    do the
    svn:external thing like dojox.app??
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


    --
    Christophe
    _______________________________________________
    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
  • Bill Keese at Dec 21, 2011 at 5:12 am
    Interesting. OK, well tag support would certainly be nice, although as a
    workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.

    My secret plan is actually that we should switch everything over to using
    github for 1.8, including dojo and dijit, and thus (theoretically) avoid
    issues like this. Not because I'm a git fan, but just because we are
    moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif wrote:

    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code on that
    dojox_application 1.7 branch, which is still wrong.

    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif wrote:

    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It
    has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and
    then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


    --
    Christophe
    _______________________________________________
    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/20111221/9d09afcc/attachment.htm
  • Tom Trenka at Dec 21, 2011 at 9:45 am
    I don't have any problems with the overall idea of trying to duplicate the
    approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.

    As far as moving Dojo and Dijit over to git, I guess that's really up to
    you guys; I don't see the need for it for 1.8, but perhaps that's something
    that should be on the roadmap for 1.9 for sure? Might be easier to let us
    work out the git kinks with DojoX first...

    Cheers--
    Tom

    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although as a
    workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.

    My secret plan is actually that we should switch everything over to using
    github for 1.8, including dojo and dijit, and thus (theoretically) avoid
    issues like this. Not because I'm a git fan, but just because we are
    moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif wrote:

    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code on that
    dojox_application 1.7 branch, which is still wrong.


    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It
    has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and
    then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will
    be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make
    sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure
    that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111221/1acd31b7/attachment-0001.htm
  • Tom Trenka at Dec 21, 2011 at 9:47 am

    On Wed, Dec 21, 2011 at 8:45 AM, Tom Trenka wrote:

    I don't have any problems with the overall idea of trying to duplicate the
    approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.

    Sorry, should have explained: by "process" I mean not only the migration
    from SVN to git, but also how we're expected to tag things, branch them,
    etc. in preparation for future releases (assuming that they are still tied
    to the 1.x line of releases).

    Cheers--
    Tom
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111221/6f3b8acc/attachment.htm
  • Bill Keese at Dec 22, 2011 at 12:40 am
    I'm also a git n00b but I did some research and unfortunately it doesn't
    look practical to clone one directory out of a git repository (i.e.
    https://github.com/dojo/dojox) into a new (top-level) repository (ex: (i.e.
    https://github.com/dojo/collections). Note that dojox.app was easy
    because it was a new project, so there was no legacy SVN code to worry
    about.

    Does anyone know who is in charge of the github mirrors of dojo, dijit, and
    dojox? One approach would be to mirror each of the DojoX packages, or at
    least the DojoX packages of interest, into separate git repositories.
    That would be a stepping stone to move the packages (history intact) to a
    writable github repository, or we could even skip that step and just
    register the mirrored packages in packages.dojotoolkit.org.


    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    I don't have any problems with the overall idea of trying to duplicate the
    approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.

    As far as moving Dojo and Dijit over to git, I guess that's really up to
    you guys; I don't see the need for it for 1.8, but perhaps that's something
    that should be on the roadmap for 1.9 for sure? Might be easier to let us
    work out the git kinks with DojoX first...

    Cheers--
    Tom


    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although as
    a workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.

    My secret plan is actually that we should switch everything over to using
    github for 1.8, including dojo and dijit, and thus (theoretically) avoid
    issues like this. Not because I'm a git fan, but just because we are
    moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif wrote:

    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code on that
    dojox_application 1.7 branch, which is still wrong.


    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It
    has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a
    svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and
    then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application
    master
    both for trunk and 1.7 branch. That means that once the master will
    be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say
    that:
    1/ dojox_application should probably create a 1.7 branch and make
    sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure
    that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111222/6a7f6328/attachment.htm
  • Dustin Machi at Dec 22, 2011 at 1:48 am
    Just as another point of reference I believe https://github.com/kriszyp/commonjs-package-template is kris' template for that which is probably better, simpler, and more up to date than dojox.app frankly (though not already in dojox as an external) Other modules (like dgrid, put-selector, etc) are probably also good examples.

    In terms of retaining history, I'm sure it is possible to transfer that data to its own new repo in git, though it may have to be done via replay (not sure how painful that is, though sourcetree might be able to help ease the complexity of the process somewhat). Alternatively one can create a new repo for a specific dojox module, push code from the entire dojox repo into that new repo (as a remote branch), and then remove everything except the files for the target dojox module. In other words instead of trying to clone just the desired parts, clone the whole thing and remove what you don't want. When completed, that new module will have all of its code by itself and all of its history (though perhaps too much history!).

    Dustin

    On Dec 22, 2011, at 12:40 AM, Bill Keese wrote:

    I'm also a git n00b but I did some research and unfortunately it doesn't look practical to clone one directory out of a git repository (i.e. https://github.com/dojo/dojox) into a new (top-level) repository (ex: (i.e. https://github.com/dojo/collections). Note that dojox.app was easy because it was a new project, so there was no legacy SVN code to worry about.

    Does anyone know who is in charge of the github mirrors of dojo, dijit, and dojox? One approach would be to mirror each of the DojoX packages, or at least the DojoX packages of interest, into separate git repositories. That would be a stepping stone to move the packages (history intact) to a writable github repository, or we could even skip that step and just register the mirrored packages in packages.dojotoolkit.org.


    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    I don't have any problems with the overall idea of trying to duplicate the approach of dojox.app, but as a git n00b (relatively speaking), clear instructions will definitely be needed in order to make sure this migration is consistent across all packages...so I guess when Bill and Christophe (or anyone else, like Dustin) have a process hammered out, is there any way we can get that documented in a place where it's easy to find for contributors? I'd hate to have a number of people kind of fumble around in order to get this going correctly.

    As far as moving Dojo and Dijit over to git, I guess that's really up to you guys; I don't see the need for it for 1.8, but perhaps that's something that should be on the roadmap for 1.9 for sure? Might be easier to let us work out the git kinks with DojoX first...

    Cheers--
    Tom


    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although as a workaround we can just make a (git) branch named 1.7.1 (or 1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static regardless.

    My secret plan is actually that we should switch everything over to using github for 1.8, including dojo and dijit, and thus (theoretically) avoid issues like this. Not because I'm a git fan, but just because we are moving in that direction so we might as well move all the way.


    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif wrote:
    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7 branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code on that
    dojox_application 1.7 branch, which is still wrong.

    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif wrote:

    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application master
    both for trunk and 1.7 branch. That means that once the master will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say that:

    1/ dojox_application should probably create a 1.7 branch and make sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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


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



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


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Dec 22, 2011 at 2:53 am
    Eugene explained some stuff to me. My current understanding is that the
    simplest way is to just import the DojoX directory (ex: dojox/collections)
    from SVN into a new github repository. So the steps to migrate a DojoX
    project from our SVN repository into it's own github repository are:

    1. Create empty repository in github from page
    https://github.com/repositories/new. Call it "collections" for this
    example.

    2. Import SVN DojoX project into local git repository and then push to
    github:

    $ mkdir collections
    $ cd collections
    $ git svn init
    http://svn.dojotoolkit.org/src/dojox/trunk/collections --no-metadata
    $ git config svn.authorsfile dojo.authors.txt
    $ git config pack.compression 9
    $ git svn fetch
    $ git gc
    $ git remote add origin git at github.com:dojo/collections.git
    $ git push origin master


    (I got the dojo.authors.txt file from Eugene, and can send it to
    whoever needs it.)


    -------

    If you are want to erase the code in SVN, and make the github version
    of the code the master version (which I have reservations about
    because of the chaos it will cause in bugs.dojotoolkit.org), then in
    SVN you would:


    3. delete the dojox/collections/ folder

    4. edit the SVN properties of dojox/, modifying svn:external to
    have a new line "collections
    http://svn.github.com/dojo/collections.git"

    5. commit


    Then you tag the code in order to create a zip file. I did:

    $ git tag -a 1.7.1

    $ git push origin 1.7.1

    --------

    If on the other hand we want to keep SVN as the master copy, and have
    github be a read-only mirror, then occasionally you would do this from
    your local collections directory, created in step #2 above.


    $ git svn fetch
    $ git rebase remotes/git-svn
    $ git push origin master


    I thought this would be a cron job, although Eugene said that sometimes it
    has problems so he does it manually.



    I tried all this with https://github.com/wkeese/collections and it worked
    pretty well, except I forgot to setup the mapping from id --> email first.
    Of course I was pushing to wkeese/ rather than dojo/ since it was just an
    experiment.

    On Thu, Dec 22, 2011 at 3:48 PM, Dustin Machi wrote:

    Just as another point of reference I believe
    https://github.com//commonjs-package-template<https://github.com/kriszyp/commonjs-package-template>is kris' template for that which is probably better, simpler, and more up
    to date than dojox.app frankly (though not already in dojox as an external)
    Other modules (like dgrid, put-selector, etc) are probably also good
    examples.
    In terms of retaining history, I'm sure it is possible to transfer that
    data to its own new repo in git, though it may have to be done via replay
    (not sure how painful that is, though sourcetree might be able to help ease
    the complexity of the process somewhat). Alternatively one can create a
    new repo for a specific dojox module, push code from the entire dojox repo
    into that new repo (as a remote branch), and then remove everything except
    the files for the target dojox module. In other words instead of trying to
    clone just the desired parts, clone the whole thing and remove what you
    don't want. When completed, that new module will have all of its code by
    itself and all of its history (though perhaps too much history!).

    Dustin

    On Dec 22, 2011, at 12:40 AM, Bill Keese wrote:

    I'm also a git n00b but I did some research and unfortunately it doesn't
    look practical to clone one directory out of a git repository (i.e.
    https://github.com/dojo/dojox) into a new (top-level) repository (ex:
    (i.e. https://github.com/dojo/collections). Note that dojox.app was
    easy because it was a new project, so there was no legacy SVN code to worry
    about.
    Does anyone know who is in charge of the github mirrors of dojo, dijit,
    and dojox? One approach would be to mirror each of the DojoX packages, or
    at least the DojoX packages of interest, into separate git repositories.
    That would be a stepping stone to move the packages (history intact) to a
    writable github repository, or we could even skip that step and just
    register the mirrored packages in packages.dojotoolkit.org.

    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    I don't have any problems with the overall idea of trying to duplicate
    the approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.
    As far as moving Dojo and Dijit over to git, I guess that's really up to
    you guys; I don't see the need for it for 1.8, but perhaps that's something
    that should be on the roadmap for 1.9 for sure? Might be easier to let us
    work out the git kinks with DojoX first...
    Cheers--
    Tom


    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although as
    a workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.
    My secret plan is actually that we should switch everything over to
    using github for 1.8, including dojo and dijit, and thus (theoretically)
    avoid issues like this. Not because I'm a git fan, but just because we
    are moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif wrote:
    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather
    than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7
    branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code
    on that
    dojox_application 1.7 branch, which is still wrong.

    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif wrote:

    Well I wrote this mail too quickly ;) The dojox_application 1.7 branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution. It
    has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a
    svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and
    then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application
    master
    both for trunk and 1.7 branch. That means that once the master will
    be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say
    that:
    1/ dojox_application should probably create a 1.7 branch and make
    sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure
    that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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


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



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


    _______________________________________________
    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/20111222/3b3a6f62/attachment-0001.htm
  • Tom Trenka at Dec 22, 2011 at 10:27 am
    Thanks for the instructions, Bill and Eugene. I guess at this point we'd
    probably want to decide, most likely on a case-by-case basis, what DojoX
    projects might stay in SVN with a github mirror for the 1.8 release, and
    which ones can make the clean break and go right to github as the master.
    The majority of projects I personally own don't have a ton of bugs
    associated with them, so I think in my case going right to github as a
    master with an SVN external back into DojoX would work out ok. Some
    projects (like charting, for instance) probably need a bit more planning
    and work before it goes out to something like github (as it depends on gfx,
    color and lang at the least), which means those projects will need to be
    moved/ported first.

    Can we get a sense (from DojoX project owners) of what they are thinking
    would be best for their project?

    -- Tom

    2011/12/22 Bill Keese <bill at dojotoolkit.org>
    Eugene explained some stuff to me. My current understanding is that the
    simplest way is to just import the DojoX directory (ex: dojox/collections)
    from SVN into a new github repository. So the steps to migrate a DojoX
    project from our SVN repository into it's own github repository are:

    1. Create empty repository in github from page
    https://github.com/repositories/new. Call it "collections" for this
    example.

    2. Import SVN DojoX project into local git repository and then push to
    github:

    $ mkdir collections
    $ cd collections
    $ git svn init http://svn.dojotoolkit.org/src/dojox/trunk/collections --no-metadata
    $ git config svn.authorsfile dojo.authors.txt
    $ git config pack.compression 9
    $ git svn fetch
    $ git gc
    $ git remote add origin git at github.com:dojo/collections.git
    $ git push origin master


    (I got the dojo.authors.txt file from Eugene, and can send it to whoever needs it.)


    -------

    If you are want to erase the code in SVN, and make the github version of the code the master version (which I have reservations about because of the chaos it will cause in bugs.dojotoolkit.org), then in SVN you would:


    3. delete the dojox/collections/ folder

    4. edit the SVN properties of dojox/, modifying svn:external to have a new line "collections http://svn.github.com/dojo/collections.git"

    5. commit


    Then you tag the code in order to create a zip file. I did:

    $ git tag -a 1.7.1

    $ git push origin 1.7.1

    --------

    If on the other hand we want to keep SVN as the master copy, and have github be a read-only mirror, then occasionally you would do this from your local collections directory, created in step #2 above.


    $ git svn fetch
    $ git rebase remotes/git-svn
    $ git push origin master


    I thought this would be a cron job, although Eugene said that sometimes it
    has problems so he does it manually.



    I tried all this with https://github.com/wkeese/collections and it worked
    pretty well, except I forgot to setup the mapping from id --> email first.
    Of course I was pushing to wkeese/ rather than dojo/ since it was just an
    experiment.

    On Thu, Dec 22, 2011 at 3:48 PM, Dustin Machi wrote:

    Just as another point of reference I believe
    https://github.com//commonjs-package-template<https://github.com/kriszyp/commonjs-package-template>is kris' template for that which is probably better, simpler, and more up
    to date than dojox.app frankly (though not already in dojox as an external)
    Other modules (like dgrid, put-selector, etc) are probably also good
    examples.
    In terms of retaining history, I'm sure it is possible to transfer that
    data to its own new repo in git, though it may have to be done via replay
    (not sure how painful that is, though sourcetree might be able to help ease
    the complexity of the process somewhat). Alternatively one can create a
    new repo for a specific dojox module, push code from the entire dojox repo
    into that new repo (as a remote branch), and then remove everything except
    the files for the target dojox module. In other words instead of trying to
    clone just the desired parts, clone the whole thing and remove what you
    don't want. When completed, that new module will have all of its code by
    itself and all of its history (though perhaps too much history!).

    Dustin

    On Dec 22, 2011, at 12:40 AM, Bill Keese wrote:

    I'm also a git n00b but I did some research and unfortunately it
    doesn't look practical to clone one directory out of a git repository (i.e.
    https://github.com/dojo/dojox) into a new (top-level) repository (ex:
    (i.e. https://github.com/dojo/collections). Note that dojox.app was
    easy because it was a new project, so there was no legacy SVN code to worry
    about.
    Does anyone know who is in charge of the github mirrors of dojo, dijit,
    and dojox? One approach would be to mirror each of the DojoX packages, or
    at least the DojoX packages of interest, into separate git repositories.
    That would be a stepping stone to move the packages (history intact) to a
    writable github repository, or we could even skip that step and just
    register the mirrored packages in packages.dojotoolkit.org.

    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    I don't have any problems with the overall idea of trying to duplicate
    the approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.
    As far as moving Dojo and Dijit over to git, I guess that's really up
    to you guys; I don't see the need for it for 1.8, but perhaps that's
    something that should be on the roadmap for 1.9 for sure? Might be easier
    to let us work out the git kinks with DojoX first...
    Cheers--
    Tom


    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although
    as a workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.
    My secret plan is actually that we should switch everything over to
    using github for 1.8, including dojo and dijit, and thus (theoretically)
    avoid issues like this. Not because I'm a git fan, but just because we
    are moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif <cjolif at gmail.com> wrote:
    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app rather
    than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7
    branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code
    on that
    dojox_application 1.7 branch, which is still wrong.


    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Well I wrote this mail too quickly ;) The dojox_application 1.7
    branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now
    the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution.
    It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a
    svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections, and
    then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application
    master
    both for trunk and 1.7 branch. That means that once the master
    will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say
    that:
    1/ dojox_application should probably create a 1.7 branch and make
    sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure
    that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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


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



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


    _______________________________________________
    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/20111222/e52759b9/attachment-0001.htm
  • Bill Keese at Dec 22, 2011 at 8:52 pm
    Just quickly, if you (or someone) moves a project to github, since we'll
    lose the automated trac check-in tracking, they should manually list each
    new commit into the tickets, for example adding a comment to #14472 like:

    https://github.com/dojo/dojox/commit/b19115039b33682b3859822e8191fc2cbc8d43f3
    : 1/ add a test for #14472 2/ fix AMD of the test. !strict.

    The URL would depend on not only the SHA, but which repository (ex:
    collections, grid, charting) the change was checked into.

    My fear is that people wouldn't do this and then we'll lose the history of
    which changes fixed which tickets. I guess it's not the end of the world,
    but it's a step backwards. The fallback for people needing that info is
    to search github's history for that repository for references to #14472.

    This is until we get something automated set up, which will probably be a
    long time, as it's rather complicated when we have trac pointing to
    multiple repositories. Or alternately until we stopped using trac, but
    that's probably even a longer time.

    PS: my second fear is that this sort-of ties us to github, via the URL.


    2011/12/23 Tom Trenka <ttrenka at gmail.com>
    Thanks for the instructions, Bill and Eugene. I guess at this point we'd
    probably want to decide, most likely on a case-by-case basis, what DojoX
    projects might stay in SVN with a github mirror for the 1.8 release, and
    which ones can make the clean break and go right to github as the master.
    The majority of projects I personally own don't have a ton of bugs
    associated with them, so I think in my case going right to github as a
    master with an SVN external back into DojoX would work out ok. Some
    projects (like charting, for instance) probably need a bit more planning
    and work before it goes out to something like github (as it depends on gfx,
    color and lang at the least), which means those projects will need to be
    moved/ported first.

    Can we get a sense (from DojoX project owners) of what they are thinking
    would be best for their project?

    -- Tom


    2011/12/22 Bill Keese <bill at dojotoolkit.org>
    Eugene explained some stuff to me. My current understanding is that the
    simplest way is to just import the DojoX directory (ex: dojox/collections)
    from SVN into a new github repository. So the steps to migrate a DojoX
    project from our SVN repository into it's own github repository are:

    1. Create empty repository in github from page
    https://github.com/repositories/new. Call it "collections" for this
    example.

    2. Import SVN DojoX project into local git repository and then push to
    github:

    $ mkdir collections
    $ cd collections
    $ git svn init http://svn.dojotoolkit.org/src/dojox/trunk/collections --no-metadata
    $ git config svn.authorsfile dojo.authors.txt
    $ git config pack.compression 9
    $ git svn fetch
    $ git gc
    $ git remote add origin git at github.com:dojo/collections.git
    $ git push origin master


    (I got the dojo.authors.txt file from Eugene, and can send it to whoever needs it.)


    -------

    If you are want to erase the code in SVN, and make the github version of the code the master version (which I have reservations about because of the chaos it will cause in bugs.dojotoolkit.org), then in SVN you would:


    3. delete the dojox/collections/ folder

    4. edit the SVN properties of dojox/, modifying svn:external to have a new line "collections http://svn.github.com/dojo/collections.git"

    5. commit


    Then you tag the code in order to create a zip file. I did:

    $ git tag -a 1.7.1

    $ git push origin 1.7.1

    --------

    If on the other hand we want to keep SVN as the master copy, and have github be a read-only mirror, then occasionally you would do this from your local collections directory, created in step #2 above.


    $ git svn fetch
    $ git rebase remotes/git-svn
    $ git push origin master


    I thought this would be a cron job, although Eugene said that sometimes
    it has problems so he does it manually.



    I tried all this with https://github.com/wkeese/collections and it
    worked pretty well, except I forgot to setup the mapping from id --> email
    first. Of course I was pushing to wkeese/ rather than dojo/ since it was
    just an experiment.

    On Thu, Dec 22, 2011 at 3:48 PM, Dustin Machi wrote:

    Just as another point of reference I believe
    https://github.com//commonjs-package-template<https://github.com/kriszyp/commonjs-package-template>is kris' template for that which is probably better, simpler, and more up
    to date than dojox.app frankly (though not already in dojox as an external)
    Other modules (like dgrid, put-selector, etc) are probably also good
    examples.
    In terms of retaining history, I'm sure it is possible to transfer that
    data to its own new repo in git, though it may have to be done via replay
    (not sure how painful that is, though sourcetree might be able to help ease
    the complexity of the process somewhat). Alternatively one can create a
    new repo for a specific dojox module, push code from the entire dojox repo
    into that new repo (as a remote branch), and then remove everything except
    the files for the target dojox module. In other words instead of trying to
    clone just the desired parts, clone the whole thing and remove what you
    don't want. When completed, that new module will have all of its code by
    itself and all of its history (though perhaps too much history!).

    Dustin

    On Dec 22, 2011, at 12:40 AM, Bill Keese wrote:

    I'm also a git n00b but I did some research and unfortunately it
    doesn't look practical to clone one directory out of a git repository (i.e.
    https://github.com/dojo/dojox) into a new (top-level) repository (ex:
    (i.e. https://github.com/dojo/collections). Note that dojox.app was
    easy because it was a new project, so there was no legacy SVN code to worry
    about.
    Does anyone know who is in charge of the github mirrors of dojo,
    dijit, and dojox? One approach would be to mirror each of the DojoX
    packages, or at least the DojoX packages of interest, into separate git
    repositories. That would be a stepping stone to move the packages
    (history intact) to a writable github repository, or we could even skip
    that step and just register the mirrored packages in
    packages.dojotoolkit.org.

    2011/12/21 Tom Trenka <ttrenka at gmail.com>
    I don't have any problems with the overall idea of trying to duplicate
    the approach of dojox.app, but as a git n00b (relatively speaking), clear
    instructions will definitely be needed in order to make sure this migration
    is consistent across all packages...so I guess when Bill and Christophe (or
    anyone else, like Dustin) have a process hammered out, is there any way we
    can get that documented in a place where it's easy to find for
    contributors? I'd hate to have a number of people kind of fumble around in
    order to get this going correctly.
    As far as moving Dojo and Dijit over to git, I guess that's really up
    to you guys; I don't see the need for it for 1.8, but perhaps that's
    something that should be on the roadmap for 1.9 for sure? Might be easier
    to let us work out the git kinks with DojoX first...
    Cheers--
    Tom


    2011/12/21 Bill Keese <bill at dojotoolkit.org>
    Interesting. OK, well tag support would certainly be nice, although
    as a workaround we can just make a (git) branch named 1.7.1 (or
    1.7.1-pretend-this-is-a-tag) and treat it as a tag. And of course, the
    copy of dojox.app on download.dojotoolkit.org/release-1.7.1 is static
    regardless.
    My secret plan is actually that we should switch everything over to
    using github for 1.8, including dojo and dijit, and thus (theoretically)
    avoid issues like this. Not because I'm a git fan, but just because we
    are moving in that direction so we might as well move all the way.

    On Wed, Dec 21, 2011 at 6:16 PM, Christophe Jolif <cjolif at gmail.com> wrote:
    Bill,

    Well I did some research meanwhile and even pointing to the branch was
    not a given. Ok you can edit the svn:external but you need something
    to point to and until 2 months ago the github SVN support was very
    limited and did not provide access to the branches. Fortunately it has
    been improved since then. See:

    https://github.com/blog/966-improved-subversion-client-support

    However as you can see if the branch support is now here, the tag
    support is not (people asking for it in comments).

    So in my mind svn:external + github svn access does not seem to be
    (yet) a solution we can trust and rely on. I will however update
    dojox.app to point to the branch as it is better than point to the
    master... And I don't think there were any fixes done on 1.7 branch so
    we don't _yet_ care about tags for it (but we must be careful and keep
    in mind there is an issue here).

    --
    Christophe

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    I was going to mention tags too, that checking out (for example)
    tags/release-1.7.0 will return the latest version of dojox.app
    rather than a
    frozen version.

    Even if we switch branches/1.7 to point to the dojox_application 1.7
    branch
    (which seems is possible via "edit SVN properties" on the dojox/ SVN
    folder), checking out tags/release-1.7.0 will return the latest code
    on that
    dojox_application 1.7 branch, which is still wrong.


    On Wed, Dec 21, 2011 at 5:55 PM, Christophe Jolif <cjolif at gmail.com>
    wrote:
    Well I wrote this mail too quickly ;) The dojox_application 1.7
    branch
    was created since I had a look at it
    (https://github.com/dmachi/dojox_application/tree/dojo17). So now
    the
    only missing piece would be to make sure dojox.app svn:external for
    1.7 point to it (but we will still miss the tags...). Anyone knows
    how to do that? Otherwise I will investigate.

    On Wed, Dec 21, 2011 at 9:44 AM, Christophe Jolif <cjolif at gmail.com
    wrote:
    Hi,

    2011/12/21 Bill Keese <bill at dojotoolkit.org>:
    For those that don't
    know, https://github.com/dmachi/dojox_application is
    our first example of a "DojoX project" (whatever that means) that
    exists in
    github but is still available through the Dojo distribution.
    It has
    documentation (http://livedocs.dojotoolkit.org/dojox/app) and
    tickets
    (http://bugs.dojotoolkit.org/query?component=DojoX+App) in Dojo
    Toolkit's
    infrastructure, and shows up in dojo's SVN thanks to a
    svn:externals
    link.

    All the DojoX code is already in github,
    at https://github.com/dojo/dojox.
    So how about instead of (for example) creating a
    new https://github.com/ttrenka/dx-collections project, clone
    from https://github.com/dojo/dojox/tree/master/collections,
    and then
    do the
    svn:external thing like dojox.app ?
    A note about that and in particular dojox_application. If I'm not
    mistaken the dojox.app svn:external point to dojox_application
    master
    both for trunk and 1.7 branch. That means that once the master
    will be
    updated with 1.8 content, that content will also I think end up in
    being picked up in a possible future 1.7.2 build... That to say
    that:
    1/ dojox_application should probably create a 1.7 branch and make
    sure
    SVN 1.7 branch point to it instead of master
    2/ that we should be cautious with using svn:external and be sure
    that
    project links correctly replicate any branching/tagging we do?

    --
    Christophe


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


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


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



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


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

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20111223/e0c4a9d8/attachment-0001.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedDec 20, '11 at 11:22a
activeDec 22, '11 at 8:52p
posts31
users7
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase