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 point now. We've been there, discussed that, and I would like to see an implementation right now.
I personally think the processes should act on upstream mailing-list threads, on upstream checkins in various branches, and on our checkins
This is different problem, and we should *not* confuse the two. Trying to mix the two can only succeed in delaying the implementation, and adding unnecessary complexity.
For instance, we want to make sure we review all upstream commits and all upstream emails with patches, but we might not want to open one bug/ticket per upstream email or email thread.
No, of course not, that would be silly.
Tracking upstream patches is interesting, but there are so many of them, across all the project we will eventually track, that you want the process to be as lightweight as possible.
I would also warn you against doing this on a large scale. There's no point in backporting every 4.6 patch to 4.5. Apart from using your entire engineering resource for patch porting work, you just end up with a 4.6 compiler, together with all the instability and other problems associated with using bleeding edge sources. We should only be interested in cherry picking specific performance improvements - even bug fixes can be left alone if the problem has never been observed.
In summary,
* tracking upstream patches is about eyeballing the list, and saying, "yes, no, no, no, yes, no .....". The "yes"s become tickets, or work items, or entries in a wiki.
* tracking local patches is about being able to ask, at any point in development, "what patches need upstreaming right now?", and "if I rebase to X, what patches will I need to forward port?"
Please don't try to unify the implementations.
Andrew