Releases, pull requests, "governance" ...
Hi all, There's been some discussion on the Enzo mailing list: https://groups.google.com/forum/#!topic/enzo-users/vtlCedbJILU about the stable/dev branch of yt. The takeaway is that bugs get fixed in the dev branch, but since our releases are much less frequent than that, they don't necessarily get propagated very rapidly to stable -- in large part because we also weave lots of new development in and out. Enzo deals with this by doing all development in forks, mandating pull requests, and being careful about which items to merge and when. It's not clear to me that we could implement that model, even if we wanted to. We've had recent success with developing in forks, issuing pull requests and the like, but there's no codified set of "when to develop in a fork" guidelines or anything like that. There've been some rumblings of "governance" discussions about yt, but nothing ever really formalized. So I guess what it comes down to -- do we want to start being aggressive about putting out patch (i.e., 2.2.X) releases? Do we need a set of release managers or curators, like there are in Enzo? When do we develop in a fork, when do we feel comfortable pushing to the main repo? The problem, as I see it, is that in some respects yt suffers from the same *problems* a project like Enzo does, in that some pieces of functionality are critical to a few applications, but it does not have the level of support or engagement as Enzo, so we don't have as much ability to spread workload around. Any thoughts on this? -Matt
Yo,
So I guess what it comes down to -- do we want to start being aggressive about putting out patch (i.e., 2.2.X) releases? Do we need a set of release managers or curators, like there are in Enzo? When do we develop in a fork, when do we feel comfortable pushing to the main repo? The problem, as I see it, is that in some respects yt suffers from the same *problems* a project like Enzo does, in that some pieces of functionality are critical to a few applications, but it does not have the level of support or engagement as Enzo, so we don't have as much ability to spread workload around. Any thoughts on this?
I feel that if we are to go to a second decimal point, it would be up to the person who did the fix to either do the point release if they have permissions (core devs), or the core dev who accepted the pull release. I think that would work fairly well. -- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice)
What if we were to, whenever the testing suite passes, automatically update
a "yt-stable" tag (or other name) on the yt branch, which would signify
that it is the latest change to pass all the tests? My guess is that this
is basically the yt tip most the time, but perhaps we could then with some
confidence tell people to just update to that by default? I'm just trying
to think of a way we don't have manually manage 2.2.X.
Sam
On Wed, Nov 2, 2011 at 10:47 AM, Stephen Skory wrote:
Yo,
So I guess what it comes down to -- do we want to start being aggressive about putting out patch (i.e., 2.2.X) releases? Do we need a set of release managers or curators, like there are in Enzo? When do we develop in a fork, when do we feel comfortable pushing to the main repo? The problem, as I see it, is that in some respects yt suffers from the same *problems* a project like Enzo does, in that some pieces of functionality are critical to a few applications, but it does not have the level of support or engagement as Enzo, so we don't have as much ability to spread workload around. Any thoughts on this?
I feel that if we are to go to a second decimal point, it would be up to the person who did the fix to either do the point release if they have permissions (core devs), or the core dev who accepted the pull release. I think that would work fairly well.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Matthew Turk
-
Sam Skillman
-
Stephen Skory