Going to take a look at this right away. Apologies for the misuse of the name, we did analyse the trademarks but for some reason apparently completely missed that.
On it now, thank you 🙏 On Wednesday, November 25, 2020 at 10:29:34 AM UTC+1 Oleg Nenashev wrote: > Hi Pawel, > > I am looking forward to see the maintenance and development to be revived > in the repository. One thing that requires your immediate attention is the > Jenkins trademark usage in your product name. The name "Jenkins" is a > registered trademark in the USA (#4664929 > <https://trademarks.justia.com/854/47/jenkins-85447465.html>, held by > Software > in the Public Interest, Inc. <https://spi-inc.org/>) in order to protect > the project and users from confusing use of the term. To reduce the process > overhead and uphold our open-source spirit, we adopt the Linux kernel > policy on trademark usage. You need to apply for a sublicense > <https://www.jenkins.io/project/trademark/sublicense> if you are using > the term "Jenkins" as part of your own trademark or brand identifier for > Jenkins-based software goods or services. You can find more information > about the trademark policy here: https://www.jenkins.io/project/trademark/ > > > "Jenkins Operator Service on Azure" does not fit the pre-approved > trademark usage patterns defined in the Linux Foundation guidelines > <https://www.linuxfoundation.org/trademark-usage/>, and hence your > company needs to go through the trademark approval process to be able to > use "Jenkins" in such product name. > > Best regards, > Oleg Nenashev > > > On Tuesday, November 24, 2020 at 6:46:50 PM UTC+1 [email protected] > wrote: > >> HI @Oleg >> >> Thanks for your quick reply! >> >> So we have just announced Jenkins Operator Service for Azure here: >> https://virtuslab.com/jenkins-operator-service-on-azure/ >> This is just the beginning of the road for Jenkins Operator Service for >> major cloud providers and platforms. Jenkins Kubernetes Operator is be a >> commercial offering, backed by freely available OSS version. >> >> Now we have a week or two of breathing space and we are getting back to >> planning future interactions and community engagement. >> >> Here are key points: >> 0. Jenkins Kubernetes Operator is a base for business initiative for >> VirtusLab, therefore we are committed to building proper full time team >> working on it. >> 1. OSS version is key part of our strategy and we don't intend to change >> that - our business model is based on managed marketplace offerings and >> support model (value added comparing to OSS that you can grab and install >> yourself). >> 2. We do agree that current Jenkins Kubernetes Operator is complicated >> and not properly modulerized. It worked for our initial version, however >> for our future plans this cannot stay. Redesigning / decoupling >> architecture is a critical step forward. >> 3. Given 2, we are now focusing on preparing proper roadmap, governance >> model and planning. >> >> Indeed point 2 will cause weird situation where there is >> simple-jenkins-operator targeting mostly OpenShift (not sure if this is the >> intention of @Akram's team, but my impression was that previous >> contributions were mostly targeted in this area) and >> jenkins-kubernetes-operator targeting wider audience (with eventually >> simplified architecture). >> >> I think it would be best discuss further cooperation going forward and we >> are happy to do that. >> >> On Wednesday, November 18, 2020 at 5:59:52 PM UTC+1 Oleg Nenashev wrote: >> >>> Hello, >>> >>> Thanks a lot to Virtus Lab for the response! I hope we could revive this >>> discussion, all interested parties are welcome to participate. >>> >>> For the record, last week there was a hosting request from Red hat for >>> starting the new operator: >>> https://groups.google.com/g/jenkinsci-dev/c/oAWCXDbgcG4 . This request >>> has been approved by the community, hence right now we may end up in a >>> situation when there are 2 operators and a community split between them. >>> >>> Best regards, >>> Oleg >>> >>> On Wednesday, November 18, 2020 at 4:54:38 PM UTC+1 [email protected] >>> wrote: >>> >>>> Hi all >>>> >>>> Quick introduction - I am CTO of VirtusLab, original company behind >>>> Jenkins Kubernetes Operator. >>>> >>>> ------ >>>> >>>> First of all, apologies for prolonged time it took us to get back to >>>> this. >>>> >>>> To the point - *it is definitely useful and desirable to have well >>>> understood governance rules* (and thanks Akram for submitting this >>>> draft proposal 🙏 ). Details might need to be discussed but this is >>>> definitely good starting point. >>>> >>>> To give you a little bit of background: >>>> Out step back from the project (in fact not a step back, rather >>>> rethinking first principles) resulted due to our internal work related >>>> very >>>> much to Jenkins Kubernetes Operator. We wanted to put some public work on >>>> hold until we have this sorted out. We were hoping for the work to be >>>> concluded in Oct, but (as is often the case with software development) we >>>> got some delays and currently aiming at having work concluded next week. >>>> >>>> *We definitely see a case for cooperation and making Jenkins Kubernetes >>>> Operator more popular e.g. in environments like Open Shift.* (which I >>>> believe is main point of interest for Red Hat). That said I think it is >>>> very much justified to say that the overwhelming majority of work done on >>>> this project (original author and overwhelmingly major developer efforts >>>> including majority of bug fixes ) comes from our organisation and we felt >>>> we have a little bit more right to steer the direction of the evolution of >>>> the operator project. We definitely see that doing work that would help >>>> Jenkins Operator be more usable e.g. in Open Shift is valuable, in the >>>> same >>>> time however this cannot be done by sacrificing the overall direction (we >>>> have more cases than only this one!). >>>> >>>> We do however understand that to have Jenkins Operator being more >>>> collaborative project we need to communicate our intention better to make >>>> sure everyone is on the same page. To that end we are going to work in >>>> following areas in upcoming weeks: >>>> >>>> - public roadmap for the project >>>> - contribution / governance model (which can be very much based on >>>> your suggestion) >>>> - separation of specific area - e.g. Open Shift is much more >>>> important for Red Hat than us and we should be able to separate this >>>> area a >>>> little bit to make Red Hat contributor's work more streamlined. >>>> >>>> As for the timeframes: >>>> >>>> - we are working on these things *right now* >>>> - we aim at being ready *s**ome time in December* (given holidays >>>> etc - it would need to be 1st part of the month). >>>> >>>> Once again - I really appreciate the governance proposal you suggested >>>> 🙏 I think it is very much in line with our thinking and I have zero >>>> doubts we would be able to come up with version that would feel >>>> satisfactory for all the sides (+future contributors). >>>> >>>> I hope this sounds reasonable (if not - don't hesitate to let me know, >>>> happy to discuss more details!) >>>> >>>> >>>> On Wednesday, October 21, 2020 at 1:28:28 AM UTC+2 slide wrote: >>>> >>>>> FYI, I made contact with some folks at VirtusLabs. They are hoping to >>>>> respond to this discussion thread in the next little while. I will keep >>>>> on >>>>> top of it an communicate with to keep the ball rolling. >>>>> >>>>> On Thursday, August 27, 2020 at 7:56:36 AM UTC-7 [email protected] >>>>> wrote: >>>>> >>>>>> *Background* >>>>>> >>>>>> In mid-october 2019, Jenkins on OpenShift developers team from Red >>>>>> Hat started to engage in the jenkinsci/kubernetes-operator >>>>>> <http://github.com/jenkinsci/kubernetes-operator> (aka Jenkins >>>>>> Operator) as contributors and committers. The initiators of the project >>>>>> are >>>>>> contributors from VirtusLab company. >>>>>> >>>>>> After a few commits related to documentation and minor bug fixes, >>>>>> the team, backed by product management, expressed their wish to engage >>>>>> more >>>>>> in the community and the project. >>>>>> >>>>>> To facilitate communication and collaboration, several rituals has >>>>>> been put in place by Red Hat team members: >>>>>> >>>>>> - >>>>>> >>>>>> Subscribing to the slack channel on virtuslab's instance and >>>>>> providing best effort community support to the users who were asking. >>>>>> - >>>>>> >>>>>> Scheduling a developer call each week to discuss developer >>>>>> related issues and ways to improve the software. Several additional >>>>>> stakeholders from Red Hat, who were strongly interested in extending >>>>>> Jenkins features were able to join (to name a few, J.F, R. Crisp, S. >>>>>> Bose, >>>>>> ....) >>>>>> - >>>>>> >>>>>> A weekly community call to allow users to talk about their use of >>>>>> the plugin and features they would like to see. If not enough users >>>>>> were >>>>>> joining, which was often the case, this call was used to discuss >>>>>> architecture and development topics. >>>>>> >>>>>> After months, discrepancies arose, especially regarding architecture >>>>>> and design. At the same time, contributing features was harder both for >>>>>> technical reasons (monolithic operator) and for governance reasons (Red >>>>>> Hat >>>>>> developers didn't have commit permissions). >>>>>> >>>>>> Despite these difficulties, Red Hat management insisted in remaining >>>>>> engaged in a community based operator and to continue the contributions, >>>>>> and also engage in larger refactoring tasks. Red Hat committers asked >>>>>> several times to have commit permissions. Initially, these requests have >>>>>> been rejected by invoking the will to keep control on the code quality. >>>>>> After several months of discussions, and difficult collaboration, Red >>>>>> Hat >>>>>> team members engagement was constant but commit permissions were still >>>>>> refused. >>>>>> >>>>>> Then, during a period of around 2 months and related to personal >>>>>> reasons, the main committer was not able to validate PRs, nor letting >>>>>> the >>>>>> other contributors be able to do it. The project was and is almost >>>>>> frozen. >>>>>> >>>>>> Red Hat is escalating the discussion to the Jenkins CI board to see >>>>>> how to solve this issue. As it was discussed as there is no existing >>>>>> process in place for transferring permissions when a component >>>>>> maintainer >>>>>> explicitly rejects that. Red Hat is asking to set up a governance that >>>>>> complies with the Jenkins Code of Conduct and allows Open Source >>>>>> friendly >>>>>> collaboration. >>>>>> >>>>>> >>>>>> *Governance revision proposal* >>>>>> >>>>>> The proposed governance has a main objective to ensure permanently >>>>>> that a distribution of the commit rights across the active stakeholders >>>>>> of >>>>>> the project always exists. The definition of "active stakeholder" can be >>>>>> defined more accurately by the project board. But, as an initial >>>>>> proposal, >>>>>> an active stakeholder can be defined as: >>>>>> >>>>>> "An entity contributing to the project in any form within the last 3 >>>>>> months would be by submitting code, committing code, proposing PRs and >>>>>> documentation or participating actively on a regular basis in the >>>>>> community >>>>>> calls". >>>>>> >>>>>> We can add to this group any active user who can submit a minimum >>>>>> amount of documented and reproducible issues. >>>>>> >>>>>> >>>>>> Initial working group leaders are defined using the following >>>>>> requirements: >>>>>> >>>>>> - >>>>>> >>>>>> Initial leadership group consists of 3 or 5 members >>>>>> - >>>>>> >>>>>> Founding parties: Virtus Lab, Red Hat, Jenkins Governance Board >>>>>> - >>>>>> >>>>>> Each party nominates a representative >>>>>> - >>>>>> >>>>>> Domination prevention: there should be no party having more than >>>>>> 50% of working group members. >>>>>> >>>>>> >>>>>> >>>>>> The governance charter needs to define a few engagements and entities: >>>>>> >>>>>> - >>>>>> >>>>>> Scope of rights and responsibilities explicitly held by the >>>>>> committee >>>>>> - >>>>>> >>>>>> Committee structure that meets the requirements above >>>>>> - >>>>>> >>>>>> Election process, including: >>>>>> - >>>>>> >>>>>> special elections in the case someone resigns or is impeached >>>>>> - >>>>>> >>>>>> who is eligible to nominate candidates and how >>>>>> - >>>>>> >>>>>> who is eligible to run as a candidate >>>>>> - >>>>>> >>>>>> Voter registration and requirements >>>>>> - >>>>>> >>>>>> election mechanics such as >>>>>> - >>>>>> >>>>>> committee company representation quotas >>>>>> - >>>>>> >>>>>> Limits on electioneering >>>>>> - >>>>>> >>>>>> Responses to election fraud >>>>>> - >>>>>> >>>>>> How are changes to the charter enacted, and by what process >>>>>> - >>>>>> >>>>>> How are meetings conducted >>>>>> - >>>>>> >>>>>> Recorded or not, and if not, how is the information shared >>>>>> - >>>>>> >>>>>> How is work tracked? Example steering project board >>>>>> - >>>>>> >>>>>> Is there a member note taker, or is there a neutral >>>>>> facilitator role that exists outside of the committee? >>>>>> - >>>>>> >>>>>> Frequency, duration, and required consistency >>>>>> - >>>>>> >>>>>> Committee decision-making process, and specifically those >>>>>> areas of action that require more/less consensus, e.g. >>>>>> modifications the >>>>>> charter >>>>>> >>>>>> *Contribution Process* >>>>>> >>>>>> - >>>>>> >>>>>> The active stakeholders of the project engage in getting members >>>>>> from the contributor/user community to form a working group to drive >>>>>> the >>>>>> direction of the project. >>>>>> - >>>>>> >>>>>> Explains to potential contributors how/if they can add code to >>>>>> the repository/repositories >>>>>> - >>>>>> >>>>>> Documents Workflow and management of pull requests >>>>>> - >>>>>> >>>>>> Identifies who is authorized to commit or revert code >>>>>> - >>>>>> >>>>>> Identifies automation is required for normal operations >>>>>> - >>>>>> >>>>>> Defines how release decisions are made >>>>>> - >>>>>> >>>>>> Who is authorized to release and when. >>>>>> - >>>>>> >>>>>> Frequency limits >>>>>> - >>>>>> >>>>>> Defines the documentation process >>>>>> - >>>>>> >>>>>> Defines what CLA process is required and how it is >>>>>> programmatically enforced before code is merged. >>>>>> >>>>>> *Project Communication Channels* >>>>>> >>>>>> - >>>>>> >>>>>> The working group is added as an official entity of the Jenkins >>>>>> community. E.g. as a sub-project until the jenkins.io terminology >>>>>> is updated: http://jenkins.io/projects >>>>>> - >>>>>> >>>>>> The working group initially includes two roles: leader and member >>>>>> - >>>>>> >>>>>> Jenkins Operator project meetings are considered to be the main >>>>>> communication and decision making channel >>>>>> - >>>>>> >>>>>> The decisions are made by a consensus among contributors >>>>>> - >>>>>> >>>>>> If a consensus cannot be reached, a voting between the working >>>>>> group leadership takes place. The decision is achieved by plain >>>>>> majority. >>>>>> - >>>>>> >>>>>> If a decision cannot be reached on the working group level, >>>>>> the Jenkins Project decision making process is used: >>>>>> https://www.jenkins.io/project/governance/#meeting >>>>>> >>>>>> *Permissions and access* >>>>>> >>>>>> TBD >>>>>> *Issues and questions* >>>>>> >>>>>> The following questions and issues are not answered yet and have to >>>>>> be answered before the establishing the governance chart: >>>>>> >>>>>> - >>>>>> >>>>>> Can a contributor lose its status? Permanently or temporarily ? >>>>>> - >>>>>> >>>>>> How can newcomers be promoted to leaders or contributors roles >>>>>> and with which frequency ? >>>>>> - >>>>>> >>>>>> What happens if an organization gets disengaged from the >>>>>> community ? >>>>>> - >>>>>> >>>>>> What if no quorum nor consensus or majority can be reached for >>>>>> some decisions ? >>>>>> - >>>>>> >>>>>> What are the permissions and accesses given to a maintainer and >>>>>> what are the different roles maintainers can have. Eg: CI Cop, >>>>>> Release Cop >>>>>> etc. >>>>>> >>>>>> >>>> Email correspondence is considered personal data processing. Check out >>>> our Privacy Policy <https://virtuslab.com/gdpr> for details about the >>>> controller of your data and your rights according to GDPR/RODO. >>> >>> >> Email correspondence is considered personal data processing. Check out >> our Privacy Policy <https://virtuslab.com/gdpr> for details about the >> controller of your data and your rights according to GDPR/RODO. > > -- Email correspondence is considered personal data processing. Check out our Privacy Policy <https://virtuslab.com/gdpr> for details about the controller of your data and your rights according to GDPR/RODO. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8f059a32-8644-4cf4-8679-539564b7e947n%40googlegroups.com.
