[draft] Release plans for 1.9.0?

Chris Shoemaker c.shoemaker at cox.net
Thu Jan 26 20:00:46 EST 2006


On Thu, Jan 26, 2006 at 11:07:47AM -0500, Josh Sled wrote:
> On Thu, 2006-01-26 at 16:17 +0100, Christian Stimming wrote:
> > If you have any more issues, please always add them to bugzilla. 
> > http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think 
> > these should be fixed before a particular release, mark them with the 
> > respective milestone.
> 
> [Slight tangent...] This assumes that we do know they should be fixed
> before a particular release, but there's two ways to approach the case
> where we know they should be fixed before 2.0, but don't know in which
> particular release they will/should be fixed in.  There's two
> approaches:
> 
> - "push-out": assign all un-slotted bugs to the next release, then
> immediately before that release goes out push-out the ones that aren't
> going to make it.
> 
> - "pull-in": assign all un-slotted bugs to the 2.0.0 target, then pull
> in the ones that have-been- or need-to-be-fixed before a particular
> milestone.
> 
> As we were just talking about on IRC, I think the later "pull-in"
> strategy is less-depressing :), though it takes a bit of discipline for
> developers to include both the next milestone and the 2.0.0 milestone in
> queries in order to get a sense of what needs/can be done for a
> particular release.
> 
> In any case, I think the project should roughly agree on one approach
> over the other, and I think it's "pull-in".  Objections?

Personally, I think "push-out" makes a lot more sense.  I don't think
we should feel any qualms about bumping all open bugs to the next
milestone at release-time.  That's just life.  AFAICT, the milestone
is intended to express "what bugs are candidates for being fixed in
that release."  The only reason why a bug wouldn't be marked for the
next milestone is that someone decided that the fix involves changes
that shouldn't be made before that release.  Marking them for a later
milestone just because we don't know when we'll get to them seems...
less useful.  I mean, if we mark all bugs milestones as the farthest
out-release, what information does that contain, other than
NotFixedYet?  And how could we use that field to convey meaning?

> > What do people think?
> 
> 1.9.0 this sunday.

My only concerns are packaging, not features or bugs.

-chris


More information about the gnucash-devel mailing list