QA weekly bug summary

Bonsoir,
The weekly bug summary as on http://news.php.
net/php.pear.qa/4210 is issued.
Why is this stuff not published on this dev list ?
At least some monthly one or each 4 weeks would be nice.
-- 
toggg

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

On 3/10/07, bertrand Gugger <togggphp.net> wrote:
> Bonsoir,
> The weekly bug summary as on http://news.php.
net/php.pear.qa/4210 is issued.
> Why is this stuff not published on this dev list ?
> At least some monthly one or each 4 weeks would be
nice.

Each month (not week):
Each package maintainer gets a list of their own packages'
bugs. The
QA list gets a list of all bugs. It doesn't need to go to
the dev
list.

-- 
Justin Patrin

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

>
> Each month (not week):
> Each package maintainer gets a list of their own
packages' bugs. The
> QA list gets a list of all bugs. It doesn't need to go
to the dev
> list.


As a list lurker; I'm always looking for ways to contribute
to PEAR without
getting bogged down with maintaining my very own package.
Doing patches would be a very easy way for me to do that.

Having stuff pushed onto the dev list / making the QA side
of it a bit more
open would be awesome - failing that, an easy to find link
to the QA bug
summary from the pearweb site would do the trick.

It would also help cut down on unmaintained packages - if
everyone can see
you aren't interested in fixing bugs, they can step up
*before* you abandon
a package.

Just an idle thought.

-- 
Browser feels a little bit slow? http://thebetterbro
wser.com/newer

Daniel O'Connor wrote:
>>
>> Each month (not week):
>> Each package maintainer gets a list of their own
packages' bugs. The
>> QA list gets a list of all bugs. It doesn't need to
go to the dev
>> list.
> 
> 
> As a list lurker; I'm always looking for ways to
contribute to PEAR without
> getting bogged down with maintaining my very own
package.
> Doing patches would be a very easy way for me to do
that.
> 
> Having stuff pushed onto the dev list / making the QA
side of it a bit more
> open would be awesome - failing that, an easy to find
link to the QA bug
> summary from the pearweb site would do the trick.
> 
> It would also help cut down on unmaintained packages -
if everyone can see
> you aren't interested in fixing bugs, they can step up
*before* you abandon
> a package.
> 
> Just an idle thought.

Hi Daniel,

In terms of the bug summary, the easiest way to find this is
to browse
to http://pear.php.ne
t/bugs/stats.php

Another very good idea is hidden in your mail, which is to
say having
patch notifications sent to pear-qa, so that everyone can
see when a bug
has a fix attached to it.

Comments?

Greg

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

Gregory Beaver wrote:

> Another very good idea is hidden in your mail, which is
to say having
> patch notifications sent to pear-qa, so that everyone
can see when a bug
> has a fix attached to it.

I haven't tried to use this patch feature, but it was often
requested to
have a possibility to attach some *code* to a bug or feature
request.
Note the word *code*: it includes not only patches, but, for
example,
also longer code snippets that show how a bug can be
reproduced. Sending
an email to pear-qa makes IMO only sense for real patches,
and in this
case also not for actively maintained packages. If somebody
sends a
patch for one of the packages that I (co-)maintain, he can
be sure that
gets at least an answer or that I apply the patch.

Therefore, an easy solution might be to use the
"unmaintained" flag: if
it is set, and a patch (or some code) is attached to a bug,
then an
email could be send to pear-qa. This has only the
disadvantage that not
every unmaintained package is marked as unmaintained.

Regards,
Mark

-- 
http://www.markwiesemann.
eu

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

On 3/12/07, Daniel O'Connor <daniel.oconnorgmail.com> wrote:
> >
> > Each month (not week):
> > Each package maintainer gets a list of their own
packages' bugs. The
> > QA list gets a list of all bugs. It doesn't need
to go to the dev
> > list.
>
>
> As a list lurker; I'm always looking for ways to
contribute to PEAR without
> getting bogged down with maintaining my very own
package.
> Doing patches would be a very easy way for me to do
that.
>
> Having stuff pushed onto the dev list / making the QA
side of it a bit more
> open would be awesome - failing that, an easy to find
link to the QA bug
> summary from the pearweb site would do the trick.
>

It's not closed...just join the pear-qa list. We try to keep
things on
separate lists to let people only get what they want to
get.

> It would also help cut down on unmaintained packages -
if everyone can see
> you aren't interested in fixing bugs, they can step up
*before* you abandon
> a package.



-- 
Justin Patrin

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

>
> > Having stuff pushed onto the dev list / making the
QA side of it a bit
> more
> > open would be awesome - failing that, an easy to
find link to the QA bug
> > summary from the pearweb site would do the trick.
> >
>
> It's not closed...just join the pear-qa list. We try to
keep things on
> separate lists to let people only get what they want to
get.


Not to nit pick, but I'd never guess that the first place to
"get involved
with pear" lived at http://pear.php.net/qa/ -
even when I followed the link
just then, and read everything on the page, it doesn't sound
like the right
place to go.


In terms of the bug summary, the easiest way to find this is
to browse to
> http://pear.php.ne
t/bugs/stats.php



http://pear.php.ne
t/bugs/stats.php is great from a 'overall look at pear'
point of view, but kind of overwhelming for a 'I just want
something to
fix'... where as the summary information pushed out in the
qa lists stuff is
just what I'm looking for...

  ID  Status     Summary (900 total)
>
===============================================[Archive_Tar]
==================
> 4013 Open      Ignoring files and directories on
creating an archive..
> 9520 Open      Doesn't allow in-memory manipulation of
tar files.
> 10145 Open      Patch to return a Pear Error Object on
failure.
>
>
Package name + one line of what it is to get me curious...
add a link to the
id... voila! I can find something worth doing.




-- 
Browser feels a little bit slow? http://thebetterbro
wser.com/newer