Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Answer about the labels feature (7)


...

Info
titleIntroduction

In dev ML at https://lists.apache.org/thread.html/r0e44a477ab39efa2b5d4c8816b67d381864a7bf60728d2915531e926%40%3Cdev.ofbiz.apache.org%3E we started a discussion about Pro and Cons with GH (GitHub)+Git and Jira+Git.

Here they are for adopting the GH workflow by default:

Pro:

...


This page is intended to capture the pros and cons regarding each for the project.



Positive aspects of Github+Git versus JIRA+Git

Github + GitJIRA + Git
  • Tight integration between Github and Git
  • More known among developers
  • Simple merge workflow (1 push button)
  • Intrinsic tools available to version & release (git aspect)
  • Enables developers in an easy way (forking/development collaborations)
  • More known in the enterprise world
  • Success story for many projects of the ASF
  • Lots of defined dashboards/overviews/etc. to provide insights to (potential) adopters and contributors
  • Well defined integration between JIRA and Git
  • Well defined separations of functions between JIRA and Git
  • Project can define own fields/workflow (JIRA)
  • Current setup of JIRA enables non-privileged contributors to participate in workflows (i.e take control to move forward, etc.)

Negative aspects of Github+Git versus JIRA+GIT

Github + GitJIRA + Git
  • Less suited for project management reports (lack of dashboards etc per current setup of the report - Not easy for potential adopters to get a feel of the project)
  • INFRA is required for every workflow change to GITHUB

  • requires additional plugins to do stuff (ref #4)
  • Legacy tools need to be kept (for history sake, etc.)
  • Current setup only favours privileged contributors to participate in workflows.
  • Loosely coupled integration between JIRA+GIT
  • When you use both Jira and GH and cross on wire with a peer you "have to" repeat on the other side to be sure to be understood

Questions and Answers

Things to check and clarify.

QuestionAnswer

1. What will be the process to give permissions to contributors on GitHub after they have filed their ICLA?

see https://ofbiz.apache.org/getting-involved.html

(Jacques Le Roux ): Anybody should be allowed to create issues (see point 3 below).

(Michael Brohl ): yes, but not anyone can provide patches afaik. They must file an ICLA first and then get specific permissions.

(Jacques Le Roux ): No, ICLA are only for committers . This is not to be confused with our policy where ICLAs are required to get write access to our wiki. It was a time where there was a check box in Jira. It has been removed, because when someone submit a patch (either on Jira or by any other way) s/he implicitely renounce to her right on the code giving the right to the ASF.

Then comes SPAM and how to handle it. Here are 2 answers:
https://help.github.com/en/github/building-a-strong-community/reporting-abuse-or-spam
https://github.com/marketplace/actions/mark-as-spam

2. How do we control the permissions for committers and contributors on GitHub?

(Jacques Le Roux ): Same than point 1. It's open, like in GH you can also have SPAM in Jira once you have created an account...

(Michael Brohl ) we have fine grained permissions set in Jira, the answer does not refer to that.

(Jacques Le Roux ): what does it add? What do we need to control?

(Michael Brohl ): Please have a look at the current Users/Roles/Permission settings. There are permissions which only administrators/PMC/committers have (e.g. deleting issues, attachments, editing comments etc.). Please check yourself.

3. What do we offer for contributors who are not able or willing to maintain their own repositories and follow the PR process?

It is relatively easy to clone the official repo, change and create a patch through git diff but it might be a hurdle for people to take all necessary steps for the PR process.

(Jacques Le Roux ) We can ask Infra to offer the "Issues" feature (a top button) in our GH mirrors. You can then report in GH as you would to in Jira. It mostly offers the same possibilities than Jira.

4. When we publish a new release we update Jira versions to reflect the change. This information is useful to group Jira tickets by version. Is there a similar feature in GitHub?

(Jacques Le Roux ) See related Jacopo's answer in my comment below

(Michael Brohl ) this is not answered as long as the process is clear. How is it used in practice?

(Jacques Le Roux ) Beside Jacopo's answer, why do we want that? What is the purpose?

(Michael Brohl ) Checking what Jira's are open for a specific release, collecting release notes (what issues were solved in the release)

5. Has GitHub

Does GH have tools to version and release software?

Answer: Yes, it does: when you create a git tag, GitHub provides download links that allow the users to generate and download an archive of that tag.

Question: Can we modify our release process to leverage GH instead of what we are doing now?

Answer: No, accordingly to the ASF "Release Distribution" policy [*] we would still need to publish and distribute our releases in the current way;

of course we can also adopt other downstream channels.

7. As mentioned Gil, we must keep Jira for (much needed) history and slowly close old, inaccurate or deprecated tickets.
8. Ability to create fork and work with peers on large or complicated subjects

Cons:

...

tools alike elaborated search in Jira, e.g. with filters?

...

Can existing filters/views be migrated from Jira to GitHub?

Examples for filters:

  • all open issues
  • all open issues assigned to me (or another contributor)
  • all open issues per component
  • all open issues with a patch (or then PR)
  • all issues watched by me
  • all issues reported by x, y, z
  • etc., see Jira search capabilities.


(Jacques Le Roux ): I think that this should not stop us in our choice. I have created a comment to move a conversation with Michael in. Else please simply look at  Searching on GitHub documentation.


6. What about dashboards, like https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12310603 ?

(Jacques Le Roux ): Do we really need that as a requirement?  I know we are a peculiar TLP at the ASF. But I would be interested to have some fedback from other TLPs wich have resigned using Jira and are only using GH. Not speaking about all the succesful not ASF projects which are using GH and are more successul than us :/ I'm not even sure that decision makers are aware of such dashboards and fancy Jira stuff or use them in their decisions...

(Michael Brohl ) This is a personal opinion and not an answer to the question.

(Pierre Smits) Whether or not the project is an odd duck compared to other projects under the umbrella of the ASF is hardly a relevant question. 
The project needs to keep in mind that such one-page information (provided by the project, based on filters like mentioned under Q5) is key when decision makers (the potential adopters) review the product. Without the decision makers choosing to implement OFBiz (or continue to use the project), this project becomes irrelevant.

7. Is it possible to tag/label issues to better identify them by different aspects like backport-needed, <component name>, refactoring, documentation etc.?

(Jacques Le Roux ): yes,  Also, as explained on top in this help page, there is a labels feature in the right bar, you can't miss it.



References

We are not using Jira to manage releases. But when we publish a new release
we update Jira versions to reflect the change. This information is useful
to group Jira tickets by version. I am not sure if there is a similar
feature in GH.

References

...

  1. https://rocketmq.apache.org/docs/pull-request/

...

  1. https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased

...

  1. https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue
  2. "gren" is a small helpful robot that will do for you just create a release from a tag and compile the release notes using issues or commits.