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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
