<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 29, 2019 at 5:31 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 29, 2019 at 4:03 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br>
><br>
> On 30/7/19 7:43 am, Gedare Bloom wrote:<br>
> > On Thu, Jul 25, 2019 at 6:34 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> >><br>
> >> Hi<br>
> >><br>
> >> I am in the middle of building tools with a newlib bump to include the ndbm addition. When I commit the patch which adds a test, builds with older toolsets will break.<br>
> >><br>
> >> I think I should conditionalize the test on the presence of one of the new methods.<br>
> >><br>
> >> Thoughts?<br>
> >><br>
> > How long do you leave the condition in?<br>
><br>
> Good question and I do not have an answer.<br>
><br>
> > at first I thought this is OK,<br>
> > but generally we accept that a patch on master can cause a need to<br>
> > update toolchain. As long as the toolchain patch is upstreamed or<br>
> > available via RSB git-pull, I think it is fine to let older toolsets<br>
> > break. One should generally expect to rebuild their toolchain after<br>
> > git-pull of master anyway.<br>
><br>
> It was very handy I did not need to build matching tools to bisect rtems.git to<br>
> find the commit that broken the RPi. I was lucky in this case as I did not need<br>
> to change tools. If I had to manually build the tools to match each rtems.git<br>
> commit being tested the task that took about an hour overall would have extended<br>
> out to days. Automation of a bisect would help.<br>
><br>
This is a good point. Maybe we can somehow buffer the need for<br>
toolchain updates (using conditionals) to some frequency<br>
(monthly/quarterly).<br></blockquote><div><br></div><div>I did this one for a couple of reasons. First it took me well over a week to get </div><div>the newlib master to the point it would build and link all the RTEMS tests. There</div><div>were some odd issues with the ndbm code (no fault of Vaibhav), a weird libm</div><div>bug which has been there about a year, and the time lag on the github mirroring. </div><div><br></div><div>Personally, I would rather allow them and put a time limit on their lifespan. 3-6 months </div><div>perhaps. Keeping git bisect working and avoiding forcing everyone to do a tool update </div><div>are big positives but we need a way to timeout the code.</div><div><br></div><div>I would be willing to annotate them with something that we could search on with a</div><div>date included like "TOOL CONDITIONAL 2019-07-28" so it would be easy to </div><div>automate looking for them and pinging us. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Gedare<br>
</blockquote></div></div>