From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Thu, 07 Nov 2013 12:52:06 +0100 Subject: [U-Boot] livetime of boards In-Reply-To: <527B7883.1080302@gmail.com> References: <5278ED18.3050105@denx.de> <20131105203736.GM5925@bill-the-cat> <20131106075049.57EB63814E8@gemini.denx.de> <527B4C80.1090704@denx.de> <527B5F54.4080501@gmail.com> <527B6DCC.80605@denx.de> <527B7883.1080302@gmail.com> Message-ID: <527B7EE6.4030307@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Andreas, Am 07.11.2013 12:24, schrieb Andreas Bie?mann: > Hello Heiko, > > On 11/07/2013 11:39 AM, Heiko Schocher wrote: >> Am 07.11.2013 10:37, schrieb Andreas Bie?mann: >>> On 11/07/2013 09:17 AM, Heiko Schocher wrote: >>>> Am 06.11.2013 08:50, schrieb Wolfgang Denk: >>>>> In message<20131105203736.GM5925@bill-the-cat> you wrote: > > > >>>> But you are right, that approach leads in a lot of conflicting >>>> patches ... but I think, we just pooled board information in boards.cfg, >>>> so this would be the right place in my eyes ... >>>> >>>> Maybe we get such Information "a Boards is tested with current mainline" >>>> inform of an EMail with an Text "Board xy tested with commit mm. Please >>>> update livetime" ... and we can add a script, which updates the >>>> livetime for this board, so we can prevent conflicting patches ... ? >>> >>> I agree here with Tom. Beside the possibility of conflicting pahces I >>> see another problem here. >>> We will get a lot of patches just for increasing the tested counter for >>> a single board. These patches needs to be handled in some way. If we >>> shift to some integrated system (gerrit comes to mind) this could be >>> easier than today, but it will bind resources anyways. >>> Therefore I think it is a bad idea to save a such often changing >>> information in the source code repository. >> >> I see this info just changing once when releasing a new U-Boot version. > > The saved information how often a board was runtime tested with the > correct SHA1 of the u-boot/master could be quite useful. > In the end just the last tested commit will be interesting but it could > give some information how often that specific board is used. The > information must not be generated by a board maintainer ... the > maintainer could then see if he needs to pull out a board or if one else > run the test before. > > If we would save this in the repository we do not have this information > in time. > If we send the information to a list we need to parse it or use some > other tool to provide the information. > Beside that we will pollute the list with status updates about boards > being tested. It could be hard to find real patches in that information > flood then. Hmm... I hope we get a lot of such EMails ... and think, this is not a big problem ... Or, maybe, if we get a lot of such EMails, maybe we open a u-boot-testing list? > > >> So (in current case Tom) should, before releasing a new U-Boot >> version, first call this script "collect_livetime_info" and he get: >> >> -> one livetime counter patch for current release >> -> one list for boards which reach end of life >> -> one list for boards, which should be deleted > > Good idea, but the information could also be saved on a website or in > another database. > It should be easily filled by the tester and also easily queried by > wherever is interested in. Ok, if we have this info, we can show it wherever we want ... >> All Infos are "release info" I think, and fully fit in the commit >> for the new release ... > > I also think that should be done on release only. Yep! But collecting this infos can be done all the time. >> ... maybe "deleting boards" can be done automatically, but this is >> not a trivial job ... > > I think deleting should be done in next release then to give the board > maintainer some time to check the boards. On a new release the board > maintainer should be mailed that in the next release the board will be > removed. We should also store this somewhere in the code (status in > boards.cfg?). See my proposal for the livetime counter: livetime init value n (n=4) livetimer decrement on every new release livetimer set to n, if in release cycle comes a test report livetimer == 0 -> EMail to board maintainer, board reached end of live in mainline, please send test report. livetimer == -1 -> board get deleted So all info is in boards.cfg availiable ... > Next question is what to do if the mail bounces ;) Board gets deleted, as board maintainer didn;t send an update patch for boards.cfg ... >> So, with such a solution, I see no big additional cost for adding >> such a feature (except the task "deleting old boards", which is maybe >> not trivial) >> >> Do not understand me wrong, if we find another solution, I am >> happy also ... just spinning around ... > > Me too. > > > >>>> If we decide to delete older boards after n release cycles without >>>> testreports, we must not decide nor look in a database. We are >>>> sure, we have only "good and working" boards ... and we just >>>> do the necessary work for new features ... and we are sure, that >>>> we get back testreports within n release cycles ... >>>> >>>> So let us decide first, if we want to go this way ... >>> >>> Yes, we should introduce some mechanism to check when a specific board >>> was last runtime tested. But I fear the overhead with patches that >>> update a tested counter. >> >> I thought with "decide": Do we want to delete "old boards"? >> With this, we do not need a "MAKEALL --check-boards -s at91" when >> we introduce new features, as all boards in mainline are in a well >> tested shape ... >> >> Ok, two decisions: >> >> - Do we want to collect board testinginformation? > > I think we should do that i none way or another. Yep. >> - Do we want to delete old boards automatically after we do not get >> some test reports after a time intervall? > > And we should delete 'unmaintained' boards, when is to be discussed. I'm > currently fiddling with at91 gpio and ask myself if I should adopt all > the boards or just let them fail ... You do not have this problem when we descide to delete old boards! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany