I've become interested in Inkscape again and I'd like to figure out a good way to contribute. Here's a couple things I thought I'd throw out there:
1) I'm used to Bugzilla, has there been any discussion about moving away from a Sourceforge Bug Tracker into something a little more powerful (in terms of search?
2) In Mozilla, anyone can submit a patch to a bug, then the admins/super-reviewers must accept and merge the patch. Is there a mechanism for this within Inkscape? For instance, I'd like to report a bug against a SVG tutorial and then post a suggested fix for it that an admin can take and merge into the codebase. Similarly, my ambitions would be to get into the source code of Inkscape eventually and attempt another patch (this is more of a long-term goal though). Basically is there a way for the "casual" developer to submit patches in a standardized way?
Thanks, Jeff
On Mon, 19 Mar 2007 11:01:08 -0500, "Jeff Schiller" <codedread@...400...> wrote:
- I'm used to Bugzilla, has there been any discussion about moving
away from a Sourceforge Bug Tracker into something a little more powerful (in terms of search?
It's being discussed, but we're still working on reaching a consensus among the admins. Personally I'm advocating Trac.
- In Mozilla, anyone can submit a patch to a bug, then the
admins/super-reviewers must accept and merge the patch. Is there a mechanism for this within Inkscape?
The best approach is to post your patches to the patch tracker, and then notify the mailing list (ideally with a summary of what the patch fixes, so people can figure out if the affected code is their area of interest/responsibility or not). If a couple of your patches pass review and are accepted, we'll just give you commit access. At that point if you want guidance or code review, I'd recommend the Jabber conference room, or failing that the mailing list again.
-mental
On Mon, Mar 19, 2007 at 11:01:08AM -0500, Jeff Schiller wrote:
I've become interested in Inkscape again and I'd like to figure out a good way to contribute. Here's a couple things I thought I'd throw out there:
Heya Jeff,
Currently one area we've been working on is setting up an Inkscape manual site at inkscape.org/manual/ that allows people to collaboratively edit the manual, but also be able to export it in docbook and other formats. The focus so far has been to build on Kevin Wixson's excellent work, and combine into it our official french Inkscape user manual by Pygmee and Yemanja.
The system is working fairly well, although there are lots and lots of rough edges I'm still working on. The manual itself is outlined and a few pages have been filled in, but it will need lots of additions before it can be considered ready for public use. It would be wonderful to have your help with this.
Longer range, as we gain experience with drupal, my hope is that we can expand its use into other areas of our website. So I'm also looking at other modules and webapps that integrate nicely with drupal.
Bryce
Bryce,
Frankly, I think the SVG tutorials included with Inkscape are excellent - I haven't found a strong need for anything else, in terms of documentation. I find the "work-in-the-tutorial" paradigm in Inkscape to be very effective way of learning and quite unique - are there any other software products that do this? And thankfully these tutorials are all offline, meaning I can travel and still learn how to use Inkscape. If anything, I would like to contribute to improving/correcting these tutorials as a first contribution (already found a couple bugs/typos).
So how does one go about submitting patches to these tutorial SVG files? Is it best to edit the tutorial in Inkscape directly and then do a svn diff? I found that there are huge differences when I do this, even for a one-word change. And the resultant patch is not very review-friendly (lots of RDF stuff seem touched, etc). Is it better to just submit the entire SVG file instead of a diff patch? If so, how do reviewers tell what has changed?
By the way, would it maybe be better to save the tutorial files as Plain SVG (without metadata) to avoid such metadata-like changes?
After that, I would like to work on the code, though I'm still struggling to build Inkscape in OpenSUSE 10.2. Unfortunately I've had no end of problems in doing this thus far, though when I discover something out, I'll contribute to pages like http://wiki.inkscape.org/wiki/index.php/CompilingSuse
Regards, Jeff
On 3/20/07, Bryce Harrington <bryce@...961...> wrote:
On Mon, Mar 19, 2007 at 11:01:08AM -0500, Jeff Schiller wrote:
I've become interested in Inkscape again and I'd like to figure out a good way to contribute. Here's a couple things I thought I'd throw out there:
Heya Jeff,
Currently one area we've been working on is setting up an Inkscape manual site at inkscape.org/manual/ that allows people to collaboratively edit the manual, but also be able to export it in docbook and other formats. The focus so far has been to build on Kevin Wixson's excellent work, and combine into it our official french Inkscape user manual by Pygmee and Yemanja.
The system is working fairly well, although there are lots and lots of rough edges I'm still working on. The manual itself is outlined and a few pages have been filled in, but it will need lots of additions before it can be considered ready for public use. It would be wonderful to have your help with this.
Longer range, as we gain experience with drupal, my hope is that we can expand its use into other areas of our website. So I'm also looking at other modules and webapps that integrate nicely with drupal.
Bryce
On Tue, Mar 20, 2007 at 01:34:54PM -0500, Jeff Schiller wrote:
Frankly, I think the SVG tutorials included with Inkscape are excellent - I haven't found a strong need for anything else, in terms of documentation. I find the "work-in-the-tutorial" paradigm in Inkscape to be very effective way of learning and quite unique - are there any other software products that do this? And thankfully these tutorials are all offline, meaning I can travel and still learn how to use Inkscape. If anything, I would like to contribute to improving/correcting these tutorials as a first contribution (already found a couple bugs/typos).
Great, well there's more then plenty of work needed for new tutorials. We'd love to see tutorials on subjects not already covered, or even non-Inkscape-specific things like general guidelines about making good art, diagrams, logos, and so on.
One way to see what tutorial topics people need is to browse through mail archives of the inkscape-user@ mailing list for questions that get asked repeatedly, and create tutorial entries to address them. For instance, we get *many* questions related to document export (PDF, JPG, etc.), and lately have gotten a number regarding blur.
Of course, also just general updates to the existing tutorials are quite welcomed.
So how does one go about submitting patches to these tutorial SVG files? Is it best to edit the tutorial in Inkscape directly and then do a svn diff?
Actually the best way is to edit the source files. The source files for the tutorials are written in Docbook format, which is XML like SVG, but a much simpler syntax. You check these out from the doc-docbook subversion module, and there are directions in that module.
However, if you don't want to mess with subversion and docbook, you could go ahead and edit them in Inkscape and post a diff to the patch tracker. I would probably make a non-edit to the original and save it to do a diff against, to avoid the huge differences.
I found that there are huge differences when I do this, even for a one-word change. And the resultant patch is not very review-friendly (lots of RDF stuff seem touched, etc). Is it better to just submit the entire SVG file instead of a diff patch? If so, how do reviewers tell what has changed?
Again, I think most people use the original docbook files, which avoids pretty much all these issues.
Other people just write textual descriptions of what should change in the text into a bug report, especially when it's just text changes.
By the way, would it maybe be better to save the tutorial files as Plain SVG (without metadata) to avoid such metadata-like changes?
It wouldn't matter since the SVG is all generated from the docbook files automagically. Plain SVG strips out information from some things which would make the drawings less useful in the inkscape tutorial; for example, stars or spirals would lose their star-ness or spiral-ness, so in general even aside from docbook I think for the tutorials you want to save in regular svg not plain svg.
After that, I would like to work on the code, though I'm still struggling to build Inkscape in OpenSUSE 10.2. Unfortunately I've had no end of problems in doing this thus far, though when I discover something out, I'll contribute to pages like http://wiki.inkscape.org/wiki/index.php/CompilingSuse
Great, that's exactly the right approach. Historically, getting Inkscape to work on SuSE has always been a bit problematic, but it can be done. I don't know that any of our developers test against SuSE regularly, though, so your efforts here will probably help out a lot of future SuSEr's.
Bryce
participants (3)
-
Bryce Harrington
-
Jeff Schiller
-
MenTaLguY