Inkscape stats 9/15/05
I would respectfully disagree with both of the substantive points in this thread(!):
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Bryce Harrington wrote:
[ snip ]
Where the project needs help right now is in closing bugs. We have our bug tracker quite well under control, but there are 258 open bugs, and it would be wonderful if we could cut that down significantly before the 0.43 release. If you can code, please check out if you can help close one or two, ...
I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42!
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle).
Other projects keep from time to time some events called "bug party", when people clean the bug/feature tracker, collaborating over IRC and closing as much as possible as DUPLICATE, WON'T FIX, INVALID, RESOLVED or prioritizing. It may have the benefit of attracting new contributors and giving non-developers a way to contribute.
What do you think about the opportunity/usefulness of such a bug party?
At 258 bugs and 448 RFEs the number may be small enough and the action not needed.
I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones.
I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time.
I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important.
Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ...
That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
Ben
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Principally, _any_ pre-1.0 release should be considered as buggy.
I suggest the following scheme we seem to follow anyway:
0.43 - both bugfixes for 0.42 and new features 0.43.x - bugfix releases 0.44 - both bugfixes for 0.43 and new features 0.44.x - bugfix releases 0.45 - both bugfixes for 0.44 and new features
etc.
Alexandre
Alexandre Prokoudine wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Are you sure about NOW? more YESTERDAY :D
You are correct about a "black or white" approach not working, but I would expect if asked, end-users to incline more for features.
Principally, _any_ pre-1.0 release should be considered as buggy.
Well, we will *not* have a 1.0 for the foreseeable future...
I suggest the following scheme we seem to follow anyway:
0.43 - both bugfixes for 0.42 and new features 0.43.x - bugfix releases
I don't think we plan to have 0.nn.x releases, as those should happen only in case of major breakages (we had such things, but those were not planned)
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Alexandre Prokoudine wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
[ snip ]
Principally, _any_ pre-1.0 release should be considered as buggy.
Well, we will *not* have a 1.0 for the foreseeable future...
This is on the FAQ list, around number 9.
Ben
I apologise again, but I don't really agree with any of that:
On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Speaking personally, a lot of the software that I use evolved their necessary feature set around 10 years ago. I would always vote for quality and bug fixes, and in some cases actual removal of features. Whilst this sounds heretical, this is not a rare and not even an especially unusual point of view.
Principally, _any_ pre-1.0 release should be considered as buggy.
Yes, but we have end users using Inkscape for their regular work. They do not want regressions, and (to repeat) are entitled to have their views concerning features listened to.
Bear in mind that good software is made from bug reports, and we will only get bug reports if (to pick up a few necessary points) the software is overall reliable enough to trust, developers are responsive, total bug counts are low ...
I suggest the following scheme we seem to follow anyway:
0.43 - both bugfixes for 0.42 and new features 0.43.x - bugfix releases 0.44 - both bugfixes for 0.43 and new features 0.44.x - bugfix releases 0.45 - both bugfixes for 0.44 and new features
In the first place, this is the even/odd scheme without using the concept of the number '2'. You could also switch to NN-preview followed by NN (back to alpha, beta release candidate), or add a patch number (I think that perl and vim do that). These schemes either involve more work for little benefit or are appropriate for mature products. (You don't expect showstoppers in perl or in vim). Finally, they have the fearful circular problem that if we release 0.43.0 saying that .0 means it is not good enough for use, then we will not get the people we want to use it (those who will give good bug reports and feedback) to download it and try it. (Did you read the 0.42 Slashdot article: There is a lot of ignorance and a certain amount of hostility out there?).
I think that everything that we release should be as good as we can make it, and if something is forward looking (untested and could have showstopping bugs) then it should be labelled as -HEAD dr or possibly alpha.
Most significantly, you assume (in this schema) that it is sufficient for version 0.43 to fix bugs uncovered in version 0.42; to wit that we have a zero defect policy in place.
I may be wrong, or it may not be my place to say, but I think that we should cater for bugs going back months.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-0.1 or not possible owing to the large number of enhancements going through.
Ben
On Friday 16 September 2005 15:06, Ben Fowler wrote:
On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Speaking personally, a lot of the software that I use evolved their necessary feature set around 10 years ago. I would always vote for quality and bug fixes, and in some cases actual removal of features. Whilst this sounds heretical, this is not a rare and not even an especially unusual point of view.
I think there is still some confusion arising here, from the fact that the "users" who are interested in bug fixes are not the "users" who are interested in a new feature. At the same moment, different people need different things. So yes, both are needed NOW, from different users' points of view, but developers need to prioritise those requests, nonetheless.
I would suggest that fixing existing issues is more important than new features, unless a new feature is going to replace the buggy code anyway. Even obscure bugs can lead to important code cleanups, that make future work easier and better.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes.
How about having a policy that feature commits happen in a certain ratio to bug fixes? Everyone likes to code new features more than to fix obscure bugs, but if their new feature depended on either them or others getting bugs quashed, it might help to even things out.
On 9/16/05, Lee Braiden <lee_b@...786...> wrote:
How about having a policy that feature commits happen in a certain ratio to bug fixes?
Good point. And as for criteria of prioritization, I suggest official roadmap to be azimuth. E.g. if an RFE relates to plans for the next release, it should have highest priority, and if it relates to the last discussed and planned milestone or to a version beyond all discussed milestones, it should have the lowest priority.
Opinions? ;)
Alexandre
On Fri, 16 Sep 2005, Ben Fowler wrote:
Date: Fri, 16 Sep 2005 15:06:26 +0100 From: Ben Fowler <ben.the.mole@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
I apologise again, but I don't really agree with any of that:
On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
This is a "black or white" approach that won't work. Users never want either bug fixes or new features. They want both (and NOW :)).
Speaking personally, a lot of the software that I use evolved their necessary feature set around 10 years ago. I would always vote for quality and bug fixes, and in some cases actual removal of features. Whilst this sounds heretical, this is not a rare and not even an especially unusual point of view.
Principally, _any_ pre-1.0 release should be considered as buggy.
This is the assumption we have been working on but then people have been getting carried away saying how great Inkscape is even though we all know it has great big problems too.
We all like Inkscape and are enthusiastic about it but overselling it is counterproductive. There is an old story about a chieftian telling his daughter her husband in the arranged marraige was an ugly brute. He figured that way she would be pleased with whatever she got (as the story goes he was not ugly at all). We dont need to make big claims about Inkscape, if we can get them to try it users should quickly realise for themselves it is pretty good.
Yes, but we have end users using Inkscape for their regular work.
The reality is distributions are shipping Inkscape and users are expecting a level of stability more than developers expect. There is also no way distributions can keep up with the fast releases coming from inkscape as they are stuck on a 6 month/yearly cycle.
In the long term I think it would be good to have a stripped down stable supported release of inkscape maybe every six months or once a year to avoid the distributions shipping something which makes Inkscape look bad.
They do not want regressions, and (to repeat) are entitled to have their views concerning features listened to.
Listen to the users. Say thank you to them for making the effort to provide us with feedback. Explain the limitations, manage their expectations and get to the enhancements when we can. If they know not to expect too much they wont be disappointed. If we dont do this we allow a predictable problem to happen and users will expect as much as they expect from fully supported commercial software.
I think that everything that we release should be as good as we can make it, and if something is forward looking (untested and could have showstopping bugs) then it should be labelled as -HEAD dr or possibly alpha.
People are already treating Inkscape like it is a stable product even if it is in fact a fast moving alpha/beta stage project. Something should be done to accomodate or compensate for that perception.
(Are we still getting questions about the Extensions not found warning?)
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-0.1 or not possible owing to the large number of enhancements going through.
I'm not going to get into specifics but I think this discussion reveals a problem we are aware of on some level and needs to be managed.
This is where I expect Bryce to step in without some wise words, to crystalize the situation and suggest a workable plan to help manage it.
;)
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
I didn't mean to evince quite such a long thread as this!
Just to reinforce a couple of points here:
On 9/16/05, Alan Horkan <horkana@...44...> wrote:
On Fri, 16 Sep 2005, Ben Fowler wrote:
From: Ben Fowler <ben.the.mole@...400...> On 9/16/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 9/16/05, Ben Fowler <ben.the.mole@...400...> wrote:
Principally, _any_ pre-1.0 release should be considered as buggy.
We all like Inkscape and are enthusiastic about it but overselling it is counterproductive. ... . We dont need to make big claims about Inkscape, if we can get them to try it users should quickly realise for themselves it is pretty good.
I think the current 'blurb' is right: Inkscape is pre-1.0, but early adopters are using it for real work.
Yes, but we have end users using Inkscape for their regular work.
The reality is distributions are shipping Inkscape and users are expecting a level of stability more than developers expect. There is also no way distributions can keep up with the fast releases coming from inkscape as they are stuck on a 6 month/yearly cycle.
If this is a major problem, then we switch to an even/odd system and urge packagers to only pass downstream the even ones, or we do once or twice a year a stable release specifically for packagers, This might be too much work until after 1.0, by which time the problems will have changed anyway!
In the long term I think it would be good to have a stripped down stable supported release of inkscape maybe every six months or once a year to avoid the distributions shipping something which makes Inkscape look bad.
I agree.
They do not want regressions, and (to repeat) are entitled to have their views concerning features listened to.
Listen to the users. Say thank you to them for making the effort to provide us with feedback. Explain the limitations, manage their expectations and get to the enhancements when we can. If they know not to expect too much they wont be disappointed. If we dont do this we allow a predictable problem to happen and users will expect as much as they expect from fully supported commercial software.
I am not sure that users want to be managed, but the 'ear'y adopters' should be treated as full partners so far as directing the goes.
I think that everything that we release should be as good as we can make it, and if something is forward looking (untested and could have showstopping bugs) then it should be labelled as -HEAD dr or possibly alpha.
People are already treating Inkscape like it is a stable product even if it is in fact a fast moving alpha/beta stage project. Something should be done to accomodate or compensate for that perception.
My suggestion is to accommodate it by having at all times a stable branch and/or occasionally having bug fix only releases - 'No new features' - to prove that we mean to keep the count of outstanding issues controlled.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-0.1 or not possible owing to the large number of enhancements going through.
I'm not going to get into specifics but I think this discussion reveals a problem we are aware of on some level and needs to be managed.
This is where I expect Bryce to step in without some wise words, to crystalize the situation and suggest a workable plan to help manage it.
A chunk of the 'Roadmap' page on the wiki seems to be missing.
See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists the Feature Freeze section.
Ben
On Sat, Sep 17, 2005 at 01:49:39PM +0100, Ben Fowler wrote:
Yes, but we have end users using Inkscape for their regular work.
The reality is distributions are shipping Inkscape and users are expecting a level of stability more than developers expect. There is also no way distributions can keep up with the fast releases coming from inkscape as they are stuck on a 6 month/yearly cycle.
If this is a major problem, then we switch to an even/odd system and urge packagers to only pass downstream the even ones, or we do once or twice a year a stable release specifically for packagers, This might be too much work until after 1.0, by which time the problems will have changed anyway!
I've thought a lot about this and paid close attention to how the project works from release to release since we started. I've noticed several things.
As a general rule, I've noticed that each release is much more stable than the one that went before, even the releases that are very development-heavy. This makes sense; whenever bugs are found in the previous release, the bug fixes go in for the next release.
So far, there hasn't been a lot of developer activity in backporting fixes. The 0.42.2 release was the first that really did this aggressively, although we've backported fixes in the past. I'm quite interested to see how things turn out following the 0.43 release. Will people take interest in backporting fixes and creating a 0.43.x series? Will we pour all of our focus into an extra-stable 0.44?
Most of the destabilization that occurs in new releases is localized to areas where new features are added. This makes sense; people aren't just randomly going through and fiddling with code for no reason. And for most of the feature work, the changes rarely break more than the specific functionality they're working on. This is good; this means that when a new feature comes out, if it brings new bugs along, those bugs are mostly only going to break that feature, so you could simply report the issue and then ignore that feature until the next release.
However, in practice I notice that new features really get early adopter users excited and they get really involved in playing with it and trying it out. They break it in all sorts of ways and talk directly to the developer, who often has a fix out within days. Thus, usually by the time a feature gets out into a release, it's been through a heavy "play testing" period and actually has a very high degree of quality. If there are remaining issues, it's usually due to lack of time to complete it rather than lack of review. This aspect of being able to team users, testers, and developers together in such a tightnit feedback loop is Inkscape's secret weapon and I think it's the reason we've been able to advance so aggressively. This is a killer competitive advantage open source has over commercial companies; I bet if we keep doing what we're doing, within a year or two Inkscape may start really making some serious inroads against the commercial apps.
Furthermore, while intuition would suggest that it is new features that bring the new bug reports, in reality I see just as many if not more bug reports arising due to use of Inkscape in new environments. For example, we got a whole nest of internationalization bugs once it started getting used by people in other countries. We've also gotten tons of bugs from users of operating systems, hardware platforms, or distros we've never tested on before. People also find unusual ways to configure Inkscape - e.g., with different input devices, with oddball sets of old or new libraries, etc. All these are legitimate bugs, but none are due to feature work; we could put out a release with no new features and see just as many of these bug reports.
I am not sure that users want to be managed, but the 'ear'y adopters' should be treated as full partners so far as directing the goes.
You're exactly right. In fact, I make a practice of when a new user expresses a need for some feature or other, if no one else is working on them, to ask, "Do you code?" If they say yes, I immediately invite them to work on that feature. I've been fairly astounded how often this actually works. I'd expect that 99% of the time the person wouldn't have the time, knowledge, or interest, but in reality I find that 25-50% of the users I ask actually react positively to the invitation to join. Even the ones that don't code will often put in time helping out in various non-coding areas.
People are already treating Inkscape like it is a stable product even if it is in fact a fast moving alpha/beta stage project. Something should be done to accomodate or compensate for that perception.
My suggestion is to accommodate it by having at all times a stable branch and/or occasionally having bug fix only releases - 'No new features' - to prove that we mean to keep the count of outstanding issues controlled.
I think both of these are excellent suggestions. Of course, like I said above, many of the bug reports we see are due not to new features but new environments. So while I think it would be good practice to have a release 100% focused on bug fixing, I suspect that restricting feature work would not actually have that much effect on the count of outstanding issues. Maybe 5-10% less, but not really enough to make it worth the impact to developers by making them stop working on cool new features. Still, sh*t happens, and you're right that this approach could be an effective way to improve quality.
Management of a stable branch would be best if we had someone dedicated to maintaining that branch. If you'd be interested in doing that, I think the other devs would be open to having you fill that role. If not, I think we'd need to find a volunteer, since most of the current devs are occupied with other efforts and wouldn't have enough time to devote to it. I don't know how much work it'd be to backport fixes and put out stable point releases, but I think you're right that users would get a lot of value out of it.
Now, I've been thinking of these same issues, but from a somewhat different context. Given that so many of our bugs come not from new features but from people just starting to test in new environments (such as on platforms that most devs don't have access to), my thought is that the most effective way to achieve better quality would not be a more rigid release process, but rather a more formalized, aggressive testing process.
I think that by applying formalized testing methods such as regular regression testing, usability testing, interoperability tests, and so forth, we will scare out a lot of these bugs before users have to run into them. As well, by doing this testing routinely, it will help us flag issues that might recur; for instance, issues that cause Inkscape to have trouble on 64-bit hardware, or on OSX, or when run with uncommon language settings.
One of the cool things about this sort of testing is that it's quite ameniable to automation. For instance, you can write a short script that sets the language setting to each of a dozen languages, then run Inkscape in various automated ways, checking if it crashes.
I'm also excited about the potential of building a tester community who can do testing work prior to each release. I think a lot of bugs that get through into a release do so simply because no one was actively looking for them. Developers were busy developing, users were busy using, and the rest were simply focused on watching the bug count drop. By having a group of a few people doing some organized banging on the app, we can have greater assurance that when the release comes out, that there will be fewer bugs.
This is why I suggest that from a developer's point of view, we either need to be able to slipstream older bug fixes (my thaw policy as outlined above) or have protected releases when we only do bug fixes. Obviously the latter might be ruled out if you felt it was anathema, unnecessary pre-1.0 or not possible owing to the large number of enhancements going through.
I'm not going to get into specifics but I think this discussion reveals a problem we are aware of on some level and needs to be managed.
This is where I expect Bryce to step in with some wise words, to crystalize the situation and suggest a workable plan to help manage it.
Hopefully the above dissertation fulfils this role. ;-)
You can probably see I was thinking along the same lines as all of this myself; I'd proposed a few ideas like bugfix only releases, etc. in the past, to gauge their viability, but came to the conclusion that a distinct, organized testing effort would be the most effective way of addressing these issues. That's why I proposed and set up the inkscape-tester community. I could really use all of your help in pushing that forward and solidifying it. We need a lot of good ideas to help get that group up and running. We need to find how to make it fun and exciting so people want to participate in it. And we need good tools and processes that make it convenient to find and report what we find in our analysis.
I would absolutely love it if we could start a regular inkscape-tester process of doing aggressive pre-release testing around the time of the hard freeze. I think this would fill a major needed gap in our release process, and it could be a lot of fun!
A chunk of the 'Roadmap' page on the wiki seems to be missing.
See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists the Feature Freeze section.
Could you stick in questions on those pages? Then myself or someone can flesh those things out when we run across them.
Thanks, Bryce
Quoting Ben Fowler <ben.the.mole@...400...>:
or have protected releases when we only do bug fixes.
That's the proper role for the 0.x.y releases, yes.
I don't think anyone would object to doing them more frequently, for less severe bugs, if someone wanted to volunteer to do the backporting of fixes, but right now we don't have anyone available for that.
(I did it for the 0.42.x releases, but that was at the expense of a lot of work I might have done for 0.43, including groundwork for the oft-requested layers dialog)
-mental
Quoting Ben Fowler <ben.the.mole@...400...>:
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
Yeah. What you describe has been our practice since the beginning.
Now, the 0.43 release cycle has been atypically short, with a long freeze relative to the overall length of the cycle. But we did unfreeze immediately after the 0.42 release...
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
It would be nice if the Sourceforge tracker supported that kind of annotation -- ideally I would like the ability to stick in a "release bug", and make its closing dependent on the resolution of various "must-fix" tasks and bugs.
But SF's tracker is too primitive to really support that. :/
-mental
On Fri, Sep 16, 2005 at 04:34:18PM -0400, mental@...3... wrote:
But SF's tracker is too primitive to really support that. :/
We might want to consider "moving on" and looking to host a bugzilla somewhere. I've had a few situations where I thought "oh, damn, I can't do that in SF's tracker..."
(or some other kind; I just prefer bugzilla because I'm familiar with it)
On Fri, 16 Sep 2005, Kees Cook wrote:
Date: Fri, 16 Sep 2005 17:41:01 -0700 From: Kees Cook <inkscape@...62...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On Fri, Sep 16, 2005 at 04:34:18PM -0400, mental@...3... wrote:
But SF's tracker is too primitive to really support that. :/
We might want to consider "moving on" and looking to host a bugzilla somewhere. I've had a few situations where I thought "oh, damn, I can't do that in SF's tracker..."
(or some other kind; I just prefer bugzilla because I'm familiar with it)
No, bugzilla is just better ;)
I'm very familiar with it too from years of Abiword and Mozilla. It is certainly a complicated system, clunky like your average web application (but no more so than webmail) and took a little getting used to at first I admit but I've never thought the Sourceforge bug tracker was better in any way.
There is the benefit that all of Gnome, KDE, Mozilla and even OpenOffice (uses a particulary weird version) all use Bugzilla.
- Alan
On Sep 16, 2005, at 7:28 PM, Alan Horkan wrote:
On Fri, 16 Sep 2005, Kees Cook wrote:
Date: Fri, 16 Sep 2005 17:41:01 -0700 From: Kees Cook <inkscape@...62...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On Fri, Sep 16, 2005 at 04:34:18PM -0400, mental@...3... wrote:
We might want to consider "moving on" and looking to host a bugzilla somewhere. I've had a few situations where I thought "oh, damn, I can't do that in SF's tracker..."
(or some other kind; I just prefer bugzilla because I'm familiar with it)
No, bugzilla is just better ;)
Better for some things, but not for others.
My vote is definitely that for our main needs the SF tracker is OK. Not great, but OK.
In raw capability Bugzilla has more capabilities, but much of the complexity goes against some of our main needs, including a low barrier to entry for outsiders.
I've used many other systems over the years, and I think the basics are all there. So far I've not seen enough added value in switching to anything else. Yes, there are some benefits, but I've not seen enough to tip the balance.
Now, Mozilla is another matter. For them it might be good. However, if you'd like my opinions on much of that you'll have to ask me privately. (A bit off-topic for this list).
On Fri, 16 Sep 2005, Jon A. Cruz wrote:
Date: Fri, 16 Sep 2005 19:43:31 -0700 From: Jon A. Cruz <jon@...18...> To: Alan Horkan <horkana@...44...> Cc: Kees Cook <inkscape@...62...>, Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On Sep 16, 2005, at 7:28 PM, Alan Horkan wrote:
On Fri, 16 Sep 2005, Kees Cook wrote:
Date: Fri, 16 Sep 2005 17:41:01 -0700 From: Kees Cook <inkscape@...62...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On Fri, Sep 16, 2005 at 04:34:18PM -0400, mental@...3... wrote:
We might want to consider "moving on" and looking to host a bugzilla somewhere. I've had a few situations where I thought "oh, damn, I can't do that in SF's tracker..."
(or some other kind; I just prefer bugzilla because I'm familiar with it)
No, bugzilla is just better ;)
Better for some things, but not for others.
My vote is definitely that for our main needs the SF tracker is OK. Not great, but OK.
In raw capability Bugzilla has more capabilities, but much of the complexity goes against some of our main needs, including a low barrier to entry for outsiders.
Which is why I pointed out bug-buddy.
When it comes to low barrier of entry I think other ways such as the wiki, the mailing list (list admins would have to clear messages from non-subscribers but I expect you must do that already) or even IRC/Jabber Chat allow user to come in and express their opinion. Any really good suggestions should motivate us enough to create a bug report for the issue even if the user doesn't want to, that would bring the barrier even lower if that is what you really want.
I've used many other systems over the years, and I think the basics are all there. So far I've not seen enough added value in switching to anything else. Yes, there are some benefits, but I've not seen enough to tip the balance.
I never going to stop pushing you guys to get more closely invovled with Gnome, just as others will always care about implementing the SVG standards or writing well documented code. (Having said that there are projects in Gnome CVS less involved with Gnome than Inkscape is already but it is something I believe is important and can be beneficial.)
While I'm jumping from subject to subject I may as well mention that mirroring the po files in Gnome CVS would be a good way to improve the quality and consistency of the translations too (been discussing it in the context of another project and the Ubuntu rosetta project has potential too).
Now, Mozilla is another matter. For them it might be good. However, if you'd like my opinions on much of that you'll have to ask me privately. (A bit off-topic for this list).
I'd be interested to know more about what you consider the downsides of Bugzilla as I haven't experienced that many bug trackers (and issue ticketing systems seem to fit into a different category and serve quite a different purpose). Please do let me know on or offlist about what you dont like about Bugzilla.
Sincerely
Alan Horkan. http://advogato.org/person/AlanHorkan/
But SF's tracker is too primitive to really support that. :/
if we moved to Gnome bugzilla it wouldn't be so primative
anonymous bug reports wouldn't techincally be allowed but if Bug-buddy support was added then you would have an even easier way for even more ordinary users to contribute and a variety of automated techiniques to weed out more obvious duplicates and quite probably if we're luckly a little more help with the bug tracking from the Gnome bug team.
Sincerely
Alan Horkan
Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/
Ralf Stephan wrote:
But SF's tracker is too primitive to really support that. :/
if we moved to Gnome bugzilla it wouldn't be so primative
anonymous bug reports wouldn't techincally be allowed
That is why I am against bugzilla, as I agree anonymous reporting is a must.
After spending a little time in the feature tracker, I would incline against anonymous requests, as you will see a lot of "hi, it would be cool to have SWF export/drop shadows/etc." and some cryptic requests without any follow-up with details.
nicu:
After spending a little time in the feature tracker, I would incline against anonymous requests, as you will see a lot of "hi, it would be cool to have SWF export/drop shadows/etc." and some cryptic requests without any follow-up with details.
Since you talk about the feature tracker and I was following up to a msg on the bug tracker, those two obviously differ in the level they can bear anonymous requests.
ralf
On Sat, Sep 17, 2005 at 03:49:28PM +0200, Ralf Stephan wrote:
nicu:
After spending a little time in the feature tracker, I would incline against anonymous requests, as you will see a lot of "hi, it would be cool to have SWF export/drop shadows/etc." and some cryptic requests without any follow-up with details.
Since you talk about the feature tracker and I was following up to a msg on the bug tracker, those two obviously differ in the level they can bear anonymous requests.
One idea I've kicked around but never done anything with is a two-tiered tracker.
The entry level is designed to be simple, easy to use, and accessible for anyone to submit any random thought, request, bug, etc.
The main level is an advanced bugzilla-like tracker with full details, tracking info, etc. It requires an account to access and participate in.
In general, the entry level tracker is ignored by the developers; by definition it's info is rarely going to be fully baked enough to bother with, and it's going to be hard to follow up on the issues.
However, the entry level tracker is a bit different than a regular bug tracker in that it enables users to collaborate, share notes, and help each other. The idea being to make it easy for them to collect info and notes on bugs, and support each other.
If/when an item in the entry level tracker gets enough detail, has a contact person assigned, enough data for replication, etc. the item can be "promoted" into the main tracker for developers to work on.
Since everyone knows that the entry level tracker is ignored by the developers, there would be motivation to work on improving the items enough to be viable in the main tracker.
Also, it would be possible for developers to bump incomplete reports out of the main tracker into the entry tracker. Thus, if it's just too poor of a report, the developers can kick it out and not worry about it, knowing that if it's important, the users will accumulate better info into it and try again later.
The things I haven't quite sorted out with this idea are: Would there really be enough users willing to spend time improving other people's trackers? Would this delay getting important items reported to devs? Would it end up that for orthogonal issues that everyone just ends up using one tracker or the other for everything? Would this actually stifle communication between users and developers, rather than improve things?
Anyway, due to all these uncertainties I don't know if this idea is viable. But who knows, maybe someone has some further insights that could make this idea actually workable.
Bryce
On Sat, Sep 17, 2005 at 03:18:55AM +0100, Alan Horkan wrote:
anonymous bug reports wouldn't techincally be allowed but if Bug-buddy
I actually modified the kernel.org bugzilla to allow anonymous comments (and email comments), and expanding that to anonymous bug reports probably wouldn't be too hard.
participants (10)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
Ben Fowler -
Bryce Harrington -
Jon A. Cruz -
Kees Cook -
Lee Braiden -
Nicu Buculei -
Ralf Stephan