Re: Patch queue management systems

[Lars Magne Ingebrigtsen]

Dmitry Gutov <address@hidden> writes:

> Okay, thanks. Any reason why it includes closed bugs in the list?

They're included for a few weeks.  `x' to make them go away.

> And could Debbugs be made to work snappier? 20000 is not much, on a
> database scale.

Indeed.

> ...I suppose. Note that integration server build status usually
> includes a status value (passed, failed, or errored before it had a
> chance to fail) and a url to the build info (where we can look at the
> log).

Well, that's also nice, but for virtually all patches we get (which are
to the Lisp bits), running a "make" in the current tree is sufficient to
see whether the patch is whack or not.  No need to wait for a result
from an integration server.

("make test" if you want to be all modern and hang with the cool kids.)

> Do you intend to keep the patch submission workflow the same?
> I.e. free-form (inline or in an attachment with arbitrary name),
> instead of a Git branch somewhere.

Sending patches is really easy, even for kids these days.  

> It increases visibility into the discussion. Even if we're only
> talking two passes, being able to see just the comments that apply to
> the latest proposed version is pretty nice.

Yes, it would be, but we're displaying the discussion threaded, so that
kinda happens naturally.  It would be nice to have a way to mark exactly
what message contains the most current version of the patch, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no