Proposed plan for 0.43 development
Hi all,
As the release of 0.42 nears, I haven't been able to help thinking about what we should do for the next release. I'd like to throw some thoughts out for comment.
I think we're all ready for a bit faster release cycle. 0.43 really took a bit too long. Partly that's because we wanted a nice long development cycle, but mostly because we had some extremely ambitious goals.
This release, though, the goals are more modest (and already mostly done). As well, we have four Google Summer of Code students producing code, and I think it would serve their learning process (and our own ability to review the code and give them feedback) if they can start getting their code drops out to the Inkscape audience.
Thus, I'd like to propose that for at least 0.43 and 0.44 that we shoot for something on the order of a month each:
3 weeks development 2 weeks feature freeze - stabilization / bugfix ~1 week hard freeze release repeat
As far as specific development goals, I think we should just set the one goal of having some working code from each of the SoC students, (plus whatever else gets done by others). Some of the students may need our assistance in learning how to integrate code, test it, fix bugs, and so forth.
(The originally planned goal of the 0.43 release was to work out how to do extensions, which thanks to hard work by Ted, ACSpike, and others, is already fairly well in the bag.)
Anyway, let me know your thoughts on the above, and if it sounds acceptable, we can start on this plan of action as soon as the release of 0.42 is complete! :-)
Bryce
I agree we should try to make it faster, but I doubt a month per release is realistic. There's too much stuff to do for each release. 0.41 was about as fast as it gets, and it was more than 2 months.
Also I think the best approach would be to alternate long and short releases, because long releases have their advantages too. So let's try to make each odd release as short as possible, so we can take our time on even releases.
On Sun, Jul 24, 2005 at 12:15:28PM -0300, bulia byak wrote:
I agree we should try to make it faster, but I doubt a month per release is realistic. There's too much stuff to do for each release. 0.41 was about as fast as it gets, and it was more than 2 months.
One thing that I've learned with releases is that the more frequently you do them, the easier it becomes, because you tend to script repetitive tasks and streamline processes. As well, the bug fixing phases are shorter with short release cycles since less new code is going in. We've seen this for our past releases.
The motivation to get the release work done seems to be strongest when a release is pending. As Jon pointed out, if we set our goal to 1 month, it could take 1.5 to 2; if we set it at 2 months, then it could turn out to be 3. So I think we should shoot for 1 month, and then if we're a bit late, it still gives the Summer of Code students at least one opportunity to see their code in practice before they have to turn it in.
Also I think the best approach would be to alternate long and short releases, because long releases have their advantages too. So let's try to make each odd release as short as possible, so we can take our time on even releases.
Sounds good to me. That'll make it easy to remember.
Bryce
On Sun, Jul 24, 2005 at 12:28:13PM -0700, Bryce Harrington wrote:
to be 3. So I think we should shoot for 1 month, and then if we're a bit late, it still gives the Summer of Code students at least one opportunity to see their code in practice before they have to turn it in.
Personally, I'd like to see a push for rapid releases while the SoC stuff is going on. It's a pretty unusual situation in itself, so I think maybe an "unusual" release cycle might be nice.
On Sun, 2005-07-24 at 00:30 -0700, Bryce Harrington wrote:
Hi all,
As the release of 0.42 nears, I haven't been able to help thinking about what we should do for the next release. I'd like to throw some thoughts out for comment.
I think we're all ready for a bit faster release cycle. 0.43 really took a bit too long. Partly that's because we wanted a nice long development cycle, but mostly because we had some extremely ambitious goals.
Agree...
This release, though, the goals are more modest (and already mostly done). As well, we have four Google Summer of Code students producing code, and I think it would serve their learning process (and our own ability to review the code and give them feedback) if they can start getting their code drops out to the Inkscape audience.
Yes, I think this is imperative for them to get full exposure to the process. Plus, since we tentatively know that Google is planning on doing a Summer of Code in the Winter (So, winter of code?), then this will set up a good precedent for this type of power dev.
Thus, I'd like to propose that for at least 0.43 and 0.44 that we shoot for something on the order of a month each:
3 weeks development 2 weeks feature freeze - stabilization / bugfix ~1 week hard freeze release repeat
As far as specific development goals, I think we should just set the one goal of having some working code from each of the SoC students, (plus whatever else gets done by others). Some of the students may need our assistance in learning how to integrate code, test it, fix bugs, and so forth.
(The originally planned goal of the 0.43 release was to work out how to do extensions, which thanks to hard work by Ted, ACSpike, and others, is already fairly well in the bag.)
Anyway, let me know your thoughts on the above, and if it sounds acceptable, we can start on this plan of action as soon as the release of 0.42 is complete! :-)
I think this sounds quite good. I think in the end we will work towards whatever plan we design. Thus, if we allocate 4 months to a release, we will probably do it in 5. And similarly, if we allocate 1 month, we will do it 1.5. Thus, I agree that we should try to get 1-1.5 month releases for a while. With this release we have verged on releasing to late and not often enough.
The plan you set forth sounds good. With regards to extensions, it would be nice to get an update about this, what is still needed, etc. I'm a little lost to what the state is of this dev.
Bryce, are you going to update the roadmap?
Jon
On Sun, Jul 24, 2005 at 11:18:32AM -0700, Jon Phillips wrote:
I think this sounds quite good. I think in the end we will work towards whatever plan we design. Thus, if we allocate 4 months to a release, we will probably do it in 5. And similarly, if we allocate 1 month, we will do it 1.5. Thus, I agree that we should try to get 1-1.5 month releases for a while. With this release we have verged on releasing to late and not often enough.
Yes, that was my thought; set it for a month, and not be surprised if it takes 1.5-2.
With regards to extensions, it would be nice to get an update about this, what is still needed, etc. I'm a little lost to what the state is of this dev.
It looks like the extensions work; it would be nice to hear a report from ACSpike and Ted about what state they feel we're in.
Bryce, are you going to update the roadmap?
Yes. It would be nice if someone could go through and mark all the completed stuff done, and/or delete tasks that are no longer needed.
I'm also hoping to continue working on the test system and continuing the gtkmm work on SPView over the next few months. I'm also playing with Cairo a bit, but only experimentally.
Bryce
participants (4)
-
Bryce Harrington -
bulia byak -
Jon Phillips -
Kees Cook