[
https://issues.apache.org/jira/browse/YUNIKORN-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Condit closed YUNIKORN-2962.
----------------------------------
Resolution: Information Provided
> 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]
