On 28/07/2017 00:40, Joel Sherrill wrote: > On Thu, Jul 27, 2017 at 7:50 AM, Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > wrote: > > Hallo, > > the GCC 7.2 release will be probably in two weeks. I would like to use GCC > 7.2 and the Newlib snapshot 2017-07-20 for the RTEMS 4.12 release > candidate. > I propose to do the 4.12 branch one week after the tool chain update.
I do not think we are ready for a branch. I think a definite plan would help identify what we want to complete and create a focus. > I don't mind bumping binutils and gcc. For now, that newlib snapshot is OK > but I > think we may want to bump to a newer one to catch the added POSIX methods from > Aditya. Agree plus we *cannot* branch until we have a build on Windows. I do not want to have to work on a branch again to complete that task. We also need a bit of time after an update of the tools for testing. A week is tight for me. > What concerns me is: https://devel.rtems.org/milestone/4.12.0 which still > shows > 80 tickets and I still don't think there is one describing the x86 breakage on > libbsd. I have no idea how many of those should be addressed. These should be > evaluated rather than just kicked down the road. Agreed. > I did a build sweep with fresh tools yesterday. All BSPs built in my > configuration and the warnings are in OK shape. I have filed some tickets > about > a few but most of these are very easy to fix for the right person. Here are > some > areas by person who could fix quickly. Out of 57 unique warnings: > > + 12 are in libdebugger(Chris) I have a patch for libdebugger I am still testing. > + 6-8 are in BSPs or termios that I think you need to look at. > + 7 are in new mmap code (Gedare)> > It would be great if the core developers could take a look at the full report > and see what can be eliminated > > ftp://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-4.12-master-20170726/ > > There are somie warnings for the static asserts. I suspect these are due to > BSPs > are low optimization levels. > > So I would like to make sure we: > > + know the state of all tickets and consciously make a decision on them. > + address some of these warnings. + Windows build of tools. + docs.rtems.org updated to work with repo updates and releases. + Zynq PCAP patches from Patrick which are on the list + examples-v2 building > That doesn't begin to address whether BSPs work or odd issues like do we > switch > to Couverture for qemu. What is the status of GSoC work? What are we looking at having merged onto master? > > I'm not trying to be an impediment. I just want a burn down list. > As you say a review of the tickets on the 4.12.0 milestone would be good. This can then become the list of tasks we need to complete. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel