Re: Fwd: 30+ patches in BugZilla.


On Wed, 2006-05-17 at 08:30 -0400, Kevin Kubasik wrote:
> Hey, I dunno if everyone here watches the f-spot devel lists, but I
> saw this, and found it to hit a little close to home. Beagle is in
> much the same position with 31 unreviewed patches in Bugzilla, while
> more of those patches have some sort of comment, several have
> bitrotten past the point of easy revival, despite their usefulness. A
> few (such as child indexables in the file system and an archive
> filter) have been outstanding with some time now, and have no clear
> definition of what still needs to be done. I know I have submitted
> several patches over the past week or so and have not heard much about
> them. Overall, the message bellow just seemed relevant.

As I mentioned before, I am just overwhelmed with Novell stuff at the
moment to do an adequate job of reviewing non-trivial patches.
Unfortunately Bera is gone for the summer, Daniel and Fredrik are pretty
busy with school and summer work, and Jon has moved on, so right now I'm
the only one I feel comfortable about individually reviewing patches.
I'm sorry about this.  Fortunately, this won't to be an issue forever,
just while we push through our release, but I do suspect it will be the
rest of the month of May.

What would really help me out a lot is if the adventurous among you who
build from CVS tried out some of these patches.  In particular, Kevin's
compressed text cache (#339470), using a regexp for parsing query
strings from Max (#339844), and the thunderbird backend (#323065) from
Pierre would all be great to test.  If a lot of people are really using
them without major problems, that makes me feel a lot better about
committing them without going over them in great detail.

A list of outstanding patches can always be found in bugzilla here:

Maybe we should put that on the wiki somewhere?

In particular from the forwarded message:
> I see some comments that the patch is not solving it to 100% or is just a
> workaround for a fault in another product. But the fact that there is a
> bug in BugZilla indicates that there is a problem, and a possible patch
> fixes it (hopefully). If it is not perfect, lets include it to HEAD, and
> fix it over time (new bug reports). 

While I understand the idea that not including (or being late reviewing)
a patch can be somewhat discouraging for potential developers, there is
also the possibility that a bunch of buggy and untested code is dropped
into HEAD and then someone (me) has to deal with a torrent of bug
reports and fix code that is unfamiliar.  If these are showstopper bugs,
then I can't do releases until these are fixed.  This is less of an
issue for people who have stuck around the community like you, Kevin,
and who can be trusted to fix these bugs, but this is can be a major
problem for very helpful and well-intentioned individuals who do one-off
patches to fix problems but who aren't interested in becoming regular
members of the community.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]