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