Re: RFC: 2.3 feature list

On Tue, 2004-11-23 at 09:20 +1100, msevior@physics.unimelb.edu.au wrote:
> This will introduce *A LOT* of regressions at first. We will have a hard

That means, with respect to new features, that it needs to be done as
soon as we branch (high priority bugs take precedent, but as far as
features go, the more invasive and the more regression-prone, the
earlier it needs to happen).

> time sorting through all the issues and we will need our intrepid QA guys
> to find all the nasty little holes we've left.

And that takes a lot of time which is no less scarce for qa guys than
for coders, so take this into account when thinking about anything else
you might want to do with your 2.4 time.

> That said, it will make the PT much easier to work with once we work
> around all the work arounds we've put in for the fact that we don't have
> an end of block strux.

I agree (and so do all the other devs that've chimed in about this so
far). But again, if it happens for 2.4, it absolutely must happen as
soon as we branch, so that QA has at least 5 months to pound the shit
out of it, because that's how long (at least) we'll need, and you must
reprioritize such that other feature work doesn't happen until you've
got time beyond what needs to be devoted to doing and fixing this.

Also, now that I've been reminded, everybody please point out to me
filed bugs which probably won't be fixed until this work happens, as
well as file any unfiled ones.

> > 5. Index support
>
> We have a very large part of what we need for index support already in
> place in the TOC code. It just needs repacking ala positioned images vs
> text boxes.

But, speaking reasonably, do you have time for this AND fixing all the
bugs introduced with this in addition to everything else? This is the
question you have to ask yourself about all intended feature development
for the next milestone cycle, and it's no less important for index
support. We may have a sizable portion of what needs to be done done,
but there's also a sizable portion that isn't, nor do we know about all
the bugs this will introduce that would otherwise remain hidden.

> > 6. Vector graphics
>
> Yes!
>
> > 7. Object embedding
> >
>
> needs the above and would be very nice.

I think you meant "needed by the above", right? In any case, I don't
think it should be too terribly many manhours for svg support, if
someone intends to spend their time that way, AFTER the generic object
framework is in place (plugins and alternate representations and all
that, remember?). The latter (objects) is a huge investment. Big
reward, but huge investment. So the question is, who (who all?)
actually intends to spend their time on this at the expense of other
things being pushed to later?

> My "small" extra features would be:
>
> 1. Progress bar.

Sure.

> 2. Split screens.
> 3. Optional Tabbed interface like firefox.
>
> These two will benefit enormously from Marc's RC work.
>

        I'm not sure how small I'd call supporting an MDI. Lord knows how many
bugs in our viewer/listener system will come to light when we try to
start supporting these things. I'm not expressly against it, but we
need to know who wants to invest himself in doing this, because it cant
be the 'martin simultaneously hacks out twenty new features' sideshow at
the AbiCircus again.
        We need people to write their new features, sure, but not delay fixing
the bugs in the new features in favor of moving on to another new
feature because again, this is how you end up with a milestone that's
eight months late and not very stable. Yes, a single person being able
to file 200 high severity bugs in just under eight months is unstable.

> 5. Tables allowed as first struxes in sections

Martin, can you please briefly note what this involves, caveats and
possible regression scenarios? Although I suppose it's a big help just
that we (meaning qa this time) know to pound specifically at tables as
first struxes.

> 6. TOC's export to RTF

No objection here.

> 7. Positioned objects imported from MS Word

Eh... depends on just what you want to do with them. See 7. above.

> 8. Sort table columns/rows

...alright, no objection here, but a little reservation.

> 9. Repeating table rows on pages

...what?

>
> I fully agree with Tomas about enabling complex scripts for the Unix build.
> Linux appears to be really taking hold in India and we have a natural
> advantage over OOo there if we can do complex scripts.
>
> However the pango integration should happen after Marc's doubles patch is
> incorporated.
>

        There's no reason that most of the work can't happen concurrently, I
think. You can make it somewhat resemble a 'working' (not to be
confused with working well) renderer (that builds, and does stuff
renderers do) without perfecting those mathematics of it. Of course,
I'm not the one writing it. Anyway, if by integration you meant 'the
making it default', sure.

> My big extra feature is Math.
>
> This already seems like too much work for 2.4 and I really want to keep
> the AbiMath branch in synch with the mainline.
>

I'm strongly inclined to agree. I can work out a better solution for
keeping AbiMath in sync with mainline for the long term.

> For my own thing I'm very comfortable fixing P1 2.2.x bugs for the next
> while.

The U.S. Meteorological Center reports massive ecologic destabilization
as thousands of users and qa people around the AbiWorld simultaneously
exhale in relief to hear you say that.

> So sum1 keep on filing those weird crashers. Everyone reveals another
> weakness in the code base.

Hear, hear!

Regards
-MG
Received on Tue Nov 23 03:21:25 2004