On 15 Jun 07, at 4:27 AM 15 Jun 07, Kenney Westerhof wrote:
Hi,
I'd like to ask that issues reported by PMC members and core
developers
get less strict reviews.
Well, you would most likely assign them to a version/component and
possibly assign them to yourself so they wouldn't end up in the
review pile. That category is really for incoming issues.
When I find an issue that's rather complex I usually describe
how to reproduce it, but I lack the time to write sample projects, at
least when reporting. When i get around to it I reproduce the issue
and fix
it in svn - I normally don't attach tests since I can commit in
core, and i think
that goes for more developers.
If you're keeping track that's fine but if you want anyone else to
work on it you need to be able to reproduce it. And you need to take
the sample project and turn it into tests or and IT.
Anyway, the incomplete resolution is fine, but closing them will
make them rather hard to find back. Maybe we could just assign
these issues to the
reporters instead, status to 'feedback' or 'incomplete', 'on hold'
or whatever.
The reporters will get email when it's closed and see the message.
In the future I'll try to attach the tests as I create the issue,
though that'll
take me 30 mins more and when I'm in time pressure I feel it's
better to report
the issue so it doesn't slip my mind, than to not do it at all
because of the high
overhead.
It makes you think about it. If you don't report with a project then
it's going to take someone else an hour to guess at the exact project
structure that caused the failure. I think what they do in Mylar
where creating a context is mandatory, and providing some form of
test so that the whole environment is setup to deal with the issue.
We're not quite there but trying to look at complete issues I now
feel is a waste of my time, and waste of anyone else's time trying to
fix an issue. The users who get attention will be those that make the
effort to provide us with tests. It's that simple. We don't have
infinite free time and at least will help those who make the effort
right now because we need the information.
Could we make this easier in the future? Absolutely, taking a
standard stack trace or specially formatted "core dump" that we can
read with a utility we could do at some point which might help us
pinpoint a problem very quickly but ultimately we need a project as a
basis for a test. Are we going to be more productive taking 10 issue
in a month with good samples and use cases, or a 100 crap issues that
provide almost nothing except a stack trace and a one liner. If
someone can't take the time to write a couple sentences and provide a
project I'm not looking at it.
wdyt?
-- Kenney
Jason van Zyl wrote:
Hi,
The 2.0.7 release will go out tomorrow, and in order to get some
decent vote feedback it would be good to clean up JIRA so that we
have an accurate 2.0.x list people can vote on for issues they
would like fixed in 2.0.8. I created a "Documentation" version so
that technical issues wouldn't be polluted by documentation
issues. I also created a "Reviewed Pending Version Assignment"
where I put everything that's probably been looked at (probably
not entirely true) so that anything coming in from now on in the
unscheduled we can process. I think between all of us we can
probably keep that empty most weeks by assigning a version,
closing if duplicated, or closing due to being incomplete.
Some simple things you can do if you have a few minutes to spare:
- look in the reviewed pending version assignment and try to put
the issue in 2.0.x or 2.1.x
- pick your favorite component and look for duplicates
- issues describing a remotely complicated problem without a
sample project get close as incomplete
- look at issues you've reported and check and see if they have
been resolved
- linking issues up that look similiar so we can close issues
together if they are resolved.
Even if we get rid of the complete cruft like already resolved,
dupes, and incomplete issues that will greatly help.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
