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

Introduction

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.

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 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

  1. https://rocketmq.apache.org/docs/pull-request/
  2. https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased
  3. https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue
  4. "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

22 Comments

  1. Michael Brohl

    IMO the arguments "More known among developers" and "More known in the enterprise world" lack evidence and are most likely wrong (e.g. Jira is much older and the base tool in the Apache world).

    They should be removed.


    1. Jacques Le Roux

      This was derived from my point by Pierre when restructuring my initial work picked from the ML (w/o asking, Pierre is a fast guy). My point was:

      More devs know GH than Jira and it has been created for them (when using Git). They like it, we need them.

      I must add here that I was mostly thinking about young developers. Those who maybe never used Svn and certainly not CVS, and maybe not Jira.

      I did not says anything about Jira and entreprise, IIRW somehow Mathieu did.

  2. Pierre Smits

    Michael Brohl ,


    If you have evidence to the contrary, provide that evidence.

  3. Jacques Le Roux

    I'm sorry Pierre Smitsbut you over simplified what I initially tried to bring. Here it is below for memepry and quick comparison, and here as a complete page. Also you did not change the references but you removed the links to them. It's maybe simpler but I wonder if, as it's completely rephrased, it's not too simple. Anyway let's people share and work on it to see what we can get out of it.

    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] (to be confirmed, it not possible)

    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.


    Ah I also added in references for [0] 

    [0] Jira offers too much IMO, hence the contributor wiki page. Developers want to code (fun), not to report to managers (boring)...

    Do we want interest from young people or not? (smile)

    1. Michael Brohl

      Jira offers too much IMO, hence the contributor wiki page. Developers want to code (fun), not to report to managers (boring)...


      I think that many of the process steps mentioned there would also apply to the GitHub process. This is a process thing not a tool thing.


      Do we want interest from young people or not?


      Apache OFBiz is a serious business framework plus ERP and long term contributors will most likely join us because they are working with OFBiz. They are able to work with either tool.

      If young people would not contribute because we use Jira + Git and not GitHub only, they are not the right contributors for us IMO. This is a weak argument IMO.

      1. Jacques Le Roux

        I think that many of the process steps mentioned there would also apply to the GitHub process. This is a process thing not a tool thing.

        That's not true. For instance the "Affects and Fix Version/s:" fields are not needed w/ GH, because it's intrinsically about code. Also do we really need the component, sprints and most of the other fields?  Sincerely this page could be quite simpler w/o Jira!

        If young people would not contribute because we use Jira + Git and not GitHub only, they are not the right contributors for us IMO. This is a weak argument IMO.

        See what happened with Mathieu and Samuel. That's a fiasco and we need people like them, don't we?

        1. Michael Brohl

          That's not true. For instance the "Affects and Fix Version/s:" fields are not needed w/ GH, because it's intrinsically about code. Also do we really need the component, sprints and most of the other fields? Sincerely this page could be quite simpler w/o Jira!

          So how would you track in which version an issue was fixed? How do you mark for backport-needed etc.? If a new tool cuts important features to structure the process and support contributors to keep oversight we'll have a problem.

          See what happened with Mathieu and Samuel. That's a fiasco and we need people like them, don't we?

          What happened with them is not caused by the tool we use to manage issues and releases so please don't mix things up here.

          In general, individual fates or personal preferences from a few people should not affect our decision making for using core tools in the project.

          1. Jacques Le Roux

            So how would you track in which version an issue was fixed?
            How do you mark for backport-needed etc.?
            If a new tool cuts important features to structure the process and support contributors to keep oversight we'll have a problem.

            That's good question, better put them in the "Questions" section

            What happened with them is not caused by the tool we use to manage issues and releases so please don't mix things up here.

            That's right, but I can't resist to see a relation when reading their reactions in comments in the thread in "Introduction" section. Notably Samuel's here

            1. Michael Brohl

              That's constantly confusing issue tracking with source code management tasks.

              You could have easily used a feature branch or external repository instead of patches and still discuss/colaborate in Jira. Jira cannot be blamed for exceptional use and therefore the argument is weak.

              1. Jacques Le Roux

                You could have easily used a feature branch or external repository instead of patches and still discuss/colaborate in Jira. Jira cannot be blamed for exceptional use and therefore the argument is weak.

                But why use 2 tools if we (not sure yet) can have issues in GH[1]? It would mean to master more tricks. I'm always thinking about newbies in such cases...

                [1] See my question there INFRA-19950 - Getting issue details... STATUS

          2. Pierre Smits

            Nevertheless, given that currently there are only a few people active in this project the choice of an individual (whether because of fate or preference) provides a great impact on the project. So yeah, it does impacts decision making.

  4. Michael Brohl

    The discussion is useless if we pick "arguments" out of the air. Both arguments are from the perspective/experience of a single person but written as if it is a fact.

    If someone thinks that he has an argument he should be able to give evidence, else it cannot be taken seriously.

    This is my last statement for this point.

    1. Pierre Smits

      You are welcome to debunk any falsehood. Or provide info that counteracts FUD.

  5. Pierre Smits

    Jacques Le Roux ,

    Nevertheless, let's keep the quotes of ml posters where they were made and keep this as concise as possible. Is that the point you're trying to make?
    Or is it about who posted a particular comment on the ML? 

    1. Jacques Le Roux

      We need the information right there under our eyes, to not have to search elsewhere, that's all.
      Notably because I quoted Jacopo's answers which are imporant IMO, and I can't do that easily with links to the dev ML

  6. Jacques Le Roux

    Anyway if we don't agree about pro and cons here, I'll start a vote in a week and that will be it

  7. Michael Brohl

    IMO these arguments are all Git features and apply also when using Jira and Git or Jira and GitHub:

    • Simple merge workflow (1 push button)
    • Intrinsic tools available to version & release (git aspect)
    • Enables developers in an easy way (forking/development collaborations)

  8. Jacques Le Roux

    I will start a vote in a week. The question will be simple: Should we continue to use Jira or keep it only for history reason?

    1. Michael Brohl

      What are your reasons to push this?

      IMO a vote should be prepared with as much information and answers to open questions as possible. We should take our time to gather all aspects to get to a good decision.

      1. Jacques Le Roux

        Is a week not enough? How long should be needed?

        1. Jacques Le Roux

          We came to a lazy consensus for a month on ofbiz Slack channedl

  9. Jacques Le Roux

    (Jacques Le Roux ) I made the below search in Jira. I was looking for "Canonical url". I could not find a result, but Markmail allowed me to find it:

    Jira:

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Refresh


    Markmail:

    https://ofbiz.markmail.org/search/?q=%22Canonical+url%22

    So, though I very like Jira search because it can be right to the point, but it's not always accurate. I can then trust Markmail, which is easier to use than Pony when you are lazy. Because it searches on all MLs for all time and you can then filter by many ways. It's also still very fast.

    (Michael Brohl ) I am able to find 4 results for "canonical url" and even more with using "canonical". You should use the search correctly.

    (Jacques Le Roux ) Can you please share your research or a filter? Mine was <<project = OFBIZ AND status in (Open, "In Progress", Reopened) AND text ~ "canonical url">>

    (Michael Brohl ) you have set a filter to the status which markmail does not. I will now stop this because if you do not take your time to thoroughly lay out you arguments and confusing everything with even more confusing answers, this is useless. Sorry Jacques.

    Part of your markmail results are from the users list which has nothing to do with Jira.

    (Jacques Le Roux ): right, I missed "Patch Available" in status, I should have used <<project = OFBIZ AND status in (Open, "In Progress", Reopened, "Patch Available") AND text ~ "canonical url">> or the simpler <<project = OFBIZ AND text ~ "canonical url">> which retrieve more information, that I tried to avoid. My point was that with "Searching on GitHub" you can make the  same kind of wide searches than with Markmail and we maybe don't need the sophistication of Jira search... KISS...