* ARM Maintainers workshop at Kernel Summit 2011 @ 2011-08-06 6:44 Grant Likely 2011-08-06 13:59 ` [Ksummit-2011-discuss] " Olof Johansson 2011-08-09 14:15 ` ARM Maintainers workshop at Kernel Summit 2011 Sascha Hauer 0 siblings, 2 replies; 14+ messages in thread From: Grant Likely @ 2011-08-06 6:44 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit 2011 2011-08-06 6:44 ARM Maintainers workshop at Kernel Summit 2011 Grant Likely @ 2011-08-06 13:59 ` Olof Johansson 2011-08-06 21:29 ` experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 Uwe Kleine-König 2011-08-09 14:15 ` ARM Maintainers workshop at Kernel Summit 2011 Sascha Hauer 1 sibling, 1 reply; 14+ messages in thread From: Olof Johansson @ 2011-08-06 13:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 2011-08-06 13:59 ` [Ksummit-2011-discuss] " Olof Johansson @ 2011-08-06 21:29 ` Uwe Kleine-König 2011-08-06 21:55 ` Nicolas Pitre 2011-08-11 13:47 ` Arnd Bergmann 0 siblings, 2 replies; 14+ messages in thread From: Uwe Kleine-König @ 2011-08-06 21:29 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 14+ messages in thread
* experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 2011-08-06 21:29 ` experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 Uwe Kleine-König @ 2011-08-06 21:55 ` Nicolas Pitre 2011-08-06 22:13 ` Michał Mirosław 2011-08-11 13:47 ` Arnd Bergmann 1 sibling, 1 reply; 14+ messages in thread From: Nicolas Pitre @ 2011-08-06 21:55 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 2011-08-06 21:55 ` Nicolas Pitre @ 2011-08-06 22:13 ` Michał Mirosław 2011-08-07 4:11 ` David Brown 0 siblings, 1 reply; 14+ messages in thread From: Michał Mirosław @ 2011-08-06 22:13 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 2011-08-06 22:13 ` Michał Mirosław @ 2011-08-07 4:11 ` David Brown 2011-08-09 15:07 ` [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: " Steven Rostedt 0 siblings, 1 reply; 14+ messages in thread From: David Brown @ 2011-08-07 4:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011 2011-08-07 4:11 ` David Brown @ 2011-08-09 15:07 ` Steven Rostedt 2011-08-09 15:34 ` Mark Brown 0 siblings, 1 reply; 14+ messages in thread From: Steven Rostedt @ 2011-08-09 15:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011 2011-08-09 15:07 ` [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: " Steven Rostedt @ 2011-08-09 15:34 ` Mark Brown 2011-08-09 15:41 ` Steven Rostedt 0 siblings, 1 reply; 14+ messages in thread From: Mark Brown @ 2011-08-09 15:34 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011 2011-08-09 15:34 ` Mark Brown @ 2011-08-09 15:41 ` Steven Rostedt 2011-08-09 15:57 ` Mark Brown 0 siblings, 1 reply; 14+ messages in thread From: Steven Rostedt @ 2011-08-09 15:41 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011 2011-08-09 15:41 ` Steven Rostedt @ 2011-08-09 15:57 ` Mark Brown 0 siblings, 0 replies; 14+ messages in thread From: Mark Brown @ 2011-08-09 15:57 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: Re: ARM Maintainers workshop at Kernel Summit) 2011 2011-08-06 21:29 ` experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 Uwe Kleine-König 2011-08-06 21:55 ` Nicolas Pitre @ 2011-08-11 13:47 ` Arnd Bergmann 1 sibling, 0 replies; 14+ messages in thread From: Arnd Bergmann @ 2011-08-11 13:47 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* ARM Maintainers workshop at Kernel Summit 2011 2011-08-06 6:44 ARM Maintainers workshop at Kernel Summit 2011 Grant Likely 2011-08-06 13:59 ` [Ksummit-2011-discuss] " Olof Johansson @ 2011-08-09 14:15 ` Sascha Hauer 2011-08-11 9:46 ` Marek Vasut 1 sibling, 1 reply; 14+ messages in thread From: Sascha Hauer @ 2011-08-09 14:15 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* ARM Maintainers workshop at Kernel Summit 2011 2011-08-09 14:15 ` ARM Maintainers workshop at Kernel Summit 2011 Sascha Hauer @ 2011-08-11 9:46 ` Marek Vasut 2011-08-11 13:32 ` Pavel Machek 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2011-08-11 9:46 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* ARM Maintainers workshop at Kernel Summit 2011 2011-08-11 9:46 ` Marek Vasut @ 2011-08-11 13:32 ` Pavel Machek 0 siblings, 0 replies; 14+ messages in thread From: Pavel Machek @ 2011-08-11 13:32 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-08-11 13:47 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-06 6:44 ARM Maintainers workshop at Kernel Summit 2011 Grant Likely 2011-08-06 13:59 ` [Ksummit-2011-discuss] " Olof Johansson 2011-08-06 21:29 ` experience with the new arm-soc workflow (Was: Re: [Ksummit-2011-discuss] ARM Maintainers workshop at Kernel Summit) 2011 Uwe Kleine-König 2011-08-06 21:55 ` Nicolas Pitre 2011-08-06 22:13 ` Michał Mirosław 2011-08-07 4:11 ` David Brown 2011-08-09 15:07 ` [Ksummit-2011-discuss] experience with the new arm-soc workflow (Was: " Steven Rostedt 2011-08-09 15:34 ` Mark Brown 2011-08-09 15:41 ` Steven Rostedt 2011-08-09 15:57 ` Mark Brown 2011-08-11 13:47 ` Arnd Bergmann 2011-08-09 14:15 ` ARM Maintainers workshop at Kernel Summit 2011 Sascha Hauer 2011-08-11 9:46 ` Marek Vasut 2011-08-11 13:32 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.