ARM Maintainers workshop at Kernel Summit 2011

ARM Maintainers workshop at Kernel Summit 2011

[Grant Likely]

As many of you know, Kernel Summit this year will be a three day
event, with the first day dedicated to kernel subsystem workshops[1].
Since Kernel Summit will be co-located with ELC-E which my arm
developers will be attending, it is the perfect opportunity to have an
ARM maintainers meeting.  Arnd Bergmann, Nicolas Pitre and I talked
about it at Linaro Connect this past week and we're going to work on
organising something.

However, for it to be successful we need to put together a draft
agenda quickly.  Kernel summit is only 80 days away, and people need
time to get approval and organise travel.  So, if you're interested in
attending, then we need to know ASAP.  Reply to this email if you're
interested.

We also need proposals for discussion topics relevant to ARM,
particularly if it relates to all arm sub-architectures or the
maintainership process.  I'll collate the list of proposals that I
receive and try to put together an agenda.

As already mentioned, the first day (Sunday Oct 23) is dedicated to
workshops, and I think that most of the discussion topics will be
covered on that day.  The invite-only core developers meeting is on
the second day (Oct 24) which a few people will be involved with.  For
the rest of the group I'm considering organizing it as a hacking day
to start sorting out problems identified/discussed on the first day.
The third and final day will be plenary sessions open to participants
of all workshops.

[1] https://sites.google.com/site/kernelsummit2011/announcements/kickoff

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

[Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit 2011

[Olof Johansson]

On Fri, Aug 5, 2011 at 11:44 PM, Grant Likely <grant.likely@secretlab.ca> wrote:

> However, for it to be successful we need to put together a draft
> agenda quickly. ?Kernel summit is only 80 days away, and people need
> time to get approval and organise travel. ?So, if you're interested in
> attending, then we need to know ASAP. ?Reply to this email if you're
> interested.

With 99% certainty I will be there (but I haven't been invited to the
closed KS day).

Do we want to cover technical topics, or keep it process-oriented like
the rest of KS? Many technical topics seem to be covered within Linaro
these days, so some of those topics would only make sense if there's
enough non-Linaro people there that would care about whatever is
discussed.

I'd like to hear from Arnd what his experiences from this first merge
window were -- what worked well and where's room for improvement? Any
particular SoC workflow that should be tuned to make his life easier?
Where are the gaps where he needs help right now? And how did it work
out for the SoC maintainers?


-Olof

experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011

[Uwe Kleine-König]

Hello,

On Sat, Aug 06, 2011 at 06:59:00AM -0700, Olof Johansson wrote:
> I'd like to hear from Arnd what his experiences from this first merge
> window were -- what worked well and where's room for improvement? Any
> particular SoC workflow that should be tuned to make his life easier?
> Where are the gaps where he needs help right now? And how did it work
> out for the SoC maintainers?
I'm neither Arnd nor a SoC maintainer, but another level further down
(read: contributor).
My thoughts about the fixes-cleanups-newfeatures separation is that it
makes contributing harder than before.

Consider I want to contribute a series consisting of a cleanup and a new
feature (that depends on the cleanup). And I want (or even need) to base
this on (say) Sascha's imx tree that already has some other features.
Now the cleanup patch should go on Sascha's (eventually empty) cleanup
branch. But for the feature patch to go on top of both Sascha's feature
branch and his new cleanup branch, he either needs so rebase his feature
branch (which is (at least considered) bad) or he has to merge. I'd say
merging is the correct approach, but the history tends to be more ugly
than without the separation between cleanups and new features.
And if Sascha wants to pull from me (opposed to apply the patches
himself) he needs two merges. 
(So it results in one merge more than before for both cases.)

I'm not sure how welcomed these additional merges are by Linus.

The obvious (to me) ways out are:
 a) Linus can live with these merges; or
 b) drop the separation between cleanup and features; or
 c) Sascha doesn't publish a (fast-forward-only) tree but works with
    a patch queue or git-rebase; or
 d) Sascha keeps my series separate from his other stuff and requests
    Arnd to pull two (or more) cleanup branches and two (or more)
    feature branches; or
 e) Sascha needs something like topgit;

As this problem didn't occur yet in real life, there might be

 f) there is no real problem.

I fear a) and f) don't apply, I don't like c) and d) and I know
Sascha won't like e).
So there might only be b) left unless there is some g) I don't see.
YMMV.

I think separating between fixes and (cleanup+features) isn't a real
problem.

Just my 2?
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011

[Nicolas Pitre]

On Sat, 6 Aug 2011, Uwe Kleine-K?nig wrote:

> My thoughts about the fixes-cleanups-newfeatures separation is that it
> makes contributing harder than before.
> 
> Consider I want to contribute a series consisting of a cleanup and a new
> feature (that depends on the cleanup). And I want (or even need) to base
> this on (say) Sascha's imx tree that already has some other features.
> Now the cleanup patch should go on Sascha's (eventually empty) cleanup
> branch. But for the feature patch to go on top of both Sascha's feature
> branch and his new cleanup branch, he either needs so rebase his feature
> branch (which is (at least considered) bad) or he has to merge. I'd say
> merging is the correct approach, but the history tends to be more ugly
> than without the separation between cleanups and new features.
> And if Sascha wants to pull from me (opposed to apply the patches
> himself) he needs two merges. 
> (So it results in one merge more than before for both cases.)
> 
> I'm not sure how welcomed these additional merges are by Linus.
> 
> The obvious (to me) ways out are:
>  a) Linus can live with these merges; or
>  b) drop the separation between cleanup and features; or
>  c) Sascha doesn't publish a (fast-forward-only) tree but works with
>     a patch queue or git-rebase; or
>  d) Sascha keeps my series separate from his other stuff and requests
>     Arnd to pull two (or more) cleanup branches and two (or more)
>     feature branches; or
>  e) Sascha needs something like topgit;
> 
> As this problem didn't occur yet in real life, there might be
> 
>  f) there is no real problem.

Don't forget:

g) There are no hard rules.

> I fear a) and f) don't apply, I don't like c) and d) and I know
> Sascha won't like e).
> So there might only be b) left unless there is some g) I don't see.

Good judgment always prevails.  If you need to merge something in your 
branch, there is no problem with you asking Sascha to merge the result 
of that merge, and in turn Sascha asking the result to be merged by 
Arnd, etc.  Suffice that you justify why you want that merge, how it 
makes your contribution for the added feature on top easier, etc.  If 
the upstream maintainer asks otherwise then just try to convince that 
maintainer.  If you are right then you shouldn't have too many problem 
convincing people.

But at least always considering the fix/cleanup/feature split initially 
is certainly a good practice since that works well in most cases, and 
when that works, this makes your upstream maintainer's life a bit 
easier.


Nicolas

experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011

[Michał Mirosław]

2011/8/6 Nicolas Pitre <nicolas.pitre@linaro.org>:
> On Sat, 6 Aug 2011, Uwe Kleine-K?nig wrote:
>
>> My thoughts about the fixes-cleanups-newfeatures separation is that it
>> makes contributing harder than before.
>>
>> Consider I want to contribute a series consisting of a cleanup and a new
>> feature (that depends on the cleanup). And I want (or even need) to base
>> this on (say) Sascha's imx tree that already has some other features.
>> Now the cleanup patch should go on Sascha's (eventually empty) cleanup
>> branch. But for the feature patch to go on top of both Sascha's feature
>> branch and his new cleanup branch, he either needs so rebase his feature
>> branch (which is (at least considered) bad) or he has to merge. I'd say
>> merging is the correct approach, but the history tends to be more ugly
>> than without the separation between cleanups and new features.
>> And if Sascha wants to pull from me (opposed to apply the patches
>> himself) he needs two merges.
>> (So it results in one merge more than before for both cases.)
>>
>> I'm not sure how welcomed these additional merges are by Linus.
>>
>> The obvious (to me) ways out are:
>> ?a) Linus can live with these merges; or
>> ?b) drop the separation between cleanup and features; or
>> ?c) Sascha doesn't publish a (fast-forward-only) tree but works with
>> ? ? a patch queue or git-rebase; or
>> ?d) Sascha keeps my series separate from his other stuff and requests
>> ? ? Arnd to pull two (or more) cleanup branches and two (or more)
>> ? ? feature branches; or
>> ?e) Sascha needs something like topgit;
>>
>> As this problem didn't occur yet in real life, there might be
>>
>> ?f) there is no real problem.
>
> Don't forget:
>
> g) There are no hard rules.
>
>> I fear a) and f) don't apply, I don't like c) and d) and I know
>> Sascha won't like e).
>> So there might only be b) left unless there is some g) I don't see.
>
> Good judgment always prevails. ?If you need to merge something in your
> branch, there is no problem with you asking Sascha to merge the result
> of that merge, and in turn Sascha asking the result to be merged by
> Arnd, etc. ?Suffice that you justify why you want that merge, how it
> makes your contribution for the added feature on top easier, etc. ?If
> the upstream maintainer asks otherwise then just try to convince that
> maintainer. ?If you are right then you shouldn't have too many problem
> convincing people.
>
> But at least always considering the fix/cleanup/feature split initially
> is certainly a good practice since that works well in most cases, and
> when that works, this makes your upstream maintainer's life a bit
> easier.

I, as another contributor, share Uwe's point of view. The problem with
cleanups vs features is that either usually depends on the other.
Fixes are a different beasts and they usually go in asynchronously
(and quicker) to development changes. The split fixes/development
works well in networking area (net and net-next trees).

Best Regards,
Micha? Miros?aw

experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011

[David Brown]

On Sun, Aug 07, 2011 at 12:13:48AM +0200, Micha? Miros?aw wrote:

> I, as another contributor, share Uwe's point of view. The problem with
> cleanups vs features is that either usually depends on the other.
> Fixes are a different beasts and they usually go in asynchronously
> (and quicker) to development changes. The split fixes/development
> works well in networking area (net and net-next trees).

Maybe we are thinking about two different kinds of cleanups.  Cleanups
that would be closely associated with a new feature do make sense to
me to keep together.  This is the kind of thing where code is cleaned
up in order to make it easier/cleaner to add the new code.  I don't
think this makes sense to have in another branch.

But, there is also a lot of code going on now that is just cleaning
things up, and it makes sense for this to be in a separate branch.

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

ARM Maintainers workshop at Kernel Summit 2011

[Sascha Hauer]

On Sat, Aug 06, 2011 at 07:44:08AM +0100, Grant Likely wrote:
> As many of you know, Kernel Summit this year will be a three day
> event, with the first day dedicated to kernel subsystem workshops[1].
> Since Kernel Summit will be co-located with ELC-E which my arm
> developers will be attending, it is the perfect opportunity to have an
> ARM maintainers meeting.  Arnd Bergmann, Nicolas Pitre and I talked
> about it at Linaro Connect this past week and we're going to work on
> organising something.
> 
> However, for it to be successful we need to put together a draft
> agenda quickly.  Kernel summit is only 80 days away, and people need
> time to get approval and organise travel.  So, if you're interested in
> attending, then we need to know ASAP.  Reply to this email if you're
> interested.

Since I'm at the ELC-E anyway and I have the ok from Robert, yes, I am
interested.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011

[Steven Rostedt]

On Sat, 2011-08-06 at 21:11 -0700, David Brown wrote:
> On Sun, Aug 07, 2011 at 12:13:48AM +0200, Micha? Miros?aw wrote:
> 
> > I, as another contributor, share Uwe's point of view. The problem with
> > cleanups vs features is that either usually depends on the other.
> > Fixes are a different beasts and they usually go in asynchronously
> > (and quicker) to development changes. The split fixes/development
> > works well in networking area (net and net-next trees).
> 
> Maybe we are thinking about two different kinds of cleanups.  Cleanups
> that would be closely associated with a new feature do make sense to
> me to keep together.  This is the kind of thing where code is cleaned
> up in order to make it easier/cleaner to add the new code.  I don't
> think this makes sense to have in another branch.
> 
> But, there is also a lot of code going on now that is just cleaning
> things up, and it makes sense for this to be in a separate branch.
> 

This isn't too different than what the RT patch does (or did). There was
lots of clean ups that went into mainline that had and ulterior motive
(pave the way for -rt).

Where a clean up goes should be more about why the clean up is
happening. If it is just a clean up for the sake of cleaning up, then a
separate branch is suitable. But if a clean up is there to pave the way
for new features, then that clean up should be with the features it
allows to provide.

-- Steve

[Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011

[Mark Brown]

On Tue, Aug 09, 2011 at 11:07:42AM -0400, Steven Rostedt wrote:

> Where a clean up goes should be more about why the clean up is
> happening. If it is just a clean up for the sake of cleaning up, then a
> separate branch is suitable. But if a clean up is there to pave the way
> for new features, then that clean up should be with the features it
> allows to provide.

Though one of the frequent consequences of any widespread cleanup is
that it ends up touching lots of places and consequently colliding with
other work.

[Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011

[Steven Rostedt]

On Tue, 2011-08-09 at 16:34 +0100, Mark Brown wrote:
> On Tue, Aug 09, 2011 at 11:07:42AM -0400, Steven Rostedt wrote:
> 
> > Where a clean up goes should be more about why the clean up is
> > happening. If it is just a clean up for the sake of cleaning up, then a
> > separate branch is suitable. But if a clean up is there to pave the way
> > for new features, then that clean up should be with the features it
> > allows to provide.
> 
> Though one of the frequent consequences of any widespread cleanup is
> that it ends up touching lots of places and consequently colliding with
> other work.

Yeah, but Linus himself said he's good at merges. Normal cleanups should
not be too difficult to figure out conflicts of this nature.

-- Steve

[Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011

[Mark Brown]

On Tue, Aug 09, 2011 at 11:41:40AM -0400, Steven Rostedt wrote:
> On Tue, 2011-08-09 at 16:34 +0100, Mark Brown wrote:

> > Though one of the frequent consequences of any widespread cleanup is
> > that it ends up touching lots of places and consequently colliding with
> > other work.

> Yeah, but Linus himself said he's good at merges. Normal cleanups should
> not be too difficult to figure out conflicts of this nature.

The problem from the submitter point of view is that it makes it much
more complicated to work out what to base your patches on when doing new
work, particularly if the cleanups are actually useful or relevant for
stuff you're doing.  It raises the overhead for upstreaming that little
bit more for limited practical gain.

ARM Maintainers workshop at Kernel Summit 2011

[Marek Vasut]

On Tuesday, August 09, 2011 04:15:48 PM Sascha Hauer wrote:
> On Sat, Aug 06, 2011 at 07:44:08AM +0100, Grant Likely wrote:
> > As many of you know, Kernel Summit this year will be a three day
> > event, with the first day dedicated to kernel subsystem workshops[1].
> > Since Kernel Summit will be co-located with ELC-E which my arm
> > developers will be attending, it is the perfect opportunity to have an
> > ARM maintainers meeting.  Arnd Bergmann, Nicolas Pitre and I talked
> > about it at Linaro Connect this past week and we're going to work on
> > organising something.
> > 
> > However, for it to be successful we need to put together a draft
> > agenda quickly.  Kernel summit is only 80 days away, and people need
> > time to get approval and organise travel.  So, if you're interested in
> > attending, then we need to know ASAP.  Reply to this email if you're
> > interested.
> 
> Since I'm at the ELC-E anyway and I have the ok from Robert, yes, I am
> interested.
> 
> Sascha

Same here, I'd be at ELC-E too.

Cheers

ARM Maintainers workshop at Kernel Summit 2011

[Pavel Machek]

Hi!

> > > However, for it to be successful we need to put together a draft
> > > agenda quickly.  Kernel summit is only 80 days away, and people need
> > > time to get approval and organise travel.  So, if you're interested in
> > > attending, then we need to know ASAP.  Reply to this email if you're
> > > interested.
> > 
> > Since I'm at the ELC-E anyway and I have the ok from Robert, yes, I am
> > interested.
> > 
> > Sascha
> 
> Same here, I'd be at ELC-E too.

I should be close so yes, I'm interested.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011

[Arnd Bergmann]

On Saturday 06 August 2011, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Sat, Aug 06, 2011 at 06:59:00AM -0700, Olof Johansson wrote:
> > I'd like to hear from Arnd what his experiences from this first merge
> > window were -- what worked well and where's room for improvement? Any
> > particular SoC workflow that should be tuned to make his life easier?
> > Where are the gaps where he needs help right now? And how did it work
> > out for the SoC maintainers?

I have actually submitted a proposal for LinuxCon for a session where
I would talk about the status and lessons learned so far.

My feeling with the 3.1 merge window was that it went better than I
had expected, once I actually started taking patches. I think initially
each of us (Nicolas, Thomas and me) was waiting for the others to
start doing something, and in the end it turned out to be me merging
almost all of the branches. I don't see this as a problem, but it
wasn't exactly how we had planned it initially.

> I'm neither Arnd nor a SoC maintainer, but another level further down
> (read: contributor).
> My thoughts about the fixes-cleanups-newfeatures separation is that it
> makes contributing harder than before.
> 
> Consider I want to contribute a series consisting of a cleanup and a new
> feature (that depends on the cleanup). And I want (or even need) to base
> this on (say) Sascha's imx tree that already has some other features.
> Now the cleanup patch should go on Sascha's (eventually empty) cleanup
> branch. But for the feature patch to go on top of both Sascha's feature
> branch and his new cleanup branch, he either needs so rebase his feature
> branch (which is (at least considered) bad) or he has to merge. I'd say
> merging is the correct approach, but the history tends to be more ugly
> than without the separation between cleanups and new features.
> And if Sascha wants to pull from me (opposed to apply the patches
> himself) he needs two merges. 
> (So it results in one merge more than before for both cases.)

The main reason for starting this separation was to have logically
distinct sets of pull requests to send forward to Linus.
The problem that I'm facing here is that there are a lot of
cleanups (I expect more for 3.2 than there were for 3.1) that
cross all platforms and that have possible conflicts with all
the other per-soc branches.

I think the scenario that you have outlined is relatively rare
and also easily worked around by having multiple sets of branches,
like

1. bug fixes
2. cleanups
3. invasive feature 1
4. cleanups based on 3
5. feature 2, based on 4
6. bug fixes based on 5

etc.

> I'm not sure how welcomed these additional merges are by Linus.
> 
> The obvious (to me) ways out are:
>  a) Linus can live with these merges; or
>  b) drop the separation between cleanup and features; or
>  c) Sascha doesn't publish a (fast-forward-only) tree but works with
>     a patch queue or git-rebase; or
>  d) Sascha keeps my series separate from his other stuff and requests
>     Arnd to pull two (or more) cleanup branches and two (or more)
>     feature branches; or
>  e) Sascha needs something like topgit;
> 
> As this problem didn't occur yet in real life, there might be
> 
>  f) there is no real problem.
> 
> I fear a) and f) don't apply, I don't like c) and d) and I know
> Sascha won't like e).

I really want to see d). Having a single branch per feature is
not the ideal situation, I would much rather see multiple such
branches, so for each new feature, you do:

1. all necessary cleanups in one branch
2. the actual new non-cleanup code, based on that branch

When a platform maintainer submits cleanups, it's normally ok
to have them all in one branch, since I expect them to be
totally uncontroversial.

For the features, I want to see one branch per major feature in
the arm-soc tree, which means that these branches need to come
through the platform maintainer tree separately. Moreover, we
often have dependencies between some features in the architecture
tree and code going through other trees (gpio, devicetree, mmc, ...).

It's totally fine for me to base one feature for a platform on
a commit from, e.g. the mmc tree plus some cleanups in the arch
code. I will then wait for the mmc tree to get merged upstream
before submitting the new feature based on it. However, if I get a
platform branch that relies on changes that went into five other
trees, I can't push any of those platform changes before all the
other trees have gone upstream.

	Arnd