As announced in the blog post GitLab licensed its technology to new independent Chinese company, GitLab Inc. has licensed its technology to JiHu. This page is outlines how the GitLab Inc. team provides support to JiHu.
Please refer to our guidelines
Please refer to our guidelines. Invitations sent to GitLab Team members to join the gitlab-jh.slack.com Slack server are legitimate. This server is used for communications between GitLab Inc. and JiHu.
Please refer to our guidelines.
Please refer to our guidelines (link to be added).
Process to be added below.
| DRI | Role |
|---|---|
| Mek Stittri | Engineering DRI |
| Kevin Chu | Product DRI |
| Kyle Wiebers | Engineering Facilitator |
| Lin Jen-Shin | Engineering Facilitator |
JiHu team projects are located at https://jihulab.com/gitlab-cn/. Mirrored projects for gitlab-org tooling and compliance checks are available at https://gitlab.com/gitlab-org/gitlab-jh-mirrors/.
Even though most of the JiHu projects are moved to JiHuLab.com, some projects are still under the gitlab-jh group. To request access please reach out to Kevin or Mek to provision.
Contributions from the JiHu team will follow two methods depending on whether they have JiHu proprietary changes or not.
To identify contributions from JiHu, the ~"JiHu contribution" label is automatically applied to all upstream contributions coming from the JiHu team. To ensure the label is accurately applied, the gitlab-jh team must keep the direct members of gitlab-jh/jh-team updated with current team members.
JiHu enablement efficiency age and review metrics are publicly accessible in this dashboard.
The Engineering Productivity team is the DRI for JiHu Engineering enablement efficiency tooling and metrics.
Contributions that do not involve JiHu proprietary content will be opened against the upstream project.
Bigger product feature contributions should follow GitLab iteration strategies.
Iteration training is available to coach on GitLab's value of iteration. This can be helpful to understand the expectations of GitLab product teams for feature iteration.
Not every features can follow the same strategy, but the first strategy we try should be crafting the minimal viable change, and for creating merge requests, always try to keep merge requests small.
In the above guidelines to keep merge requests small, we mentioned:
Given JiHu upstream contributions cannot easily slice horizontally due to lacking developer permissions, always try to slice vertically first, that is, reduce the scope of the feature. Only consider slicing horizontally if it cannot be smaller, while it's still too large to fit inside a single merge request.
Here are some examples for how we break down a feature in multiple iterations, both horizontally and vertically:
| Feature | Merge requests (not an exhaustive list) | Slicing |
|---|---|---|
| GitLab Insights | Mixture with both. Horizontally for the base and vertically on top of it | |
| Filter search results by state | Vertically that each merge request shipped a standalone feature |
Please refer to JiHu Contribution Review Process for details.
Contributions in projects that have proprietary and upstream contributions will use the following guidelines to have a streamlined review.
gitlab-jh Engineering team will open two MRs:
jh/ changes against the default branch in gitlab-org/gitlab.gitlab-org/gitlab team members. Reviewers should follow the guidelines for reviewing JiHu (JH) Edition related merge requests.main-jh https://jihulab.com/gitlab-cn/gitlab branch with a code sync.gitlab-jh Engineering team will remove all non-jh/ changes from the JH MR.gitlab-jh Engineering team will review and merge the JH MR against the gitlab-jh/gitlab default branch.
There are times where main-jh branch is broken and requires upstream merge requests to resolve. When this happens the following process will be enacted for a timely resolution within 2 business days of JiHu upstream MR creation.
~"JiHu Broken Pipeline" label to the merge request and solicit a review from the appropriate domain (backend, frontend).Please refer to our guidelines.
The Application Security team performs a certification of each release that includes JiHu contributions. Please see this documentation for more information about this process.
Certification issues containing a report can be found in the issue tracker of the jh-upstream-report repository.
JiHu is responsible for building and releasing the JiHu Edition each month including all patch and security releases. For security releases, GitLab Inc will continue to follow our existing security release process to publish our security releases. To enable JiHu to build their security releases in a timely manner, GitLab Inc will notify JiHu when a security release is in progress along so that their teams can be on stand by. GitLab Inc will not notify JiHu of the contents of the security release or of the vulnerability.
To notify JiHu of an upcoming security release, please simply post a comment in: https://gitlab.com/gitlab-jh/gitlab-jh-enablement/-/issues/112
JiHu benefits from GitLab expertise, particularly around operating GitLab as a SaaS product. GitLab may charge JiHu for consulting on items that require engagement beyond a quick response on Slack. This way, GitLab can safeguard against unplanned work while JiHu builds its domain expertise. This is also agreed upon in GitLab's Technical Services Agreement with JiHu - Internal.
The Product DRI has the following responsibilities:
JiHu contributions are similar to community contributions. The difference is they are higher in volume and frequency. As JiHu ramps up in the GitLab codebase, they are also eager to build understanding and learn where and how they might contribute to GitLab. Product Managers can share their public directions and work with the JiHu team to help JiHu become self-sufficient and efficient.
At times, product managers are asked to provide feedback or directly respond to specific proposals from JiHu. GitLab PMs should help facilitate collaboration between GitLab engineers and the JiHu team. This means if there's misalignment on product direction, call that out early so JiHu doesn't spend time working on things GitLab doesn't intend to merge.
If product managers need help connecting with JiHu counterparts, ping the Product DRI in #jihu-product.
We differentiate proprietary features for JiHu distributions by including them in the /jh directory. However, the majority of contributions from JiHu team members should be outside of the /jh directory signaling the expectation that most contributions are to GitLab Core and only certain specific features are exclusive to the /jh offering.
Process to be added below.