Inkscape Project Status
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.
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.
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.
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?
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.
Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up.
Bryce
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?
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 ;)
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 ;)
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/)
I abhor drupal, and wonder what the endgame is? Is that for our site? I'm all for just going 100% wordpress since its so easily extensible...yes, I know...we tried the hybrid approach before ;)
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...
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...
Anyway, I've probably missed something, but I think that covers the pending changes that are percolating. Most of these would benefit from discussion, so we can make sure there is a rough concensus favoring the change - so if you have concerns about any of these changes, now's a good chance to bring 'em up.
Bryce
Thanks Bryce!!!
Jon
[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.
Bryce
On Tue, 2007-02-27 at 15:02 -0800, Bryce Harrington wrote:
[Limiting followup for this thread to inkscape-devel@]
<snip />
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?
You know, we haven't had a good ole IRC meeting in some time. I think this would be a *great* time to discuss these issues, large scale plans, etc. We have done this a couple of times in coordination with scribus and that worked out well...it would be great to pull together in anticipation of LGM2007 as well.
How about we plan this for this SUNDAY at a good time we can all hit. I'll say 8 PM PST as a starting point.
<snip />
On Tue, Feb 27, 2007 at 03:13:01PM -0800, Jon Phillips wrote:
You know, we haven't had a good ole IRC meeting in some time. I think this would be a *great* time to discuss these issues, large scale plans, etc. We have done this a couple of times in coordination with scribus and that worked out well...it would be great to pull together in anticipation of LGM2007 as well.
How about we plan this for this SUNDAY at a good time we can all hit. I'll say 8 PM PST as a starting point.
I'm up for this, especially to chime into the build system discussion. Between doing the regular builds of the svn HEAD tarball, doing random distcheck builds, and keeping an eye on the Inkscape bundle in both Debian and Ubuntu, any changes will have significant impact on stuff I'm used to doing. :)
# from Bryce Harrington # on Tuesday 27 February 2007 01:51 pm:
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.
It looks like this discussion got started regarding the difficulty of maintaining a branch for Cairo work. I'm not sure you really need distributed version control just for that. IME, branching in svn isn't that painful, but I guess if you're trying to constantly merge-down from trunk it could be.
It's my impression that we're only talking about a single branch for one monolithic development iteration. To me, that sounds like svn. If I'm mistaken and the plan is to have multiple competing/cooperating branches ala kernel, then yes, darcs/mercurial/git make more sense. However, IME anything distributed is going to have some friction with svn's linear central model.
If you just want better merge tools for svn, look at svk. With that approach, you keep the linear central model, but with a local buffer and easier branching/merging.
just my $0.02.
--Eric
On Tue, 27 Feb 2007 14:19:47 -0800, Eric Wilhelm <scratchcomputing@...400...> wrote:
IME, branching in svn isn't that painful, but I guess if you're trying to constantly merge-down from trunk it could be.
Yeah. Even one or two merge-downs will get painful, so you end up saving up the entire re-integration burden for the end. I've had enough bad experiences at this point that I would never want to do a long-running branch in SVN that I would eventually have to re-integrate (it's not so a big deal for e.g. release branches, obviously). We might be better off doing the cairo development in HEAD, with conditional compilation (or better, runtime switchover) between the two renderers.
As far as git for cairoification goes, though, I set up the git infrastructure to support my own work on the bbox cleanup. While it meets my needs, I'm not entirely sure that (given issues which have already been mentioned) it's ready for that kind of primetime yet.
If you just want better merge tools for svn, look at svk. With that approach, you keep the linear central model, but with a local buffer and easier branching/merging.
Been there, done that, got the teeshirt. As far as svk goes, it has the functionality, but the implementation is crap and it's painful to use as a result. Nowadays I use git-svn instead (most of my recent SVN commits actually originated in git) -- while the SVN integration isn't as nice as svk's, everything else works so much better.
Ever since we started talking about switching from CVS to SVN, I've made something of a project of trying out all the various available Open Source SCMs. At this point, in order of preference, I'd rate them roughly:
1. git 2. Darcs 3. mercurial 4. Subversion 5. Arch/bzr 6. monotone 7. svk 8. CVS
Darcs, Arch, and bzr are the only SCMs I've not actively maintained a project in yet.
-mental
On Tue, 27 Feb 2007 15:51:47 -0800, MenTaLguY <mental@...3...> wrote:
We might be better off doing the cairo development in HEAD, with conditional compilation (or better, runtime switchover) between the two renderers.
And, as you (Eric) had suggested, it's not clear that a doing a monolithic development push in HEAD isn't appropriate yet.
-mental
On Tue, Feb 27, 2007 at 03:51:47PM -0800, MenTaLguY wrote:
Ever since we started talking about switching from CVS to SVN, I've made something of a project of trying out all the various available Open Source SCMs. At this point, in order of preference, I'd rate them roughly:
- git
- Darcs
- mercurial
- Subversion
- Arch/bzr
- monotone
- svk
- CVS
Darcs, Arch, and bzr are the only SCMs I've not actively maintained a project in yet.
I've been using bazaar with various Ubuntu things. It is still slow, but being improved. I've been impressed with its merge capabilities, but I'm not a significant user of git, so I'm not sure I can make a reasonable comparison. :)
Eric Wilhelm wrote (snippet):
It's my impression that we're only talking about a single branch for one monolithic development iteration. To me, that sounds like svn. If I'm mistaken and the plan is to have multiple competing/cooperating branches ala kernel, then yes, darcs/mercurial/git make more sense.
I am very strongly in favor of having as less branches as possible, as this greatly simplifies things in my head. Moreover, investigating bugs can be swift without lots of clean builds (I am assuming each branch will need a clean build; on my windows machine at least). For me it is best to keep it simple stupid :) I like the tortoise tool sooo much, but I guess any GUI tool will do (I have used WinSVN or some tool with a similar name but I did not understand a single thing of it... maybe now I would though)
Regards, Johan
Bryce Harrington wrote:
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.
Reading that thread (git, mercurial, etc.) I hadn't seen mention of bzr (bazaar-ng), a canonical-backed distributed VCS written in python, which should at least be in the evaluation mix.
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.
Please don't overlook Trac, which seems very strong based on the results of the projects that have adopted it.
(users include many projects of inkscape's scale in community and codebase) http://trac.edgewall.org/wiki/TracUsers
(pet favorite feature) http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook
(sourceforge migration) http://trac.edgewall.org/browser/trunk/contrib/sourceforge2trac.py
(kitchen sink worth of add-ons) http://trac-hacks.org/
Trac developers conveyed at a recent informal discussion (PyCon 2007) that the git and mercurial backends are working, while the bzr backend might yet need a little work. Trac wouldn't limit inkscape to Subversion, at any rate.
On Tue, 27 Feb 2007 18:59:32 -0500, Jeff Kowalczyk <jtk@...36...> wrote:
Please don't overlook Trac, which seems very strong based on the results of the projects that have adopted it.
I'd second the recommendation of Trac.
-mental
On Tue, 27 Feb 2007, Bryce Harrington wrote:
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?
Has bugzilla been considered? Since Gnome, KDE, Mozilla, Freedesktop.org (including Openclipart) and many others use it that means many more people are familiar with it. Also if Inkscape were to request a place in the Gnome bug tracker it would be in a much better position to gain people willing to help out with testing and checking and general bug triage. (Joining Openclipart.org in the Freedesktop.org bug tracker might be another option to consider.)
The Sourceforge tracker doesn't have many advantages but the fact that someone else runs it is worth mentioning. if you were to go with Mantis is there an existing large project using Mantis that might make space for Inkscape in their tracker?
And in terms of the website maybe the existing Wiki could be reorganised in some way to reduce or avoid the need to switch to other systems and instead consolidate on what we have already?
On Wed, 2007-02-28 at 02:07 +0000, Alan Horkan wrote:
On Tue, 27 Feb 2007, Bryce Harrington wrote:
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?
Has bugzilla been considered?
While I would say that the default configuration of bugzilla us unusable, I really like the GNOME bug tracker.
Also, I think we shouldn't switch to something that can't use bug buddy someday. I think that utility would get us more stack traces (as it pretty much does it for the user) with our bugs.
--Ted
On 2007-February-27 , at 22:51 , Bryce Harrington wrote:
[...] 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.
Having an official manual distributed with Inkscape would greatly enhance its dissemination. People in my lab are progressively switching from Illustrator to Inkscape (Yay!... well, I must admit it's mainly because Inkscape is free and we do not have much credits for software in the lab but still, that's great ;-) ) and having a good, integrated manual is one of the thing they are missing (the other one being image format support: EPS import and PDF export mainly, btw). In comparison, The Gimp has gained more acceptance because the sys admins can just point newbies to the contextual help. Do you think Inkscape could have contextual help? I really think it would be of great help. I guess this would only come once content is finished but it might useful to check requirements for such a system beforehand.
Cheers,
JiHO --- http://jo.irisson.free.fr/
On 2/28/07 jiho wrote:
Having an official manual distributed with Inkscape would greatly enhance its dissemination.
You are right: an official manual should be available. I wouldn't like to undermine Tavmjong's effort, however, and I see nothing bad in Kevin's usinginkscape.com. But:
a) a user manual should be available without Internet access; b) a user manual should be available in as many languages as possible. c) a user manual has to be written in such a way that it could be used for context sensitive help; d) a user manual browser should have a search function; e) a user manual should be "aware" of existing tutorials.
The e) is an issue maker, since our tutorials are SVG files, not just illustrated hypertext. The idea behind SVG is great. But what is the real situation? Do users actually appreciate it? I've heard quite a dozen of times users complaining that opening a tutorial takes too much time and noone ever mentioned how much fun it is to be able to draw right in a tutorial.
So, if we want Inkscape's documentation to rock the world, we need to know:
1. Do we have human resources to maintain a good thorough user manual? If we do, what would be the best way to organize this work? 2. Do we have human resources to maintain translations (Cedric's & Kevin's XML file in SVN is about 500 Kbyte large)? If we do, what would be the best way to organize their work? 3. Is it possible to reuse GIMP's approach to context help? 4. What should we use as user manual's browser?
My thoughts on some of the above.
1. We do not have such human resources as of now. We have neither one single coordinator of the documentation effort, nor instant contributors. If I am wrong, please stand up high and blame me :)
2 . We _might_ have human resources to provide translation of the manual into _some_ languages. I know that at least German and Brazilian communities are quite active, dunno for others. There is no way a single person can instantly maintain such a huge translation, stay sane and be able to work to pay the bills :) A team of 2-3 people is a minimum. That's what I know from my experience with translation of GIMP's docs.
Please share your thoughts.
Cheers, Alexandre
participants (11)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
Bryce Harrington -
Eric Wilhelm -
Jeff Kowalczyk -
jiho -
Jon Phillips -
Kees Cook -
MenTaLguY -
Ted Gould