On Wed, 2011-04-13 at 14:54 +1200, Michael Hope wrote:
On Sat, Apr 9, 2011 at 2:14 AM, James Westby james.westby@linaro.org wrote:
Hi,
This service is going to be used by management to get an idea of the number of patches going to each project over time, the number of patches submitted upstream by each team over time, the % of patches accepted upstream, the average time from submission to acceptance for each project, and other things like that.
For this to work well, and for your work to be accurately counted, you are going to be expected to keep it up to date as you submit patches upstream.
Now is the time to speak up if the interface doesn't have what you need to do this. Obviously it would be better if it took care of everything for you, but we don't think that everything can be automated. If you know better then we would obviously like to hear about that too.
Hmm. We already do patch tracking in Linaro GCC to make sure that all patches go upstream. It's a manual process as the GCC workflow itself is very manual.
I don't want to manually update two places when a patch changes state. How can we merge these systems?
If you update the patch state in the new system, you get a list of patches that can be filtered by state/submitter/etc, like: http://ec2-184-73-78-92.compute-1.amazonaws.com/project/gcc-patches/list/
But I assume that's not everything you want so our long term goal should be to have the features you need implemented directly into the system, although in the meantime we could have them implemented as separate tools, using our system as a data source via its xml-rpc API.