A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
On 1 December 2011 19:14, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
This raises the question of what effect this should have on what we do with the Beagleboard models in Linaro QEMU, since we don't have a Panda model that we would move over to as our supported model. Since this is the first EOL for a board we model, I don't think we've thought about this before.
Here's my initial suggestion: * we will continue to hold the omap3/beagle qemu patches in qemu-linaro. We may try to get bits of them upstream in our copious free time but not as a priority. * users are welcome to report beagle related model bugs in launchpad but we won't spend any official effort on fixing them * beagle model will no longer be an obligatory part of qemu-linaro release testing
Does that seem reasonable or would another approach be better?
(OMAP3/Beagle model maintenance is at a very low priority anyway so it wouldn't be a major change to go to "officially not working on it". Actually dropping the OMAP3 patchset from qemu-linaro would be a more abrupt change of direction.)
-- Peter Maydell
On 1 December 2011 19:14, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
I'm in two minds about this: On the 'that's fine' side is: 1) We support other A8 boards 2) We can always run non-linaro installs on the Beagles if we want to test other things like toolchains 3) There have been some bugs that have made it hard for me to use the beagle for a while anyway.
On the 'hmm I'd rather not' side is: 1) The Beagle is still quite popular 2) It's the only non-A9 board I physically have
I think it's OK to drop beagle, but we should make sure we keep an A8 board of some type; or to be more specific we should : a) Make sure we don't become an A9 monoculture - from a toolchain point of view it's valuable to see whether the behaviour you are seeing is specific to one chip type. b) Make sure we have some ARM V7-nonsmp hosts that we can test to make sure that we don't break them (I'm thinking that there are some prefetch instructions that were added in v7-SMP).
Dave
-- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
Cheers ---Dave
+++ Dave Martin [2011-12-02 11:19 +0000]:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
Indeed. Part of the benefit of Free Software is that you don't get support for hardware dropped at the whim of manufacturers who only care about their latest, greatest products.
Now of course linaro's focus is on the newer stuff to a large degree, not least because that's our member's focus and they are ultimately paying the bills, but we are primarily here as an interface between members and their corporate 'only the _next_ product counts' view of the world and the community/users/engineers who care about what they have on their desks, and getting work done with it.
So ideally, at this point we would have successfully upstreamed everything of significance on beagleboards and could leave it to others to maintain suitable distro support. Is that in fact the case? (I admit I haven't been following the details at all (I have, and thus only care about, nslu2/panda/n900/freerunner :-) )
It seems that both Debian and Ubuntu beagleboard installs are available: http://elinux.org/BeagleBoardDebian http://elinux.org/BeagleBoardUbuntu but it's not clear (to me) to what degree this support is in-distro. Should we be helping complete that work so that there really is proper in-distro support. I'm not convinced that our work is really done until that's the case, but we could declare that we only upstream stuff. distro-support is distro's problem.
I'm not sure we've really thought that much about the criteria for declaring a board 'done' in the sense that Linaro has done its bit of knwoledge and code-transfer from the vendors to upstreams and distros. This issue is going to come up regularly so we probably ought to work out what the rules are.
I think it's quite important that we don't act just like pure vendors and drop stuff the moment there is a new thing to care about: that's not being a good community member. But it is our job to get shot of that maintenance as soon as it's been successfully transferred. There is clearly a continuum between very popular indeed hardware like beagleboard at one end and snowball v3 (which never got out into the wild) at the other, and it's reasonable not to treat them the same.
If we really did only send code from vendors to upstreams this would be simpler, but we've also put a lot of effort into making board images which is distro-like behaviour. Both aspects of our work need to be considered: perhaps they should even have different end-dates?
Are we happy that our job is done in this case and users are not being (unduly) left in the lurch?
Do we have our 'end-of-support' criteria written down somewhere? I think they should contain something more than 'member says so', which seems to be where we are currently at. But if in fact that really is how it's going to work then we should say so.
Wookey
On Fri, Dec 2, 2011 at 5:56 AM, Wookey wookey@wookware.org wrote:
+++ Dave Martin [2011-12-02 11:19 +0000]:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
Indeed. Part of the benefit of Free Software is that you don't get support for hardware dropped at the whim of manufacturers who only care about their latest, greatest products.
Now of course linaro's focus is on the newer stuff to a large degree, not least because that's our member's focus and they are ultimately paying the bills, but we are primarily here as an interface between members and their corporate 'only the _next_ product counts' view of the world and the community/users/engineers who care about what they have on their desks, and getting work done with it.
So ideally, at this point we would have successfully upstreamed everything of significance on beagleboards and could leave it to others to maintain suitable distro support. Is that in fact the case? (I admit I haven't been following the details at all (I have, and thus only care about, nslu2/panda/n900/freerunner :-) )
It seems that both Debian and Ubuntu beagleboard installs are available: http://elinux.org/BeagleBoardDebian http://elinux.org/BeagleBoardUbuntu but it's not clear (to me) to what degree this support is in-distro. Should we be helping complete that work so that there really is proper in-distro support. I'm not convinced that our work is really done until that's the case, but we could declare that we only upstream stuff. distro-support is distro's problem.
Consider both those wiki's as more a guide for installing new boards & unsupported not yet mainline features for existing stable userspace... For the BeagleBoard specifically, this means the zippy1/2, trainer, and ulcd expansion boards work out of the box along with dsp support (via dspbridge). and as of this week, support for the new BeagleBone, which probably won't be enabled by Linaro/Canonical till 12.04/12.10..
We still ship a lot of BeagleBoard's, so i have no plans of dropping support on my end..
Regards,
On 2 December 2011 11:19, Dave Martin dave.martin@linaro.org wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinman david.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
At a minimum, this decision needs a better rationale. Someone (who?) said so is about as bad as it cat get. There is talk about transparency in processes. This is not it.
Possibly the best way to anger a community is to force decisions on it without providing any explanations. This is exactly what is happening here, and it has to stop if Linaro is to be taken seriously as a member of the community.
On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
On 2 December 2011 11:19, Dave Martindave.martin@linaro.org wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinmandavid.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle:
- There will be no more LEB or Linaro Developer builds.
- No more testing will be applied by Linaro to the boards at all,
and no quality assurance will be performed.
- No more bugs will be filed against these boards assigned to
Linaro resources.
- All currently filed bugs will be re-targeted to the appropriate
community resource.
- Landing team support is no longer needed or expected.
- Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
At a minimum, this decision needs a better rationale. Someone (who?) said so is about as bad as it cat get. There is talk about transparency in processes. This is not it.
I can give a good rationale for generally keeping some pressure up to limit the number of supported boards, it's very difficult to provide good quality over multiple platforms. We at the LT had quite a big shock with 4460 Panda which has much more restricted changes than between OMAP3 and OMAP4, it doubled our test load and led to a lot of problems for a while.
All the LTs will get next-gen stuff to work on in the coming months, some clearing of the decks to limit the scale we have to cover will be a very good idea.... if BB is to go then probably igep should go the same way. There's no point just having them there in name only but they're second-class citizens for actual work and test (OMAP3 has never had any TI LT attention for example).
Possibly the best way to anger a community is to force decisions on it without providing any explanations. This is exactly what is happening here, and it has to stop if Linaro is to be taken seriously as a member of the community.
I am not sure that's a usable consideration for making the decision. I think the question is, is providing these builds and doing the work on that platform still moving Linaro and the vendor's interests forward, or is the time better spent on supporting future products early and making a bigger difference there.
-Andy
On 2 December 2011 13:31, Andy Green andy.green@linaro.org wrote:
On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
On 2 December 2011 11:19, Dave Martindave.martin@linaro.org wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinmandavid.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
At a minimum, this decision needs a better rationale. Someone (who?) said so is about as bad as it cat get. There is talk about transparency in processes. This is not it.
I can give a good rationale for generally keeping some pressure up to limit the number of supported boards, it's very difficult to provide good quality over multiple platforms. We at the LT had quite a big shock with 4460 Panda which has much more restricted changes than between OMAP3 and OMAP4, it doubled our test load and led to a lot of problems for a while.
All the LTs will get next-gen stuff to work on in the coming months, some clearing of the decks to limit the scale we have to cover will be a very good idea....
See, that wasn't so hard. If manpower is the issue, just say so. People can understand that. Arbitrary-looking decisions handed down from management without explanation they cannot. This is how many companies create a very clear separation of classes among their employees, the privileged management on one side, and the engineering plebs on the other. Is this how Linaro wants to be?
if BB is to go then probably igep should go the same way. There's no point just having them there in name only but they're second-class citizens for actual work and test (OMAP3 has never had any TI LT attention for example).
Possibly the best way to anger a community is to force decisions on it without providing any explanations. This is exactly what is happening here, and it has to stop if Linaro is to be taken seriously as a member of the community.
I am not sure that's a usable consideration for making the decision. I think the question is, is providing these builds and doing the work on that platform still moving Linaro and the vendor's interests forward, or is the time better spent on supporting future products early and making a bigger difference there.
I'm not saying the community needs to be considered in making every decision. However, if Linaro wants to be seen as, even partially, being part of the community, decisions such as this need to be given some justification beyond "someone said so". Alternatively, Linaro could stop pretending to care about the community at all. Being seen as dishonest is far worse than simply not caring.
On 12/02/2011 10:02 PM, Somebody in the thread at some point said:
On 2 December 2011 13:31, Andy Greenandy.green@linaro.org wrote:
On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
On 2 December 2011 11:19, Dave Martindave.martin@linaro.org wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinmandavid.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle:
- There will be no more LEB or Linaro Developer builds.
- No more testing will be applied by Linaro to the boards at all,
and no quality assurance will be performed.
- No more bugs will be filed against these boards assigned to
Linaro resources.
- All currently filed bugs will be re-targeted to the appropriate
community resource.
- Landing team support is no longer needed or expected.
- Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
At a minimum, this decision needs a better rationale. Someone (who?) said so is about as bad as it cat get. There is talk about transparency in processes. This is not it.
I can give a good rationale for generally keeping some pressure up to limit the number of supported boards, it's very difficult to provide good quality over multiple platforms. We at the LT had quite a big shock with 4460 Panda which has much more restricted changes than between OMAP3 and OMAP4, it doubled our test load and led to a lot of problems for a while.
All the LTs will get next-gen stuff to work on in the coming months, some clearing of the decks to limit the scale we have to cover will be a very good idea....
See, that wasn't so hard. If manpower is the issue, just say so. People can understand that. Arbitrary-looking decisions handed down from management without explanation they cannot. This is how many companies create a very clear separation of classes among their employees, the privileged management on one side, and the engineering plebs on the other. Is this how Linaro wants to be?
This is OT but Linaro has been like that for a while, it's not set up as a co-op or a kibbutz but a distributed tech company with > 100 engineers spread all over. It's really quite hierarchical, has its own HR department, the lot.
if BB is to go then probably igep should go the same way. There's no point just having them there in name only but they're second-class citizens for actual work and test (OMAP3 has never had any TI LT attention for example).
Possibly the best way to anger a community is to force decisions on it without providing any explanations. This is exactly what is happening here, and it has to stop if Linaro is to be taken seriously as a member of the community.
I am not sure that's a usable consideration for making the decision. I think the question is, is providing these builds and doing the work on that platform still moving Linaro and the vendor's interests forward, or is the time better spent on supporting future products early and making a bigger difference there.
I'm not saying the community needs to be considered in making every decision. However, if Linaro wants to be seen as, even partially, being part of the community, decisions such as this need to be given some justification beyond "someone said so". Alternatively, Linaro could stop pretending to care about the community at all. Being seen as dishonest is far worse than simply not caring.
Yeah it won't hurt to explain the general reasoning along with the proposal. But I don't know really how much that reasoning will be responsive to individual annoyance at it.
I think if Linaro provides value for people in a way that makes sense for them to take up, they'll take it up and what you're maybe thinking of as a community will form naturally for the duration. What's valuable changes over time and we need to take care to continue to be relevant in the end to have a community (or a business) over time.
-Andy
On 2 December 2011 08:31, Andy Green andy.green@linaro.org wrote:
On 12/02/2011 08:21 PM, Somebody in the thread at some point said:
On 2 December 2011 11:19, Dave Martindave.martin@linaro.org wrote:
On Thu, Dec 1, 2011 at 7:14 PM, David Zinmandavid.zinman@linaro.org wrote:
A request has been received to discontinue Linaro's support for the Beagleboard and Beagleboard-xM hardware.
The following conditions will be applied for the 2012.01 release cycle: * There will be no more LEB or Linaro Developer builds. * No more testing will be applied by Linaro to the boards at all, and no quality assurance will be performed. * No more bugs will be filed against these boards assigned to Linaro resources. * All currently filed bugs will be re-targeted to the appropriate community resource. * Landing team support is no longer needed or expected. * Linaro Release notes will no longer refer to Beagleboard.
Although they are starting to be replaced, Beagle and Beagle xM are particularly popular boards in the community at large. What is the rationale behind discontinuing support for these boards at this particular point in time? Will we still continue to produce best-effort "community" builds (as for some other boards)?
EOL-ing popular boards could weaken our links to the community, so we need to think carefully about it.
At a minimum, this decision needs a better rationale. Someone (who?) said so is about as bad as it cat get. There is talk about transparency in processes. This is not it.
I can give a good rationale for generally keeping some pressure up to limit the number of supported boards, it's very difficult to provide good quality over multiple platforms. We at the LT had quite a big shock with 4460 Panda which has much more restricted changes than between OMAP3 and OMAP4, it doubled our test load and led to a lot of problems for a while.
All the LTs will get next-gen stuff to work on in the coming months, some clearing of the decks to limit the scale we have to cover will be a very good idea.... if BB is to go then probably igep should go the same way. There's no point just having them there in name only but they're second-class citizens for actual work and test (OMAP3 has never had any TI LT attention for example).
Possibly the best way to anger a community is to force decisions on it without providing any explanations. This is exactly what is happening here, and it has to stop if Linaro is to be taken seriously as a member of the community.
I am not sure that's a usable consideration for making the decision. I think the question is, is providing these builds and doing the work on that platform still moving Linaro and the vendor's interests forward, or is the time better spent on supporting future products early and making a bigger difference there.
-Andy
-- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi Mans, I would also like to add on top of Andy's comment that this is by no means a directive to cease support now. The process has recently been set up to give a period of time to have a dialogue on the issue, which is exactly what is happening now. A one month period is in effect to determine what level of support to apply to a nominated platform. Please see
https://wiki.linaro.org/Platform/RFCs/BoardSupportAndLifecycle
We welcome your contribution.
DZ
-
Andy Green -
Dave Martin -
David Gilbert -
David Zinman -
Mans Rullgard -
Peter Maydell -
Robert Nelson -
Wookey