Gedare Bloom commented: https://gitlab.rtems.org/groups/rtems/-/work_items/35#note_133402 An issue to keep in mind is how to stage reformatting in a way that reduces backport maintenance burden. Although nothing can really make this easy. I see three options. First, we could consider doing a reformatting pass on the release branch. For example, assuming `7.1` is the reformatting milestone, we could land reformatting on the `6` branch for a `6.3` release. This is a lot of churn for a release branch, but it would make it a lot easier to apply backported patches. Second, we could reformat files as part of doing a backport. This would cause some additional overhead on backports also, but reduce the amount of changes across the releases in the `6` series. Third, we could leave it as a problem for each developer backporting patches to handle. This shifts burden on developers and may reduce the likelihood of backports being made to `6` after the reformatting lands on `main`. I don't have a strong opinion either way. The reformatting should be non-functional changes in nature, so I see no problem with doing a reformat pass on `6.2`, but it does introduce a large code change within the dot release. -- View it on GitLab: https://gitlab.rtems.org/groups/rtems/-/work_items/35#note_133402 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
