On Fri, Aug 13, 2010 at 11:06 PM, Loïc Minier wrote:
> On Fri, Aug 13, 2010, Andrew Stubbs 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
>> us
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 10 Aug
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
On Fri, Aug 13, 2010 at 2:06 PM, Loïc Minier wrote:
> On Fri, Aug 13, 2010, Andrew Stubbs 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
>> usi
On Fri, Aug 13, 2010, Andrew Stubbs 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 thou
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
17 matches
Mail list logo
