On Fri, 2022-09-09 at 11:27 +0200, Konrad Weihmann wrote: > > On 09.09.22 11:09, Richard Purdie wrote: > > On Fri, 2022-09-09 at 10:42 +0200, Konrad Weihmann wrote: > > > A general remark from my side about this patch is that this limitation > > > isn't mentioned in the documentation at all [1]. > > > I would have been in favor of just dropping this piece of code, esp as > > > the check wasn't run for years now - but here we are with another > > > undocumented and breaking change (at least for me, as the template confs > > > in my projects weren't located under templates, until everything fell > > > apart in CI over night) > > > > The tone of what you've written here isn't great but let me comment. > > Sorry about the tone - I was a little frustrated about this. > I fully understand that there will be breaking changes, esp. if they are > justified - I'm just questioning that this here in the case. > The migration path should have been to drop the code piece and let users > freely decide where to place those template configs (basically keeping > the existing behavior and having an easy migration path).
I guess enforcing a location was probably my fault. The reason I'm keen to have a known location is for discoverability. We need better tools around setup and configuration but tools work best with known layouts rather than making guesses. I think that this is a small step towards solving a much bigger problem but we have to start somewhere. I'm sorry you disagree. You are effectively advocating for don't change anything though (and would later then be unhappy new tooling didn't work with your templates). If we did that it would likely lead to people advocating for more complex guessing about layouts which in my experience is error prone. > > The project can and will make changes and try to improve, it has to. > > Some of these changes will break things. We usually try our best to > > minimise disruption but change is what happens on the development > > branch. We usually do a reasonable job of documenting things as part of > > the release notes and the migration guide but this isn't in a release > > yet. > > But what I actually wanted to highlight, is that this is simple > undocumented as of now - so my expectation would have been, if there's > new limitation then it should be accompanied by a patch to the > documentation, otherwise there will be a gap. > And the documentation improved quite a lot over the past 2 years, so I > would want to keep this quality as high a possible. I believe the documentation is known about and coming, there were emails on the docs list about it already. Ideally we'd require all changes to arrive with the documentation complete. The barriers to making *any* breaking change are already at the point where many developers run away screaming with the levels of issues they face and are asked to resolve. I personally often don't do things either just due to these kinds of issues too. I'm reluctant to put further obstacles in the way. It should be clear I do hugely value documentation btw. I have strongly supported maintaining and developing our docs, I just have to take a pragmatic view over how changes merge. > From my perspective it's super hard to train my developers to a master > first approach, but not having proper documentation what they have to be > aware of. And I'm sure it's not the expectation of the project to have > users grep through the fairly huge code base and git history to find out > why all of a sudden a known good behavior changes. To find out what changed you had to look at the changelog of the last few changes on master as presumably you build on a semi regular (and known basis). We do require good commit messages and there was information in there about this. I therefore don't agree you had to grep through a large codebase, you could knew where this change came from and how to find out more information. > We (as in my devs and me in the several projects) could stay on LTS or > what ever release version is out there, but that would clearly miss my > goal of bringing in more contributors to the project, which is currently > already hard enough. I do appreciate the help with that. > > We do have LTS branches and we are not in the habit of pushing breaking > > changes to those. > > > > For reference, I would ideally love to have a team of engineers I could > > work with to make sure all changes had strong migration code and > > nothing every broke. We have to manage with what we have. > > To me that sounds like a selftest tbh - from my perspective it should > have been caught in the existing CI before hitting master The existing CI initially failed with some of the changes. The changes were revised, some new tests were even added. The changes passed before they merged. > Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#170481): https://lists.openembedded.org/g/openembedded-core/message/170481 Mute This Topic: https://lists.openembedded.org/mt/93502783/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
