Detecting patch sets

[Greg Geldorp]

> From: Dan Kegel
>
> when I was running patchwatcher, taking the number of patches
> in the series helped more than it hurt.  (It's fairly frequent for
> people to submit two patchsets, and fairly infrequent for the
> second patchset to have the same number of patches.)

Thanks Dan, I think we have a winner then: take the maximum patch
number into account.

> The darn interface needed babysitting, though, since
> there were always malformed and/or partial series.
>
> I think it'd be cool to have a UI where developers
> could correct their detected patchsets if they don't
> like what the automated extractor did.  That could
> morph into a way of submitting patchsets in the
> first place later on.

I tend to get distracted every now and then by things my boss wants
me to do and don't always have time for babysitting bots, which is why
I kind of like the idea of giving control to the devs, so the whole
bot doesn't break down when I'm not available.
I can certainly imagine a future where patches would be submitted
through Alexandres patch tracker and send out to wine-patches from
there, instead of the patch tracker picking up emails. But for now,
it's probably most productive for everyone to adjust to the existing
workflow.

> It'd also be cool if other tools - say, a buildbot or a patchwatcher -
> could monitor the detected patchset stream
> (to save them from having to maintain their own).

I'm always open to talk about integration.
One of the things that always kind of irked me about the Wine websites
is that each (including mine) has its own user management. I think
a central Wine LDAP server would be a good idea. I'll be adding LDAP
support to the testbot for internal VMware usage anyway.

Ge.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4183 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100413/2c2af1ba/attachment.bin>