Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
xnox opened this issue Mar 17, 2020 · 2 comments
Open

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

xnox opened this issue Mar 17, 2020 · 2 comments

Comments

@xnox
Copy link
Contributor

xnox commented Mar 17, 2020

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
Copy link
Contributor

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
Copy link
Contributor Author

xnox commented Mar 18, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants