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 Fri, Aug 13, 2010 at 09:31:16AM +0100, Dave Martin wrote:
> Hi all,
>
> There are various PPAs relevant to linaro, but they can be hard to
> find when you don't work with them actively. Do we have a list
> somewhere? If not, it could be worth listing them on the wiki
> somewhere, or documenti
Fixed a minor error in v2 where a check was erronueously done
twice.
Original commit message follows:
Applies to 2.6.35
(git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6.git
perf/core branch)
The new patch loads the ELF section headers from a separate
file if necessary, to avoid gett
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
Hi all,
There are various PPAs relevant to linaro, but they can be hard to
find when you don't work with them actively. Do we have a list
somewhere? If not, it could be worth listing them on the wiki
somewhere, or documenting how to find them.
Cheers
---Dave
___
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
18 matches
Mail list logo
