Thermal release for this month.
andrey.konovalov at linaro.org
Mon Apr 16 12:58:03 UTC 2012
On 04/14/2012 09:29 PM, Amit Kucheria wrote:
> On Sat, Apr 14, 2012 at 3:49 AM, Christian Robottom Reis
> <kiko at linaro.org <mailto:kiko at linaro.org>> wrote:
> On Sat, Apr 14, 2012 at 01:02:59AM +0400, Andrey Konovalov wrote:
> > 2) So the new thermal_exynos4_imx6_work obsoletes the old
> > exynos_thermal_framework_V2 topic. You should mention that
> > explicitly when asking to add the new one to linux-linaro!
> I was a bit surprised at something related to this as well -- the new
> Exynos4 thermal patchset actually includes the generic cpu cooling
> patchset instead of keeping it separate. I realized later this was added
> because the maintainer suggested including a user of the generic code to
> demonstrate its usefulness, so it seems fine to me, though it might have
> been easier to understand if you had maintained the original subject
> "Add generic cpu cooling devices" and just expanded the patchset by
> including the Exynos4 implementation at the end.
> At any range, Andrey's comment is right -- you need to let him know when
> you're merging or splitting patchsets/topics or it'll be hard for him to
> keep track of them.
> I agree it would be hard for Andrey to resolve conflicts.
> Andrey: what percentage of external branches you're pulling are
> completely new versions of the patches (refactored or rebased) vs. those
> that build on top of the old stuff?
Most of the topics appeared in the 12.03 first time. So this is too
early to calculate the percents. But to my (little) experience, most of
the topics are rebased. The rest are "single shot" ones. Can't recall
any topics with history.
> I expect most of our work to be rebased/refactored work so that it would
> require reverting all old patches. Would it help if you were told that
> in the beginning of a feature integration? So we'd say, for example,
> "Please pull in this XXX thermal branch from git.linaro.org/foo.git
> <http://git.linaro.org/foo.git> and this will be constantly rebased, so
> pull a new version of it everytime you recreate the tree".
Yes, that would be fine. Actually, this was my default case so far :)
After having reviewed most of the 12.03 topics WRT moving them to 12.04,
I'll probably require the new topics submitters to make an explicit
statement like "please track this topic and include it into all the
following linux-linaro releases until further note" when requesting the
topic addition. Otherwise the topic would be dropped in the next release.
Rebased topics are ok for me. What I really need to know about such
topics is what they are based upon. By default I would assume that they
are upstream based (the mainline Linus kernel tree). If the topic is
based on top of another topic (this happened before), this must be
mentioned when sending me the request to add the topic to linux-linaro.
I'll put these instructions on wiki shortly, so the submittion process
should become more clear then.
More information about the linaro-dev