more bug tracker improvements

Hi all,

After seeing several people struggle with the bug tracker
registration,
I've redesigned the way that accounts are set up.

Now, when you open a bug or make a comment, the only
information needed
from you is your email address.  This is used to send out a
confirmation
email.  When you follow the link in the confirmation email,
you will be
prompted for a username, password, and your name.

In addition, anyone with bug tracker karma automatically
gets pear.voter
karma (and vice-versa).

This way, the confusion of registering for an account while
at the same
time reporting a bug is eliminated.

I'd like to hear how this works for you who are doing the
bug reporting.
 Is this easier?  Our goal is to make it very easy to report
bugs and to
assign proper credit to people who have provided fixes, and
at the same
time very hard to spam.

Thanks,
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:

> I'd like to hear how this works for you who are doing
the bug reporting.
>  Is this easier?  Our goal is to make it very easy to
report bugs and to
> assign proper credit to people who have provided fixes,
and at the same
> time very hard to spam.

IMHO credits belong into the changelog, not somewhere hidden
in a bug
report. This is also something that people often complain
about after
new PHP releases are available. In those changelogs the same
thing can
be seen as for example as in the last changelog for pearweb
1.10.1: The
names of the persons who changed something are mentioned,
but not the
people who reported the issue (or the improvement). But if
John Miller
(just a random name) provides a patch for e.g. a major bug,
then his
name should be mentioned there, not the name of the PEAR
developer who
applied the patch.

IMHO it is self-evident that each of the developers that are
listed in
the release announcement mail has worked on the package. If
that's not
the case, mark this person as inactive and the name won't
appear in the
list in the email anymore. And whether person A or B has
fixed bug #0815
or #4711 is IMHO not really interesting. And if it is
interesting for
somebody, people can lookup that name in the bug tracker or
in the CVS
web viewer.

Comments are welcome, of course.

Regards,
Mark

-- 
http://www.markwiesemann.
eu

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Mark Wiesemann wrote:
> Gregory Beaver wrote:
> 
>> I'd like to hear how this works for you who are
doing the bug reporting.
>>  Is this easier?  Our goal is to make it very easy
to report bugs and to
>> assign proper credit to people who have provided
fixes, and at the same
>> time very hard to spam.
> 
> IMHO credits belong into the changelog, not somewhere
hidden in a bug
> report. This is also something that people often
complain about after
> new PHP releases are available. In those changelogs the
same thing can
> be seen as for example as in the last changelog for
pearweb 1.10.1: The
> names of the persons who changed something are
mentioned, but not the
> people who reported the issue (or the improvement). But
if John Miller
> (just a random name) provides a patch for e.g. a major
bug, then his
> name should be mentioned there, not the name of the
PEAR developer who
> applied the patch.
> 
> IMHO it is self-evident that each of the developers
that are listed in
> the release announcement mail has worked on the
package. If that's not
> the case, mark this person as inactive and the name
won't appear in the
> list in the email anymore. And whether person A or B
has fixed bug #0815
> or #4711 is IMHO not really interesting. And if it is
interesting for
> somebody, people can lookup that name in the bug
tracker or in the CVS
> web viewer.
> 
> Comments are welcome, of course.

Hi Mark,

It makes me a bit sad to see both the implied mistrust in
your message
and the problem in the changelog of 1.10.1.  One of the main
purposes
behind adding the package.xml generator for roadmap,
requiring
pear.php.net accounts for opening bugs and so on is to
provide a
technical way to implement proper crediting.  If you feel
that this is
not providing enough, a patch or fleshed-out idea would be
very appreciated.

The changelog notes generated by the roadmap at pear.php.net
lists a bug
fixer based on the "Assigned" field.

In the case of pearweb 1.10.1, after investigating, I did
find a few
bugs were not assigned to the person who provided the fixing
patch.  The
truth is that this is not a technology problem, but a
political one.  If
the fixing developer doesn't assign the bug to the account
who provided
the fix, there's no way to enforce this.  I would not have
released
before changing credit had I figured this out in advance.

As for suggesting that developers who fix bugs should not be
listed next
to the bug that they fix, this seems to be a double
standard.  Why are
the people actually taking the trouble to apply fixes,
verify that they
work and don't introduce regressions, close the bug, update
package.xml
and other work any less important than someone who opens a
bug with a
2-line patch?  Either everyone or no one should be
credited.
Interestingly, Subversion takes the "no one"
approach, even forbidding
names in the source files.

Your message is especially frustrating to me personally
because this is
the first update to the website in years that was truly the
work of a
team, and the changelog has credit for every fixed bug,
which I thought
was a great step forward.  To then hear that the credit was
improperly
given is really annoying.  I'm also certain that this was
all done in
good faith with no attempt to grandstand or grab ego, which
makes it
even more frustrating.

Please, let's try to avoid both the insinuation of
intentional
mis-crediting and the accidental mis-crediting that prompts
it.  PEAR as
a project has had a long enough history of mistrust and of
good reasons
to mistrust, this stops now.

Thanks,
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:

> It makes me a bit sad to see both the implied mistrust
in your message
> and the problem in the changelog of 1.10.1.

Greg, there is no mistrust implied. I just wanted to say
that the old
way of assigning the developer (e.g. you or me) to a bug,
while at the
same time this name shows up in the generated changelog, is
not a good
solution for every case. If, of course, e.g. the patch
provider is
assigned to the bug, this solution might be okay.

And my message wasn't meant badly against the pearweb
package, it was
just the last changelog showing up on the pear-general
mailing list. I
could have chosen another examle.

> One of the main purposes
> behind adding the package.xml generator for roadmap,
requiring
> pear.php.net accounts for opening bugs and so on is to
provide a
> technical way to implement proper crediting.  If you
feel that this is
> not providing enough, a patch or fleshed-out idea would
be very appreciated.

No, I have no better idea (seen from a technical point of
view). I give
credits manually, and see no problem, because I edit the
package.xml
manually anyway. This is again not meant badly about the
generator.
There might be a lot of other people that want to use it,
while I'm
already happy with the old way. This is, as many things in
life,
personal preference

> As for suggesting that developers who fix bugs should
not be listed next
> to the bug that they fix, this seems to be a double
standard.  Why are
> the people actually taking the trouble to apply fixes,
verify that they
> work and don't introduce regressions, close the bug,
update package.xml
> and other work any less important than someone who
opens a bug with a
> 2-line patch?  Either everyone or no one should be
credited.

Again, maybe pearweb was a bad example because of its
"big" maintainer
list with having only you being really active in the past.
For "normal"
packages credit is (IMO!) already given in the release
announcement. 

With the generator way only one person can be credited. But
what would
you do if person X reports a bug, provides a 90% ready
patch, and you do
the other 10% work of it, do some more tests etc.? In this
situation
both people should be credited with your reasoning.

And again, my message wasn't meant badly against you or
anybody else. I
just wanted to say that we shouldn't do the
"mistake" that the PHP
people do -- at least many people don't like the missing
credits of
patch providing people there.

And please note that I appreciate the work that you put into
the PEAR
installer and the website. Without that we maybe would still
wait for
features that were announced in spring 2006 and before.

Conclusion: Don't interpret my message as a critism against
you, but as
a general reminder about crediting and how we shouldn't do
it. I'll try
to find a better example next time.

Regards,
Mark

-- 
http://www.markwiesemann.
eu

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Mark Wiesemann wrote:

> With the generator way only one person can be credited.
But what would
> you do if person X reports a bug, provides a 90% ready
patch, and you do
> the other 10% work of it, do some more tests etc.? In
this situation
> both people should be credited with your reasoning.

Yeah, this is tricky. Of course we could add another field
for the patch 
provider. And then we will have a case where multiple people
wrote and 
applied a patch etc. So maybe the conclusion is that we
should cover the 
95% cases with this, and the other cases people should be
able to hand 
fix things?

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Lukas Kahwe Smith wrote:

> Mark Wiesemann wrote:
> 
>> With the generator way only one person can be
credited. But what would
>> you do if person X reports a bug, provides a 90%
ready patch, and you do
>> the other 10% work of it, do some more tests etc.?
In this situation
>> both people should be credited with your
reasoning.
> 
> Yeah, this is tricky. Of course we could add another
field for the patch 
> provider. And then we will have a case where multiple
people wrote and 
> applied a patch etc. So maybe the conclusion is that we
should cover the 
> 95% cases with this, and the other cases people should
be able to hand 
> fix things?

Right, although the generator automates most of the work, we
shouldn't
take its result as 100% ready, but we should think about
whether it is
complete -- not only regarding the crediting aspect, but
also regarding
whether the bug description is reasonable enough (although
many
developers already change the summary before they close a
bug, of
course).

Regards,
Mark

-- 
http://www.markwiesemann.
eu

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php