4:21 p.m.
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.
5:10 p.m.
New subject: Proposal for release plan - Platform Packaging Notes
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
# Period Tasks
Notes
--------------------------------------------------------------------------------
1. Open development.
2. Chill. Development focuses on wrapping up
Identify any critical OSX/Win32 packaging issues P
3. 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.
4. Feature Freeze.
5. Hard freeze. Post additional inkscape-0.91-pre*.tar.gz releases
6. Release. Post inkscape-0.91.tar.gz
Post packages
7. Open development.
Bryce
5:21 p.m.
New subject: Proposal for release plan - Bug Hunt Notes
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
--------------------------------------------------------------------------------
1. Open development.
2. Chill. Development focuses on wrapping up
Regressions Bug Hunt: 500 points H
3. 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.
4. Feature Freeze. Stable Branch is forked from Mainline
B
String Freeze No further string changes allowed on Stable Branch. T
5. Hard freeze. Only Release Wardens can commit to Stable Branch B
6. Release. Post inkscape-0.91.tar.gz
7. 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....
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:22 p.m.
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
--------------------------------------------------------------------------------
1. Open development.
2. Chill. Development focuses on wrapping up
3. Frost. Experimental Branch is forked B
Mainline Branch focuses on stabilization B
Only production-ready code committed to Mainline B
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
5. Hard freeze. Only Release Wardens can commit to Stable Branch B
Cherrypick bug fixes from Mainline to Stable B
6. Release. Post inkscape-0.91.tar.gz
7. 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
6:28 p.m.
New subject: Proposal for release plan - About Screen Notes
On Wed, Dec 18, 2013 at 11:21:49PM -0800, Bryce Harrington wrote:
# Period Tasks
Notes
--------------------------------------------------------------------------------
1. Open development.
2. Chill. Development focuses on wrapping up
3. 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.
4. 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.
5. Hard freeze. Only Release Wardens can commit to Stable Branch
B
6. Release. Post inkscape-0.91.tar.gz
7. Open development.
6:36 p.m.
New subject: Proposal for release plan - Translation Notes
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
--------------------------------------------------------------------------------
1. Open development.
2. Chill. Development focuses on wrapping up
Update tutorials and other docs
3. Frost. Experimental Branch is forked B
Post inkscape-0.91-pre0.tar.gz
Release Notes should be >90% filled in.
4. 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
5. 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
6. Release. Post inkscape-0.91.tar.gz
Post packages
Post official announcements
Plan 0.91.1+ release(s), if needed
7. Open development.
Bryce
11:03 p.m.
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,
1:33 a.m.
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....
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
3:33 a.m.
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,
7:31 a.m.
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
7:39 a.m.
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,
8:19 a.m.
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
8:51 a.m.
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,
7:37 a.m.
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
1:02 a.m.
2013/12/19 Bryce Harrington <bryce@...961...>:
6. 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
7:32 a.m.
On Thu, Dec 19, 2013 at 05:02:29PM +0100, Krzysztof Kosiński wrote:
2013/12/19 Bryce Harrington <bryce@...961...>:
> 6. 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
3389
days inactive
3389
days old
inkscape-devel@lists.inkscape.org
15 comments
4 participants
participants (4)
-
Bryce Harrington -
John Cliff -
Krzysztof Kosiński -
Martin Owens