From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26850 invoked by alias); 15 May 2009 09:52:04 -0000 Received: (qmail 26838 invoked by uid 22791); 15 May 2009 09:52:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from rubicon.hasler.ascom.ch (HELO rubicon.hasler.ascom.ch) (139.79.129.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 May 2009 09:51:56 +0000 Received: from eiger.ma.tech.ascom.ch (eiger.ma.tech.ascom.ch [139.79.100.1]) by rubicon.hasler.ascom.ch (8.14.1/8.14.1) with ESMTP id n4F9ppPY029399; Fri, 15 May 2009 11:51:51 +0200 (MEST) Received: from [139.79.100.143] (helo=donkey.ma.tech.ascom.ch) by eiger.ma.tech.ascom.ch with esmtp (Exim 3.16 #1) id 1M4u50-0006Y0-00; Fri, 15 May 2009 11:51:50 +0200 Received: from lunn by donkey.ma.tech.ascom.ch with local (Exim 4.69) (envelope-from ) id 1M4u50-0000om-NC; Fri, 15 May 2009 11:51:50 +0200 Date: Fri, 15 May 2009 09:52:00 -0000 From: Andrew Lunn To: Rutger Hofman Cc: Ross Younger , ecos-maintainers@ecos.sourceware.org, Simon Kallweit , Sergei Gavrikov , Melanie Rieback , Paul Beskeen Subject: Re: NAND & YAFFS Message-ID: <20090515095150.GH17679@ma.tech.ascom.ch> References: <4A0AD212.60208@ecoscentric.com> <4A0C6674.5030006@cs.vu.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0C6674.5030006@cs.vu.nl> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact ecos-maintainers-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00014.txt.bz2 Hi Folks As an eCos maintainer i've been taking a back seat recently, pursuing other interest etc. However i'm probably the most independent maintainer since i've never worked for eCosCentric. [...] > I dutifully followed eCos' outlined procedures to avoid double work, > and did RFCs and notification of early release (including the > statement that it is complete on my BlackFin hardware, and that it > had survived some long YAFFS tests). Sure, I picked up the comments > made by Andrew Lunn. I fully agree with you here. You did all the right things. I wish i could of helped some more, but i have no real knowledge of NAND, don't have any hardware which uses it and no real personal need for it. I did consider writing a synth NAND emulator, as a way to get into the subject more, but there is no really itch i needed to scratch. Anyway, this is getting away from the point of the email... > Allow me to confess that I am disappointed that the work I put into NAND > flash for eCos has not been considered by eCosPro. [...] > > Another reason that I think eCosPro has not chosen the wisest course > here is the shadow it throws into the future. Isn't it an unattractive > proposition for anyone who would want to contribute that they will only > afterwards be informed that their work may be out-competed by eCosPro > themselves? This is also not the first time this has happened. A recent example would be the Cortex-M3 work. If i dug into the email archives i could find other examples. There is a possibility of it happening again soon as well. eCosCentric have a more modern lwIP port in there tree than the current in anoncvs. I understand they have optimized it for small platform and made it more stable. There is the current effort going on to update the anoncvs lwip code. When this reaches maturity, which looks like will happen soon, are eCosCentric going to pull out there trump card again and contribute there lwip port? In most of these cases there has been early communication from the community. eCosCentric don't take part in such communications, which is find disappointing. In fact the only module i can think of which had open discussion between an open community development and eCosCentric payed for by contract was the flash_v2 code. They are a commercial organization, so do have some restrictions. Fixed delivery dates, NDAs with customers, the desire to sell something a couple of times to recoup their costs etc. They also need to defend against the case that somebody says they are going to develop feature X, which eCosCentric already have, in a hope that eCosCentric will make there version available for free. It seems to me eCosCentric waits for the open version of feature X to reached beta quality, is clearly going to be useable, but is incompatible to there implementation. They then make there own available to easy there own integration problems. By this time, whoever has implemented the open version has spent a few man months and is not happy about there wasted effort and maybe then being forced to port there device drivers etc to eCosCentric infrastructure, so causing them more effort. How can things be better? I would say eCosCentric needs to find a way to be more open about what they are doing. Was this level of secrecy needed for a NAND infrastructure? What has been gained by eCosCentrics customer by keeping it secret? Why could eCosCentric, when it got the contract, not jump into the discussion, suggest changes to the proposed API and get it frozen. Maybe offered to take over development of the core and ask Rutger to work on drivers for his specific devices using the frozen API? If this could not be done out in the open would it not of been possible to setup an NDA with Rutger and do it behind closed doors until it was ready for release? eCosCentric is also not benefiting from the community. They have lost 3 man months of effort from Rutger which could of been used for nearly free to fulfil there customer contract! Once they released there Cortex-M3 port a few bugs where quickly found which with a more open development process would of been found earlier. There own products could be made better from more interaction with the community. How do we go forward with the NAND work? First impressions is that the two implementations are roughly equal. So we need an open review of both. Since eCosCentric are offering to contribute theres, please post it to ecos-patches along side Rutgers, so all interested parties can take part in the review. Andrew