Hi Richard,
Am 09.12.2022 um 13:01 schrieb Richard Purdie:
On Fri, 2022-12-09 at 11:39 +0100, Stefan Herbrechtsmeier wrote:
Sorry for the harsh tone but you ignore existing tools and add just
another tool to oe-core without mention any reason or document it. Do
you really expect that somebody will patch existing tools if main
developers ignore existing tools and provide new tool for their use
case?
I'm not sure that is entirely fair criticism. We have some challenges
with some of the new languages. Rust support was in a separate layer.
We took some of those recipes into core, then ended up making
significant changes to them. We never took the external tool.
The hope in doing that was that we'd find a better way to make things
work. I think what Alex has done is an improvement over that external
tool and it experiments with a different way of handling things. I've
had generally quite positive feedback on the approach itself. Yes,
there are some issues with documentation and some people using it have
struggled with some usability issues. None of those look like they're
unfixable.
Why should somebody improve an existing tool, extend the
documentation, add tests or even upstream its work if these same
requirements don’t exist for the main developers. It looks like the
requirements for foreign and main contributors are different and this
doesn't encourage people to participant.
I don't see us treating developers differently and I am concerned you
think we/I do. Any given solution that is proposed is evaluated on it's
pros and cons. In this case the solution is quite self contained and
allowed the approach to be experimented with whilst solving a real
world issue. If it doesn't work out we can easily drop it. The risk
from taking it is therefore low. Yes, I should probably insist on
documentation. In this case it is relatively simple code which is
relatively easily understood so I've been less worried about that up
front.
If it worked out well, we can integrate it further and document it. If
it doesn't it can be removed. FWIW I have heard people saying they like
the approach and that we should use it for some of the other languages
with challenges like this.
Maybe this is only my personal feeling and I apologize my harsh
tone, but the acceptance of patches should be comprehensible, and
expectations should be the same for everyone.
I do try to ensure that. My "algorithm" for accepting patches is
probably not easily documented but I think the factors here which are
the standalone nature of the change and the easy with which we could
drop it if needed. As such it is in my "low risk" category of patches.
I'd note Alex has another patch which has been sitting for months
unmerged as it is in my "high risk" to the project category. I suspect
that one will not actually merge but I need to find the time to explain
why, right now it is more based on a feeling it is the wrong direction.
Should others answer to your comments that their solution doesn’t
preclude your suggestion and that they welcome patches? For sure it
takes more time to add rust support to recipetool but I think a
second tool without a clear reason in oe-core hurts more in long term
because its now unclear if new features (like checksums or licenses
support) should be added to this tool or if this tool is only a
temporary solution and should be replaced by recipetool in long term.
Furthermore, this class is marked as a class for a recipe but
shouldn’t be inherit by a recipe and manipulates a file inside the
meta data.
We do have precedence for classes that help updates like this. Both
python and perl have code that adds tasks that function a bit like
this, in those cases for the core recipe.
Personally, I would ultimately like to see these operations handled by
recipetool and I suspect natural evolution of the code may head that
way. Both devtool and recipetool have used classes as a way to help
them perform operations so in that sense, this is actually a logical
development path for those tools.
Thanks for you feedback and the clarification. This helps me a lot.
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174461):
https://lists.openembedded.org/g/openembedded-core/message/174461
Mute This Topic: https://lists.openembedded.org/mt/94683148/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
