[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