Resolutions from Wednesday's meeting
=============================
Here are the things we decided by majority vote at the weekly meeting yesterday.

IE version
---------------
We'll still support IE6 for the 1.8 release. Change the release
notes to say that some DojoX projects (like the new Calendar planner,
if/when that gets put into the release) don't support it.

Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
although we didn't actually vote on it.

Source control
---------------------

(1) use git repos [instead of SVN]

(2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
charting, mobile, gfx), no mega projects (ex: dojox)

(3) github dojo org (https://github.com/dojo/) account

The github account https://github.com/dojo/ an opt-in area, meaning
that repositories (ex: dijit, charting) can live in this group
account, but they aren't required to. A project could still be part
of the cpm, website, etc. while existing under a different github
account.

Projects in the group dojo account exist as separate repositories.

Projects are accepted under the dojo org account by a vote of
contributors or maybe by foundation board of directors (or
contributors vote and board can veto). ?As written above, the project
owner must want it to be added.

Affiliation prerequisites for a project:
1. requires CLA
2. uses same licensing (as current dojo toolkit)
3. has some % of code coverage with tests (75%? 80%?)
4. has a project manager and support guarantee
5. uses the same docs and testing system
6. valid package.json

Unresolved issues
=============
We should discuss these at next week's meeting.

- Bug database (use one bug database, or separate ones per project,
or half-and-half). I guess we could also discuss splitting/not
splitting documentation, website, etc.
- Tarballs aka releases (going forward, which of the packages get
bundled up as part of the "dojo release", i.e. what today is known as
dojo 1.6, dojo 1.7, etc.)
- 1.8 contents and timing

Note: The line between dojo toolkit and dojo foundation has become
blurry. We could discuss "what is dojotoolkit?" at next week's
meeting.

Search Discussions

  • Ben hockey at Jan 5, 2012 at 11:49 pm
    Thanks for the update. I thought we always vote via email though... or can voting be done at meetings if a quorum is met?

    I'm fine with the outcome but just want to make sure I'm clear about our processes.

    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting yesterday.

    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    1. requires CLA
    2. uses same licensing (as current dojo toolkit)
    3. has some % of code coverage with tests (75%? 80%?)
    4. has a project manager and support guarantee
    5. uses the same docs and testing system
    6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database (use one bug database, or separate ones per project,
    or half-and-half). I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 6, 2012 at 12:03 am
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". (Majority, not unanimous.) It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.
    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey wrote:
    Thanks for the update. ?I thought we always vote via email though... or can voting be done at meetings if a quorum is met?

    I'm fine with the outcome but just want to make sure I'm clear about our processes.

    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting yesterday.

    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. ? Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. ? A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). ?As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    ? 1. requires CLA
    ? 2. uses same licensing (as current dojo toolkit)
    ? 3. has some % of code coverage with tests (75%? 80%?)
    ? 4. has a project manager and support guarantee
    ? 5. uses the same docs and testing system
    ? 6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database ?(use one bug database, or separate ones per project,
    or half-and-half). ? I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. ?We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    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
  • Dylan Schiemann at Jan 6, 2012 at 9:17 am
    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...

    Also, would be worth rethinking how themes and mobile work with Dijit,
    gfx, charts, and dojox widgets, etc. See my notes at
    https://docs.google.com/document/d/1UckrURF1UjnTh01b48fFAeG0X6NSkW-6ZM_ERnaNluI/edit?hl=en_US
    on themes in general.

    on 1/5/12 10:03 PM (GMT-07:00) Bill Keese said the following:
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". (Majority, not unanimous.) It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.
    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey wrote:
    Thanks for the update. I thought we always vote via email though... or can voting be done at meetings if a quorum is met?

    I'm fine with the outcome but just want to make sure I'm clear about our processes.

    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting yesterday.

    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    1. requires CLA
    2. uses same licensing (as current dojo toolkit)
    3. has some % of code coverage with tests (75%? 80%?)
    4. has a project manager and support guarantee
    5. uses the same docs and testing system
    6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database (use one bug database, or separate ones per project,
    or half-and-half). I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    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 Jan 6, 2012 at 9:27 am
    It's a fair question. My instinct is to split off dijit.Editor and combine
    with dojox.Editor as a top level project. As for the other stuff, I'm not
    sure what the advantage would be, but it's worth considering.
    On Friday, January 6, 2012, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...

    Also, would be worth rethinking how themes and mobile work with Dijit,
    gfx, charts, and dojox widgets, etc. See my notes at
    https://docs.google.com/document/d/1UckrURF1UjnTh01b48fFAeG0X6NSkW-6ZM_ERnaNluI/edit?hl=en_US
    on themes in general.

    on 1/5/12 10:03 PM (GMT-07:00) Bill Keese said the following:
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". (Majority, not unanimous.) It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.
    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey wrote:
    Thanks for the update. I thought we always vote via email though... or
    can voting be done at meetings if a quorum is met?
    I'm fine with the outcome but just want to make sure I'm clear about
    our processes.
    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting
    yesterday.
    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    1. requires CLA
    2. uses same licensing (as current dojo toolkit)
    3. has some % of code coverage with tests (75%? 80%?)
    4. has a project manager and support guarantee
    5. uses the same docs and testing system
    6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database (use one bug database, or separate ones per project,
    or half-and-half). I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk8HAokACgkQ1E2HcBNypM6u7QCdGN5KQqmGSt9QRQ4bZ/rydkfH
    9t4AnjCUZS+aBXOkwlY8OIH7EjUif39x
    =tM9Q
    -----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/20120106/e19048df/attachment-0001.htm
  • Christophe Jolif at Jan 6, 2012 at 9:32 am
    Hi,

    I think more than the size of the project the question should be "what
    is the probability than a user in a single application use a majority
    of the components/code of the project". If there is a relatively high
    probability then even if there is a lot of stuff it probably make
    sense to keep them together? If that is not the case we should
    consider what is "exotic" as won't be use in a lot of cases and put
    that other stuff out?

    (I guess that for Dijit it would probably ends up with something like
    what Bill suggested in the email that arrived while I was writing this
    one)
    --
    Christophe
    On Fri, Jan 6, 2012 at 3:17 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...

    Also, would be worth rethinking how themes and mobile work with Dijit,
    gfx, charts, and dojox widgets, etc. See my notes at
    https://docs.google.com/document/d/1UckrURF1UjnTh01b48fFAeG0X6NSkW-6ZM_ERnaNluI/edit?hl=en_US
    on themes in general.

    on 1/5/12 10:03 PM (GMT-07:00) Bill Keese said the following:
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". ? ?(Majority, not unanimous.) ?It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.
    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey wrote:
    Thanks for the update. ?I thought we always vote via email though... or can voting be done at meetings if a quorum is met?

    I'm fine with the outcome but just want to make sure I'm clear about our processes.

    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting yesterday.

    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. ? Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. ? A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). ?As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    ? 1. requires CLA
    ? 2. uses same licensing (as current dojo toolkit)
    ? 3. has some % of code coverage with tests (75%? 80%?)
    ? 4. has a project manager and support guarantee
    ? 5. uses the same docs and testing system
    ? 6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database ?(use one bug database, or separate ones per project,
    or half-and-half). ? I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. ?We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    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
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk8HAokACgkQ1E2HcBNypM6u7QCdGN5KQqmGSt9QRQ4bZ/rydkfH
    9t4AnjCUZS+aBXOkwlY8OIH7EjUif39x
    =tM9Q
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Adam L. Peller at Jan 6, 2012 at 1:01 pm
    I would hope the proposed package infrastructure makes it easy for the user
    to consume code across multiple projects and that usage shouldn't
    necessarily drive how we factor our code. When I think of "no mega
    projects" I'm really thinking of lumping vastly different bodies of code
    together from an organizational standpoint, like dojox/* but also
    dojox/widget/* and even to some extent dojox/editor/plugins. I'm thinking
    the most important factors involve release cycle, project leadership,
    scalability, etc. Dijit is unusual in that it comprises a large and
    largely static set of widgets, which are themed and released together by
    one individual. Extensions (like those in dojox/widget) would be separate
    packages, grouped by these same criteria or packaged individually in some
    cases.

    -Adam
    On Fri, Jan 6, 2012 at 9:32 AM, Christophe Jolif wrote:

    Hi,

    I think more than the size of the project the question should be "what
    is the probability than a user in a single application use a majority
    of the components/code of the project". If there is a relatively high
    probability then even if there is a lot of stuff it probably make
    sense to keep them together? If that is not the case we should
    consider what is "exotic" as won't be use in a lot of cases and put
    that other stuff out?

    (I guess that for Dijit it would probably ends up with something like
    what Bill suggested in the email that arrived while I was writing this
    one)
    --
    Christophe
    On Fri, Jan 6, 2012 at 3:17 PM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...

    Also, would be worth rethinking how themes and mobile work with Dijit,
    gfx, charts, and dojox widgets, etc. See my notes at
    https://docs.google.com/document/d/1UckrURF1UjnTh01b48fFAeG0X6NSkW-6ZM_ERnaNluI/edit?hl=en_US
    on themes in general.

    on 1/5/12 10:03 PM (GMT-07:00) Bill Keese said the following:
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". (Majority, not unanimous.) It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.
    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey wrote:
    Thanks for the update. I thought we always vote via email though...
    or can voting be done at meetings if a quorum is met?
    I'm fine with the outcome but just want to make sure I'm clear about
    our processes.
    --
    ben...
    On Jan 5, 2012, at 23:36, Bill Keese wrote:

    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting
    yesterday.
    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    1. requires CLA
    2. uses same licensing (as current dojo toolkit)
    3. has some % of code coverage with tests (75%? 80%?)
    4. has a project manager and support guarantee
    5. uses the same docs and testing system
    6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database (use one bug database, or separate ones per project,
    or half-and-half). I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    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
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk8HAokACgkQ1E2HcBNypM6u7QCdGN5KQqmGSt9QRQ4bZ/rydkfH
    9t4AnjCUZS+aBXOkwlY8OIH7EjUif39x
    =tM9Q
    -----END PGP SIGNATURE-----
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120106/ab9242fe/attachment-0001.htm
  • Dylan Schiemann at Jan 6, 2012 at 1:10 pm
    My thought process was that there are features that are useful outside
    of Dijit. Some of those have been refactored and moved to dojo. But for
    example, themes are implemented differently in other subprojects
    (charting, mobile, and dgrid come to mind). I don't really like the idea
    of having 4 separate theme implementations when creating an app, for
    example.

    I believe this is caused by several things:
    * the perception that Dijit is large
    * special use cases (vector graphics vs. html)
    * difficulty in getting a limited subset of features

    We also see many Dijits extended in DojoX (calendar, contentpane, etc.).
    Would these be better served as a project for that Dijit, with plugins
    for the things that live in DojoX? I would think that would be an easier
    paradigm to follow in that case.

    Or thinking through effects, we have dojo/fx, dojox/fx, some css3
    effects, some mobile specific effects, etc.

    By removing the concept of dojox, it makes more sense to me for all
    effects systems to live in a common repo, with a small core, and then
    extensions, than the current split between dojo and dojox.

    Regards,
    - -Dylan

    on 1/6/12 11:01 AM (GMT-07:00) Adam L. Peller said the following:
    I would hope the proposed package infrastructure makes it easy for the
    user to consume code across multiple projects and that usage shouldn't
    necessarily drive how we factor our code. When I think of "no mega
    projects" I'm really thinking of lumping vastly different bodies of code
    together from an organizational standpoint, like dojox/* but also
    dojox/widget/* and even to some extent dojox/editor/plugins. I'm
    thinking the most important factors involve release cycle, project
    leadership, scalability, etc. Dijit is unusual in that it comprises a
    large and largely static set of widgets, which are themed and released
    together by one individual. Extensions (like those in dojox/widget)
    would be separate packages, grouped by these same criteria or packaged
    individually in some cases.

    -Adam

    On Fri, Jan 6, 2012 at 9:32 AM, Christophe Jolif <cjolif at gmail.com
    wrote:

    Hi,

    I think more than the size of the project the question should be "what
    is the probability than a user in a single application use a majority
    of the components/code of the project". If there is a relatively high
    probability then even if there is a lot of stuff it probably make
    sense to keep them together? If that is not the case we should
    consider what is "exotic" as won't be use in a lot of cases and put
    that other stuff out?

    (I guess that for Dijit it would probably ends up with something like
    what Bill suggested in the email that arrived while I was writing this
    one)
    --
    Christophe

    On Fri, Jan 6, 2012 at 3:17 PM, Dylan Schiemann
    <dylan at dojotoolkit.org wrote:
    Have we considered splitting Dijit up into subprojects? When we
    say "no
    mega projects", I guess I think of Dijit as a whole as being mega
    today.
    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...

    Also, would be worth rethinking how themes and mobile work with Dijit,
    gfx, charts, and dojox widgets, etc. See my notes at
    on themes in general.

    on 1/5/12 10:03 PM (GMT-07:00) Bill Keese said the following:
    Maybe instead of saying "vote" I should have said that "the majority
    of people agreed to". (Majority, not unanimous.) It's true that
    voting is generally by email, although I'm sure we've made some
    previous decisions in the IRC meetings.

    On Fri, Jan 6, 2012 at 1:49 PM, ben hockey
    <neonstalwart at gmail.com wrote:
    Thanks for the update. I thought we always vote via email
    though... or can voting be done at meetings if a quorum is met?
    I'm fine with the outcome but just want to make sure I'm clear
    about our processes.
    --
    ben...

    On Jan 5, 2012, at 23:36, Bill Keese <bill at dojotoolkit.org
    wrote:
    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly
    meeting yesterday.
    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. Change the release
    notes to say that some DojoX projects (like the new Calendar
    planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. A project could still
    be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). As written above, the
    project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    1. requires CLA
    2. uses same licensing (as current dojo toolkit)
    3. has some % of code coverage with tests (75%? 80%?)
    4. has a project manager and support guarantee
    5. uses the same docs and testing system
    6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database (use one bug database, or separate ones per
    project,
    or half-and-half). I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is
    known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    <mailto:dojo-contributors at mail.dojotoolkit.org>
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Kitson Kelly at Jan 6, 2012 at 1:49 pm
    Well, and widget theming is interesting, it is something that you can spend
    a lot of time on. I know claro took a lot of effort because while it is
    easy to "consume" theming, there is no "registry" for a widget to declare
    what sort of unique CSS classes it needs and what it is borrowing from the
    "core" dijit.

    I could see a world where it would become quickly very difficult for people
    to consume a random widget and expect to even render with a theme in our
    brave new world.

    There is a bit of an argument that says theming should be should
    be separated out and potentially take its own trajectory, but it is so
    basic to any widget that you can't not have it. So I +1 that.

    Personally, I think that the theming sub-system should be responsible for
    loading and managing its own resources, it does seem to be a bit silly for
    me as an end developer to make sure I @import every css as well as ensure I
    load the module. I should be able to say I just need X, you sort out the
    rest.

    But to an earlier point, I guess we need to remember to figure out 1.8
    first!
    On 6 January 2012 18:10, Dylan Schiemann wrote:

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

    My thought process was that there are features that are useful outside
    of Dijit. Some of those have been refactored and moved to dojo. But for
    example, themes are implemented differently in other subprojects
    (charting, mobile, and dgrid come to mind). I don't really like the idea
    of having 4 separate theme implementations when creating an app, for
    example.

    I believe this is caused by several things:
    * the perception that Dijit is large
    * special use cases (vector graphics vs. html)
    * difficulty in getting a limited subset of features

    We also see many Dijits extended in DojoX (calendar, contentpane, etc.).
    Would these be better served as a project for that Dijit, with plugins
    for the things that live in DojoX? I would think that would be an easier
    paradigm to follow in that case.

    Or thinking through effects, we have dojo/fx, dojox/fx, some css3
    effects, some mobile specific effects, etc.

    By removing the concept of dojox, it makes more sense to me for all
    effects systems to live in a common repo, with a small core, and then
    extensions, than the current split between dojo and dojox.

    Regards,
    - -Dylan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120106/732c2df6/attachment.htm
  • Tom Trenka at Jan 6, 2012 at 2:22 pm
    Keep in mind that tools such as CPM rely on being able to grab a tarball of
    some sort and manipulate it; this is what I was trying to remember during
    the Wed meeting and failed miserably at =( In my mind that means that any
    "autonomous" package needs to be available, in some way, as a separate
    download. Part of the reason for looking at Github for repo hosting is to
    take advantage of that kind of download.

    That being said, I think Dylan's got a point here =)

    Cheers--
    Tom
    On Fri, Jan 6, 2012 at 12:10 PM, Dylan Schiemann wrote:

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

    My thought process was that there are features that are useful outside
    of Dijit. Some of those have been refactored and moved to dojo. But for
    example, themes are implemented differently in other subprojects
    (charting, mobile, and dgrid come to mind). I don't really like the idea
    of having 4 separate theme implementations when creating an app, for
    example.

    I believe this is caused by several things:
    * the perception that Dijit is large
    * special use cases (vector graphics vs. html)
    * difficulty in getting a limited subset of features

    We also see many Dijits extended in DojoX (calendar, contentpane, etc.).
    Would these be better served as a project for that Dijit, with plugins
    for the things that live in DojoX? I would think that would be an easier
    paradigm to follow in that case.

    Or thinking through effects, we have dojo/fx, dojox/fx, some css3
    effects, some mobile specific effects, etc.

    By removing the concept of dojox, it makes more sense to me for all
    effects systems to live in a common repo, with a small core, and then
    extensions, than the current split between dojo and dojox.

    Regards,
    - -Dylan
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120106/e23d5e65/attachment.htm
  • Rawld at Jan 6, 2012 at 3:25 pm

    On 01/06/2012 11:22 AM, Tom Trenka wrote:
    Keep in mind that tools such as CPM rely on being able to grab a
    tarball of some sort and manipulate it; this is what I was trying to
    remember during the Wed meeting and failed miserably at =( In my mind
    that means that any "autonomous" package needs to be available, in
    some way, as a separate download. Part of the reason for looking at
    Github for repo hosting is to take advantage of that kind of download.
    Right. And one thing to keep in mind as we talk about mixing and
    matching packages with different release cycles is that you may have an
    app that requires

    package-A depending on package-X, version 1
    package-B depending on package-X, version 2

    The dojo loader can handle that with its relocating feature. I'm not
    sure what may need to be done (if anything) with CPM to make it all work.

    --Rawld
  • Tom Trenka at Jan 6, 2012 at 4:01 pm
    I'm sorry. What I meant was (and someone please correct me if I'm wrong
    about this) GitHub offers a repo download as a zip only when it is a
    top-level directory under an account. In other words, you can grab
    SitePen/dgrid but you can't grab SitePen/dgrid/extensions. CPM kind of
    relies on this ability for installation.

    This is the main reason I was objecting to the idea of using
    https://github.com/dojo as a place for projects to live.

    Someone want to point out that maybe I'm still too much of a github n00b on
    this one?

    -- Tom
    On Fri, Jan 6, 2012 at 2:25 PM, Rawld wrote:
    On 01/06/2012 11:22 AM, Tom Trenka wrote:
    Keep in mind that tools such as CPM rely on being able to grab a
    tarball of some sort and manipulate it; this is what I was trying to
    remember during the Wed meeting and failed miserably at =( In my mind
    that means that any "autonomous" package needs to be available, in
    some way, as a separate download. Part of the reason for looking at
    Github for repo hosting is to take advantage of that kind of download.
    Right. And one thing to keep in mind as we talk about mixing and
    matching packages with different release cycles is that you may have an
    app that requires

    package-A depending on package-X, version 1
    package-B depending on package-X, version 2

    The dojo loader can handle that with its relocating feature. I'm not
    sure what may need to be done (if anything) with CPM to make it all work.

    --Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120106/b199348b/attachment.htm
  • Rawld at Jan 6, 2012 at 4:10 pm

    On 01/06/2012 01:01 PM, Tom Trenka wrote:
    I'm sorry. What I meant was (and someone please correct me if I'm
    wrong about this) GitHub offers a repo download as a zip only when it
    is a top-level directory under an account. In other words, you can
    grab SitePen/dgrid but you can't grab SitePen/dgrid/extensions. CPM
    kind of relies on this ability for installation.

    This is the main reason I was objecting to the idea of using
    https://github.com/dojo as a place for projects to live.

    Someone want to point out that maybe I'm still too much of a github
    n00b on this one?
    SitePen/dgrid is a repo

    SitePen/dgrid/extensions is a directory in a repo


    You can already download several zips from https://github.com/dojo, e.g.,

    https://github.com/dojo/dojo
    https://github.com/dojo/dijit

    Some (including me) were advocating allowing affiliated project *repos*
    to live in the dojo *account* (not the dojo repo).

    --Rawld
  • Kenneth G. Franqueiro at Jan 6, 2012 at 7:53 pm
    Well, keep in mind that github.com/dojo is the *organization*, just as
    github.com/SitePen is. You're not downloading the Dojo organization or
    SitePen, you're downloading e.g. dojo, dijit, or dgrid. (The dojo repo
    is github.com/dojo/dojo.)

    --Ken
    On 1/6/2012 4:01 PM, Tom Trenka wrote:
    I'm sorry. What I meant was (and someone please correct me if I'm wrong
    about this) GitHub offers a repo download as a zip only when it is a
    top-level directory under an account. In other words, you can grab
    SitePen/dgrid but you can't grab SitePen/dgrid/extensions. CPM kind of
    relies on this ability for installation.

    This is the main reason I was objecting to the idea of using
    https://github.com/dojo as a place for projects to live.

    Someone want to point out that maybe I'm still too much of a github n00b
    on this one?

    -- Tom

    On Fri, Jan 6, 2012 at 2:25 PM, Rawld <rgill at altoviso.com
    wrote:
    On 01/06/2012 11:22 AM, Tom Trenka wrote:
    Keep in mind that tools such as CPM rely on being able to grab a
    tarball of some sort and manipulate it; this is what I was trying to
    remember during the Wed meeting and failed miserably at =( In my mind
    that means that any "autonomous" package needs to be available, in
    some way, as a separate download. Part of the reason for looking at
    Github for repo hosting is to take advantage of that kind of download.
    Right. And one thing to keep in mind as we talk about mixing and
    matching packages with different release cycles is that you may have an
    app that requires

    package-A depending on package-X, version 1
    package-B depending on package-X, version 2

    The dojo loader can handle that with its relocating feature. I'm not
    sure what may need to be done (if anything) with CPM to make it all
    work.

    --Rawld

    _______________________________________________
    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
  • Tom Trenka at Jan 7, 2012 at 10:44 am
    Sorry again, I should clarify more, since it will speak directly to the
    organization of repos under the dojo github account.

    Automated zip/tarballs are created at the repo level only. In other words,
    you can get a zip of github/dojo/dojo, but if you were try to get something
    like github/dojo/dojox/charting, you'd be blocked (this is one of the main
    reasons, if not the main reason, why dojox is not offered as a package at
    packages.dojofoundation.org).

    That means that any smaller packages hosted under the Github dojo account
    would have to be full, independent repos; i.e. we'd have to have it be
    https://github.com/dojo/dx-charting (or something similar).

    Let's keep that in mind when talking about whether everything should be
    hosted under the GitHub dojo account or not. I suppose that if we choose
    which projects are "affliated" and want to make it simple(r), we *could*
    simply fork an independent project as dojo, and use that approach to
    determine what gets distributed as DTK?

    Cheers--
    Tom

    On Fri, Jan 6, 2012 at 6:53 PM, Kenneth G. Franqueiro
    wrote:
    Well, keep in mind that github.com/dojo is the *organization*, just as
    github.com/SitePen is. You're not downloading the Dojo organization or
    SitePen, you're downloading e.g. dojo, dijit, or dgrid. (The dojo repo
    is github.com/dojo/dojo.)

    --Ken
    On 1/6/2012 4:01 PM, Tom Trenka wrote:
    I'm sorry. What I meant was (and someone please correct me if I'm wrong
    about this) GitHub offers a repo download as a zip only when it is a
    top-level directory under an account. In other words, you can grab
    SitePen/dgrid but you can't grab SitePen/dgrid/extensions. CPM kind of
    relies on this ability for installation.

    This is the main reason I was objecting to the idea of using
    https://github.com/dojo as a place for projects to live.

    Someone want to point out that maybe I'm still too much of a github n00b
    on this one?

    -- Tom

    On Fri, Jan 6, 2012 at 2:25 PM, Rawld <rgill at altoviso.com
    wrote:
    On 01/06/2012 11:22 AM, Tom Trenka wrote:
    Keep in mind that tools such as CPM rely on being able to grab a
    tarball of some sort and manipulate it; this is what I was trying
    to
    remember during the Wed meeting and failed miserably at =( In my
    mind
    that means that any "autonomous" package needs to be available, in
    some way, as a separate download. Part of the reason for looking
    at
    Github for repo hosting is to take advantage of that kind of
    download.
    Right. And one thing to keep in mind as we talk about mixing and
    matching packages with different release cycles is that you may have an
    app that requires

    package-A depending on package-X, version 1
    package-B depending on package-X, version 2

    The dojo loader can handle that with its relocating feature. I'm not
    sure what may need to be done (if anything) with CPM to make it all
    work.

    --Rawld

    _______________________________________________
    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
    _______________________________________________
    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/20120107/bf37495d/attachment.htm
  • Rawld at Jan 6, 2012 at 3:14 pm

    On 01/06/2012 10:01 AM, Adam L. Peller wrote:
    I would hope the proposed package infrastructure makes it easy for the
    user to consume code across multiple projects and that usage shouldn't
    necessarily drive how we factor our code. When I think of "no mega
    projects" I'm really thinking of lumping vastly different bodies of
    code together from an organizational standpoint, like dojox/* but also
    dojox/widget/* and even to some extent dojox/editor/plugins. I'm
    thinking the most important factors involve release cycle, project
    leadership, scalability, etc. Dijit is unusual in that it comprises a
    large and largely static set of widgets, which are themed and released
    together by one individual. Extensions (like those in dojox/widget)
    would be separate packages, grouped by these same criteria or packaged
    individually in some cases.
    Excellent points.

    I would slightly rephrase and say the "release cycle, project
    leadership, scalability, etc" are as important as feature/API
    commonality (e.g., various effects frameworks as Dylan mentions in his
    next msg).

    --Rawld
  • Rawld at Jan 6, 2012 at 3:21 pm

    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld
  • Revin Guillen at Jan 6, 2012 at 3:32 pm
    I for one would *love* to see Dijit nano-ized into atomic capability-based modules. For those who saw Chris Barber's DojoConf talk (or at least saw his slides) about nano widgets, recall that he made great gains in code size (enormous shrinkage?) by eliminating features he didn't need for his project--even stuff like the ability to disable his widgets when he didn't need it. I haven't thought it through much at all, but if the overhead involved in breaking things up so you could build nano sized groups of Dijit widgets wasn't killer, I could stop reinventing one-off do-very-little widgets and just use the same widget set no matter how big or small the project.

    OK OK, it's probably like wishing for a pony, but I thought I should say it anyway. The first step would probably be organizing into dijit base and widget packages like Rawld mentions, so I thought it relevant.

    -Revin

    On Jan 6, 2012, at Jan 6 | 12:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Bill Keese at Jan 6, 2012 at 11:30 pm
    The "nano-sized" stuff is a more important discussion, but orthogonal
    to packaging. I think we are moving in that direction already, just
    in small steps, but if you have more specific suggestions I'd welcome
    you to discuss them (but preferably on a new thread from this one).

    As for packaging, just because we can split up dijit into multiple
    packages doesn't mean we should. I haven't heard a really good
    reason in favor of splitting it yet. Conversely, if we went as far
    as separate bug databases etc. for different parts of dijit, that
    would probably really annoy users, even more so than splitting apart
    dojo and dijit, or splitting dojox into separate projects.
    On Sat, Jan 7, 2012 at 5:32 AM, Revin Guillen wrote:
    I for one would *love* to see Dijit nano-ized into atomic capability-based modules. For those who saw Chris Barber's DojoConf talk (or at least saw his slides) about nano widgets, recall that he made great gains in code size (enormous shrinkage?) by eliminating features he didn't need for his project--even stuff like the ability to disable his widgets when he didn't need it. I haven't thought it through much at all, but if the overhead involved in breaking things up so you could build nano sized groups of Dijit widgets wasn't killer, I could stop reinventing one-off do-very-little widgets and just use the same widget set no matter how big or small the project.

    OK OK, it's probably like wishing for a pony, but I thought I should say it anyway. The first step would probably be organizing into dijit base and widget packages like Rawld mentions, so I thought it relevant.

    -Revin

    On Jan 6, 2012, at Jan 6 | 12:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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 Jan 9, 2012 at 6:59 am
    BTW, the focus tracking machinery is getting some competition from dojo/on,
    which has bubbling focusin/focusout events (at least according to the
    dojo/on documentation).

    There are quite a few non-widget dijit modules:

    - a11y.js
    - focus.js
    - hccss.js
    - place.js
    - popup.js
    - typematic.js
    - layout/utils.js

    I can see the argument for moving them to dojo core, so they can be easily
    used by apps that don't have widgets

    The counterargument is that I'll likely update those modules along with the
    widgets, so it's easier from a release standpoint if they are in dijit, if
    dijit ever got to the point where it released independently from dojo core.
    On Sat, Jan 7, 2012 at 5:21 AM, Rawld wrote:

    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo?
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120109/331bd3bc/attachment.htm
  • Ben hockey at Jan 9, 2012 at 10:32 am
    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
  • Revin Guillen at Jan 9, 2012 at 11:06 am
    Good question. I've worked on non-Dojo projects where I missed having easy access to the Dojo build and for various reasons (often even political reasons) adding all of Dojo to our source tree was untenable. A separate loader and builder could be easy ways to give people a taste of Dojo without having to seemingly commit to too much. I'd be in favor of it.

    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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 Jan 9, 2012 at 4:27 pm
    Hmm, seems like just a few months ago when the loader/builder were in a
    separate repository, and we checked them into dojo's SVN.

    IIRC the loader code is intermingled with dojo core. It defines some of
    the functions for core (dojo.eval etc.), and also depends on some of the
    core modules (ex: dojo/lang). I forget the specifics.

    On Tue, Jan 10, 2012 at 1:06 AM, Revin Guillen wrote:

    Good question. I've worked on non-Dojo projects where I missed having easy
    access to the Dojo build and for various reasons (often even political
    reasons) adding all of Dojo to our source tree was untenable. A separate
    loader and builder could be easy ways to give people a taste of Dojo
    without having to seemingly commit to too much. I'd be in favor of it.

    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega
    today.
    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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/20120110/603f6cb9/attachment.htm
  • Revin Guillen at Jan 9, 2012 at 4:39 pm
    It's entirely possible I just didn't look closely enough at the time. The general point I was trying to make is that if we can reasonably make any of our tools usable independently, I'll pretty much always be in favor of that approach.

    It's high time I looked at the new loader in more detail. Even if making it usable outside the context of a regular Dojo app means creating a shim for its dependencies (as long as the shim doesn't duplicate too large a percentage of those dependencies), I'd be interested in at least exploring it.

    On Jan 9, 2012, at Jan 9 | 1:27 PM, Bill Keese wrote:

    Hmm, seems like just a few months ago when the loader/builder were in a separate repository, and we checked them into dojo's SVN.

    IIRC the loader code is intermingled with dojo core. It defines some of the functions for core (dojo.eval etc.), and also depends on some of the core modules (ex: dojo/lang). I forget the specifics.


    On Tue, Jan 10, 2012 at 1:06 AM, Revin Guillen wrote:
    Good question. I've worked on non-Dojo projects where I missed having easy access to the Dojo build and for various reasons (often even political reasons) adding all of Dojo to our source tree was untenable. A separate loader and builder could be easy ways to give people a taste of Dojo without having to seemingly commit to too much. I'd be in favor of it.

    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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 Jan 9, 2012 at 4:51 pm
    Hmm, I see your point, but OTOH wasn't one of the purposes of AMD to be
    able to pull in dependencies piecemeal, and not duplicate code? Another
    recent change was to make DOH use some dojo/ modules rather than
    cut-and-pasting the code from dojo. Do you want to roll that back too?
    On Tue, Jan 10, 2012 at 6:39 AM, Revin Guillen wrote:

    It's entirely possible I just didn't look closely enough at the time. The
    general point I was trying to make is that if we can reasonably make any of
    our tools usable independently, I'll pretty much always be in favor of that
    approach.

    It's high time I looked at the new loader in more detail. Even if making
    it usable outside the context of a regular Dojo app means creating a shim
    for its dependencies (as long as the shim doesn't duplicate too large a
    percentage of those dependencies), I'd be interested in at least exploring
    it.

    On Jan 9, 2012, at Jan 9 | 1:27 PM, Bill Keese wrote:

    Hmm, seems like just a few months ago when the loader/builder were in a
    separate repository, and we checked them into dojo's SVN.
    IIRC the loader code is intermingled with dojo core. It defines some
    of the functions for core (dojo.eval etc.), and also depends on some of the
    core modules (ex: dojo/lang). I forget the specifics.

    On Tue, Jan 10, 2012 at 1:06 AM, Revin Guillen wrote:
    Good question. I've worked on non-Dojo projects where I missed having
    easy access to the Dojo build and for various reasons (often even political
    reasons) adding all of Dojo to our source tree was untenable. A separate
    loader and builder could be easy ways to give people a taste of Dojo
    without having to seemingly commit to too much. I'd be in favor of it.
    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say
    "no
    mega projects", I guess I think of Dijit as a whole as being mega
    today.
    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such
    modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as
    somebody
    has thought about it and gives a reason for why things are as they
    are.
    --Rawld

    _______________________________________________
    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/20120110/40ff0f53/attachment.htm
  • Revin Guillen at Jan 9, 2012 at 6:24 pm
    Well, I'm not really suggesting rolling the loader back; my original concerns might be moot now with the AMD implementation. I think if we make it easy enough to download a single archive containing everything needed to use a particular tool, I'd be happy. It's more an issue of perception than anything, to my thinking.

    I hadn't been thinking about DOH, but now that you mention it, I *have* indeed seen a small handful of complaints about that change on Twitter, from developers I respect. Mostly it's philosophical; how can you test something (e.g., Dojo itself) if you're using its own code to test itself? I'm undecided on the issue, but I know it directly caused a few people to go with other test frameworks for their (non-Dojo) projects.

    All in all, using AMD to avoid duplicating code is an obvious win; however, it *has* sort of opened up the topic of marketing vis a vis module naming. People don't have a problem with a tool depending on some support code, but for whatever reason if that support code is in the Dojo core, suddenly the discussion is like, "wait, I have to download all of Dojo for this?" I'd argue that it's exactly the same as some random package living on top of Underscore or jQuery or whatever, but those are seen as "small" and Dojo as "big".

    TL;DR After talking it through, I'm simply inclined to leave everything as is but make sure we have downloads available that include the minimum set of dependencies for a tool, for people who just want that tool by itself.

    -Revin

    On Jan 9, 2012, at Jan 9 | 1:51 PM, Bill Keese wrote:

    Hmm, I see your point, but OTOH wasn't one of the purposes of AMD to be able to pull in dependencies piecemeal, and not duplicate code? Another recent change was to make DOH use some dojo/ modules rather than cut-and-pasting the code from dojo. Do you want to roll that back too?

    On Tue, Jan 10, 2012 at 6:39 AM, Revin Guillen wrote:
    It's entirely possible I just didn't look closely enough at the time. The general point I was trying to make is that if we can reasonably make any of our tools usable independently, I'll pretty much always be in favor of that approach.

    It's high time I looked at the new loader in more detail. Even if making it usable outside the context of a regular Dojo app means creating a shim for its dependencies (as long as the shim doesn't duplicate too large a percentage of those dependencies), I'd be interested in at least exploring it.

    On Jan 9, 2012, at Jan 9 | 1:27 PM, Bill Keese wrote:

    Hmm, seems like just a few months ago when the loader/builder were in a separate repository, and we checked them into dojo's SVN.

    IIRC the loader code is intermingled with dojo core. It defines some of the functions for core (dojo.eval etc.), and also depends on some of the core modules (ex: dojo/lang). I forget the specifics.


    On Tue, Jan 10, 2012 at 1:06 AM, Revin Guillen wrote:
    Good question. I've worked on non-Dojo projects where I missed having easy access to the Dojo build and for various reasons (often even political reasons) adding all of Dojo to our source tree was untenable. A separate loader and builder could be easy ways to give people a taste of Dojo without having to seemingly commit to too much. I'd be in favor of it.

    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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
  • Dylan Schiemann at Jan 9, 2012 at 6:44 pm
    Well, when we pull this off, and people see that Dojo does indeed start
    at less than 4K, and makes it super easy to only use what you need,
    perceptions will change.

    We cannot continue to feel sorry for ourselves or embarrassed by our
    past, we need to fix perceptions and continue down the path we're on. If
    we're constantly worried that someone isn't going to like us, well, we
    might as well just go home, which none of us really plan to do.

    See Steve Jobs, on ignoring Michael Dell's comments in the late 90s.
    Deliver on all fronts (engineering excellence, useful features, simple
    APIs, solid marketing), and we'll continue to see success like we did in
    2011.

    Regards,
    - -Dylan

    on 1/9/12 4:24 PM (GMT-07:00) Revin Guillen said the following:
    Well, I'm not really suggesting rolling the loader back; my original concerns might be moot now with the AMD implementation. I think if we make it easy enough to download a single archive containing everything needed to use a particular tool, I'd be happy. It's more an issue of perception than anything, to my thinking.

    I hadn't been thinking about DOH, but now that you mention it, I *have* indeed seen a small handful of complaints about that change on Twitter, from developers I respect. Mostly it's philosophical; how can you test something (e.g., Dojo itself) if you're using its own code to test itself? I'm undecided on the issue, but I know it directly caused a few people to go with other test frameworks for their (non-Dojo) projects.

    All in all, using AMD to avoid duplicating code is an obvious win; however, it *has* sort of opened up the topic of marketing vis a vis module naming. People don't have a problem with a tool depending on some support code, but for whatever reason if that support code is in the Dojo core, suddenly the discussion is like, "wait, I have to download all of Dojo for this?" I'd argue that it's exactly the same as some random package living on top of Underscore or jQuery or whatever, but those are seen as "small" and Dojo as "big".

    TL;DR After talking it through, I'm simply inclined to leave everything as is but make sure we have downloads available that include the minimum set of dependencies for a tool, for people who just want that tool by itself.

    -Revin

    On Jan 9, 2012, at Jan 9 | 1:51 PM, Bill Keese wrote:

    Hmm, I see your point, but OTOH wasn't one of the purposes of AMD to be able to pull in dependencies piecemeal, and not duplicate code? Another recent change was to make DOH use some dojo/ modules rather than cut-and-pasting the code from dojo. Do you want to roll that back too?

    On Tue, Jan 10, 2012 at 6:39 AM, Revin Guillen wrote:
    It's entirely possible I just didn't look closely enough at the time. The general point I was trying to make is that if we can reasonably make any of our tools usable independently, I'll pretty much always be in favor of that approach.

    It's high time I looked at the new loader in more detail. Even if making it usable outside the context of a regular Dojo app means creating a shim for its dependencies (as long as the shim doesn't duplicate too large a percentage of those dependencies), I'd be interested in at least exploring it.

    On Jan 9, 2012, at Jan 9 | 1:27 PM, Bill Keese wrote:

    Hmm, seems like just a few months ago when the loader/builder were in a separate repository, and we checked them into dojo's SVN.

    IIRC the loader code is intermingled with dojo core. It defines some of the functions for core (dojo.eval etc.), and also depends on some of the core modules (ex: dojo/lang). I forget the specifics.


    On Tue, Jan 10, 2012 at 1:06 AM, Revin Guillen wrote:
    Good question. I've worked on non-Dojo projects where I missed having easy access to the Dojo build and for various reasons (often even political reasons) adding all of Dojo to our source tree was untenable. A separate loader and builder could be easy ways to give people a taste of Dojo without having to seemingly commit to too much. I'd be in favor of it.

    -Revin

    On Jan 9, 2012, at Jan 9 | 7:32 AM, ben hockey wrote:

    along these lines... the loader and build tool are valuable on their
    own. should they be broken out into separate repos (a la bdLoad and
    bdBuild). i'm not sure i'm advocating that we should but does anyone
    have thoughts on it? i think i might like the build tool in its own
    repo, separate from the rest of the bag of utils.

    ben...
    On 1/6/2012 3:21 PM, Rawld wrote:
    On 01/06/2012 06:17 AM, Dylan Schiemann wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Have we considered splitting Dijit up into subprojects? When we say "no
    mega projects", I guess I think of Dijit as a whole as being mega today.

    e.g.
    dijit-core (the underlying framework)
    dijit-form
    dijit-layout
    ...
    Some things like the focus tracking machinery in widget seem quite
    valuable in general (btw Bill, I love that module!). Should such modules
    got to dojo? Should dijit become just dijit base and actual widgets go
    into "widget packages"? Probably any decision is OK as long as somebody
    has thought about it and gives a reason for why things are as they are.

    --Rawld

    _______________________________________________
    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
  • Rawld at Jan 9, 2012 at 11:17 pm

    On 01/09/2012 03:24 PM, Revin Guillen wrote:
    I hadn't been thinking about DOH, but now that you mention it, I *have* indeed seen a small handful of complaints about that change on Twitter, from developers I respect. Mostly it's philosophical; how can you test something (e.g., Dojo itself) if you're using its own code to test itself? I'm undecided on the issue, but I know it directly caused a few people to go with other test frameworks for their (non-Dojo) projects.
    Right. That struck me as odd the first time I saw it many years ago.
    Today, owing to the dojo loader's ability to relocate namespaces, you
    can load a sandbox version of dojo only visible to the DOH code, then
    the load another version of dojo (or, for that matter, many other
    versions) as part of testing. I had this up and working last June.
    However, I confess I haven't played with it recently, so there may be
    some code rot there. But, in theory, the objection is no longer valid.

    That said, this issue is just one of many we would need to address to
    make DOH a first-class product.

    [snip]

    --Rawld
  • Bill Keese at Jan 9, 2012 at 11:41 pm
    Rawld - that's great but it won't mollify people that don't want to
    download dojo just to use DOH.
    On Tue, Jan 10, 2012 at 1:17 PM, Rawld wrote:
    On 01/09/2012 03:24 PM, Revin Guillen wrote:

    I hadn't been thinking about DOH, but now that you mention it, I *have*
    indeed seen a small handful of complaints about that change on Twitter,
    from developers I respect. Mostly it's philosophical; how can you test
    something (e.g., Dojo itself) if you're using its own code to test itself?
    I'm undecided on the issue, but I know it directly caused a few people to
    go with other test frameworks for their (non-Dojo) projects.

    Right. That struck me as odd the first time I saw it many years ago.
    Today, owing to the dojo loader's ability to relocate namespaces, you
    can load a sandbox version of dojo only visible to the DOH code, then
    the load another version of dojo (or, for that matter, many other
    versions) as part of testing. I had this up and working last June.
    However, I confess I haven't played with it recently, so there may be
    some code rot there. But, in theory, the objection is no longer valid.

    That said, this issue is just one of many we would need to address to
    make DOH a first-class product.

    [snip]

    --Rawld
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120110/235c3307/attachment.htm
  • Kitson Kelly at Jan 10, 2012 at 2:49 am
    In the brave new world, is there dojo?
  • Rawld at Jan 9, 2012 at 11:11 pm

    On 01/09/2012 01:39 PM, Revin Guillen wrote:
    Even if making it usable outside the context of a regular Dojo app means creating a shim for its dependencies (as long as the shim doesn't duplicate too large a percentage of those dependencies),
    The dojo loader and build system can be used today, without
    modification, for projects that never load a single dojo module...for
    projects that never utter the variable "dojo".
  • Rawld at Jan 9, 2012 at 11:08 pm

    On 01/09/2012 01:27 PM, Bill Keese wrote:
    Hmm, seems like just a few months ago when the loader/builder were in
    a separate repository, and we checked them into dojo's SVN.
    Right. But those repos weren't part of Dojo (they were part of
    backdraft, made to work with dojo). I think it would have been untenable
    to say, "here's 1.7, but if you want to use it, mosey over to Altoviso
    and grab the backdraft loader" (much as I would have loved that!).
    IIRC the loader code is intermingled with dojo core. It defines some
    of the functions for core (dojo.eval etc.), and also depends on some
    of the core modules (ex: dojo/lang). I forget the specifics.
    The *AMD loader* part of the loader is carefully designed to be
    *un*entangled with dojo core...in fact, anything dojo. You can set a few
    has switches, run a build, and have a loader that doesn't even mention dojo.

    The dojo bootstrap and backcompat synchronous loading is a whole other
    ball of worms that does depend on dojo; but that's OK since the boot and
    synchronous loader are dojo APIs.

    --Rawld

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120109/c880be42/attachment.htm
  • Ben hockey at Jan 9, 2012 at 11:17 pm


    The dojo bootstrap and backcompat synchronous loading is a whole other ball of worms that does depend on dojo; but that's OK since the boot and synchronous loader are dojo APIs.
    ...which can be removed in 2.0. right?

    Without too much pain couldn't we have a loader that even in source form does not define or depend on dojo if we wanted to? The synchronous loader can obviously go but I guess the bootstrap depends on getting rid of the globals - which I think we've (almost?) figured out we can do. Is there anything else that might prevent decoupling the loader in 2.0 even if it's still in the "dojo/dojo" repo?

    ben...
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120109/b8f8d073/attachment-0001.htm
  • Rawld at Jan 9, 2012 at 11:22 pm

    On 01/09/2012 08:17 PM, ben hockey wrote:


    The dojo bootstrap and backcompat synchronous loading is a whole
    other ball of worms that does depend on dojo; but that's OK since the
    boot and synchronous loader are dojo APIs.
    ...which can be removed in 2.0. right?

    Without too much pain couldn't we have a loader that even in source
    form does not define or depend on dojo if we wanted to? The
    synchronous loader can obviously go but I guess the bootstrap depends
    on getting rid of the globals - which I think we've (almost?) figured
    out we can do. Is there anything else that might prevent decoupling
    the loader in 2.0 even if it's still in the "dojo/dojo" repo?
    Yes, in fact, dojo/dojo.js (the core loader), is self contained and
    doesn't need any other modules, as long as you don't load any backcompat
    stuff. It has cruft needed for backcompat loading that can be cut out
    with has.js...either at runtime or build time.

    --Rawld


    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120109/94ee9067/attachment.htm
  • Christophe Jolif at Jan 6, 2012 at 9:48 am
    Thanks. I have updated the 1.8 document to reflect this. For (1) I
    supposed you meant "github" not just "git". But let me know if my
    supposition was wrong.

    Side note:

    I understand how easy it is to determine if a project as a project
    manager, I have more trouble understanding how we will check if there
    is a "support guarantee". At least we should make clear how we will
    "check" that.
    On Fri, Jan 6, 2012 at 5:36 AM, Bill Keese wrote:
    Resolutions from Wednesday's meeting
    =============================
    Here are the things we decided by majority vote at the weekly meeting yesterday.

    IE version
    ---------------
    We'll still support IE6 for the 1.8 release. ? Change the release
    notes to say that some DojoX projects (like the new Calendar planner,
    if/when that gets put into the release) don't support it.

    Everyone seemed to be in favor of dropping IE6 and IE7 for 2.0
    although we didn't actually vote on it.

    Source control
    ---------------------

    (1) use git repos [instead of SVN]

    (2) divide [dojo toolkit] into projects (ex: dojo-core, dijit,
    charting, mobile, gfx), no mega projects (ex: dojox)

    (3) github dojo org (https://github.com/dojo/) account

    The github account https://github.com/dojo/ an opt-in area, meaning
    that repositories (ex: dijit, charting) can live in this group
    account, but they aren't required to. ? A project could still be part
    of the cpm, website, etc. while existing under a different github
    account.

    Projects in the group dojo account exist as separate repositories.

    Projects are accepted under the dojo org account by a vote of
    contributors or maybe by foundation board of directors (or
    contributors vote and board can veto). ?As written above, the project
    owner must want it to be added.

    Affiliation prerequisites for a project:
    ? 1. requires CLA
    ? 2. uses same licensing (as current dojo toolkit)
    ? 3. has some % of code coverage with tests (75%? 80%?)
    ? 4. has a project manager and support guarantee
    ? 5. uses the same docs and testing system
    ? 6. valid package.json

    Unresolved issues
    =============
    We should discuss these at next week's meeting.

    - Bug database ?(use one bug database, or separate ones per project,
    or half-and-half). ? I guess we could also discuss splitting/not
    splitting documentation, website, etc.
    - Tarballs aka releases (going forward, which of the packages get
    bundled up as part of the "dojo release", i.e. what today is known as
    dojo 1.6, dojo 1.7, etc.)
    - 1.8 contents and timing

    Note: The line between dojo toolkit and dojo foundation has become
    blurry. ?We could discuss "what is dojotoolkit?" at next week's
    meeting.
    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors


    --
    Christophe

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedJan 5, '12 at 11:36p
activeJan 10, '12 at 2:49a
posts35
users10
websitedojotoolkit.org

People

Translate

site design / logo © 2022 Grokbase