Thanks for your reply, Liam. On June 19, 2011 01:51:57 PM Liam R E Quin wrote: > On Sun, 2011-06-19 at 13:11 -0400, Yuval Levy wrote: > > I am trying to make sense of the discrepancy between > > > > April 2008: http://www.markshuttleworth.com/archives/135 > > > > and > > > > June 2011: https://bugs.launchpad.net/inkscape > > > > (634 new, 3083 open) ? > > I don't see a discrepancy. The first report is not about open vs closed > bugs, it's about new vs "triaged" bugs - i.e. whether or not the bugs > have been categorised and identified as bugs.
In 2008 the project went from 1800+ new to about 100 new. If this was just a consequence of the tool used (as implied in the first article), going back up to 634 new needs an explanation. Then maybe there is my expectation that once the gates are open, the river will start flowing unencumbered? Opening the gates of the bug tracker, and triaging the bugs, has seemingly not helped much. I have done something similar with Hugin about half a year ago, and the initial results were great: everything got triaged / sorted out. duplicates and outdated reports have been weeded out, giving us a clearer picture. some bug fixing has started. but bug fixing has not accelerated and as the in-flow of reports increases instead of ending up at an equilibrium with a higher capacity for bug processing we end up in a disequilibrium with an even higher number of new or open bugs - the bush becomes thicker again and the overview is lost... > Note also that Inkscape is not in fact an Ubuntu-only project. nor is Hugin. you don't need to be an Ubuntu project to use the Ubuntu infrastructure. I have driven the migration of our bug tracker from Sourceforge to Launchpad because I found Launchpad easier to use and because I hoped it would help us improve ticket processing. I have looked at Inkscape as a successful example. I perceive Inkscape as being ahead of us and I am trying to learn from their experience. > If no-one else has commented on it my guess would be that not many other > people are in that position. It often happens that one person, or a few > people, are unable to use a particular program at all (a "critical" > bug). The solutions for them are generally one or more of... > (1) fix the bug and submit the fix as a patch (this is the Open Source > Way) > (2) hire or bribe a programmer to fix the bug and submit the fix as a > patch > (3) persuade one or more active developers on th project that the bug > should be fixed, or if it it's easy, that you'll go away if it's > fixed :-) > (4) use a different program > > For (3), which you are trying to do, you typically need to become part > of the project community actually I'd be happy with (1) but need guidance and have not yet found the right entry point for me. This is one point in which Hugin may be ahead of Inkscape (or, more likely, I may not be aware of the Inkscape resources out there). When I got on the Hugin bandwagon, building it for your own platform was a Mammoth task for wizards. I nagged the developers for long enough and mobilized the wizards in the community until the project had a build documented in painful detail, enabling even the most newbie of newbies (like I was) to get easily on the learning curve and start hacking. Building the code from source is the first pre-requiste for (1). > In this particular case, though, it's hard to rotate a bitmap except by > multiples of 90 degrees and not lose sharpness or detail, and it's hard > to scale a bitmap, especially trying to make it larger as you're then > asking the computer program to add detail on the fly. I am actually trying to downsize more than upsize, but yes, this case should also be considered. > You might find the gimp does a better job at these two tasks than > Inkscape. I did, and indeed this is how I solved my problem - at least partially. It is still not a nice solution because I would like to place those bitmaps inside enriching SVG drawings that are then rendered for the final bitmap for web or print. At the moment, many changes in the SVG drawing force me to re-render the bitmap and it is all a cumbersome manual process, and something that I believe could be automated. > My guess would be that a good architectural approach might be > for Inkscape to use the babl and gegl libraries to rotate and scale > bitmaps for export to png, wit appropriate box filters sounds like the approach for me. whether I have the skill and knowledge to implement it, i doubt it, but at least i can try if i know how to build Inkscape from scratch and where to start hacking. I built Gimp from scratch a couple of years ago, I guess I can get back at it. The other thing about this, and the reason why I place it at the create level: scaling and rotating of bitmaps seems to me like an operation common to many tools. Wouldn't it make sense to have a single, shared library for that, so that advances in technology benefits everybody automatically? > there would > still be problems with shapness if you took a 100x100 pixel image and > scaled it to be 500x500 pixels in the rendered output, or if you tried > to rotate a bitmap image by (say) 3.5 degrees. I look forward for that problem, because it means that the first part of the problem is solved :) > I've only tried to address your specific questions. I asked plenty of questions for which I need an historical perspective, ideally from somebody who has been involved in Inkscape for the past four years or so. Your answer sure help a few of my questions, but not the main ones. > Open Source projects do of course have life cycles, and often do end up > abandoned, or get merged into some other project or taken over, or the > goals of the developers change and the program mutates to do something > entirely different. I'm not closely involved with Inkscape, but as far > as I can tell it's being actively developed; the version I have here was > released in February 2011, and I see from the Inkscape.org that the > development version just got a new feature as of this June. This is on a very high level, I am interested a level or two deeper into detail. Hence my questions about what happened to the teams of triagers and developers in the past four years. An attempt to predict a possible outcome for Hugin in three years. > To some extent each project has its own culture. This is part of what > makes a conference like LGM so exciting. Yes, culture is part of the equation. I vaguely recall that Inkscape is the result of a fork, and that the original project dried out unmaintained. History and culture are what make us and understanding them is equally important as understanding the technicalities of a project). I regret missing LGM this year but simply could not make it. I was underwater then and am barely back up to the surface for a breath of air now, I hope I can make it to a future edition of LGM, although for the next three years an additional (self-imposted) constrain is being added: I am going back to university in September. Less money. Less free time. But I am happy. Yuv > > Liam
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ CREATE mailing list CREATE@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create
