On Sun, Apr 24, 2011 at 1:27 PM, Zach Pfeffer wrote:
> We're planning on bringing up Gerrit at UDS for tracking Android
> upstreaming. Perhaps it could be used for tracking GCC patches?
Probably not. It seems to be tied to git and requires the Android
workflow. Here's our workflow:
Patches tha
We're planning on bringing up Gerrit at UDS for tracking Android
upstreaming. Perhaps it could be used for tracking GCC patches?
On Tue, Apr 19, 2011 at 4:22 PM, James Westby wrote:
> On Wed, 13 Apr 2011 14:54:55 +1200, Michael Hope
> wrote:
>> Hmm. We already do patch track
On Wed, 13 Apr 2011 14:54:55 +1200, Michael Hope
wrote:
> 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 w
n'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
>
s 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
somewhere, then some data will be lost.
> >> * ability to add other people's patches (ie by non-Linaro
> >>people) to my "need to review this patch" list and to "will put into
> >>next pull request", etc. [I know this is a bit out of
On Fri, 2011-04-08 at 16:25 +0200, Alexander Sack wrote:
> On Fri, Apr 8, 2011 at 4:14 PM, James Westby 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
On 9 April 2011 00:25, Alexander Sack wrote:
> On Fri, Apr 8, 2011 at 4:14 PM, James Westby wrote:
>> 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 c
On Fri, 8 Apr 2011 18:24:03 +0100, Peter Maydell
wrote:
> Sure. It does mean that fixing deficiencies in the system is more
> important than if it's just collecting patches and only needs to
> be interacted with by a few people.
Agreed.
> It's a feature I'd really like to see, and upstream soun
>> people) to my "need to review this patch" list and to "will put into
>> next pull request", etc. [I know this is a bit out of scope for
>> linaro's metrics tracking, but I definitely don't want to have to
>> track patches in more th
ot; list and to "will put into
>next pull request", etc. [I know this is a bit out of scope for
>linaro's metrics tracking, but I definitely don't want to have to
>track patches in more than one place if I can avoid it]
Yes, I think this is out of scope for th
* ability to add other people's patches (ie by non-Linaro
people) to my "need to review this patch" list and to "will put into
next pull request", etc. [I know this is a bit out of scope for
linaro's metrics tracking, but I definitely don't want to
On Fri, Apr 8, 2011 at 4:14 PM, James Westby 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 avera
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 othe
On 7 April 2011 16:04, Guilherme Salgado wrote:
> On Thu, 2011-04-07 at 16:01 +0100, Peter Maydell wrote:
>> but when I sign into this patchwork via openid it only knows about
>> the chiark one, not the linaro one.
>
> That's because Launchpad only sends us your preferred email address when
> you
On Thu, 2011-04-07 at 16:01 +0100, Peter Maydell wrote:
> On 7 April 2011 15:45, Guilherme Salgado wrote:
>
> > - Not all of your patches may be shown under /user/submitted. if that's
> > the case, make sure all your email addresses are registered in Launchpad
> > as we're sucking that data from
Hi folks,
I've been working on this app[1] (based on Patchwork) to track patches
submitted/accepted upstream by Linaro engineers. It's still a work in
progress and we're waiting for IS to deploy it but I wanted to show you
what I have so far and ask for feedback, so I've deployed it on an ec2
inst
o do
>> it manually. We would modify one of the tracking tickets to reference
>> both parts of the patch (and close the other ticket, or mark it a
>> duplicate).
>
> Sorry, wasn't clear, the part of my email which you quote above was
> meant to underline the proper
On Fri, Aug 13, 2010 at 9:08 PM, Amit Kucheria wrote:
> On 10 Aug 13, Michael Hope wrote:
>> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria
>> wrote:
>> > So git-based workflows won't benefit from this then?
>>
>> There's no particular dependence on any VC system. I will be making a
>> report o
I have started to put a Flow Chart together for Patch Tracking Process
(very preliminary draft) , see if that is what we want and let me know what
to add/modify to visualize the process at at a high level, first.
Cheers,
Mounir
On Fri, Aug 13, 2010 at 2:57 PM, Amit Kucheria wrote:
> On
On 10 Aug 13, Nicolas Pitre wrote:
> On Fri, 13 Aug 2010, Michael Hope wrote:
>
> > On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria
> > wrote:
> > > So git-based workflows won't benefit from this then?
> >
> > There's no particular dependence on any VC system. I will be making a
> > report on e
On Fri, 13 Aug 2010, Michael Hope wrote:
> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria
> wrote:
> > So git-based workflows won't benefit from this then?
>
> There's no particular dependence on any VC system. I will be making a
> report on each bzr commit to make sure there is a correspondin
On 13/08/10 12:35, Amit Kucheria wrote:
> patchwork[1][2][3] can already monitor mailing lists for patches and
> is used by several projects (Linux kernel, various sub-system
> maintainers, etc.) to make sure that patches posted to the mailing
> list are not dropped. (cc'ed Jeremy, author of patch
On 13/08/10 12:06, Loïc Minier wrote:
> Before we dive into implementation questions such as Launchpad tags, or
> tickets, or new software to be developed, I think it's important to
> understand the fundamental goals of the tracker and the data it would
> be working on.
We're way past that
On Fri, 2010-08-13 at 14:35 +0300, Amit Kucheria wrote:
> patchwork[1][2][3] can already monitor mailing lists for patches and
> is used by several projects (Linux kernel, various sub-system
> maintainers, etc.) to make sure that patches posted to the mailing
> list are not dropped. (cc'ed Jeremy,
On Fri, Aug 13, 2010, Amit Kucheria wrote:
> patchwork[1][2][3] can already monitor mailing lists for patches and
> is used by several projects (Linux kernel, various sub-system
> maintainers, etc.) to make sure that patches posted to the mailing
> list are not dropped. (cc'ed Jeremy, author of pat
o do
>> it manually. We would modify one of the tracking tickets to reference
>> both parts of the patch (and close the other ticket, or mark it a
>> duplicate).
>
> Sorry, wasn't clear, the part of my email which you quote above was
> meant to underline the proper
; both parts of the patch (and close the other ticket, or mark it a
> duplicate).
Sorry, wasn't clear, the part of my email which you quote above was
meant to underline the properties of the patch tracking system that I
care about rather than suggesting a design. The bottom of my orig
On 13/08/10 10:44, Loïc Minier wrote:
> I think it's relevant to consider two things around this tracking:
> - we're tracking a feature or a bug fix
There's no automatic way to determine this, but it could be tracked
using launchpad tags. Updating the tags might be tedious though.
> - we w
On 13/08/10 10:08, Amit Kucheria wrote:
> On 10 Aug 13, Michael Hope wrote:
>> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria
>> wrote:
>>> So git-based workflows won't benefit from this then?
>>
>> There's no particular dependence on any VC system. I will be making a
>> report on each bzr commi
On Fri, Aug 13, 2010, Michael Hope wrote:
> * Do a change upstream in 4.7, backport it to our 4.5, and backport
> it to our 4.6 when we make one
> * Do a change locally, track where it lands upstream, and figure out
> what we have to bring forward when we next rebase
> * Track what is Linaro spe
On 10 Aug 13, Michael Hope wrote:
> On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria
> wrote:
> > So git-based workflows won't benefit from this then?
>
> There's no particular dependence on any VC system. I will be making a
> report on each bzr commit to make sure there is a corresponding ticket
On Fri, Aug 13, 2010 at 7:19 PM, Amit Kucheria wrote:
> So git-based workflows won't benefit from this then?
There's no particular dependence on any VC system. I will be making a
report on each bzr commit to make sure there is a corresponding ticket
that tracks the upstream state.
At the moment
On 10 Aug 13, Michael Hope wrote:
> The next big thing for the Toolchain WG is sending patches upstream
> and beginning to track patches in general. Some of the use cases are:
>
> * Do a change upstream in 4.7, backport it to our 4.5, and backport
> it to our 4.6 when we make one
> * Do a chang
The next big thing for the Toolchain WG is sending patches upstream
and beginning to track patches in general. Some of the use cases are:
* Do a change upstream in 4.7, backport it to our 4.5, and backport
it to our 4.6 when we make one
* Do a change locally, track where it lands upstream, and
35 matches
Mail list logo
