search

ibm-s390-linux / s390-tools

Tools for use with the s390 Linux kernel and device drivers
MIT License
63 stars 59 forks source link

Why simple refactoring fixes from 2018 getting code-dropped in 2020? #83

Open xnox opened 4 years ago

xnox commented 4 years ago

Why simple refactoring fixes from 2018 getting code-dropped in 2020?

Can you please streamline your processes of releasing non-feature bugfixes, refactors, whitespace changes, such that they land publically as soon as they are developed? And not a year and a quarter later?

hoeppnerj commented 4 years ago

Changes are pushed upstream fairly regularly. The only commits from 2018 that were pushed recently were related to the FCP Endpoint Security feature. Most of the time there are internal reasons that prohibit a push to upstream and delay the public availability.

I can't see any of the mentioned non-feature bugfixes, refactors, whitespace changes that would've been made back then. Quite a few changes of that sort, however, were pushed just recently in the scope of the development of a new tool.

I don't think that we hold back on those kind of changes (there would be no reason). What exactly is the issue for you? Do you encounter conflict because you've made similar changes? You're always welcome to send PRs for non-feature bugfixes, refactors, or whitspace changes.

xnox commented 4 years ago

I don't have immediate concerns about the code that has been made public.

My concern is with the internal reasons that prohibit a push to upstream and delay the public availability and my wish to eliminate those.

Ubuntu is downstream, and for all other hardware vendors we integrate public trees that are not yet merged upstream for toleration and exploitation of unreleased hardware. E.g. we pull kernel/toolchain Linaro trees before they are finalised and merged in respective upstream. Yet with s390-tools, we are made aware that a code-drop is coming, and the patches are available, yet there are no public-pre-release trees for us to pull from. That would be ok, if the patches are not developed yet / not stable yet. It feels like the code was ready for a long time, just not made public.

I recall when Linux upstream pulled support for a hardware family for like more than a year, with many updates (both toleration and exploitation). Only for that hardware family to never GA, and subsequently it was dropped from Linux upstream. I prefer that. Because downstream can integrate all the code, making it so much easier to develop and test future hardware, as everything pre-supports it out of the box.

Please consider maintaining a devel/next branch, which is rebased on top of master, and includes future integration patches/trees, which have no API/ABI stability guarantees and are expected to be rewritten/dropped/evolve. This way, there is a public tree to land cutting-edge changed, which might not be quite ready for wide consumption. Something similar to the next linux kernel trees in spirit.