On 2 December 2011 13: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....
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. -- Mans Rullgard / mru _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
