[
https://issues.apache.org/jira/browse/YUNIKORN-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Gantenbein updated YUNIKORN-2962:
---------------------------------------
Description:
Hey,
If you’re not aware, G-Research Open Source Software (GR-OSS), has been working
in and around the YuniKorn ecosystem for the last several months. We’ve
actively contributed a number of enhancements to the project, along with
several features related to our need for a persistent record of YuniKorn events
merged[0][1][2].
However, recently many of our contributions to Apache YuniKorn appear to have
been reverted unilaterally with minimal explanation. It’s unclear to us where
the open discussion about this removal, as required by the ASF Code of Conduct,
occurred for this – we’re interested and would like to participate in those
technical discussions in the future. We’ve tried to glean the primary points of
contention here:
First, our choice of name for the (formerly) YuniKorn-history-server project
was unwise given YuniKorn is a trademark of the Apache Software Foundation
(ASF). We’ve rectified this issue by renaming the project to
unicorn-history-server. The original name was driven by our hope that
unicorn-history-server may one day find its home as an official part of the
YuniKorn. We hope our swift resolution of this concern is evidence of our
commitment to the same open philosophies held by the ASF.
Next, Craig Condit stated a concern[3] that our changes were geared towards
permitting proprietary extensions to YuniKorn. GR-OSS is an open source policy
office that does not write any proprietary code as part of our mission. In
fact, the unicorn-history-server is Apache 2.0 licensed, just like YuniKorn.
Our team made extensive efforts to devise the most minimally intrusive changes
possible after it was suggested to us that it was better to be out of tree –
we’d be thrilled if the solution to this problem would be the
unicorn-history-server being adopted as part of yunikorn-core; in lieu of this,
keeping a plugin mechanism is a base-level requirement for the
unicorn-history-server to function. We hope that our reputation as good
upstream citizens and operators can help you understand that we have no hidden
agendas – we aren’t even a product company.
Finally, it was suggested[4] that the getApplication API endpoint was
inappropriate due to its exposure of internal YuniKorn data structures. We’re
open to feedback regarding this feature and how to improve it, but again, we’re
confused as to where these discussions are happening and how to get involved in
them. In the original proposal of this feature[5], we added tests and modified
the implementation at the request of project maintainers – it’s upsetting to
have all that work and cooperation discarded without even a conversation.
Our desire is to remain a part of the YuniKorn community, but we’re very
confused about the governance and technical design process for the project –
according to [https://yunikorn.apache.org/community/people/], the maintainers
reverting our patches are at the same leadership level as those who approved
the patches originally. Can we get some clarity on the reasoning for reverting
the patches and documentation of the open community collaboration, as required
by the ASF Code of Conduct, that precipitated this removal – this appeared to
have been mentioned in the October 30th meeting[6], but this date is after the
revert of the patches, so we assume there must have been another discussion.
If there’s anything further we need to do in order to spawn the technical
dialogue needed to address your concerns with unicorn-history-server and the
supporting elements, please let us know. Our desire is to implement something
in an open way that meets not only the needs of G-Research, but also those of
the overall YuniKorn community.
Thanks for your time,
Rich Scott, Open Source Developer
Denis Coric, Open Source Developer
Jay Faulkner, Open Source Developer
Dave Gantenbein, Director of Software Development
Alexander Scammon, Head of Open Source Development
G-Research Open Source Software
0: https://issues.apache.org/jira/browse/YUNIKORN-2606
1: https://issues.apache.org/jira/browse/YUNIKORN-2652
2: [http://tiny.cc/ag5tzz]
3: https://issues.apache.org/jira/browse/YUNIKORN-2954
4: https://issues.apache.org/jira/browse/YUNIKORN-2925
5: [https://github.com/apache/yunikorn-core/pull/897]
6: [Apache YuniKorn Community Sync
Up|https://docs.google.com/document/d/165gzC7uhcKc5XDWiMYSRKBiPQBy2tDtXADUPuhGlUa0/edit?tab=t.0#heading=h.6wgz1xgh0qde]
was:
Hey,
If you’re not aware, G-Research Open Source Software (GR-OSS), has been working
in and around the YuniKorn ecosystem for the last several months. We’ve
actively contributed a number of enhancements to the project, along with
several features related to our need for a persistent record of YuniKorn events
merged[0][1][2].
However, recently many of our contributions to Apache YuniKorn appear to have
been reverted unilaterally with minimal explanation. It’s unclear to us where
the open discussion about this removal, as required by the ASF Code of Conduct,
occurred for this – we’re interested and would like to participate in those
technical discussions in the future. We’ve tried to glean the primary points of
contention here:
First, our choice of name for the (formerly) YuniKorn-history-server project
was unwise given YuniKorn is a trademark of the Apache Software Foundation
(ASF). We’ve rectified this issue by renaming the project to
unicorn-history-server. The original name was driven by our hope that
unicorn-history-server may one day find its home as an official part of the
YuniKorn. We hope our swift resolution of this concern is evidence of our
commitment to the same open philosophies held by the ASF.
Next, Craig Condit stated a concern[3] that our changes were geared towards
permitting proprietary extensions to YuniKorn. GR-OSS is an open source policy
office that does not write any proprietary code as part of our mission. In
fact, the unicorn-history-server is Apache 2.0 licensed, just like YuniKorn.
Our team made extensive efforts to devise the most minimally intrusive changes
possible after it was suggested to us that it was better to be out of tree –
we’d be thrilled if the solution to this problem would be the
unicorn-history-server being adopted as part of yunikorn-core; in lieu of this,
keeping a plugin mechanism is a base-level requirement for the
unicorn-history-server to function. We hope that our reputation as good
upstream citizens and operators can help you understand that we have no hidden
agendas – we aren’t even a product company.
Finally, it was suggested[4] that the getApplication API endpoint was
inappropriate due to its exposure of internal YuniKorn data structures. We’re
open to feedback regarding this feature and how to improve it, but again, we’re
confused as to where these discussions are happening and how to get involved in
them. In the original proposal of this feature[5], we added tests and modified
the implementation at the request of project maintainers – it’s upsetting to
have all that work and cooperation discarded without even a conversation.
Our desire is to remain a part of the YuniKorn community, but we’re very
confused about the governance and technical design process for the project –
according to https://yunikorn.apache.org/community/people/, the maintainers
reverting our patches are at the same leadership level as those who approved
the patches originally. Can we get some clarity on the reasoning for reverting
the patches and documentation of the open community collaboration, as required
by the ASF Code of Conduct, that precipitated this removal – this appeared to
have been mentioned in the October 30th meeting[6], but this date is after the
revert of the patches, so we assume there must have been another discussion.
If there’s anything further we need to do in order to spawn the technical
dialogue needed to address your concerns with unicorn-history-server and the
supporting elements, please let us know. Our desire is to implement something
in an open way that meets not only the needs of G-Research, but also those of
the overall YuniKorn community.
Thanks for your time,
Rich Scott, Open Source Developer
Denis Coric, Open Source Developer
Jay Faulkner, Open Source Developer
Dave Gantenbein, Director of Software Development
Alexander Scammon, Head of Open Source Development
G-Research Open Source Software
0: https://issues.apache.org/jira/browse/YUNIKORN-2606
1: https://issues.apache.org/jira/browse/YUNIKORN-2652
2: http://tiny.cc/ag5tzz
3: https://issues.apache.org/jira/browse/YUNIKORN-2954
4: https://issues.apache.org/jira/browse/YUNIKORN-2925
5: https://github.com/apache/yunikorn-core/pull/897
6: Apache YuniKorn Community Sync Up
> Governance clarification: guidance requested on extending Yunikorn core
> functionality
> -------------------------------------------------------------------------------------
>
> Key: YUNIKORN-2962
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2962
> Project: Apache YuniKorn
> Issue Type: Task
> Reporter: David Gantenbein
> Priority: Major
>
> Hey,
>
> If you’re not aware, G-Research Open Source Software (GR-OSS), has been
> working in and around the YuniKorn ecosystem for the last several months.
> We’ve actively contributed a number of enhancements to the project, along
> with several features related to our need for a persistent record of YuniKorn
> events merged[0][1][2].
>
> However, recently many of our contributions to Apache YuniKorn appear to have
> been reverted unilaterally with minimal explanation. It’s unclear to us where
> the open discussion about this removal, as required by the ASF Code of
> Conduct, occurred for this – we’re interested and would like to participate
> in those technical discussions in the future. We’ve tried to glean the
> primary points of contention here:
>
> First, our choice of name for the (formerly) YuniKorn-history-server project
> was unwise given YuniKorn is a trademark of the Apache Software Foundation
> (ASF). We’ve rectified this issue by renaming the project to
> unicorn-history-server. The original name was driven by our hope that
> unicorn-history-server may one day find its home as an official part of the
> YuniKorn. We hope our swift resolution of this concern is evidence of our
> commitment to the same open philosophies held by the ASF.
>
> Next, Craig Condit stated a concern[3] that our changes were geared towards
> permitting proprietary extensions to YuniKorn. GR-OSS is an open source
> policy office that does not write any proprietary code as part of our
> mission. In fact, the unicorn-history-server is Apache 2.0 licensed, just
> like YuniKorn. Our team made extensive efforts to devise the most minimally
> intrusive changes possible after it was suggested to us that it was better to
> be out of tree – we’d be thrilled if the solution to this problem would be
> the unicorn-history-server being adopted as part of yunikorn-core; in lieu of
> this, keeping a plugin mechanism is a base-level requirement for the
> unicorn-history-server to function. We hope that our reputation as good
> upstream citizens and operators can help you understand that we have no
> hidden agendas – we aren’t even a product company.
>
> Finally, it was suggested[4] that the getApplication API endpoint was
> inappropriate due to its exposure of internal YuniKorn data structures. We’re
> open to feedback regarding this feature and how to improve it, but again,
> we’re confused as to where these discussions are happening and how to get
> involved in them. In the original proposal of this feature[5], we added tests
> and modified the implementation at the request of project maintainers – it’s
> upsetting to have all that work and cooperation discarded without even a
> conversation.
>
> Our desire is to remain a part of the YuniKorn community, but we’re very
> confused about the governance and technical design process for the project –
> according to [https://yunikorn.apache.org/community/people/], the maintainers
> reverting our patches are at the same leadership level as those who approved
> the patches originally. Can we get some clarity on the reasoning for
> reverting the patches and documentation of the open community collaboration,
> as required by the ASF Code of Conduct, that precipitated this removal – this
> appeared to have been mentioned in the October 30th meeting[6], but this date
> is after the revert of the patches, so we assume there must have been another
> discussion.
>
> If there’s anything further we need to do in order to spawn the technical
> dialogue needed to address your concerns with unicorn-history-server and the
> supporting elements, please let us know. Our desire is to implement something
> in an open way that meets not only the needs of G-Research, but also those of
> the overall YuniKorn community.
>
> Thanks for your time,
> Rich Scott, Open Source Developer
> Denis Coric, Open Source Developer
> Jay Faulkner, Open Source Developer
> Dave Gantenbein, Director of Software Development
> Alexander Scammon, Head of Open Source Development
> G-Research Open Source Software
>
> 0: https://issues.apache.org/jira/browse/YUNIKORN-2606
> 1: https://issues.apache.org/jira/browse/YUNIKORN-2652
> 2: [http://tiny.cc/ag5tzz]
> 3: https://issues.apache.org/jira/browse/YUNIKORN-2954
> 4: https://issues.apache.org/jira/browse/YUNIKORN-2925
> 5: [https://github.com/apache/yunikorn-core/pull/897]
> 6: [Apache YuniKorn Community Sync
> Up|https://docs.google.com/document/d/165gzC7uhcKc5XDWiMYSRKBiPQBy2tDtXADUPuhGlUa0/edit?tab=t.0#heading=h.6wgz1xgh0qde]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
