On Wed, 2011-04-13 at 14:54 +1200, Michael Hope wrote: > On Sat, Apr 9, 2011 at 2:14 AM, James Westby <james.wes...@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. -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
