Ed,
Comments below.
On 12/07/2013 8:18 PM, Ed Willink wrote:
Hi
That's exactly what I mean by 'less prejudiced'.
Prejudice is a stronger word than bias.
The project committers can always produce a long list of reasons for
WONTFIX, often including time/money.
Indeed they can. They can even behave arbitrarily counter to all reason...
The users can produce a long list of WIBNIFs.
Indeed they can and do.
If an independent view considers the benefits are genuine and outweigh
the problems,
In a completely unbiased and unprejudiced way...
then it may be that once time/money is available a way should be found.
That's often the key point, as Doug mentions in a subsequent note on
this thread: the resource for addressing the reported issues. Neither
changing how bugzilla is monitored, how bugs are resolved, nor even a
fancy new issue tracking gizmo are going to help produce resource for
addressing a single reported issue. The time used on these is likely
better spent directly on addressing reported issues.
Perhaps an overruled WONTFIX could attract 'funding' from a foundation
let's-not-suck fund.
I'm sorry, but overruling my handling of the issues in the tracking
system for my projects seems highly counter to the spirit of open
source. And I can well imagine the extent to which the demand for funds
from a let's-not-suck fund will always exceed the bounds of the fund.
Ultimately if there is something that the user's resonably want, I
feel that we should be looking for a way to provide it.
"Reasonable" is certainly one of the key criteria, but of course
everyone feels what they want is reasonable, and who's to say who's
unbiased or unprejudiced and therefore ought to judge what's reasonably
reasonable, and who isn't?
I think Doug's other point of how best to get people actually involved
in the projects to address the lack-of-resource problem is a more
important focal point.
Ask yourself, as a committer with a significant amount of experience
working on your own project (i.e., you know a lot about how to work with
Eclipse's infrastructure), if you wanted to work on some other Eclipse
project Foo to provide a patch for a problem, how much work is it to do
the following:
* Extract that project's source repos; Does Foo have many repos?
Goodness forbid does it use SVN? If it uses git, does it also use
gerrit so you can commit changes for review?
* Ensure that you have the appropriate VM; Does Foo need Java 1.4,
1.5., 1.6 or 1.7 to be available? Do they have project specific
settings to help?
* Install the right tools in the IDE; Does Foo rely on build and
generator tools that you'll need to produce runnable code? Does Foo
rely on tools to work with its specialized artifacts?
* Provision a target platform with the right things needed by Foo just
to compile and run the tests. Are those dependencies documented?
Are there 30 such dependencies? Which p2 repos do those dependencies
come from? Which versions of the dependencies are needed by which
branches of Foo?
* Provision a workspace with the necessary projects; Are there 300
hundred of them? Are they logically grouped into working sets. Do
you have you have to figure that out yourself?
How many of these issues are well addressed by team project sets? Just
the last bullet I think. Also, consider this: how many of you have
tried one of those for project Foo, and ended up with a sea of errors
that can and will cost you hours to address? This is one of the key
barriers to entry, because those hours spent on setup time will drive
anyone but the most resilient to despair and saps the very lifeblood
from those we wish to tap for involvement and contribution.
Regards
Ed Willink
On 12/07/2013 18:57, Ed Merks wrote:
Igor,
I think it's even stronger than that. In the end, WONTFIX shouldn't
mean "I don't have time or I don't feel like it" but rather "it's
working as designed and changing it isn't what I believe is
appropriate". As such, even if someone provided a "fix," that's not
what's desired. Committers have the right and in fact an obligation
to maintain design integrity; sometimes that annoys people. In any
case, we're not obligated to spend every waking moment of every day
to fix every reported problem, though it sometimes feels that way....
Regards,
Ed
On 12/07/2013 7:26 PM, Igor Fedorenko wrote:
How is this going to help? In most/all cases bugs are not fixed because
nobody comes forward with quality fixes. Weather somebody says "it
needs
to be fixed" does not matter unless his/her words are backed up by the
code.
--
Regards,
Igor
On 2013-07-12 11:50 PM, Ed Willink wrote:
Hi
Get a committer from a related but independent project to review the
Bugzilla discussion to form a less prejudiced on view on whether the
WONTFIX is justified.
Regards
Ed Willink
On 12/07/2013 17:25, Doug Schaefer wrote:
It is. And I'm sure there are hate sites for every tool people use.
Eclipse isn't unique that way.
My point is that user experience is so important to our success, we
need to be sensitive to the issues our users are facing. There are a
lot of such issues marked WONTFIX, and CDT is as guilty of that as
anyone. I'm just wondering how we fix it.
Doug.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3349 / Virus Database: 3204/6486 - Release Date:
07/12/13
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
