[Tracker-discuss] 'regression' type

[Georg Brandl]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 08.04.2010 09:25, schrieb anatoly techtonik:

>> That's on purpose. We have had issues in the past of reporters disagreeing
>> with how important an issue is and flipping the state to something else
>> *after* a core developer already changed the priority.
> 
> I think it is a normal workflow. How else could people state that
> issue is important for them? In Google there are stars, in Bugzilla -
> votes. In other projects such as Trac there are 'priority' and
> 'severity'.

Sorry, but I think you're mixing up concepts here.  I agree with Martin
(and Brett) that it needs to be reserved to developers (which is not the
same set as committers; it includes all those with sufficient tracker
privileges) to determine and set the priority of an issue.  It is
sometimes annoying enough that users can reopen an issue (but most of the
time, it makes sense that they can.)

Voting for bugs (or starring, or the "affects me too" in Launchpad) is
different.  Sure, the number of affected people can be an indication of
a bug's priority, but an often-run-into annoyance remains an annoyance.
I would not be opposed to introducing voting for bugs, but I don't think
it is necessary; interested users can leave a comment, which is often
better since they can add useful information.

> The developers may schedule issue with priority, and user
> editable severity may stay the same. If a person thinks that the issue
> is 'critical' or a 'blocker' - that means this person is very
> interested (or even very-very interested) in fixing the issue. All you
> need is to show this person that his help is required and assist in
> making a proper contribution.

That still doesn't make it a release blocker.  Quite the opposite -- for
example if the bug reported completely prevents using Python on an obscure,
maybe unsupported platform, it is certainly a blocker for the reporter,
but we certainly wouldn't consider holding up a release because of it.
he same holds for the very particular feature request that a user needs
desperately to write his application.

> This means:
> 1. help him to localize the problem, i.e.
> http://wiki.winehq.org/RegressionTesting
> 2. explain him which code does he need to dig the problem
> 3. show where is this code located
> 4. explain how to setup dev environment
> 5. explain how to get test suite running easily
> 6. show an entrypoint to debug/fix cycle
> 7. show how to create a patch for review
> 8. show how to submit the patch
> 9. show how to refresh the patch easily for review
> 
> After a few 1-9 cycles you will be able to create a Python
> Contribution Manual, similar or even better than
> http://subversion.apache.org/docs/community-guide/   After some more
> experience some steps could be automated or streamlined.

As pointed out, we have these guides.  It should be a simple step to add
the pertinent links to tracker pages.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAkvAwKwACgkQN9GcIYhpnLD0PQCfQtarzeIrxeuY1PCViOppD7Zd
rhsAnArTpkOJFNnRz698E4cp98zsBNUY
=yExD
-----END PGP SIGNATURE-----