Git history problem

[Jacques Le Roux]

Le 12/03/2020 à 10:30, Jacques Le Roux a écrit :

>
> 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). Please Jacopo confirm since you are the release
>     manager[1.5]
>  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

[Jacques Le Roux]

Le 12/03/2020 à 11:46, Jacques Le Roux a écrit :

> Le 12/03/2020 à 10:30, Jacques Le Roux a écrit :
>>
>> 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). Please Jacopo confirm since you are the release
>>     manager[1.5]
>>  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
>

To stop at this moment, I have created https://cwiki.apache.org/confluence/display/OFBIZ/Adopting+Github+Workflow and added Jacopo's answer as RM

Jacques

[Jacopo Cappellato-3]

On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
[hidden email]> wrote:

> As I see no Jira references in "Release Distribution Policy" I guess it's
> not an issue to no longer use Jira to manage versions and releases numbers,
> ie using
>
> [1.5]
> https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased


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.

Jacopo

[Jacques Le Roux]

Le 12/03/2020 à 12:17, Jacopo Cappellato a écrit :

> On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
> [hidden email]> wrote:
>
>> As I see no Jira references in "Release Distribution Policy" I guess it's
>> not an issue to no longer use Jira to manage versions and releases numbers,
>> ie using
>>
>> [1.5]
>> https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased
>
> 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.
>
> Jacopo

Thanks Jacopo,

I have updated the wiki page with your answer as, for now, a cons.

Jacques

[Jacques Le Roux]

Le 12/03/2020 à 13:32, Jacques Le Roux a écrit :

> Le 12/03/2020 à 12:17, Jacopo Cappellato a écrit :
>> On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>> As I see no Jira references in "Release Distribution Policy" I guess it's
>>> not an issue to no longer use Jira to manage versions and releases numbers,
>>> ie using
>>>
>>> [1.5]
>>> https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased
>>
>> 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.
>>
>> Jacopo
>
> Thanks Jacopo,
>
> I have updated the wiki page with your answer as, for now, a cons.
>
>

https://github.com/github-tools/github-release-notes seems to be the solution (to be confirmed), updated the wiki page for the same

Jacques

[Jacques Le Roux]

You are all invited to review, discuss in comments and possibly add pro and cons on this page

https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT

It would else become unreadable here...

Hopefully we will get to a consensus...

Jacques

Le 12/03/2020 à 13:40, Jacques Le Roux a écrit :

> Le 12/03/2020 à 13:32, Jacques Le Roux a écrit :
>> Le 12/03/2020 à 12:17, Jacopo Cappellato a écrit :
>>> On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> As I see no Jira references in "Release Distribution Policy" I guess it's
>>>> not an issue to no longer use Jira to manage versions and releases numbers,
>>>> ie using
>>>>
>>>> [1.5]
>>>> https://issues.apache.org/jira/plugins/servlet/project-config/OFBIZ/administer-versions?status=released-unreleased
>>>
>>> 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.
>>>
>>> Jacopo
>>
>> Thanks Jacopo,
>>
>> I have updated the wiki page with your answer as, for now, a cons.
>>
>>
> https://github.com/github-tools/github-release-notes seems to be the solution (to be confirmed), updated the wiki page for the same
>
> Jacques
>

[Michael Brohl-3]

Hi all,

I'd like to encourage everyone to visit the wiki page
https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT,
read carefully, check, dicuss and ask questions to get to a good
information base for an important decision to make.

Thanks everyone,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 12.03.20 um 17:28 schrieb Jacques Le Roux:

> You are all invited to review, discuss in comments and possibly add
> pro and cons on this page
>
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT 
>
>
> It would else become unreadable here...
>
> Hopefully we will get to a consensus...
>
> Jacques
>
>

[Jacopo Cappellato-3]

On Wed, Mar 11, 2020 at 10:20 PM Pierre Smits <[hidden email]>
wrote:

> [...]
> As for PMC Members claiming that the Github services (repositories etc.)
> are not *official* ASF tools, I suggest these persons stop this kind of FUD
> (and maybe check back with the ASF).
>

Pierre, rather than accusing others of FUD, it would be more constructive
to the conversation to research and provide references that support a
decision.
I did a research and I have found this useful ticket:

https://issues.apache.org/jira/browse/LEGAL-249

After carefully reviewing the various comments/opinions posted there, I
think we can conclude that from the legal point-of-view, as an ASF project,
we can adopt a ticketing system that is not maintained by the ASF (such as
GH Issues) provided that we setup all notifications to be archived to a
mailing list managed by the ASF (such as notifications@ofbiz...); in this
way, the ASF will always have an history log of all the information shared
in GH Issues even in the unlikely case that GH will disappear, change
license, shut down the service etc...
The other, valid in my opinion, concern expressed in that ticket about
adopting GH Issues and GH PR as the only mechanism to accept reports and
contributions is that people will have to create an account and accept the
Terms of Services of a 3rd party company (GitHub). And the 3rd party may
also apply restrictions to the users (see for example
https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/ ) that
may be different from the ones that are accepted by the ASF.
In my opinion, these are concerns that need to be addressed and discussed
with patience (not accusing others on disagreement) and calm: however, for
this specific case, we could, in my opinion, consider GH Issues and GH PR
as our primary mechanisms but also accept contributions via our mailing
lists (for example) for the ones that can not or don't want to register an
account with a 3rd party company.

Jacopo

[Jacques Le Roux]

Le 13/03/2020 à 11:29, Jacopo Cappellato a écrit :

> On Wed, Mar 11, 2020 at 10:20 PM Pierre Smits <[hidden email]>
> wrote:
>
>> [...]
>> As for PMC Members claiming that the Github services (repositories etc.)
>> are not *official* ASF tools, I suggest these persons stop this kind of FUD
>> (and maybe check back with the ASF).
>>
> Pierre, rather than accusing others of FUD, it would be more constructive
> to the conversation to research and provide references that support a
> decision.
> I did a research and I have found this useful ticket:
>
> https://issues.apache.org/jira/browse/LEGAL-249
>
> After carefully reviewing the various comments/opinions posted there, I
> think we can conclude that from the legal point-of-view, as an ASF project,
> we can adopt a ticketing system that is not maintained by the ASF (such as
> GH Issues) provided that we setup all notifications to be archived to a
> mailing list managed by the ASF (such as notifications@ofbiz...); in this
> way, the ASF will always have an history log of all the information shared
> in GH Issues even in the unlikely case that GH will disappear, change
> license, shut down the service etc...
> The other, valid in my opinion, concern expressed in that ticket about
> adopting GH Issues and GH PR as the only mechanism to accept reports and
> contributions is that people will have to create an account and accept the
> Terms of Services of a 3rd party company (GitHub). And the 3rd party may
> also apply restrictions to the users (see for example
> https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/ ) that
> may be different from the ones that are accepted by the ASF.
> In my opinion, these are concerns that need to be addressed and discussed
> with patience (not accusing others on disagreement) and calm: however, for
> this specific case, we could, in my opinion, consider GH Issues and GH PR
> as our primary mechanisms but also accept contributions via our mailing
> lists (for example) for the ones that can not or don't want to register an
> account with a 3rd party company.
>
> Jacopo

Thanks Jacopo,

That sounds like a good plan to me!

I have asked at https://issues.apache.org/jira/browse/INFRA-19950 if we could have GH issues.

Jacques

[Jacopo Cappellato-3]

On Fri, Mar 13, 2020 at 11:33 AM Jacques Le Roux <
[hidden email]> wrote:

> [...]
> I have asked at https://issues.apache.org/jira/browse/INFRA-19950 if we
> could have GH issues.
>

Yes, I saw your comment but I am wondering if the way you have phrased your
question [*] will make sense to Infra.

[*] "can using issues be implement in the the context of the dual-host?"

[Jacques Le Roux]

Le 13/03/2020 à 11:40, Jacopo Cappellato a écrit :

> On Fri, Mar 13, 2020 at 11:33 AM Jacques Le Roux <
> [hidden email]> wrote:
>
>> [...]
>> I have asked at https://issues.apache.org/jira/browse/INFRA-19950 if we
>> could have GH issues.
>>
> Yes, I saw your comment but I am wondering if the way you have phrased your
> question [*] will make sense to Infra.
>
> [*] "can using issues be implement in the the context of the dual-host?"

I thought that with the link I put there:

https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue

It will clear enough for them. What would you propose?

Jacques

[Jacques Le Roux]

Hi All,

This is done, you may check with an open GH PR

We will now ask Infra to add GH Issues[1]. It needs again a PMC agreement.

[1] https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue

Jacques

Le 10/03/2020 à 11:22, Jacques Le Roux a écrit :

> The infra team requires a PMC decision for this change, see https://issues.apache.org/jira/browse/INFRA-19950
>
> Jacques
>
> Le 10/03/2020 à 10:57, Jacques Le Roux a écrit :
>> Le 09/03/2020 à 17:58, Mathieu Lirzin a écrit :
>>> Hello,
>>>
>>> The history of OFBiz trunk with the adoption of the Pull Request based
>>> contribution process is getting less and less readable. Here is a
>>> snippet of `git log --oneline --graph` demonstrating that:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> a3bcdc4cc3 * | Improved: Removes getSubContentWithPermCheck and getSubSub
>>>             |/
>>> 8ec3886d7f * Fixed: Code refactoring to support groovy syntax (OFBIZ-1023
>>> 604a3bfa02 * Improved: Convert PartyInvitationService.xml from minilang t
>>> 5b8c89906c *   Merge pull request #36 from danwatford/ofbiz-11428-checkst
>>>             |\
>>> e665f9dc68 | * Improved: Set checkstyle to use LF line endings
>>> e9ec4181ec * |   Merge pull request #17 from PierreSmits/Label-Cleanup
>>>             |\ \
>>> 974b85f4ec | * | Improved: Cleanup HumanRes labels
>>> c71a7ae06d | * | Improved: UI labels
>>> c121ad6b9d * | |   Merge pull request #15 from PierreSmits/OFBIZ-10551
>>>             |\ \ \
>>>             | |_|/
>>>             |/| |
>>> 58b0da26f5 | * | Improved: Remove unused labels from ProductUiLabels.xml
>>> 66aa76d7f7 * | |   Merge pull request #35 from danwatford/ofbiz-11418-doc
>>>             |\ \ \
>>> 0ece441228 | * | | Fixed: Fixed line lengths in ModelFormFieldTest to adh
>>> cfad407c48 * | | |   Merge pull request #34 from danwatford/ofbiz-11418-d
>>>             |\ \ \ \
>>>             | |/ / /
>>> 5640de4eba | * | | Documented: Documented use of field attribute paramete
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I personnally think this is a huge issue because it makes analysing
>>> history and chasing previously introduced bugs unecessary hard.
>>>
>>> I would strongly recommend configuring OFBiz Github to require a linear
>>> commit history when merging PR [1].
>>>
>>> Thanks.
>>>
>>> [1] https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history
>>>
>>> PS: Even if I try to be polite, I am profoundly angry regarding the way
>>> the PR contribution process has been adopted without any formal
>>> community approval or listening to people having stated important
>>> requirements that needed to be addressed before moving towards that new
>>> contribution process.
>>
>> Hi Mathieu,
>>
>> If my opinion is worth telling, I was initially reluctant to use the PR process instead of the patch process. Because in general I prefer to
>> control things, it's even sometimes a problem for me in real life. I must say it was more laziness which inclined me to PR.
>>
>> I noticed that sometimes strange things happen when you use a PR. Consider this recent email for instance:
>> https://markmail.org/message/amq5fj2dfma7pcbb.
>>
>> There is only the files names, nothing about the changes. You have to get there to have the information
>> https://github.com/apache/ofbiz-plugins/commit/4afe603/ not very convenient :/
>>
>> Moreover if you look at the commit comment in related Jira (OFBIZ-10948), it says:
>>
>>    <<Merge pull request #7 from priyasharma1/OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>
>>
>>    Improved: Convert DimensionServices.xml minilang to groovy (OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>)>>
>>
>> When I supposed it would be only the title and comment at https://github.com/apache/ofbiz-plugins/pull/7. Why is "Merge pull request #7 from
>> priyasharma1/OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>" added, mystery!
>>
>> For a reason I ignore (must be a reason, but I'll not try to understand) we did not get that.
>>
>> Sorry for the digression, now about your point, I agree. I find strange that the default value of the GH (GitHub) merge button is not merge and
>> rebase. I guess it's history and legacy... Using the squash value is also a good option when the merge passes and there are several commits, it
>> simplifies things when reading emails.
>>
>> Like Michael I had a look about the settings. The settings button is available on my fork but not on the official mirror Github repo.
>>
>> This said you certainly saw this thread started by Pierre Smits: https://markmail.org/message/so7ljoqxzuq7jplz and the related wiki document
>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github
>>
>> The discussion ended with Michael's disagreement, as somehow yours, but nothing happened. So I think we should move ahead with your proposition and
>> note the change in the wiki page. I have created https://issues.apache.org/jira/browse/INFRA-19950 for that. If somebody disagrees please speak
>> now, even if it will always possible to revert the change.
>>
>> We have also to maintain the related stuff which are also still WIP:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Migration+from+Subversion+%28SVN%29+to+Git
>> https://issues.apache.org/jira/browse/OFBIZ-11268
>>
>> Nothing happens magically, but it seems we are near the end about the migration from Subversion to Git process.
>>
>> BTW, a question for you: do you think not having a linear commit history would have an impact on Bisect. I don't think so, just asking in case you
>> have an experience with that.
>>
>> Please don't be angry, it's not good for health. Just listen few minutes to https://www.youtube.com/watch?v=d-diB65scQU it generally helps ;)
>>
>> Thanks for your proposition!
>>
>> Jacques
>>

[Jacques Le Roux]

Some notes before I forget:

 1. Except if Infra (or I) missed something, GH "Rebase and Merge" does not always create a linear commit history. See the log of ofbiz-site after the
    "Rebase and Merge" I did for PR1. If commits happen beetwen it's does not deliver a linear commit history.
 2. With our request to Infra at INFRA-19950, which was normally based on Matthieu's [1] link below, the "Squash and Merge" option is still available.
    AFAIK it does not rebase before squashing and merging. I though find it convenient in some cases. But we can also ask contributors to manually
    squash their commits before committing the lot again (always in a new PR?) and ask Infra to also remove this option. Opinions?

Jacques

Le 13/03/2020 à 14:48, Jacques Le Roux a écrit :

> Hi All,
>
> This is done, you may check with an open GH PR
>
> We will now ask Infra to add GH Issues[1]. It needs again a PMC agreement.
>
> [1] https://help.github.com/en/github/managing-your-work-on-github/creating-an-issue
>
> Jacques
>
> Le 10/03/2020 à 11:22, Jacques Le Roux a écrit :
>> The infra team requires a PMC decision for this change, see https://issues.apache.org/jira/browse/INFRA-19950
>>
>> Jacques
>>
>> Le 10/03/2020 à 10:57, Jacques Le Roux a écrit :
>>> Le 09/03/2020 à 17:58, Mathieu Lirzin a écrit :
>>>> Hello,
>>>>
>>>> The history of OFBiz trunk with the adoption of the Pull Request based
>>>> contribution process is getting less and less readable. Here is a
>>>> snippet of `git log --oneline --graph` demonstrating that:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> a3bcdc4cc3 * | Improved: Removes getSubContentWithPermCheck and getSubSub
>>>>             |/
>>>> 8ec3886d7f * Fixed: Code refactoring to support groovy syntax (OFBIZ-1023
>>>> 604a3bfa02 * Improved: Convert PartyInvitationService.xml from minilang t
>>>> 5b8c89906c *   Merge pull request #36 from danwatford/ofbiz-11428-checkst
>>>>             |\
>>>> e665f9dc68 | * Improved: Set checkstyle to use LF line endings
>>>> e9ec4181ec * |   Merge pull request #17 from PierreSmits/Label-Cleanup
>>>>             |\ \
>>>> 974b85f4ec | * | Improved: Cleanup HumanRes labels
>>>> c71a7ae06d | * | Improved: UI labels
>>>> c121ad6b9d * | |   Merge pull request #15 from PierreSmits/OFBIZ-10551
>>>>             |\ \ \
>>>>             | |_|/
>>>>             |/| |
>>>> 58b0da26f5 | * | Improved: Remove unused labels from ProductUiLabels.xml
>>>> 66aa76d7f7 * | |   Merge pull request #35 from danwatford/ofbiz-11418-doc
>>>>             |\ \ \
>>>> 0ece441228 | * | | Fixed: Fixed line lengths in ModelFormFieldTest to adh
>>>> cfad407c48 * | | |   Merge pull request #34 from danwatford/ofbiz-11418-d
>>>>             |\ \ \ \
>>>>             | |/ / /
>>>> 5640de4eba | * | | Documented: Documented use of field attribute paramete
>>>> --8<---------------cut here---------------end--------------->8---
>>>>
>>>> I personnally think this is a huge issue because it makes analysing
>>>> history and chasing previously introduced bugs unecessary hard.
>>>>
>>>> I would strongly recommend configuring OFBiz Github to require a linear
>>>> commit history when merging PR [1].
>>>>
>>>> Thanks.
>>>>
>>>> [1] https://help.github.com/en/github/administering-a-repository/requiring-a-linear-commit-history
>>>>
>>>> PS: Even if I try to be polite, I am profoundly angry regarding the way
>>>> the PR contribution process has been adopted without any formal
>>>> community approval or listening to people having stated important
>>>> requirements that needed to be addressed before moving towards that new
>>>> contribution process.
>>>
>>> Hi Mathieu,
>>>
>>> If my opinion is worth telling, I was initially reluctant to use the PR process instead of the patch process. Because in general I prefer to
>>> control things, it's even sometimes a problem for me in real life. I must say it was more laziness which inclined me to PR.
>>>
>>> I noticed that sometimes strange things happen when you use a PR. Consider this recent email for instance:
>>> https://markmail.org/message/amq5fj2dfma7pcbb.
>>>
>>> There is only the files names, nothing about the changes. You have to get there to have the information
>>> https://github.com/apache/ofbiz-plugins/commit/4afe603/ not very convenient :/
>>>
>>> Moreover if you look at the commit comment in related Jira (OFBIZ-10948), it says:
>>>
>>>    <<Merge pull request #7 from priyasharma1/OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>
>>>
>>>    Improved: Convert DimensionServices.xml minilang to groovy (OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>)>>
>>>
>>> When I supposed it would be only the title and comment at https://github.com/apache/ofbiz-plugins/pull/7. Why is "Merge pull request #7 from
>>> priyasharma1/OFBIZ-10948 <https://issues.apache.org/jira/browse/OFBIZ-10948>" added, mystery!
>>>
>>> For a reason I ignore (must be a reason, but I'll not try to understand) we did not get that.
>>>
>>> Sorry for the digression, now about your point, I agree. I find strange that the default value of the GH (GitHub) merge button is not merge and
>>> rebase. I guess it's history and legacy... Using the squash value is also a good option when the merge passes and there are several commits, it
>>> simplifies things when reading emails.
>>>
>>> Like Michael I had a look about the settings. The settings button is available on my fork but not on the official mirror Github repo.
>>>
>>> This said you certainly saw this thread started by Pierre Smits: https://markmail.org/message/so7ljoqxzuq7jplz and the related wiki document
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github
>>>
>>> The discussion ended with Michael's disagreement, as somehow yours, but nothing happened. So I think we should move ahead with your proposition
>>> and note the change in the wiki page. I have created https://issues.apache.org/jira/browse/INFRA-19950 for that. If somebody disagrees please
>>> speak now, even if it will always possible to revert the change.
>>>
>>> We have also to maintain the related stuff which are also still WIP:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Migration+from+Subversion+%28SVN%29+to+Git
>>> https://issues.apache.org/jira/browse/OFBIZ-11268
>>>
>>> Nothing happens magically, but it seems we are near the end about the migration from Subversion to Git process.
>>>
>>> BTW, a question for you: do you think not having a linear commit history would have an impact on Bisect. I don't think so, just asking in case you
>>> have an experience with that.
>>>
>>> Please don't be angry, it's not good for health. Just listen few minutes to https://www.youtube.com/watch?v=d-diB65scQU it generally helps ;)
>>>
>>> Thanks for your proposition!
>>>
>>> Jacques
>>>

[Benjamin Jugl]

I have been following this discussion for a while.  However, I still
wonder if this discussion is about which of the two options is the
better one. In my opinion, the discussion should rather be about whether
the potential benefits of a new process justify the effort to change the
old one. It seems to me at least that this aspect is being neglected a bit.

Am 13.03.20 um 10:24 schrieb Michael Brohl:

> Hi all,
>
> I'd like to encourage everyone to visit the wiki page
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT,
> read carefully, check, dicuss and ask questions to get to a good
> information base for an important decision to make.
>
> Thanks everyone,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
>> You are all invited to review, discuss in comments and possibly add
>> pro and cons on this page
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT 
>>
>>
>> It would else become unreadable here...
>>
>> Hopefully we will get to a consensus...
>>
>> Jacques
>>
>>
>

--
Benjamin Jugl
Consultant

Fon       [phone]
Fax       [phone]
Mobil     [phone]
Xing      xing.com/profile/Benjamin_Jugl3/
LinkedIn  linkedin.com/in/benjamin-jugl-693664ab/

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: [phone], Fax: [phone],www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

[Jacques Le Roux]

Hi Benjamin, All,

That's a good point indeed. And we 1st need to clearly define what are the old and the new processes. Here is a try:

The "old process" (not so old, changed with Git replacing Svn, hence the discussion) is

  * use Jira to create issues with possibly attached patches and discussion there. With all what Jira affords...
  * You can also link a GH PR from Jira. And have a patch, then it begins to be confusing (which one is the later, etc.)
  * You can create a PR in GH and discuss it there, nothing else. There should not be crossed discussions in Jira and GH
  * I certainly miss other points, that's the gist

The new process is not clearly defined, here are 2 possible versions:

  * Jira is only used for history reason, no more issue creations allowed
  * GH is used not only for PR but also to create issues (needs a PMC agreement). It's then a replacement of Jira and we need to be quite careful
    doing so.

  * Jira continues to be used as is. With IMO some restrictions, like: if you have a patch you don't create a PR, it's one or the other way.
  * GH is used not only for PR but also to create issues (needs a PMC agreement) an discuss them there. PR or attached patch can be used to contribute.

As you see, for me the question is not  "GitHub or Jira"  but "GitHub or Jira or both" I have changed the title of the related wiki page accordingly:

https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both

HTH

Jacques

Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :

> I have been following this discussion for a while.  However, I still wonder if this discussion is about which of the two options is the better one.
> In my opinion, the discussion should rather be about whether the potential benefits of a new process justify the effort to change the old one. It
> seems to me at least that this aspect is being neglected a bit.
>
> Am 13.03.20 um 10:24 schrieb Michael Brohl:
>> Hi all,
>>
>> I'd like to encourage everyone to visit the wiki page https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT, read
>> carefully, check, dicuss and ask questions to get to a good information base for an important decision to make.
>>
>> Thanks everyone,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
>>> You are all invited to review, discuss in comments and possibly add pro and cons on this page
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
>>>
>>> It would else become unreadable here...
>>>
>>> Hopefully we will get to a consensus...
>>>
>>> Jacques
>>>
>>>
>>

[Pierre Smits-3]

You are correct. Instead of just looking at what the technical differences
(and similarities) between between the two approaches are (and opting for
one or the other based on personal preferences), we should be looking at:

   1. will the change from one to another bring more to our potential
   adopters (their decision makers) and contributors. But also to
   developers/implementers not aspiring to be a contributor;
   2. how much effort will this change take, and when will the change-over
   be normalised into a smooth sailing cruise.

These two factors should determine whether the project goes forward with
yet another big refactoring. And this time it is not code, but procedural
changes accompanied by documentation changes. If not done properly, there
will be confusion. And confusion (too long and/or too much) leads to people
not choosing to adopt/contribute or even leaving the project.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer

[James Yong-2]

Hi all,

I personally feel we should allow both JIRA and Github for issue management, and let contributers use their own judgement on which one to use. JIRA contains wealth of information and many open issues for review, while Github allows easier review of source codes.
So do either JIRA + Patch, or GH + PR.

Regards,
James

On 2020/03/14 10:43:31, Jacques Le Roux <[hidden email]> wrote:

> Hi Benjamin, All,
>
> That's a good point indeed. And we 1st need to clearly define what are the old and the new processes. Here is a try:
>
> The "old process" (not so old, changed with Git replacing Svn, hence the discussion) is
>
>   * use Jira to create issues with possibly attached patches and discussion there. With all what Jira affords...
>   * You can also link a GH PR from Jira. And have a patch, then it begins to be confusing (which one is the later, etc.)
>   * You can create a PR in GH and discuss it there, nothing else. There should not be crossed discussions in Jira and GH
>   * I certainly miss other points, that's the gist
>
> The new process is not clearly defined, here are 2 possible versions:
>
>   * Jira is only used for history reason, no more issue creations allowed
>   * GH is used not only for PR but also to create issues (needs a PMC agreement). It's then a replacement of Jira and we need to be quite careful
>     doing so.
>
>   * Jira continues to be used as is. With IMO some restrictions, like: if you have a patch you don't create a PR, it's one or the other way.
>   * GH is used not only for PR but also to create issues (needs a PMC agreement) an discuss them there. PR or attached patch can be used to contribute.
>
> As you see, for me the question is not  "GitHub or Jira"  but "GitHub or Jira or both" I have changed the title of the related wiki page accordingly:
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
>
> HTH
>
> Jacques
>
> Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :
> > I have been following this discussion for a while.  However, I still wonder if this discussion is about which of the two options is the better one.
> > In my opinion, the discussion should rather be about whether the potential benefits of a new process justify the effort to change the old one. It
> > seems to me at least that this aspect is being neglected a bit.
> >
> > Am 13.03.20 um 10:24 schrieb Michael Brohl:
> >> Hi all,
> >>
> >> I'd like to encourage everyone to visit the wiki page https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT, read
> >> carefully, check, dicuss and ask questions to get to a good information base for an important decision to make.
> >>
> >> Thanks everyone,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
> >>> You are all invited to review, discuss in comments and possibly add pro and cons on this page
> >>>
> >>> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
> >>>
> >>> It would else become unreadable here...
> >>>
> >>> Hopefully we will get to a consensus...
> >>>
> >>> Jacques
> >>>
> >>>
> >>
>

[Michael Brohl-3]

+1 James!

Thanks,

Michael


Am 18.03.20 um 17:13 schrieb James Yong:

> Hi all,
>
> I personally feel we should allow both JIRA and Github for issue management, and let contributers use their own judgement on which one to use. JIRA contains wealth of information and many open issues for review, while Github allows easier review of source codes.
> So do either JIRA + Patch, or GH + PR.
>
> Regards,
> James
>
> On 2020/03/14 10:43:31, Jacques Le Roux <[hidden email]> wrote:
>> Hi Benjamin, All,
>>
>> That's a good point indeed. And we 1st need to clearly define what are the old and the new processes. Here is a try:
>>
>> The "old process" (not so old, changed with Git replacing Svn, hence the discussion) is
>>
>>    * use Jira to create issues with possibly attached patches and discussion there. With all what Jira affords...
>>    * You can also link a GH PR from Jira. And have a patch, then it begins to be confusing (which one is the later, etc.)
>>    * You can create a PR in GH and discuss it there, nothing else. There should not be crossed discussions in Jira and GH
>>    * I certainly miss other points, that's the gist
>>
>> The new process is not clearly defined, here are 2 possible versions:
>>
>>    * Jira is only used for history reason, no more issue creations allowed
>>    * GH is used not only for PR but also to create issues (needs a PMC agreement). It's then a replacement of Jira and we need to be quite careful
>>      doing so.
>>
>>    * Jira continues to be used as is. With IMO some restrictions, like: if you have a patch you don't create a PR, it's one or the other way.
>>    * GH is used not only for PR but also to create issues (needs a PMC agreement) an discuss them there. PR or attached patch can be used to contribute.
>>
>> As you see, for me the question is not  "GitHub or Jira"  but "GitHub or Jira or both" I have changed the title of the related wiki page accordingly:
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
>>
>> HTH
>>
>> Jacques
>>
>> Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :
>>> I have been following this discussion for a while.  However, I still wonder if this discussion is about which of the two options is the better one.
>>> In my opinion, the discussion should rather be about whether the potential benefits of a new process justify the effort to change the old one. It
>>> seems to me at least that this aspect is being neglected a bit.
>>>
>>> Am 13.03.20 um 10:24 schrieb Michael Brohl:
>>>> Hi all,
>>>>
>>>> I'd like to encourage everyone to visit the wiki page https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT, read
>>>> carefully, check, dicuss and ask questions to get to a good information base for an important decision to make.
>>>>
>>>> Thanks everyone,
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
>>>>> You are all invited to review, discuss in comments and possibly add pro and cons on this page
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
>>>>>
>>>>> It would else become unreadable here...
>>>>>
>>>>> Hopefully we will get to a consensus...
>>>>>
>>>>> Jacques
>>>>>
>>>>>

[Jacques Le Roux]

Hi All,

I believe we are now pragmatically using JIRA + Patch, or GH + PR.

Remains the question about allowing the creation of issues in GH. It seems to me that nobody actually asked for that since Jira is enough for our needs.

So I should not need more than what we use currently and can put https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both 
in Attic now, right?

Jacques

Le 18/03/2020 à 18:22, Michael Brohl a écrit :

> +1 James!
>
> Thanks,
>
> Michael
>
>
> Am 18.03.20 um 17:13 schrieb James Yong:
>> Hi all,
>>
>> I personally feel we should allow both JIRA and Github for issue management, and let contributers use their own judgement on which one to use. JIRA
>> contains wealth of information and many open issues for review, while Github allows easier review of source codes.
>> So do either JIRA + Patch, or GH + PR.
>>
>> Regards,
>> James
>>
>> On 2020/03/14 10:43:31, Jacques Le Roux <[hidden email]> wrote:
>>> Hi Benjamin, All,
>>>
>>> That's a good point indeed. And we 1st need to clearly define what are the old and the new processes. Here is a try:
>>>
>>> The "old process" (not so old, changed with Git replacing Svn, hence the discussion) is
>>>
>>>    * use Jira to create issues with possibly attached patches and discussion there. With all what Jira affords...
>>>    * You can also link a GH PR from Jira. And have a patch, then it begins to be confusing (which one is the later, etc.)
>>>    * You can create a PR in GH and discuss it there, nothing else. There should not be crossed discussions in Jira and GH
>>>    * I certainly miss other points, that's the gist
>>>
>>> The new process is not clearly defined, here are 2 possible versions:
>>>
>>>    * Jira is only used for history reason, no more issue creations allowed
>>>    * GH is used not only for PR but also to create issues (needs a PMC agreement). It's then a replacement of Jira and we need to be quite careful
>>>      doing so.
>>>
>>>    * Jira continues to be used as is. With IMO some restrictions, like: if you have a patch you don't create a PR, it's one or the other way.
>>>    * GH is used not only for PR but also to create issues (needs a PMC agreement) an discuss them there. PR or attached patch can be used to
>>> contribute.
>>>
>>> As you see, for me the question is not  "GitHub or Jira"  but "GitHub or Jira or both" I have changed the title of the related wiki page accordingly:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
>>>
>>> HTH
>>>
>>> Jacques
>>>
>>> Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :
>>>> I have been following this discussion for a while.  However, I still wonder if this discussion is about which of the two options is the better one.
>>>> In my opinion, the discussion should rather be about whether the potential benefits of a new process justify the effort to change the old one. It
>>>> seems to me at least that this aspect is being neglected a bit.
>>>>
>>>> Am 13.03.20 um 10:24 schrieb Michael Brohl:
>>>>> Hi all,
>>>>>
>>>>> I'd like to encourage everyone to visit the wiki page https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT, read
>>>>> carefully, check, dicuss and ask questions to get to a good information base for an important decision to make.
>>>>>
>>>>> Thanks everyone,
>>>>>
>>>>> Michael Brohl
>>>>>
>>>>> ecomify GmbH - www.ecomify.de
>>>>>
>>>>>
>>>>> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
>>>>>> You are all invited to review, discuss in comments and possibly add pro and cons on this page
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
>>>>>>
>>>>>> It would else become unreadable here...
>>>>>>
>>>>>> Hopefully we will get to a consensus...
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>

[Pierre Smits-3]

HI Jacques,

IMO, we can. But I would give it another few days (the customary minimum)
to see whether others care to differ.

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Mon, May 25, 2020 at 6:54 PM Jacques Le Roux <
[hidden email]> wrote:

> Hi All,
>
> I believe we are now pragmatically using JIRA + Patch, or GH + PR.
>
> Remains the question about allowing the creation of issues in GH. It seems
> to me that nobody actually asked for that since Jira is enough for our
> needs.
>
> So I should not need more than what we use currently and can put
> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
> in Attic now, right?
>
> Jacques
>
> Le 18/03/2020 à 18:22, Michael Brohl a écrit :
> > +1 James!
> >
> > Thanks,
> >
> > Michael
> >
> >
> > Am 18.03.20 um 17:13 schrieb James Yong:
> >> Hi all,
> >>
> >> I personally feel we should allow both JIRA and Github for issue
> management, and let contributers use their own judgement on which one to
> use. JIRA
> >> contains wealth of information and many open issues for review, while
> Github allows easier review of source codes.
> >> So do either JIRA + Patch, or GH + PR.
> >>
> >> Regards,
> >> James
> >>
> >> On 2020/03/14 10:43:31, Jacques Le Roux <[hidden email]>
> wrote:
> >>> Hi Benjamin, All,
> >>>
> >>> That's a good point indeed. And we 1st need to clearly define what are
> the old and the new processes. Here is a try:
> >>>
> >>> The "old process" (not so old, changed with Git replacing Svn, hence
> the discussion) is
> >>>
> >>>    * use Jira to create issues with possibly attached patches and
> discussion there. With all what Jira affords...
> >>>    * You can also link a GH PR from Jira. And have a patch, then it
> begins to be confusing (which one is the later, etc.)
> >>>    * You can create a PR in GH and discuss it there, nothing else.
> There should not be crossed discussions in Jira and GH
> >>>    * I certainly miss other points, that's the gist
> >>>
> >>> The new process is not clearly defined, here are 2 possible versions:
> >>>
> >>>    * Jira is only used for history reason, no more issue creations
> allowed
> >>>    * GH is used not only for PR but also to create issues (needs a PMC
> agreement). It's then a replacement of Jira and we need to be quite careful
> >>>      doing so.
> >>>
> >>>    * Jira continues to be used as is. With IMO some restrictions,
> like: if you have a patch you don't create a PR, it's one or the other way.
> >>>    * GH is used not only for PR but also to create issues (needs a PMC
> agreement) an discuss them there. PR or attached patch can be used to
> >>> contribute.
> >>>
> >>> As you see, for me the question is not  "GitHub or Jira"  but "GitHub
> or Jira or both" I have changed the title of the related wiki page
> accordingly:
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/OFBIZ/Question%3A+GitHub+or+Jira+or+both
> >>>
> >>> HTH
> >>>
> >>> Jacques
> >>>
> >>> Le 13/03/2020 à 17:41, Benjamin Jugl a écrit :
> >>>> I have been following this discussion for a while.  However, I still
> wonder if this discussion is about which of the two options is the better
> one.
> >>>> In my opinion, the discussion should rather be about whether the
> potential benefits of a new process justify the effort to change the old
> one. It
> >>>> seems to me at least that this aspect is being neglected a bit.
> >>>>
> >>>> Am 13.03.20 um 10:24 schrieb Michael Brohl:
> >>>>> Hi all,
> >>>>>
> >>>>> I'd like to encourage everyone to visit the wiki page
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT,
> read
> >>>>> carefully, check, dicuss and ask questions to get to a good
> information base for an important decision to make.
> >>>>>
> >>>>> Thanks everyone,
> >>>>>
> >>>>> Michael Brohl
> >>>>>
> >>>>> ecomify GmbH - www.ecomify.de
> >>>>>
> >>>>>
> >>>>> Am 12.03.20 um 17:28 schrieb Jacques Le Roux:
> >>>>>> You are all invited to review, discuss in comments and possibly add
> pro and cons on this page
> >>>>>>
> >>>>>>
> https://cwiki.apache.org/confluence/display/OFBIZ/GITHUB+plus+GIT+VS+JIRA+plus+GIT
> >>>>>>
> >>>>>> It would else become unreadable here...
> >>>>>>
> >>>>>> Hopefully we will get to a consensus...
> >>>>>>
> >>>>>> Jacques
> >>>>>>
> >>>>>>
> >
>