JiHu Support

1. You are here:
2. CEO
3. Chief of Staff Team to the CEO
4. JiHu Support

Maintained by:

On this page

• Overview
• Brand
• Communications
• Sales
• Professional Services
• Customer Support
• Engineering
  • R&D Roles
  • Projects
  • Merge Request Process
    • Guidelines for upstream contributions
      • Guidelines for iterative contributions
    • Guidelines for upstream contributions review process
    • Guidelines for proprietary and upstream contributions
    • MR escalation
    • Release Certification Process
  • Security Release Process
• Product
  • Differentiating Proprietary JiHu Features
• Design
• Links

Overview

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.

Brand

Please refer to our guidelines

Communications

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.

Sales

Please refer to our guidelines.

Professional Services

Please refer to our guidelines (link to be added).

Customer Support

Process to be added below.

Engineering

R&D Roles

Projects

JiHu team projects are under the gitlab-jh group. To request access please reach out to Kenny or Mek to provision.

Merge Request Process

Contributions from the JiHu team will follow two methods depending on whether they have JiHu proprietary changes or not.

• Upstream method - start with a merge request in the GitLab Inc. repository.
• Proprietary and upstream method - start with a merge request with all changes against the GitLab JiHu project and a merge request with all non-proprietary changes against the upstream project.

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.

Guidelines for upstream contributions

Contributions that do not involve JiHu proprietary content will be opened against the upstream project.

Guidelines for iterative contributions

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:

• Horizontal slicing
• Vertical slicing

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:

Guidelines for upstream contributions review process

Please refer to JiHu Contribution Review Process for details.

Guidelines for proprietary and upstream contributions

Contributions in projects that have proprietary and upstream contributions will use the following guidelines to have a streamlined review.

1. The gitlab-jh Engineering team will open two MRs:
   1. JH MR with all changes against gitlab-jh/gitlab
   2. Inc MR with all non-jh/ changes against the default branch in gitlab-org/gitlab
2. The GitLab Inc MR will be reviewed by the gitlab-org/gitlab team members
3. After merging, the updates will be mirrored to gitlab-jh/gitlab via pull mirroring and synced to the main-jh gitlab-jh/gitlab branch with a code sync.
4. The gitlab-jh Engineering team will remove all non-jh/ changes from the JH MR.
5. The gitlab-jh Engineering team will review and merge the JH MR against the gitlab-jh/gitlab default branch

MR escalation

Please refer to our guidelines.

Release Certification Process

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.

Security Release Process

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

Product

Differentiating Proprietary JiHu Features

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.

Design

Process to be added below.

Links

• GitLab licensed its technology to new independent Chinese company
• GitLab licensing technology to independent Chinese company FAQ
• China Service Working Group