Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote: On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. I like the idea of sprinkling alpha/beta releases along the way. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. Which trimester is concurrent to the 1.N.x branched, but 1.N.0 not released yet period?
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 06/17/2013 09:57 AM, Daniel Shahaf wrote: On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote: On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. I like the idea of sprinkling alpha/beta releases along the way. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. Which trimester is concurrent to the 1.N.x branched, but 1.N.0 not released yet period? That was a point we didn't fully settle on in Berlin. Today that period is a limbo of sorts. Trunk is technically open to anything, but we don't like to codebomb it because it complicates backports of stabilization fixes to the release branch. I suggest that it should instead be the first trimester of the new release cycle -- and as such, wide open to changes -- because if all goes as planned, there will be fewer things to backport anyway (since we will have already been sitting in a feature-frozen stabilization mode on the trunk for three months prior.) Other ideas? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
C. Michael Pilato wrote on Mon, Jun 17, 2013 at 11:24:45 -0400: On 06/17/2013 09:57 AM, Daniel Shahaf wrote: On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote: On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. I like the idea of sprinkling alpha/beta releases along the way. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. Which trimester is concurrent to the 1.N.x branched, but 1.N.0 not released yet period? That was a point we didn't fully settle on in Berlin. Today that period is a limbo of sorts. Trunk is technically open to anything, but we don't like to codebomb it because it complicates backports of stabilization fixes to the release branch. I suggest that it should instead be the first trimester of the new release cycle -- and as such, wide open to changes -- because if all goes as planned, there will be fewer things to backport anyway (since we will have already been sitting in a feature-frozen stabilization mode on the trunk for three months prior.) Other ideas? How about: at the end of the third trimester, the release branch is created, a release candidate is cut, and the 1st trimester begins on trunk? I.e., make all of those simultaneous. Trunk will be in Tri1 mode while the release branch is in soak, so we won't have the problem of needing to pay attention to two active branches. That's also consistent with doing alpha at the end of tri1 and beta at the end of tri2.
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 6/17/2013 11:36 AM, Daniel Shahaf wrote: C. Michael Pilato wrote on Mon, Jun 17, 2013 at 11:24:45 -0400: On 06/17/2013 09:57 AM, Daniel Shahaf wrote: On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote: On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. I like the idea of sprinkling alpha/beta releases along the way. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. Which trimester is concurrent to the 1.N.x branched, but 1.N.0 not released yet period? That was a point we didn't fully settle on in Berlin. Today that period is a limbo of sorts. Trunk is technically open to anything, but we don't like to codebomb it because it complicates backports of stabilization fixes to the release branch. I suggest that it should instead be the first trimester of the new release cycle -- and as such, wide open to changes -- because if all goes as planned, there will be fewer things to backport anyway (since we will have already been sitting in a feature-frozen stabilization mode on the trunk for three months prior.) Other ideas? How about: at the end of the third trimester, the release branch is created, a release candidate is cut, and the 1st trimester begins on trunk? I.e., make all of those simultaneous. Trunk will be in Tri1 mode while the release branch is in soak, so we won't have the problem of needing to pay attention to two active branches. That's also consistent with doing alpha at the end of tri1 and beta at the end of tri2. Did you consider a process that produces a release every month, or every quarter? If any engineering team can do it, the Apache Subversion team can do it. There is some discipline around code review and a long history of automated testing. I like the trimester plan. However, in my experience, when you get into a situation where it takes longer and longer to test and release a piece of software, it's hard to reverse. The system is becoming more complex, it has more pieces and use cases, and it naturally takes longer to test it. Is it possible that this dynamic is at work with Subversion, and that the trimester plan has a high probability of falling into a situation where the third trimester takes substantially longer than one trimester? One reliable way to fix the problem is to move the development to continuous delivery and force testing much earlier in the process. It might end up being less work. You could argue that Subversion is a difficult case for continuous delivery because it requires compatible upgrades to both client and server. Yes, this is a difficult problem. However, Subversion is already dealing with this problem. There is an implicit requirement that new server releases be compatible with older clients. Increasing the release frequency does not increase the difficulty of dealing with this requirement. You can also argue that Subversion is a difficult case because it isn't just adding features. The team is making deep structural reforms that can't be finished in a month, and aren't backwards compatible. This is a problem that is faced by every continuous delivery team. They often release two separate versions of a major subsystem in one piece of software, with one subsystem switched for most users off until it is ready. This requires some extra engineering work during the transition period. However, you get back a lot of the extra work when you go to
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 17.06.2013 18:34, Andy Singleton wrote: On 6/17/2013 11:36 AM, Daniel Shahaf wrote: C. Michael Pilato wrote on Mon, Jun 17, 2013 at 11:24:45 -0400: On 06/17/2013 09:57 AM, Daniel Shahaf wrote: On Mon, Jun 17, 2013 at 09:36:29AM -0400, C. Michael Pilato wrote: On 06/13/2013 10:30 PM, Greg Stein wrote: Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. In private mail, you also asked for tighter definition of the various trimesters of stability (which is an interesting choice of terminology in my own personal life right now, but I digress...). Here's my thinking: Tri 1: Trunk builds and passes tests, but may have crazy new, sweeping-change types of features on it. We've tried to be forward-thinking, but who knows if these are the APIs/protocols/etc. that we'll wind up with in the release. At the end of this period, we might say we're merely build stable. We could ship an alpha at the end of this period to get the crazy new features into the public's hands for user acceptance testing. I like the idea of sprinkling alpha/beta releases along the way. Tri 2: Trunk builds and passes tests, and the crazy stuff is still getting hammered into release-worthiness, but we're not allowing any more crazy stuff in. Smallish features and enhancements are fine, but nothing like a WC-NG or Ev2 or FS-NG or At the end of this period, we would say we're feature stable, and could ship a beta release. Tri 3: Trunk is feature-complete. Oh, and it builds and passes tests. :-) We're serious about getting this thing ready to release, now. Strictly speaking, this period of trunk's life extends until the final release is cut by taking the release branch side of the fork in the road. But we don't want to lock down the trunk indefinitely, so we get as much stabilization done on the trunk as we can before branching for release stabilization and reopening the trunk for a new first trimester. Which trimester is concurrent to the 1.N.x branched, but 1.N.0 not released yet period? That was a point we didn't fully settle on in Berlin. Today that period is a limbo of sorts. Trunk is technically open to anything, but we don't like to codebomb it because it complicates backports of stabilization fixes to the release branch. I suggest that it should instead be the first trimester of the new release cycle -- and as such, wide open to changes -- because if all goes as planned, there will be fewer things to backport anyway (since we will have already been sitting in a feature-frozen stabilization mode on the trunk for three months prior.) Other ideas? How about: at the end of the third trimester, the release branch is created, a release candidate is cut, and the 1st trimester begins on trunk? I.e., make all of those simultaneous. Trunk will be in Tri1 mode while the release branch is in soak, so we won't have the problem of needing to pay attention to two active branches. That's also consistent with doing alpha at the end of tri1 and beta at the end of tri2. Did you consider a process that produces a release every month, or every quarter? If any engineering team can do it, the Apache Subversion team can do it. There is some discipline around code review and a long history of automated testing. I like the trimester plan. However, in my experience, when you get into a situation where it takes longer and longer to test and release a piece of software, it’s hard to reverse. The system is becoming more complex, it has more pieces and use cases, and it naturally takes longer to test it. Is it possible that this dynamic is at work with Subversion, and that the trimester plan has a high probability of falling into a situation where the third trimester takes substantially longer than one trimester? I think we've considered all that. While I find the idea appealing, we do have to consider that it would be an even more significant departure from our current workflow. I'd personally prefer to avoid taking big steps. One reliable way to fix the problem is to move the development to continuous delivery and force testing much earlier in the process. It might end up being less work. I fear it's the force testing much earlier part that is hard to get down peoples' throats, given that the majority of active developers are volunteers. On the other hand, we are in fact releasing often, it's just that most releases are bug fixes. You could argue that Subversion is a difficult case for continuous delivery because it requires compatible upgrades to both client and server. Yes, this is a difficult problem. However, Subversion is already dealing with this problem. There is an implicit requirement that new server releases be compatible with older clients. Increasing the release frequency does not increase the difficulty of dealing with this
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
The unintended private email CMike referred to a bit ago: On Jun 13, 2013 8:13 PM, Greg Stein gst...@gmail.com wrote: On Thu, Jun 13, 2013 at 7:34 PM, C. Michael Pilato cmpil...@collab.net wrote: On 06/13/2013 08:00 PM, Greg Stein wrote: ... People don't pay attention to branches. That has been empirically proven. If you want eyeballs, then you code on trunk. (and that seems fine, as long as your code does not *destabilize* trunk; with the new rule, it also seems that any new feature needs to stay hidden until ready, for some definition of ready) Unfortunately for the case you make, we have also empirically proven that even if you do code on trunk, you are not guaranteed to get eyeballs or even codepath executions. This isn't 2004. The kinds of changes we're making are complex changes which affect multiple areas of the codebase, often bringing dependencies on new server-side capabilities, relatively non-trivial workflows, and so one. *We* don't even use the kinds of workflows we're trying to write code for on behalf of our users, and we certainly aren't popping up new experimental installations of Subversion on svn.apache.org every other week so we can exercise our own features, either. The word destabilize has different meanings. We've always tended to use trunk is stable to mean roughly, trunk compiles and passes the tests. As you well know, and as the past four (at least) major release cycles bore out publicly, just because some body of work compiles and passes regression tests does not mean that body of work is release-worthy -- that APIs and behaviors introduced are of the sort that we want to live with and maintain once they reach users hands and then indefinitely beyond as we honor our compat promises. We can probably name at least one major oops we didn't think it would be that hard/take that long/cost that much moment for every release we've made over the last half-decade. So in the context of the discussions today, and for the long-term health of this community's relationship to an entire class (arguably the lion's share) of its user base, I suggest that stable has to start meaning a little more than that. That's the sole idea behind the new rule. The rule isn't arbitrary and is not the goal. Rather, it is a practical way to help us achieve that goal, which is getting into a steady release rhythm. Now, obviously, if you disagree with the goal, you will see this path toward it as pointless. And for what it's worth, you'd be right. After all, why would we need to care about the release-readiness of our trunk if releasing was always something that could be put off until tomorrow when things might be more stable? That's how we've worked ever since the 1.0 release shipped. I (and others) simply believe that as a project, we don't want to work that way any more. Wait. So if I boil down your lengthy explanation, you're saying well, developing on trunk introduces bugs, too, so therefore we should use branches. Is that it? It seems that you've jumped to a solution before you have defined stable. I believe you're defining trunk is stable as if I release it right now, then our users won't be screwed. That's quite a long way from our current definition of trunk is stable. Not disagreeing with the notion, but it seems that must be defined first. And it also sounds like there may be different definitions of trunk is stable based on which trimester the project is in. In the first trimester, we use the current definition? In the second, it tightens up to ???, and the third is the I should be able to ship this definition? When that stuff is defined, to a consensus position, then I think we can look at solutions. That may or may not be branch-based development. But I bet it will be more obvious. And we'll be able to better document/describe how our community likes to operate. And we can point to our rationale for time-based releases, stability guarantees at each point, etc. (and yes, at this pace, 1.8 would be unsupported in 18 months; adding one more release into the supported train extends that would to 27 months, which feels about right) Cheers, -g
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200: In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags, with -DTHAT_FEATURE being disabled by default. In the second three months, we will still accept smaller new features. But at the end of the six months, the trunk is closed to new features and stabilization for the release begins. We will allow up to three months for stabilization on the trunk, cutting the release stabilization branch at the end of the period (or beforehand, if we agree that the codebase is ready for RC). The release branch is managed the same as it is today, with an RC at the earliest reasonable moment and the same soak requirements and such that we've always had.
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 13.06.2013 15:43, Daniel Shahaf wrote: C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200: In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags, with -DTHAT_FEATURE being disabled by default. I'd have thought so too, but in fact, we're supposed to be writing a version control system, so avoiding using branches for their primary purpose (i.e., isolating lines of development) seems kind of counter-productive. Quite frankly, I'm sometimes just a bit bored by all the conditional blocks in our code. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote: On 13.06.2013 15:43, Daniel Shahaf wrote: C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200: In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags, with -DTHAT_FEATURE being disabled by default. I'd have thought so too, but in fact, we're supposed to be writing a version control system, so avoiding using branches for their primary purpose (i.e., isolating lines of development) seems kind of counter-productive. People don't pay attention to branches. That has been empirically proven. If you want eyeballs, then you code on trunk. (and that seems fine, as long as your code does not *destabilize* trunk; with the new rule, it also seems that any new feature needs to stay hidden until ready, for some definition of ready) Cheers, -g
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 06/13/2013 08:00 PM, Greg Stein wrote: On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote: On 13.06.2013 15:43, Daniel Shahaf wrote: C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200: In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags, with -DTHAT_FEATURE being disabled by default. I'd have thought so too, but in fact, we're supposed to be writing a version control system, so avoiding using branches for their primary purpose (i.e., isolating lines of development) seems kind of counter-productive. People don't pay attention to branches. That has been empirically proven. If you want eyeballs, then you code on trunk. (and that seems fine, as long as your code does not *destabilize* trunk; with the new rule, it also seems that any new feature needs to stay hidden until ready, for some definition of ready) Unfortunately for the case you make, we have also empirically proven that even if you do code on trunk, you are not guaranteed to get eyeballs or even codepath executions. This isn't 2004. The kinds of changes we're making are complex changes which affect multiple areas of the codebase, often bringing dependencies on new server-side capabilities, relatively non-trivial workflows, and so one. *We* don't even use the kinds of workflows we're trying to write code for on behalf of our users, and we certainly aren't popping up new experimental installations of Subversion on svn.apache.org every other week so we can exercise our own features, either. The word destabilize has different meanings. We've always tended to use trunk is stable to mean roughly, trunk compiles and passes the tests. As you well know, and as the past four (at least) major release cycles bore out publicly, just because some body of work compiles and passes regression tests does not mean that body of work is release-worthy -- that APIs and behaviors introduced are of the sort that we want to live with and maintain once they reach users hands and then indefinitely beyond as we honor our compat promises. We can probably name at least one major oops we didn't think it would be that hard/take that long/cost that much moment for every release we've made over the last half-decade. So in the context of the discussions today, and for the long-term health of this community's relationship to an entire class (arguably the lion's share) of its user base, I suggest that stable has to start meaning a little more than that. That's the sole idea behind the new rule. The rule isn't arbitrary and is not the goal. Rather, it is a practical way to help us achieve that goal, which is getting into a steady release rhythm. Now, obviously, if you disagree with the goal, you will see this path toward it as pointless. And for what it's worth, you'd be right. After all, why would we need to care about the release-readiness of our trunk if releasing was always something that could be put off until tomorrow when things might be more stable? That's how we've worked ever since the 1.0 release shipped. I (and others) simply believe that as a project, we don't want to work that way any more. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Enterprise Cloud Development signature.asc Description: OpenPGP digital signature
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 13.06.2013 20:00, Greg Stein wrote: On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej br...@wandisco.com wrote: On 13.06.2013 15:43, Daniel Shahaf wrote: C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200: In the interest of serving our user base, we are proposing that each release live on the trunk for at most nine months. The first six months of this period are open to new features. In the first three months of the new feature period, large, destabilizing features will be accepted (under the provision that the feature itself is arguably “complete”, which seemingly implies that it was developed on a feature branch maintained with routine sync merges. Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags, with -DTHAT_FEATURE being disabled by default. I'd have thought so too, but in fact, we're supposed to be writing a version control system, so avoiding using branches for their primary purpose (i.e., isolating lines of development) seems kind of counter-productive. People don't pay attention to branches. That has been empirically proven. If you want eyeballs, then you code on trunk. I have to disagree here -- even through you know I subscribed to that point of view for a long time. But the thing is, all that we've really empirically proven is that we, as a community, can't be bothered to think about more than trunk, and/or more than the next .0 release. I'll also point out that conditional blocks of code on trunk are just as invisible to exactly the same majority of developers as code on branches -- and they look messier to boot. I submit it's time to change that. We've historically done everything on trunk and released when it's ready, and the result is that every release takes longer to produce -- 1.8 was, I believe, by far the longest in the project's history (apart from 1.0 of course, but that's not relevant to this discussion). And the galling thing is that we essentially had a nice set of features ready back in November, but there was this just one small thing that has taken another half a year. From today's point of view, the infamous 1.5 was blazingly fast. I at least don't want something like that to happen yet again. Moreover, we are now discussing features that will likely take years to implement. I can't think of a sane way to do that other than on a branch. OK, there are some exceptions, e.g., you can do a whole new filesystem backend on trunk withour affecting other parts. But that's the exception rather than the rule. So instead of just waving a collective hand and repeating the old saw about branches being invisible, I propose we instead invent ways to make them visible. Starting by actually documenting a sane workflow based on feature branches. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej br...@wandisco.com wrote: On 13.06.2013 20:00, Greg Stein wrote: ... People don't pay attention to branches. That has been empirically proven. If you want eyeballs, then you code on trunk. I have to disagree here -- even through you know I subscribed to that point of view for a long time. But the thing is, all that we've really empirically proven is that we, as a community, can't be bothered to think about more than trunk, and/or more than the next .0 release. I'll I concur with your assessment. Such is the nature of volunteers :-) also point out that conditional blocks of code on trunk are just as invisible to exactly the same majority of developers as code on branches -- and they look messier to boot. Depends on how much you #ifdef away. Julian's experimental obliterate stuff was mostly present, for everybody. The only thing hidden was its visibility at the command line. I submit it's time to change that. We've historically done everything on trunk and released when it's ready, and the result is that every release takes longer to produce -- 1.8 was, I believe, by far the longest in the project's history (apart from 1.0 of course, but that's not relevant to this discussion). And the galling thing is that we Euh... did you go into a coma during 1.7? :-P 1.7 was the longest, at a full 31 months. Then 1.5 at 21 months, and 1.8 at 20 months. [ http://subversion.apache.org/docs/release-notes/ ] essentially had a nice set of features ready back in November, but there was this just one small thing that has taken another half a year. From today's point of view, the infamous 1.5 was blazingly fast. I at least don't want something like that to happen yet again. Sure. And I think CMike's original note about time-based releases will fix this. Then, he continues on a phased-approach to stability, but I believe that requires more definition. I have *no* problem with time-based releases. You may recall back in 2001, that I put myself and The Chicago Four onto cranking out releases every two weeks. To this day, I believe that the change in activity level, and the constant stream of new work really helped the project. There isn't much stopping a similar style of effort today. Apache rules allow an RM to make a release at any time, as long as they get three +1 votes. That RM could branch trunk after six months of dev work, and then cherry-pick stabilization fixes for the next three months, and then begin release candidates. Nothing stopping anybody from doing that, beyond the simple fact of trying to stabilize a moving target without some level of help/cooperation from the devs. But we don't put our RMs into that position. As a community, we help out the RM according to certain consensus policy. I see CMike's email (and its reflection of the Hackathon participants) as a suggestion towards adjusting that policy. Cool. It just seems that we need to figure out that consensus in more detail before offering solutions. Personally, I have some more issues with the proffered solutions, than the originating policy changes. Moreover, we are now discussing features that will likely take years to implement. I can't think of a sane way to do that other than on a branch. OK, there are some exceptions, e.g., you can do a whole new filesystem backend on trunk withour affecting other parts. But that's the exception rather than the rule. Agreed. That's why we let a total newcomer develop svnrdump right in trunk. It really didn't affect anybody, and it was dead easy to remove if we felt it wasn't ready for shipping. [ unfortunately, it has created some issues that nobody saw, but that's the nature of the game; we would have missed those deeper problems even using a branch-based approach ] So instead of just waving a collective hand and repeating the old saw about branches being invisible, I propose we instead invent ways to make them visible. Starting by actually documenting a sane workflow based on feature branches. Fair enough. But I think you're talking about Step Two. There is more work on what stable means, what time schedules to use, etc. That's Step One. (well, figuring out a sane workflow can certainly be developed in parallel, but I'll continue to posit there may be other solutions) Cheers, -g
Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.
On 14.06.2013 04:30, Greg Stein wrote: On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej br...@wandisco.com wrote: I submit it's time to change that. We've historically done everything on trunk and released when it's ready, and the result is that every release takes longer to produce -- 1.8 was, I believe, by far the longest in the project's history (apart from 1.0 of course, but that's not relevant to this discussion). And the galling thing is that we Euh... did you go into a coma during 1.7? :-P 1.7 was the longest, at a full 31 months. Then 1.5 at 21 months, and 1.8 at 20 months. Omigosh ... Yeah, I must've done. :) Must remember to remember to not trust my memory ... er, I think I just forgot what I have to remember? -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
