Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

]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) and Jira.

Here they are for adopting the GH workflow by default:

Pro:


1. More devs know GH than Jira and it has been created for them (when using Git). They like it, we need them.
2. Simple things are easy to directly push with the PR commit button (w/ forced rebase and merge). For large or complicate other paths are possible, like attaching a patch.
3. If we use both solutions we complicate things (mental overload, cf. the contributor wiki page). GH is an opportunity to simplify the processes.
    Too much details[0] (bikeshedding) often does not help, KISS often helps.
4. Jacopo referred to an example of success (since 2016) in the GH wiki page[1]. See how it's simple and easy to apply compared to our contributor wiki page?
5. As Infra team supports the dual-host it's not a venture
6. GH has intrinsically tools to version and release (it's a dev tool not a reporting tool). Jacopo confirmed:

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:

1. People knowing only Jira will need to adapt to GH, easy stuff since it's supposed to be simpler to use in our acceptance.
2. Jira is maybe easier for not dev users to report. Though you can also report in GH[2]. It then offers the same possibilities than Jira (which adapted during its evolution) but we miss the feature (=> ask Infra)
3. Has GH tools alike elaborated search in Jira, e.g. with filters?
4. Will we miss tools like Dashboard, fancy graphs, etc? (I don't think so)
5. Jacopo's answer about [1.5] ([3] seems to be the solution)

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

[0] Jira offers too much IMO, hence the contributor wiki page. Developers want to code (fun), not to report to managers (boring)
[1] https://rocketmq.apache.org/docs/pull-request/
[1.5] https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased
[2] https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue
[3] "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.

  • No labels