Building rtems-4.9 using source builder failes

[Chris Johns]

On 10/11/2017 05:28, Michael Davidsaver wrote:
> On 11/08/2017 02:57 PM, Chris Johns wrote:
>> I am happy to merge patched onto other branches including 4.9 if the change has
>> been tested. I would need a tested patch attached to a ticket and a ticket for
>> each branch with the branch and next release milestone set on the ticket. Please
>> consider doing this as it helps everyone.
> 
> IMO this is a high threshold for making small changes.

For master and the normal development cycle, yes of course it is. The 4.9.6
release is now 6 years old and the 4.9 series is 8 years old. I would have been
able to say I was young when first released, I cannot make that claim now. :)

Your point is important and it deserves a complete answer.

We have added the requirement for tickets for releases and release branches so
we can track the state of a release and automatically generate an accurate set
of release notes. I do not consider this constraint a burden, I welcome it. I do
however have a conflict of interest, I have to sit on the other side and decide
when we release and generate the releases. Manually creating release notes is a
major undertaking and prone to error and omission. Using tickets to track
changes gives a clear and traceable process for the entry of changes onto a
release and a release branch. The ability to automatically create release notes
removes one of the major blockers when it comes to making a release. Tickets
also provide us with a simple way to audit a release to see what is outstanding.

Asking users to create a ticket and attach a patch does increase the effort
required however it saves a huge amount of time for those maintaining the
project so we ask with a big smile to "please take a little longer and do this
because it really does help".

In relation to the patch being tested, I just assumed the patch is useful for
the person posting it so they would have built the tools, RTEMS and then any
application. For this type of patch I consider that to be a suitable test. I did
not see this as any extra effort.

> You're right
> about publicizing issues encountered and possible fixes.  In future I'll
> at least send a note to this mailing list.

Please consider posting the patch as well as sending a note.

The only problem with posted patches or notes without a ticket is the patch
being forgotten and not merged. A ticket with a milestone helps stop changes
being lost. The top page of the wiki provides links to the release milestones
for quick access.

Chris