appdb developers please read

[Francois Gouget]

On Thu, 8 Sep 2005, Ivan Leo Puoti wrote:

> Hello, if you look at 
> http://www.winehq.com/pipermail/wine-devel/2005-September/039837.html
> you'll see there was a project at some point to make a decent patch 
> management system

What is a 'patch management system'?

If it's something Alexandre uses to apply patches, then his requirement 
that it be usable from his desktop environement (Emacs) precludes a 
web-based system.

So what about something more like a patch tracking system, not for 
Alexandre's use but for everyone to see on the web?

The idea would be to match emails sent to wine-patches with commits made 
to CVS as found in the wine-cvs mailing list for instance. Then each 
email would be in one of the following states:

  * pending
    New emails that have just been sent.

  * committed
    We found a CVS commit that matches this email. We could link such 
emails to the corresponding commit.

  * dropped
    After 48 hours in the pending state, emails go into the dropped 
state. The system could even automatically send an email to the 
submitter explaining the situation and pointing to a web page describing 
what to do. We could arrange to send that email only to new contributors 
by keeping a list of email addresses which have received one already.
    Obviously the 48 hours delay should be adjusted for week-ends and 
Alexandre's vacations.

  * discuss
    Emails that have not been committed and for which we find a reply 
either in wine-patches or in wine-devel go into this state. In 
particular this means they never enter the dropped state. Basically the 
idea is that if someone replied to the email it's either to point out 
the patch is missing, wrong, incomplete or some such and thus we should 
have no expectation of the patch being committed. But if we then find a 
match in wine-cvs then fine, switch it to committed.

  * hidden
    The system would hide replies to other wine-patches emails.


There would most likely be some miscategorisations but as long as 
it's not too many of them it does not matter. The benefits would be:
  * we'd have a clear indication of what's the status of a patch
  * we'd have a better idea of how many patches get dropped
  * if we implement the automatic email notification submitters of 
dropped patches would automatically get instructions on how to remedy 
the issue
  * dropped patches would be clearly visible making it easy for 
volunteers to investigate them and take action


How can we match wine-patches emails to CVS commits?
  * date
    If the commit was before the patch was received by wine-patches then 
it does not match

  * submitter name / email
    Alexandre always puts the submitter name / email on the first commit 
line so we can check for a match or partial match (name or email only) 
there.

  * commit log
    This one is tricky because we are unlikely to get a perfect match. 
Still the commit log should be present somewhere in the email, either in 
the subject or in the body. In some cases it could be in the attachement 
and if we can scan attachements that's good, but I think this case 
is not frequent enough to matter if we cannot.

  * modified files
    If we can open attachements and parse the diff then we could compare 
the list of files in the diff and in the commit. But I don't think 
this is needed for proper matching.

Note that one commit may correspond to more than one wine-patches email 
(resends). So loop on the emails and try to find matching cvs commits.

-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.