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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
