Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
1. Develop is cumbersome because it is taking place within Matt's fork, meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
2. Experience has shown that the only way to identify all the bugs is by actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
3. There is still a good amount of documentation, testing, polishing, etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
*I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark.* I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing, etc
before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing, etc
before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 On Mar 12, 2014 7:39 AM, "John ZuHone" jzuhone@gmail.com wrote:
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com
wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way
to an
official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all
fields
and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a
"parameter
file", an "indexer" instead of a "hierarchy", etc.) and attempt to
de-astro
the infrastructure as we start to think about working with other
sciences.
The unitrefactor also contains some rebranding efforts in the form of
field
renaming (e.g., "Density" becoming "density"), so these changes are
somewhat
linked.
What we need to figure out is the process by which these changes are
merged
into the yt-3.0 branch of the main repo (yt_analysis). In my opinion,
the
primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to
that.
This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means
is we
need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people,
having
to pull changes in from an external repo and perform various mercurial
magic
just to test changes is a bridge to far. We need to lower the barrier
to
entry.
- There is still a good amount of documentation, testing, polishing,
etc
before this can be called stable. Even though yt-3.0 is still
officially
Under Development, a number of people are using it to do actual things
and
so it is unreasonable to just land this on them without full
documentation
and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the
main
repository in an "experimental" bookmark. I think this will a)
streamline
development and make it more visible to everyone, b) lower the barrier
to
trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of
yt-3.0. I
also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards:
https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1
The documentation has also come a long way since this topic was last discussed on the list.
On Wednesday, March 12, 2014, Sam Skillman samskillman@gmail.com wrote:
+1 On Mar 12, 2014 7:39 AM, "John ZuHone" jzuhone@gmail.com wrote:
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com
wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way
to an
official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all
fields
and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a
"parameter
file", an "indexer" instead of a "hierarchy", etc.) and attempt to
de-astro
the infrastructure as we start to think about working with other
sciences.
The unitrefactor also contains some rebranding efforts in the form of
field
renaming (e.g., "Density" becoming "density"), so these changes are
somewhat
linked.
What we need to figure out is the process by which these changes are
merged
into the yt-3.0 branch of the main repo (yt_analysis). In my opinion,
the
primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to
that.
This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means
is we
need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people,
having
to pull changes in from an external repo and perform various mercurial
magic
just to test changes is a bridge to far. We need to lower the barrier
to
entry.
- There is still a good amount of documentation, testing, polishing,
etc
before this can be called stable. Even though yt-3.0 is still
officially
Under Development, a number of people are using it to do actual things
and
so it is unreasonable to just land this on them without full
documentation
and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the
main
repository in an "experimental" bookmark. I think this will a)
streamline
development and make it more visible to everyone, b) lower the barrier
to
trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of
yt-3.0. I
also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards:
https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Mar 12, 2014 at 12:56 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
+1
The documentation has also come a long way since this topic was last discussed on the list.
I agree, and I think it's nearing the "mergable" state. Not releasable, but mergable.
On Wednesday, March 12, 2014, Sam Skillman samskillman@gmail.com wrote:
+1
On Mar 12, 2014 7:39 AM, "John ZuHone" jzuhone@gmail.com wrote:
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is
by actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Okay, seems like we have broad consensus, but I want to wait a day or two before doing anything to ensure all sides are heard from.
But, one last outstanding question: can we merge the rebranding PR in to the unitrefactor work?
https://bitbucket.org/MatthewTurk/yt/pull-request/85/rebranding
On Wed, Mar 12, 2014 at 12:58 PM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 12:56 PM, Nathan Goldbaum nathan12343@gmail.com wrote:
+1
The documentation has also come a long way since this topic was last discussed on the list.
I agree, and I think it's nearing the "mergable" state. Not releasable, but mergable.
On Wednesday, March 12, 2014, Sam Skillman samskillman@gmail.com wrote:
+1
On Mar 12, 2014 7:39 AM, "John ZuHone" jzuhone@gmail.com wrote:
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith brittonsmith@gmail.com wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is
by actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Did you fix the issue I reported about iterating over time series? If so, I think it's good to go in. I've been using it for day-to-day stuff all week and have noticed no issues.
If there are issues present having more people using the code will certainly shake them out more quickly.
On Wed, Mar 12, 2014 at 1:32 PM, Matthew Turk matthewturk@gmail.com wrote:
Okay, seems like we have broad consensus, but I want to wait a day or two before doing anything to ensure all sides are heard from.
But, one last outstanding question: can we merge the rebranding PR in to the unitrefactor work?
https://bitbucket.org/MatthewTurk/yt/pull-request/85/rebranding
On Wed, Mar 12, 2014 at 12:58 PM, Matthew Turk matthewturk@gmail.com wrote:
On Wed, Mar 12, 2014 at 12:56 PM, Nathan Goldbaum nathan12343@gmail.com
wrote:
+1
The documentation has also come a long way since this topic was last discussed on the list.
I agree, and I think it's nearing the "mergable" state. Not releasable, but mergable.
On Wednesday, March 12, 2014, Sam Skillman samskillman@gmail.com
wrote:
+1
On Mar 12, 2014 7:39 AM, "John ZuHone" jzuhone@gmail.com wrote:
+1
On Mar 12, 2014, at 9:11 AM, Matthew Turk matthewturk@gmail.com
wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Britton Smith <
brittonsmith@gmail.com>
wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our
way
to an official release. These are the unitrefactor and the rebranding.
The
unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form
of
field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my
opinion,
the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's
fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because
most
people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs
is
by actually attempting to use the code to do Real Stuff. What this
means
is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various
mercurial
magic just to test changes is a bridge to far. We need to lower the
barrier
to entry.
- There is still a good amount of documentation, testing,
polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual
things
and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into
the
main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the
barrier
to trying it out for people so we can actually get everything tested
and
working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms
of
getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and
for
yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
+1, for all of these reasons.
I'm really keen to get things merged in, but nervous -- for the reasons you note.
-Matt
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1
While in general, I would advocate that PRs only be accepted when they include sufficient documentation, in this case, it sounds fair to merge into the main 3.0 repo with the bookmark, as it will be a lot less cumbersome to test and document things before removing the bookmark and going gold.
Good work, everyone!
Cameron
On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith brittonsmith@gmail.comwrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing, etc
before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
*I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark.* I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1
On Wed, Mar 12, 2014 at 6:08 PM, Cameron Hummels chummels@gmail.com wrote:
+1
While in general, I would advocate that PRs only be accepted when they include sufficient documentation, in this case, it sounds fair to merge into the main 3.0 repo with the bookmark, as it will be a lot less cumbersome to test and document things before removing the bookmark and going gold.
Good work, everyone!
Cameron
On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith brittonsmith@gmail.comwrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing, etc
before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
*I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark.* I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Great, I think this has the requisite support. Matt, would you care to do the honors of pushing both the rebranding and unitrefactor PRs to this new "experimental" bookmark in yt_analysis?
Britton
On Thu, Mar 13, 2014 at 12:22 AM, Anthony Scopatz scopatz@gmail.com wrote:
+1
On Wed, Mar 12, 2014 at 6:08 PM, Cameron Hummels chummels@gmail.comwrote:
+1
While in general, I would advocate that PRs only be accepted when they include sufficient documentation, in this case, it sounds fair to merge into the main 3.0 repo with the bookmark, as it will be a lot less cumbersome to test and document things before removing the bookmark and going gold.
Good work, everyone!
Cameron
On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith brittonsmith@gmail.comwrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
*I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark.* I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton,
Okay, done.
There are now three bookmarks that will get updated in the main yt_analysis/yt repository.
development: this is the yt-3.0 branch that does not include unitrefactor experimental: this is the yt-3.0 branch that does include unitrefactor and rebranding @: this is yt-2.x
stable branch is still the stable release. The differences between @ and stable are quite minimal right now. I've also tagged a yt-3.0a4 which is pre-unitrefactor/rebranding.
Also, this was 1130 changesets.
-Matt
On Thu, Mar 13, 2014 at 9:13 AM, Britton Smith brittonsmith@gmail.com wrote:
Great, I think this has the requisite support. Matt, would you care to do the honors of pushing both the rebranding and unitrefactor PRs to this new "experimental" bookmark in yt_analysis?
Britton
On Thu, Mar 13, 2014 at 12:22 AM, Anthony Scopatz scopatz@gmail.com wrote:
+1
On Wed, Mar 12, 2014 at 6:08 PM, Cameron Hummels chummels@gmail.com wrote:
+1
While in general, I would advocate that PRs only be accepted when they include sufficient documentation, in this case, it sounds fair to merge into the main 3.0 repo with the bookmark, as it will be a lot less cumbersome to test and document things before removing the bookmark and going gold.
Good work, everyone!
Cameron
On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith brittonsmith@gmail.com wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the rebranding. The unitrefactor adds symbolically expressed, convertible units to all fields and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a "parameter file", an "indexer" instead of a "hierarchy", etc.) and attempt to de-astro the infrastructure as we start to think about working with other sciences. The unitrefactor also contains some rebranding efforts in the form of field renaming (e.g., "Density" becoming "density"), so these changes are somewhat linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's fork,
meaning that all contributors have to fork his fork and issue PRs to that. This is annoying because one has to maintain two forks and because most people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is by
actually attempting to use the code to do Real Stuff. What this means is we need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people, having to pull changes in from an external repo and perform various mercurial magic just to test changes is a bridge to far. We need to lower the barrier to entry.
- There is still a good amount of documentation, testing, polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do actual things and so it is unreasonable to just land this on them without full documentation and with such a high likelihood that it will break things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower the barrier to trying it out for people so we can actually get everything tested and working, and c) not disrupt the workflow of the current users of yt-3.0. I also think this is the quickest way of satisfying everyone in terms of getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards: https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt,
Perfect, thanks for the summary of the state of things as well.
1130 changeset?! Yowza!
Britton
On Thu, Mar 13, 2014 at 1:55 PM, Matthew Turk matthewturk@gmail.com wrote:
Hi Britton,
Okay, done.
There are now three bookmarks that will get updated in the main yt_analysis/yt repository.
development: this is the yt-3.0 branch that does not include unitrefactor experimental: this is the yt-3.0 branch that does include unitrefactor and rebranding @: this is yt-2.x
stable branch is still the stable release. The differences between @ and stable are quite minimal right now. I've also tagged a yt-3.0a4 which is pre-unitrefactor/rebranding.
Also, this was 1130 changesets.
-Matt
On Thu, Mar 13, 2014 at 9:13 AM, Britton Smith brittonsmith@gmail.com wrote:
Great, I think this has the requisite support. Matt, would you care to
do
the honors of pushing both the rebranding and unitrefactor PRs to this
new
"experimental" bookmark in yt_analysis?
Britton
On Thu, Mar 13, 2014 at 12:22 AM, Anthony Scopatz scopatz@gmail.com
wrote:
+1
On Wed, Mar 12, 2014 at 6:08 PM, Cameron Hummels chummels@gmail.com wrote:
+1
While in general, I would advocate that PRs only be accepted when they include sufficient documentation, in this case, it sounds fair to
merge into
the main 3.0 repo with the bookmark, as it will be a lot less
cumbersome to
test and document things before removing the bookmark and going gold.
Good work, everyone!
Cameron
On Wed, Mar 12, 2014 at 6:05 AM, Britton Smith <brittonsmith@gmail.com
wrote:
Hi all,
There are two major changes coming soon for yt-3.0 as we march our way to an official release. These are the unitrefactor and the
rebranding. The
unitrefactor adds symbolically expressed, convertible units to all
fields
and scalars in yt. The rebranding is a rethinking of some of yt's conceptual entities (such as thinking of a "dataset" instead of a
"parameter
file", an "indexer" instead of a "hierarchy", etc.) and attempt to
de-astro
the infrastructure as we start to think about working with other
sciences.
The unitrefactor also contains some rebranding efforts in the form of
field
renaming (e.g., "Density" becoming "density"), so these changes are
somewhat
linked.
What we need to figure out is the process by which these changes are merged into the yt-3.0 branch of the main repo (yt_analysis). In my opinion, the primary issues are the following:
- Develop is cumbersome because it is taking place within Matt's
fork,
meaning that all contributors have to fork his fork and issue PRs to
that.
This is annoying because one has to maintain two forks and because
most
people aren't getting notified of PRs issued to Matt's fork.
- Experience has shown that the only way to identify all the bugs is
by
actually attempting to use the code to do Real Stuff. What this
means is we
need all the frontends represented and people putting the various functionality and analysis modules to use. I think for most people,
having
to pull changes in from an external repo and perform various
mercurial magic
just to test changes is a bridge to far. We need to lower the
barrier to
entry.
- There is still a good amount of documentation, testing, polishing,
etc before this can be called stable. Even though yt-3.0 is still officially Under Development, a number of people are using it to do
actual
things and so it is unreasonable to just land this on them without
full
documentation and with such a high likelihood that it will break
things.
I propose that the unitrefactor and rebranding work be pulled into the main repository in an "experimental" bookmark. I think this will a) streamline development and make it more visible to everyone, b) lower
the
barrier to trying it out for people so we can actually get everything
tested
and working, and c) not disrupt the workflow of the current users of
yt-3.0.
I also think this is the quickest way of satisfying everyone in terms
of
getting all of the necessary documentation written as it makes the development significantly more open and accessible.
For more info on what needs to be done on both of these fronts and for yt-3.0 in general, see the trello boards:
https://trello.com/yt_analysis
Can we get a +/-1 on this?
Britton
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-
Anthony Scopatz -
Britton Smith -
Cameron Hummels -
John ZuHone -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman