freebsd-bugbusters Digest, Vol 134, Issue 2
freebsd-bugbu...@freebsd.org
freebsd-b...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-bugbusters
or, via email, send a message with subject or body 'help' to
freebsd-bugbu...@freebsd.org
You can reach the person managing the list at
freebsd-bugb...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-bugbusters digest..."
Today's Topics:
1. PR backlog [was: Re: usb/umass, devfs: this sucks] (Mark Linimon)
2. Re: PR backlog (M. Warner Losh)
3. Re: PR backlog (Richard Neese)
4. Re: PR backlog (Mark Linimon)
5. Re: PR backlog (Remko Lodder)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Dec 2007 12:04:15 -0600
From: lin...@lonesome.com (Mark Linimon)
Subject: PR backlog [was: Re: usb/umass, devfs: this sucks]
To: Henrik Gulbrandsen <hen...@gulbra.net>
Cc: freeb...@freebsd.org, sta...@freebsd.org, Mikhail Teterin
<mi+...@aldan.algebra.com>, "M. Warner Losh" <i...@bsdimp.com>,
freebsd-b...@FreeBSD.org
Message-ID: <20071226180...@soaustin.net>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 26, 2007 at 06:15:16PM +0100, Henrik Gulbrandsen wrote:
> Fixing and merging are good, but it seems to me (as an occasional patch
> contributor without commit privileges) that the bottleneck for USB is
> still in the handling of incoming patches [...] if a one-line fix
> such as that in usb/78984 has not been applied after more than a year,
> how long will it take for patches that involve multiple subsystems?
I'll put on my bugmeister hat for a moment.
First, I share your frustration.
Second, unfortunately, it's not just USB. We suffer from this problem in
several other areas, notably, patches for the userland utilities ("bin").
There are two interrelated problems that create a chicken-and-egg
situation:
- the PR tool is insufficient for our needs;
- there's not a "culture" of going and fixing bugs outside of the code
one usually works on.
As for 1), once the releases are out, I intend to start working on defining
what "our needs" are. As I've stated before in other places, until we
understand those, and get community buy-in to define an actual "process"
rather than just a particular PR system, it's unwise just to change the
PR system. (IMHO, there's no reason to further automate a process that
doesn't work correctly.) I hope to have something concrete to present at
BSDCan in May.
As for 2), I've scratched my head for what to do about that for a while,
and not been able to make much progress. Here's what we've tried:
- The creation of a weekly posting "bugs the bugmeister team thinks are
ready for commit". This doesn't seem to have attracted the desired
attention. Perhaps this is a problem of "push" not being the right
solution here; perhaps it just hasn't been publicized enough.
- The creation of a hack for classifying PRs, the "[tag]" convention.
This is simply working around the weakness of the tool. However,
it is sufficient to be able to generate weekly email sorting the
PRs by tag, and another email showing only PRs with patches, also
sorted by tag. If you are a committer, it's also possible to run
queries via:
~gnats/tools/showwithtag <tagname>
to get a summary.
- Trying to get more traffic on the freebsd-bugbusters@ mailing list.
- Trying to create some interest in #freebsd-bugbusters on EFNet on IRC.
This has not attracted enough committers to be viable yet.
- Holding some "bugathons" (idea stolen from NetBSD) where we try to get
committers to come onto the IRC channel at particular weekends to try
to interactively work through PRs. This had some success, but we have
not done one in a while.
The odd thing is that for ports, the existing PR system -- plus, most
importantly, the hacks we've added on top of it -- works reasonably well.
- Each port has an explicit "maintainer" field (even though many of
the entries are null). Most of the src codebase does not, therefore
no one in particular "owns" it.
- We've taken advantage of that to layer a PR auto-assigner on top, that
also sets things to 'feedback'.
- portsmon is also able to track PRs by the port they affect, and semi-
weekly reminder emails are sent out.
But the first of these items is really particular to ports. Also, more
ports PRs than src PRs are upgrades/bugfixes, rather than true bug reports
that need substantial investigation (in fact, the ratio is probably
exactly reversed). This means we can clear a proportionally larger number
of ports PRs. All of this has helped get the port PR count down over the
last several years, to the point where it no longer seems as overwhelming
as the backlog in the other areas. The size of the backlog creates a
substantial disincentive to try to fix a handful -- thus perpeturating
the cycle.
What we all need to understand is that the PR count will never be at zero;
if we can instead settle for a steady-state, where the most concrete PRs
can be worked on as they arrive, then I'll feel we've have made great
progress.
Unfortunately I don't have any brilliant insights as to how to make the
work more interesting; most of my ideas have the focus of simply making
it less frustrating.
I'll throw the floor open for brainstorming at this point.
mcl
------------------------------
Message: 2
Date: Wed, 26 Dec 2007 11:42:24 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: PR backlog
To: lin...@lonesome.com
Cc: sta...@freebsd.org, hen...@gulbra.net, freeb...@freebsd.org,
mi+...@aldan.algebra.com, freebsd-b...@freebsd.org
Message-ID: <20071226.114224...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii
Mark and Henrik make a number of good points here. Rather than reply
to the details, I'm going to make a couple of quick observations.
As a project we're not leveraging the community sufficiently when it
comes to contributions. The current system of patch review and
submission is very hap-hazard. If you happen to get the attention of
the right person at the right time, then it goes in. If not, patches
can languish a long time in the PR system.
The PR system is also the wrong tool for the job. While Mark touches
on the cultural issues in play, they are exacerbated by the
misapplication of a problem system to be a patch submission and
tracking system. Maybe we need to adopt a practice from the Linux
community. At least for arm kernel patches, there is a two step
process: submit it to a mailing list for review and refinement, with
the second step being submitting it into a queue. I'm not sure the
details we need to be successful in the FreeBSD project.
Many of the USB patches in the PR system I left alone because I didn't
have the time and/or knowledge to evaluate them for inclusion, or I
saw something obviously wrong in the patch. When I was trying to just
get through the obviously trivial patches.
Warner
------------------------------
Message: 3
Date: Wed, 26 Dec 2007 12:43:06 -0800
From: Richard Neese <r.n...@gmail.com>
Subject: Re: PR backlog
To: freeb...@freebsd.org
Cc: lin...@lonesome.com, sta...@freebsd.org,
mi+...@aldan.algebra.com, "M. Warner Losh" <i...@bsdimp.com>,
freebsd-b...@freebsd.org
Message-ID: <200712261243....@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I agree with this and there is also the 2nd issue of commiters not responding
to those working on updating ports.
Point and Fax I have emaile Sobomax about fixing and updating the asterisk
ports. and have sent patches but never got a reply in 9 months.
If your going to be a maintainer you need to respond to those working on
projects already in ports.
On December 26, 2007 10:42:24 am M. Warner Losh wrote:
> Mark and Henrik make a number of good points here. Rather than reply
> to the details, I'm going to make a couple of quick observations.
>
> As a project we're not leveraging the community sufficiently when it
> comes to contributions. The current system of patch review and
> submission is very hap-hazard. If you happen to get the attention of
> the right person at the right time, then it goes in. If not, patches
> can languish a long time in the PR system.
>
> The PR system is also the wrong tool for the job. While Mark touches
> on the cultural issues in play, they are exacerbated by the
> misapplication of a problem system to be a patch submission and
> tracking system. Maybe we need to adopt a practice from the Linux
> community. At least for arm kernel patches, there is a two step
> process: submit it to a mailing list for review and refinement, with
> the second step being submitting it into a queue. I'm not sure the
> details we need to be successful in the FreeBSD project.
>
> Many of the USB patches in the PR system I left alone because I didn't
> have the time and/or knowledge to evaluate them for inclusion, or I
> saw something obviously wrong in the patch. When I was trying to just
> get through the obviously trivial patches.
>
> Warner
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
> To unsubscribe, send any mail to "freebsd-usb...@freebsd.org"
--
Welcome to the World. An the World gets smaller.
------------------------------
Message: 4
Date: Wed, 26 Dec 2007 18:58:58 -0600
From: lin...@lonesome.com (Mark Linimon)
Subject: Re: PR backlog
To: Richard Neese <r.n...@gmail.com>
Cc: sta...@freebsd.org, mi+...@aldan.algebra.com,
freebsd-b...@freebsd.org, freeb...@freebsd.org,
lin...@lonesome.com, "M. Warner Losh" <i...@bsdimp.com>
Message-ID: <2007122700...@soaustin.net>
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 26, 2007 at 12:43:06PM -0800, Richard Neese wrote:
> Point and Fax I have emaile Sobomax about fixing and updating the asterisk
> ports. and have sent patches but never got a reply in 9 months.
For situations like this you need to email portmgr@. We already have
defined parameters for resetting inactive maintainers.
mcl
------------------------------
Message: 5
Date: Thu, 27 Dec 2007 09:43:08 +0100 (CET)
From: "Remko Lodder" <re...@elvandar.org>
Subject: Re: PR backlog
To: "M. Warner Losh" <i...@bsdimp.com>
Cc: sta...@freebsd.org, freeb...@freebsd.org,
freebsd-b...@freebsd.org, mi+...@aldan.algebra.com,
lin...@lonesome.com, hen...@gulbra.net
Message-ID:
<18754.194.74.82.3....@galain.elvandar.org>
Content-Type: text/plain;charset=iso-8859-1
Hello Warner et all,
On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote:
> Mark and Henrik make a number of good points here. Rather than reply
> to the details, I'm going to make a couple of quick observations.
>
> As a project we're not leveraging the community sufficiently when it
> comes to contributions. The current system of patch review and
> submission is very hap-hazard. If you happen to get the attention of
> the right person at the right time, then it goes in. If not, patches
> can languish a long time in the PR system.
Indeed, I am one of the persons trying to find these relatively easy
things which I can do along side my other projects and things, but I dont
see them all (eventhough I try to keep track of them as much as possible);
but what will happen is that I learn more and more about the system and at
some point in time I will "stop" working on these easy PR's and seeking
more difficult ones to fix, at that point someone else has to step up to
fill in the gap that gets created; this might be a problematic part :-)
Though for everyone having simple fixes, please send them to me so that I
can evaluate them and (together with Warner in this case (As my mentor)) I
will try to get them in as correctly and quickly as possible :-) (keeping
up with the high standards of FreeBSD ofcourse).
>
> The PR system is also the wrong tool for the job. While Mark touches
> on the cultural issues in play, they are exacerbated by the
> misapplication of a problem system to be a patch submission and
> tracking system. Maybe we need to adopt a practice from the Linux
> community. At least for arm kernel patches, there is a two step
> process: submit it to a mailing list for review and refinement, with
> the second step being submitting it into a queue. I'm not sure the
> details we need to be successful in the FreeBSD project.
>
> Many of the USB patches in the PR system I left alone because I didn't
> have the time and/or knowledge to evaluate them for inclusion, or I
> saw something obviously wrong in the patch. When I was trying to just
> get through the obviously trivial patches.
>
> Warner
Some things that I think need to be done by the bugbuster/bugmeister team
and additional people is a constant effort to keep track of the incoming
tickets; Mark does a great job at that, and I try to helpout as much as
possible there, but we are all busy every now and then and then a backlog
on processing the incoming tickets gets created and we loose the "battle"
:-)
This is where you (the reader) can get in and try to help us with that, so
that we can properly assign the tickets, and try to keep track of them so
that they can get resolved as soon as possible.
Though, some complains are that we are not fast enough etc, I think we
need to make sure that everyone keeps understanding that we are a
Voluntary project, and that we have resources at unknown times and dates,
a committer can be active the one day, and remain inactive the rest of the
week; that's a side effect on the project being based on volunteers; we
did a good job so far with that, but every now and then something slips in
between. What we should do at that point is not ranting around as I see
happen sometimes, but instead try to get the bugbusters / bugmeister team
involved so that we can see what other options are available, sometimes we
can succeed in and sometimes we cannot; but dont keep the problem to
yourself and the "assigned" person because that might not work :-)
Just my E 0,02 :-)
--
/"\ Best regards, | re...@FreeBSD.org
\ / Remko Lodder | remko@EFnet
X http://www.evilcoder.org/ |
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
------------------------------
End of freebsd-bugbusters Digest, Vol 134, Issue 2
**************************************************