Re: RFC: 2.3 feature list

On Mon, 2004-11-22 at 17:19 +0100, J.M. Maurer wrote:
> > There is no reason whatsoever for usage of pango/cairo to be _limited_
> > to unix. I have no intention whatsoever of trying to force it on win32
> > folks who have uniscribe, but there's no reason for us to develop it as
> > unix-only.
>
> Except for the additional dependencies...
>

No, not dependancy. I thought I was clear on that. If you have
technical questions about avoiding dependancy in build and in run, I can
explain that (so could the thirty bajillion cs students in #abiword),
but it's beyond the scope of this thread. I have no intention
whatsoever of trying to force it on win32 folks.

> To add to the list:
>
> - What about 'my double patch'? Would be nice to get that in... It's
> about 90% ready for the first part. I could have it compilable in about
> 1 week.
>

        When it's not only compilable but also essentially free of regression
in runtime and thoroughly peer-reviewed, I certainly don't have a
problem with it. After all, why else would you do the work if not to
have it eventually released? We all know that it's good to improve the
accuracy and reliability of our rendering, my only request is that any
regressions (including, secondarily, code readability) be worked out
outside of mainline.
        That said, I do believe that you'll have more than enough time to get
that work into 2.4, so don't worry about rushing it or pushing for its
inclusion. I know I support it's eventual inclusion in the 2.4 cycle,
and I believe that the rest of the development staff in general agrees.
You've got _over_ two months to work out the kinks prior to inclusion
(-:

> - What about fixing the _massive_ number of filed bugs? I would give
> that the nr 1 priority over any new feature.

That would certainly be nice, but we can't even keep coders from being
coders (so to speak) in a hard freeze long past intended release (ie, a
new feature with new unfixed bugs being added September 29th), much less
ask that they then go another six months without putting anything fun in
mainline. Taking this realistic approach, I strongly encourage the
adoption of this two part focus:
1) Taking care of the really bloody important bugs by not branching 2.2
until there's been substantial progress on the top priority (P1 and some
P2) 2.2.x bugs. These are in large part bugs that were postponed from
2.2 with great reluctance because the release simply could not wait for
anything short of a global catastrophe. They must be taken care of
_now_.
2) While 'allowing' (we're all volunteers here, but to speak on similar
terms as you) new feature work into 2.4 by reopening mainline, we _must_
insist that the new features and their associated kinks and, heaven
forbid, regressions be worked out _in branch_, or, more accurately
(taking into consideration for example your double patch), _outside of
mainline_. I've also enumerated some important aspects of how those
branches should work in a prior mail and am pressed for time right now.

I described in a recent mail 2.2.x priorities as follows. It's verbose,
but more 'lay' terminology than usual for me, and I think the coders can
appreciate the wording of it:

2.2.x: P1 - Needs to be fixed ASAP. If not by 2.2.1, then by 2.2.2.
If not by 2.2.2, then by 2.2.3, and so on.... if the number of P1 bugs
doesn't diminish, it should be justifiably used to support not
branching.
        P2 - Still very important, fix ASAP. Not all of these bugs should stop
branching, though. "Don't be spending most of your time working on
nutty 2.4 feature branches when there's still P1 and P2 bugs left,
they're marked important because they are."
        P3 - Yay, we've fixed the P1 and P2 bugs, those were the really urgent
ones that needed to be fixed ASAP. Now the big post-milestone rush is
over, we can relax the release schedule and encompass more P3 bugs in
each. "We won't be terribly upset at you if you reward yourself by
dividing your time with feature work on 2.4 either, as long as there's
still a steady stream of P3 fixes coming in."
        P4 - Dear developer, you've fixed the P1-P3 bugs, good job. Have a cup
of coffee, take a nap, visit your family who hasn't seen you since the
2.2 rush began, you deserve it. Then come back to these.
        P5 - It'd be quite nice for 2.2.x to eventually include these fixes,
but noone is going to be upset if it's 2.2.10 before you get to them.
"Have fun hacking away at 2.4 as long as you don't forget about these."
Not so much because they're hard to fix as because they're either
absolutely trivial or of easily survivable severity and likely not to be
encountered by more than one in thirty thousand users.

Mind you, coder, there's a problem, in that many bugs are not
prioritized or are prioritized incorrectly. However, we've gone to
great effort to ensure that the P1 and P2 2.2.x bugs are essentially
correctly prioritized, so that should give plenty of focus for the near
term while qa is bothering about prioritization of 'the rest'.

Marc, does this help answer how I feel about the best way to approach a
focus on bugs? There's more to it, but I needn't go into it here or now
(and I'm again pressed for time).

>
> > Math support is under development in branch and is NOT ready to be
> > merged. GSF IO also is not near ready, but this will take much fewer
> > manhours than math in general so I'm less worried about it.
>
> We don't even have the beginnings of any GSF IO work ?
>

        Ah. Well, I still think in the end, gsf takes rather less manhours
than math because so much is already done for us, but just don't worry
about it. If it is done and stable in two months, it goes in. If not,
it does not. If noone works on it, it won't be done, so it won't go in.
Again, the advantages of doing this sort of invasive work outside of
mainline: The timeframe doesnt depend on the work, the work doesn't
depend on the timeframe.

        An ancillary benefit of keeping such work in branch, not allowing
regression and stall into mainline: by the time mainline has diverged
sufficiently from 2-2 to raise the bar for backporting, you'll be
prefix-branching the 2-4 release (like many large successful projects)
and backporting fixes from mainline to there while concurrently
initializing the next milestone cycle. You don't even have the wasted
effort that comes with having to decide and to act on backporting or
not, or refixing in two places or not, and developers can safely keep
having fun. IOW, you get more stable release, AND the coders have MORE
time they get to do fun stuff.

Making sense to everyone?

> > Once it
> > works in branch and doesn't fsck over otherwise working platforms, it
> > should be mergable (as long as we aren't frozen by then).
>
> > RC is
> > unfortunately in the same branch but is nearly ready to be merged, so
> > I'll hand-merge that when I get the goahead from the lead dev with whom
> > I've talked (after 2.2 is branched).
>
> Will give you a ping when it is ready. Not within the next 2 weeks
> though, and even after the merge, I'd like to see it in DEBUG only for a
> while.
>

No worries mate. You've got time, and the right attitude about it.

> > On that note, 2.2 cannot be branched until after a significant number of
> > first priority 2.2.x bugs are fixed. NOT all of them, but there's quite
> > a few that we really felt sick to our stomachs about releasing 2.2
> > without.
>
> ACK! (see above where I made the same point, I should read the whole msg
> first :)
>

Oh, and I just made the same mistake, replying just-in-time (-: oh
well, at least we're on the same page, that's good to know.

Regards
-MG, late for a test
Received on Mon Nov 22 18:51:04 2004