On 2021-03-08 16:43, Joel Sherrill wrote:
On Sun, Mar 7, 2021 at 9:51 AM Daniel Hellstrom <dan...@gaisler.com
<mailto:dan...@gaisler.com>> wrote:
On 2020-09-23 17:05, Gedare Bloom wrote:
On Wed, Sep 23, 2020 at 4:34 AM Daniel Hellstrom<dan...@gaisler.com>
<mailto:dan...@gaisler.com> wrote:
Hi Sebastian,
Thanks for asking and sorry for dropping the ball on these.
The status is that two needs updating (BSD license for new CAN files and
the last tn0018 patch needs some redesign based on feedback) and the
others are accepted for master. I've sent an response on the tn0018
errata patch just now. I would like to push them on the 5 and master
branches. To get them onto 5, should I create a ticket for the whole
patch set? I will try getting this done next next couple of days, and
have a look at you patches too, thanks!
It would be good to separate them logically to the TN-0018 errata
fixes vs the CAN/grlib improvements. The concern for pushing them to 5
is that they touch core sparc files, but since you guys are releasing
them this way in RCC I'm also comfortable with it. I didn't see any
changes outside the sparc (since currently grlib is sparc-specific
too). We'll need those tickets to help us with the dot-release notes.
Sorry for my very late response. There were some more updates on a
few of the patches based on the review comments which has been
addressed. I have now created tickets for all of them which are
referenced from the patches, so I will go ahead and push them for
the 5-branch (the posted patches targeted 5).
I agree with Gedare on trusting the patches. My only concern is making
sure proper tickets are filed. A couple of guidelines may help decide
how many tickets and for what.
The first thing to remember is that tickets are automatically
processed into release notes. If it is important enough to show up in
a release note, file a ticket. I have been prodding Ryan to file
tickets for the Coverity issues because I think they should be in
release notes.
For 5, any changes should have tickets. This is a long standing rule
for release branches.
Thanks for the comments, I will keep that in mind going forward. I made
a couple of tickets for the RTEMS/master and tickets for all patches for
5.2 milestone.
However, I will wait with the TN-0018 before I get an acknowledge
for that one. I updated the its ticket with links to the GCC patch
that has now been accepted into upstreams GCC (GCC-10 stable and
master). The TN0018 patch is not enabled if the GCC-patch is not
included in the toolchain, so I believe it should be ok to push,
even before RSB is updated?
It sounds like it will be ok.
Ok, thanks!
What happens with TN0018 on the 5 branch where we are using older tools?
https://devel.rtems.org/ticket/4155
<https://devel.rtems.org/ticket/4155>
I have submitted a RSB patch which as been acked by Chris and Sebastian,
so I will proceed to push the tn0018 patch to 5 now.
Next step for me is to add some configurations for the new build
system before I can push them to RTEMS/master.
This has been done and pushed now. waf is really a speed improvement!
Thanks!
Thanks for submitting all these. Is this going to clean your queue?
The queue is much smaller now! These were the most important when I
started but got choked, I will follow up with a few important fixes done
lately.
/Daniel
--joel
Thanks,
/Daniel
Kind Regards,
Daniel
On 2020-09-18 10:03, Sebastian Huber wrote:
Hallo Daniel,
what are your plans with respect to this patch set?
Please also have a look at:
https://lists.rtems.org/pipermail/devel/2020-September/062176.html
<https://lists.rtems.org/pipermail/devel/2020-September/062176.html>
_______________________________________________
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
_______________________________________________
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
