Hi all,
Josh and I have been discussing plans for the upcoming release; below is what we've come up with so far. This is loosely based on past 0.4x plans. I'll follow up this email with explanations for the major differences. Meanwhile, feedback would be appreciated.
# Period Tasks Notes -------------------------------------------------------------------------------- 1. Open development. Triage and prioritize bugs report this year Itemize regression bugs found since last release
2. Chill. Development focuses on wrapping up Disable features that aren't finished Identify 'make distcheck' issues Identify any critical OSX/Win32 packaging issues P Identify remaining writing needed for Release Notes. Regressions Bug Hunt: 500 points H Update tutorials and other docs
3. Frost. Experimental Branch is forked B Mainline Branch focuses on stabilization B Only production-ready code committed to Mainline B Post inkscape-0.91-pre0.tar.gz Finalize any major changes to platform packaging P Release Notes should be >90% filled in. Inkscape must pass >90% of 'make distcheck' Start an About Screen contest A General Bug Hunt: 1500 points H Post additional inkscape-0.91-pre*.tar.gz releases Packagers test creating pkgs of the -pre* releases P
4. Feature Freeze. Stable Branch is forked from Mainline B Regular development resumes on Mainline. B Avoid major refactorings on Mainline. B Only bug fixes committed to Stable Branch. B Bug fixes are cherrypicked from Mainline. B Inkscape must pass 'make distcheck' String Freeze No further string changes allowed on Stable Branch. T Finalize tutorials to be shipped with release Finalize other docs included in the release Finalize about screen A Finalize Release Notes except Known Issues Translators work on translations. T Recruit Release Wardens for Hard Freeze
5. Hard freeze. Only Release Wardens can commit to Stable Branch B Cherrypick bug fixes from Mainline to Stable B Complete any late work under advisement of Wardens Focus on release-critical bug fixing. Finalize all extensions Finalize codebase translations T Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
6. Release. Post inkscape-0.91.tar.gz Post packages Post official announcements Plan 0.91.1+ release(s), if needed
7. Open development.
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
# Period Tasks Notes
- Open development.
- Chill. Development focuses on wrapping up Identify any critical OSX/Win32 packaging issues P
- Frost. Finalize any major changes to platform packaging P Packagers test creating pkgs of the -pre* releases P
This places an earlier than usual focus on platform-specific packaging and packaging issues.
Since we like to coordinate release announcements with availability of packages for all major platforms, if the packaging for one platform is in poor shape, it can hold up the works.
Along with that, sometimes fixing the packaging includes a desire or need for major surgery on it. And that too can add delay to the release.
So, the idea here is to get the packaging dusted off and reviewed, and see where we are. If we need major changes to it, let's hop on it ASAP, so it has time to stabilize while Inkscape itself is being stabilized.
- Feature Freeze.
- Hard freeze. Post additional inkscape-0.91-pre*.tar.gz releases
- Release. Post inkscape-0.91.tar.gz Post packages
- Open development.
Bryce
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
Hi all,
Josh and I have been discussing plans for the upcoming release; below is what we've come up with so far. This is loosely based on past 0.4x plans. I'll follow up this email with explanations for the major differences. Meanwhile, feedback would be appreciated.
# Period Tasks Notes
- Open development.
- Chill. Development focuses on wrapping up Regressions Bug Hunt: 500 points H
- Frost. General Bug Hunt: 1500 points H
In this plan, we're ambitiously adding two bug hunts. The first is focused at targeting regressions specifically. Our intent is not to get every last regression fixed, or even the worst ones, but just to get the overall quantity of regressions down.
The second bug hunt is open to all bugs like we've done in the past, but with a goal three times larger than usual. But with how long it's been since the last release, and how much has changed in mainline, this will help retire a lot of technical debt. My experience with past bug hunts is that the points tally up surprisingly quickly.
- Feature Freeze. Stable Branch is forked from Mainline B String Freeze No further string changes allowed on Stable Branch. T
- Hard freeze. Only Release Wardens can commit to Stable Branch B
- Release. Post inkscape-0.91.tar.gz
- Open development.
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
Hi all,
Josh and I have been discussing plans for the upcoming release; below is what we've come up with so far. This is loosely based on past 0.4x plans. I'll follow up this email with explanations for the major differences. Meanwhile, feedback would be appreciated.
# Period Tasks Notes
- Open development.
- Chill. Development focuses on wrapping up
- Frost. Experimental Branch is forked B Mainline Branch focuses on stabilization B Only production-ready code committed to Mainline B
- Feature Freeze. Stable Branch is forked from Mainline B Regular development resumes on Mainline. B Avoid major refactorings on Mainline. B Only bug fixes committed to Stable Branch. B Bug fixes are cherrypicked from Mainline. B
- Hard freeze. Only Release Wardens can commit to Stable Branch B Cherrypick bug fixes from Mainline to Stable B
- Release. Post inkscape-0.91.tar.gz
- Open development.
The branch strategy may seem a bit excessive, so let me explain the thinking behind it.
The GSoC program has been great for Inkscape but it places some constraints on when we can do releases. While GSoC is ongoing, many of our key folks are busy mentoring, so coordinating a release can be tricky. After it's completed, often the deliverables get integrated to mainline and need time to stabilize. But we don't want to delay the integration too long - ideally it's done during the summer while the program is still ongoing and the student is still actively engaged with it. Being able to deliver their branch to an "official tree" is often a mark of accomplishment for the students.
Despite these challenges, since GSoC is a seasonal thing, we still can schedule around it, with releases in winter or early spring.
But what about other sponsored development work, that might not follow such a routine schedule? Several proposals have been floated recently for kickstarter-ish efforts to fund development work. We definitely want to encourage these types of efforts and enable them to have successful deliveries. To do so we need to make the release process more flexible.
So the idea here is to split off an official (but temporary) Experimental branch. Not just the sponsored development work, but really any efforts that are large, potentially disruptive, or otherwise risky should be focused here.
During the whole Chill/Frost/Freeze process, Mainline focuses on stability, with only bug fixes and production-ready features being committed. We use an honor system for making commits, but also encourage aggressive reverting of commits that prove to cause regressions.
The Stable Branch is established earlier in this plan than in past release plans. It occurs at Feature Freeze rather than at Hard Freeze in order to give more time for the final stabilization. The Stable branch then can cherrypick fixes from Mainline as they're proven necessary.
Once the release is completed, the Stable branch can continue to accumulate bug fixes towards .1, .2, etc. releases. At this point, the Experimental branch (or pieces thereof) can be merged back to Mainline, or we can hold off a bit, if we want Mainline to continue focusing on stability for a bit. But eventually the Experimental branch will be EOL'd.
This Experimental / Mainline / Stable multiple branch strategy might prove to be complicated, but it's an approach other projects have used quite effectively. The main downside is that it takes a bit more branch and patch management needed to keep the various branches coordinated.
Bryce
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
# Period Tasks Notes
- Open development.
- Chill. Development focuses on wrapping up
- Frost. Experimental Branch is forked B Post inkscape-0.91-pre0.tar.gz Start an About Screen contest A
Note that the about screen contest is moved later in the process one step. This is to put it after the pre0 package becomes available, so that about screen contributors will have a packaged version of inkscape available.
- Feature Freeze. Stable Branch is forked from Mainline B Finalize about screen A
Hopefully finalizing the about screen here gives enough time to run the contest, while allowing enough time after to do any final tweaks and testing.
- Hard freeze. Only Release Wardens can commit to Stable Branch B
- Release. Post inkscape-0.91.tar.gz
- Open development.
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
Hi all,
Josh and I have been discussing plans for the upcoming release; below is what we've come up with so far. This is loosely based on past 0.4x plans. I'll follow up this email with explanations for the major differences. Meanwhile, feedback would be appreciated.
# Period Tasks Notes
- Open development.
- Chill. Development focuses on wrapping up Update tutorials and other docs
- Frost. Experimental Branch is forked B Post inkscape-0.91-pre0.tar.gz Release Notes should be >90% filled in.
- Feature Freeze. Stable Branch is forked from Mainline B String Freeze No further string changes allowed on Stable Branch. T Finalize tutorials to be shipped with release Finalize other docs included in the release Finalize about screen A Finalize Release Notes except Known Issues Translators work on translations. T
- Hard freeze. Only Release Wardens can commit to Stable Branch B Finalize codebase translations T
We've tried to ensure ample time for doing translations in this plan, by establishing String Freeze during Feature Freeze, and allowing until Hard Freeze for translation work to be done. Beyond code, this also attempts to get all translatable documentation finalized relatively early on.
Release Notes are also finalized a bit earlier, in order to permit time for anyone wishing to create translations of them. The only major thing I can foresee changing significantly are the Known Issues; I figure that's less critical to be translated though.
Finalize Known Issues section of Release Notes Finalize packaging scripts Post additional inkscape-0.91-pre*.tar.gz releases
Release. Post inkscape-0.91.tar.gz Post packages Post official announcements Plan 0.91.1+ release(s), if needed
Open development.
Bryce
On Wed, 2013-12-18 at 23:21 -0800, Bryce Harrington wrote:
Meanwhile, feedback would be appreciated.
The plan as laid out makes a lot of sense. I'd like to see us prioritize bugs during the bug hunts and freeze more aggressively. So our tracker always points to the most useful bugs to fix and doesn't overload the potential bug fixer with 200 wishlist options.
Martin,
It's one of the things that I really dislike with launchpad, on sf bugs and feature requests were the same system, but not the same thing, so you could filter them out. The bastardized system we have on launchpad is frustrating in comparison.
Sent from my iPhone
On 19 Dec 2013, at 14:03, Martin Owens <doctormo@...400...> wrote:
On Wed, 2013-12-18 at 23:21 -0800, Bryce Harrington wrote:
Meanwhile, feedback would be appreciated.
The plan as laid out makes a lot of sense. I'd like to see us prioritize bugs during the bug hunts and freeze more aggressively. So our tracker always points to the most useful bugs to fix and doesn't overload the potential bug fixer with 200 wishlist options.
Martin,
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2013-12-19 at 16:33 +0000, John Cliff wrote:
It's one of the things that I really dislike with launchpad, on sf bugs and feature requests were the same system, but not the same thing, so you could filter them out. The bastardized system we have on launchpad is frustrating in comparison.
What is it you'd like to see? Email me, maybe there's some way of getting the right workflow with the website's unreleased roadmap page which would be based on launchpad blueprints.
Martin,
On Thu, Dec 19, 2013 at 01:33:58PM -0500, Martin Owens wrote:
On Thu, 2013-12-19 at 16:33 +0000, John Cliff wrote:
It's one of the things that I really dislike with launchpad, on sf bugs and feature requests were the same system, but not the same thing, so you could filter them out. The bastardized system we have on launchpad is frustrating in comparison.
What is it you'd like to see? Email me, maybe there's some way of getting the right workflow with the website's unreleased roadmap page which would be based on launchpad blueprints.
Martin,
I know what he's referring to, and I definitely sympathize. In SourceForge we had an entirely separate queue for bugs that were feature requests. So like having two parallel bug trackers, and we could prioritize features just like bugs. When we converted over to Launchpad both queues were merged into the one bug list, with the features being set to importance Wishlist without the ability to order them by priority.
The Launchpad developers had work under way to change Blueprints to unify them with bugs, which I think would be a better model for what we actually want here, but as blueprints are currently implemented I'm not sure they're a very good match to our needs. When we first switched to launchpad I tried to encourage reporters to write blueprints instead of filing bugs for feature requests, but it seemed to not really catch on well. But maybe it's worth more thought.
Theoretically, if we did want to move the feature request bugs into blueprints, we could make a launchpad API script to copy them over. Think we'd need to consider if it'd pay off well enough to be worth the trouble.
Bryce
On Thu, 2013-12-19 at 14:31 -0800, Bryce Harrington wrote:
Theoretically, if we did want to move the feature request bugs into blueprints, we could make a launchpad API script to copy them over. Think we'd need to consider if it'd pay off well enough to be worth the trouble.
If a script to move over wishlist bugs to blueprints automatically was what made blueprints useful and usable. Then I'd be happy to write it.
The idea behind designing the roadmap page to reflect the blueprints, is to actually make them visisble instead of tucked away on the project page where I admit, it's hard to use them effectively.
Martin,
On Thu, Dec 19, 2013 at 05:39:36PM -0500, Martin Owens wrote:
On Thu, 2013-12-19 at 14:31 -0800, Bryce Harrington wrote:
Theoretically, if we did want to move the feature request bugs into blueprints, we could make a launchpad API script to copy them over. Think we'd need to consider if it'd pay off well enough to be worth the trouble.
If a script to move over wishlist bugs to blueprints automatically was what made blueprints useful and usable. Then I'd be happy to write it.
Me too, probably wouldn't be hard.
However, blueprints are pretty anemic. No comments, hard to search, etc. I hashed this over with suv just now and sounds like moving them to blueprints would probably make them unmanagable. Anyone else got ideas?
The idea behind designing the roadmap page to reflect the blueprints, is to actually make them visisble instead of tucked away on the project page where I admit, it's hard to use them effectively.
*Nod* Not a bad idea.
I do have to say I'm rather amazed looking at how short the roadmap is right now. I remember years ago it seemed overwhelming all the work that needed done. The developers have really done a remarkable job at hammering through that list.
Bryce
On Thu, 2013-12-19 at 15:19 -0800, Bryce Harrington wrote:
However, blueprints are pretty anemic. No comments, hard to search, etc. I hashed this over with suv just now and sounds like moving them to blueprints would probably make them unmanagable. Anyone else got ideas?
So the idea is this: We use blueprints in launchpad _if_ we need to link our roadmap items to bugs, commits and other launchpad objects. If that sort of link isn't required, then we can ignore them.
Simply the blueprint on launchpad could act as a very basic one-to-one key from someone we can build say on the website (if needed) and the launchpad system.
Alternatively we don't need that link and we can just junk blueprints in favour of something we build ourselves. It's not django-rocket-science.
Martin,
On Thu, Dec 19, 2013 at 09:03:13AM -0500, Martin Owens wrote:
On Wed, 2013-12-18 at 23:21 -0800, Bryce Harrington wrote:
Meanwhile, feedback would be appreciated.
The plan as laid out makes a lot of sense. I'd like to see us prioritize bugs during the bug hunts and freeze more aggressively. So our tracker always points to the most useful bugs to fix and doesn't overload the potential bug fixer with 200 wishlist options.
The way we do the bug hunt is we count 3 points for resolving low priority bugs, 6 for medium, 9 for high, and 12 for critical, which is intended to motivate attention on the larger priorities. Wishlist bugs aren't worth any points. And it's worthwhile to make sure all bugs have a priority assigned to them.
And I definitely agree that anything to help bubble up good bugs to work on and expose that to the crew will be handy to have.
Bryce
2013/12/19 Bryce Harrington <bryce@...961...>:
- Release. Post inkscape-0.91.tar.gz Post packages Post official announcements Plan 0.91.1+ release(s), if needed
Just a note - since there seems to be a sort of consensus on changing the goal for 1.0, I've renamed the upcoming release in Launchpad from 0.49 to 0.91. Regards, Krzysztof
On Thu, Dec 19, 2013 at 05:02:29PM +0100, Krzysztof Kosiński wrote:
2013/12/19 Bryce Harrington <bryce@...961...>:
- Release. Post inkscape-0.91.tar.gz Post packages Post official announcements Plan 0.91.1+ release(s), if needed
Just a note - since there seems to be a sort of consensus on changing the goal for 1.0, I've renamed the upcoming release in Launchpad from 0.49 to 0.91. Regards, Krzysztof
Excellent, thanks. The release notes will need updated with the new number too.
Bryce
participants (4)
-
Bryce Harrington -
John Cliff -
Krzysztof Kosiński -
Martin Owens