[Limiting followup for this thread to inkscape-devel@]
On Tue, Feb 27, 2007 at 02:02:47PM -0800, Jon Phillips wrote:
> On Tue, 2007-02-27 at 13:51 -0800, Bryce Harrington wrote:
> > Just to give some visibility into some of the work bubbling away these
> > days:
> > Cairo renderer: Bulia has taken point on investigation of conversion to
> > Cairo. Some tough problems have been uncovered but we're gaining a
> > clearer picture of what needs done. Presently this looks like it will
> > require an all at once brute force approach, rather than incremental
> > refactoring. If so, we'll need to reach a decision on how to
> > undertake that while minimizing disruption to SVN HEAD users.
> Yes, I've got a shovel? Where's the plan?
It's probably going to involve adding conditionalized #defines for Cairo
alternate calls in key places, but I don't think a specific plan has
been decided on yet.
> > Build system: There is definitely a concensus that our current build
> > system sucks. Options include CMAKE, Bob's buildtool, or just a
> > cleaned up automake. We really need to have interested parties mind
> > meld and find a single solution.
> CMake seems good, but I guess its the best one wins and/or who puts in
> the most time ;)
No, I think in this case we really do need to have the people who care
about this a lot to talk it through and come to a unified concensus in
what to do. Maybe we need to hold an IRC meeting or something?
> > Version control system: Mental has been experimenting with git and
> > trying to get it to operate with svn. This study is still very early
> > on, but if it works out well, one day we may begin encouraging
> > developers to use git.
> Yes, hybrid approach good. But if it ain't broke, why break it ;)
I think it's a "best tool for the job" type of issue here. git uses a
different model than CVS/SVN that is better at certain kinds of tasks.
Also, cairo uses git, so there could be some advantages in that. But at
this time it's just to experiment and see what can be done.
> > Bug tracking: I have been experimenting with use of Mantis with the
> > goal of replacing our SF bug tracker. It looks good, but the
> > principle issue is how to migrate the bugs and their history from SF
> > to Mantis. I'm also interested in seeing if it can be combined well
> > with Drupal, maybe along with Pootle. Any drupalheads out there?
> Lets discuss this somemore. I've been hacking on pootle for Creative
> Commons so that we can get near live translations of our code projects
> using pootle's web interface (http://translate.creativecommons.org/)
> Oh, it would be great to have a generalized issue tracker rather than
> just a "bug tracker," since we want to track more than just bugs, right?
> We need patch, features, bugs at minimum...
Right, I guess I figure this goes without saying. However I'm thinking
that making these categories isn't the right way to go. Instead, it
should have a way to search for "issues that have patches attached to
them", or to distinguish between issues that result in data loss, or
crashes, or usability concerns, or etc.
The more ways we can mine the bugs, I think the more useful it'll be.
Presently, once something gets filed as an RFE, or prioritized to 6 or
lower, it tends to not get much attention, especially if it isn't
assigned to anyone. The more categorization, keywording, relating,
etc. etc. we can do, the better.
> > Manual: We've got a good unofficial non-free manual/book and several
> > [semi-]official incomplete free manuals. There is discussion about if
> > efforts can be combined to produce a good official free manual.
> Yes, this would be great to standardsize behind something like how
> scribus does it: http://docs.inkscape.org and/or
> http://manual.inkscape.org We need an official place for this IMO. This
> should be easy to do. I think we should just make this a solid portal
> into the various efforts and let the best rise to the top...
Yes, I think the effort is mostly just touching base with all the people
working on various manual/tutorial things and organizing an agreed on
strategy for integrating all the efforts in a way that gains them each
the credit they deserve, but results in a single official product.