<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 24, 2019 at 4:44 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@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 23/11/19 1:31 am, Sebastian Huber wrote:<br>
> On 22/11/2019 15:25, Joel Sherrill wrote:<br>
>> On Fri, Nov 22, 2019, 8:19 AM Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
>> I am about to add the documentation of the new build system to the user<br>
>> manual. There is no longer a bootstrap of the sources necessary. Should<br>
>> I remove all information for the bootstrapping from the user manual?<br>
>> Should there be a chapter for the old build system?<br>
>><br>
>> Don't remove the old process until the code is removed. I thought we had<br>
>> agreed to a final autoconf based release. A release with both will help ensure<br>
>> it is functionally equivalent and provide a baseline for comparison.<br>
> <br>
> I would remove the old build system as soon as possible. Shipping a release with<br>
> two build systems makes maintenance more difficult. Getting rid of<br>
> Automake/Autoconf would remove these packages from the RSB build for example.<br>
<br>
After a some consideration over the weekend I am not sure what we should do and<br>
I think we need to discuss it some more.<br>
<br>
We need to answer the important question of user churn. A change of this type<br>
will have a flow on effect to established users and any infrastructure they have<br>
to build and deploy RTEMS. An example is the `5/bsps` build sets in the RTEMS, a<br>
build system change breaks those configurations. I am sure there are many other<br>
scripts in use today. I also know there are sites running 4.11 and 5 in parallel<br>
and building each will break.<br>
<br>
We need to decide if this churn to our users is something we want now.<br>
<br>
I currently do not favor a release with both build systems being present.<br></blockquote><div><br></div><div>My big concern is ensuring that we know the new build system works exactly like</div><div>the old one. And by works, I mean produces the same binary code with the same</div><div>configure options expressed in the new build system's manner. Here are some</div><div>things we need to consider. These are of varying complexity and type.</div><div><br></div><div>(1) Users historically test "dot zero" releases and the "dot one" incorporates<br></div><div>a lot of fixes that we really wish had been in the "dot zero". This raises the</div><div>question of when do we get enough community testing to have confidence</div><div>the new system has no breakages from the old one?</div><div><br></div><div>(2) rtems-bsp-builder will need to change to support the new build system.<br></div><div>I think this is a must have to ensure a certain level of no breakages.</div><div><br></div><div>(2a) Related: Do we know the new build system builds all the configurations<br></div><div>rtems-bsp-builder performs?</div><div><br></div><div>(3) BSPs have a number of variables which can be overridden. How will we</div><div>know these still are supported and work?</div><div><br></div><div>(4) an unknown number of instructions will have to change. [This may be<br></div><div>time to purge/convert/fix more wiki content. This is not necessarily a bad</div><div>thing -- just a stick to beat us to do something.]</div><div><br></div><div>(5) Developer disruption. I am hoping this doesn't have the negative impact</div><div>switching from CVS to git did. But it could. It isn't that the switch over itself</div><div>is bad. It's just that we can forget all the side-effects and human retraining.</div><div><br></div><div>My overarching concern with all of these is "risk reduction". The primary</div><div>risk is breaking something. And the risk reduction is (1) testing before switch</div><div>over and (2) having a reference after switch over for behavior? </div><div><br></div><div>So what's the criteria for switching over? I have no idea what the acceptance </div><div>criteria is. Can we define that?</div><div><br></div><div>What can that reference be? I think this is from heaviest to lightest.</div><div><br></div><div>+ Build systems in parallel on same branch for N time?<br></div><div><br></div><div>+ final release with old build system and then kill it.<br></div><div><br></div><div>+ final autoconf snapshot known to work -- implies testing the snapshot which<br></div><div>we don't do right now..</div><div><br></div><div>+ (lightest) tag RSB, tools, rtems, and libbsd repos with a "pre-autoconf-death"<br></div><div>tag. This at least lets someone easily go back to that point in time across the repos.</div><div>You can't do this easily with git log because you would have to find the right place</div><div>in multiple repositories.</div><div><br></div><div>I probably can be convinced that the lightest option is acceptable. Whatever</div><div>the reference point is, it just needs to be documented what it is and how to</div><div>recreate it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If we decide it is OK to have the churn we can proceed as we currently are. The<br>
build changes can be merged and the autotools build system can be removed.<br>
<br>
If we decide we would like to make RTEMS 5 the last autotools release we need to<br>
make the release and that would mean a focused effort by more than just me. We<br>
cannot leave all the hard work done by Sebastian for a new build system on hold.<br>
<br></blockquote><div>I agree on not letting the new build system hold.</div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Either path effects someone, a developer, for example Sebastian, our users with<br>
churn or me and I hope other core developers with a release.<br></blockquote><div><br></div><div>Churn will occur at some point. My concern is risk.</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>
A release means getting the release itself debugged then we need to test it. It<br>
also means there may be possible changes and we need to be mindful of the effect<br>
that might have on the work Sebastian has already done.<br></blockquote><div><br></div><div>And knowing that we don't have good infrastructure to test those snapshots right now,</div><div>I would lean to having tags in the repos. We have good testing on the repos.</div><div><br>Perhaps after the build system switch, we can focus on testing the snapshots.</div><div><br></div><div>We only have a finite amount of volunteer time to make this transition. Where is</div><div>the effort best spent? </div><div><br></div><div>My gut hunch is on updating the testing infrastructure and documentation after </div><div>the switch to get back to full speed as quickly as possible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I look forward to hearing what our developers and community think.<br></blockquote><div><br></div><div>Me too. </div><div><br></div><div>I'm not trying to put extra burden, work or churn on anyone. I'm just concerned</div><div>that this build system transition has inherent risks. We need to do what we can</div><div>to reduce risk before the switch, provide a known (good?) reference point,</div><div>and make sure we have a complete work list. And commitment to finish that</div><div>work list. </div><div><br></div><div>And we all have holidays. etc coming up.</div><div><br></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>
Chris<br>
</blockquote></div></div>