On 2 December 2011 08:31, Andy Green <andy.gr...@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 Martin<dave.mar...@linaro.org> wrote: >>> >>> On Thu, Dec 1, 2011 at 7:14 PM, David Zinman<david.zin...@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/#!/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 -- David Zinman Linaro Release Manager | Project Manager Linaro.org | Open source software for ARM SoCs _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
