Re: RFC: future develpment/release strategy

From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Jun 24 2002 - 03:00:40 EDT

  • Next message: Patrick Lam: "commit: hdrftr fix, 3324"

    On Sat, 22 Jun 2002, Tomas Frydrych wrote:

    >
    >
    > I wonder in light of Joaquin's work (see my posting to the "more Xft
    > stuff" thread), and would like feedback from the whole team, whether
    > we might not need to have two development branches; one a
    > continuation of the 1.x line; this would contain Martin's table code,
    > Joaquin's xft code, footnotes and endnotes code and similar, and
    > lead toward and intermediate 1.2 release. The second developement
    > branch would lead to 2.0 release eventually, and would contain the
    > Pango/gtk2 stuff.

    Dom could speak to this better than me but I think the gtk2 port is about
    ready to be moved into HEAD. If this is the case then it is just the pango
    stuff that needs to be moved off.

    I would have guessed that the new improved xft code could be integrated
    with the gtk2 code w/o too much trouble. I guess that moving to a pure
    pango based font/rendering would not be any harder this way that making
    the direct change to pango from our current code.

    Indeed moving to a pure pango based layout system will require pango to be
    come stabally XP on a number of different systems much of which will be
    outside our control.

    It seems safer to make the change

    1.0.x => gtk 2/xft/Freetype(on Unix) + other nice features for 1.2 => 2.0
    pure pango XP.

    >
    > My main reason for this suggestion is that it will take a while before
    > we have a 2.0 release with the Pango stuff; things are moving along
    > slower than I have been hoping.

    Is this because the work is much harder than you thought or because you
    haven't had the time to work on it?

    > However, much work has been
    > done already that could eventually be released in an intermediate
    > release, and it would be pitty to hold it back for many months just
    > because other changes are not yet finished. So, I think the best way
    > would be to brach present head into 1.x and 2.x development
    > branches. The present stable would be left as is at present for
    > bugfixes only, and after the 1.2 release would be replaced with
    > stable 1.2 branch. The 2.x-dev would be Pango-enabled and gtk2
    > dependant, so we could remove the #ifdef WITH_PANGO defines as
    > soon as the Pango code provides basic functionality, while 1.x-dev
    > would be Pango-less, gtk1 based, so that all the existing Pango code
    > would be removed from it.
    >

    I agreee except that I thin the GTK 2 port should be ready on the 1.2
    timeline.

    > If we agreed this was a good idea, the question remains which
    > should be the head (I would prefer the Pango/gtk2 branch, as it
    > would be heading toward the next major release), and what
    > procedure would be used to for maintaining the non-head dev
    > branch. The easiest would probably be that each developer would be
    > responsible to commit all changes to both branches when
    > applicable, although, we might want to have a formal maintainer, who
    > would be sent patches.
    >

    Hmmm this will be a pain. How much work will be done on the XP parts of
    pango in within the next few months?

    Maybe it would be better to freeze XP related pango developement until
    after 1.2? I guess it depends on your assessment of how long before pango
    itself is ready for a prime time XP environment.

    Cheers

    Martin



    This archive was generated by hypermail 2.1.4 : Mon Jun 24 2002 - 03:04:13 EDT