You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Mathieu Lirzin <ma...@nereide.fr> on 2020/03/09 16:58:33 UTC
Git history problem
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.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Michael Brohl <mi...@ecomify.de>.
This is why I was advocating to leave the wiki page in WIP state until
the command line process is described also.
We should rework the wiki page to also show the command line process to
merge PR's on the local sandbox which permits ultimate control about
what is going to be pushed to the official repositories. I think
committers should get used to the process of handling the PRs on their
local sandbox and avoid doing it directly against the official repo.
I've set the wiki status to WIP again with the reference link to the
RocketMQ process which is a good example for the command line processes
as well.
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 10.03.20 um 10:57 schrieb Jacques Le Roux:
> 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
>
>
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>>
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>
Re: Git commits email notification problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/03/2020 à 11:46, Mathieu Lirzin a écrit :
> Hello Jacques,
>
> Here is a first answer on the specific point of the commit notification
> issue.
>
> Jacques Le Roux <ja...@les7arts.com> writes:
>
>> 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.
> I guess this is related to the synchronization between Gitbox and
> Github. because that email says that 4087 revisions have been added
> which correspond to the total number of commits in the ofbiz-plugins
> repository.
Thanks Mathieu,
I think you are right, it must take some time indeed to sync the dual-host stuff. Anyway it's not a big deal, just annoying.
Jacques
Git commits email notification problem (was: Git history problem)
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello Jacques,
Here is a first answer on the specific point of the commit notification
issue.
Jacques Le Roux <ja...@les7arts.com> writes:
> 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.
I guess this is related to the synchronization between Gitbox and
Github. because that email says that 4087 revisions have been added
which correspond to the total number of commits in the ofbiz-plugins
repository.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Gil Portenseigne <gi...@nereide.fr>.
+1
IMO i prefer to rebase and check the commit i push in my local repo.
Thanks
Le 11 mars 2020 16:52:36 GMT+01:00, Mathieu Lirzin <ma...@nereide.fr> a écrit :
>>> The simple solution to prevent this is to get into the habit of
>>> linearizing history, meaning always rebasing and clean history
>before
>>> merging into trunk.
>>
>> I guess the GH merge button option "Rebase and merge" is what we are
>> looking to enforce with the request to Infra, right?
>
>I personnally think we should have *no button* because the committers
>should cleanup the commits (reword, squash, ...) before merging to
>trunk, but "rebase and merge" is an improvement compared to basic
>"merge".
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Git history problem
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Jacques Le Roux <ja...@les7arts.com> writes:
> Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
>> Yes things seems to happen not magically but by putting earplugs on and
>> going ahead, which is certainly more effective but IMO not acceptable
>> when working within a community.
>
> I'm not sure to who it's destined, so I'll not take it for me :)
This was destined to no-one, it was just general remark regarding
handling community input on a proposal. So you do not have to feel
targeted.
By the way the expression “not acceptable” was probably too strong and
should have been “not a good thing” because as Pierre said this is
eventually necessary to get things done.
>> The simple solution to prevent this is to get into the habit of
>> linearizing history, meaning always rebasing and clean history before
>> merging into trunk.
>
> I guess the GH merge button option "Rebase and merge" is what we are
> looking to enforce with the request to Infra, right?
I personnally think we should have *no button* because the committers
should cleanup the commits (reword, squash, ...) before merging to
trunk, but "rebase and merge" is an improvement compared to basic
"merge".
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
> Yes things seems to happen not magically but by putting earplugs on and
> going ahead, which is certainly more effective but IMO not acceptable
> when working within a community.
I'm not sure to who it's destined, so I'll not take it for me :)
>
>> 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.
> ‘git bisect’ handles non-linear history nicely but it achieves this with
> a more complex algorithm than basic binary search [1][2].
>
> The difficulty is when a commit identified as introducing the regression
> is a merge commit because it requires analysing each branch up to their
> common ancestor.
Thanks, did not think about that.
> The major issue is more social, because once people adopts the practice
> of merging branches without rebasing and cleaning that branch first,
> since contributors often branch from another development branch, this
> will eventually lead to have the same commit present multiple times but
> with different hashes.
Mmm, that's bad indeed.
> The simple solution to prevent this is to get into the habit of
> linearizing history, meaning always rebasing and clean history before
> merging into trunk.
I guess the GH merge button option "Rebase and merge" is what we are looking to enforce with the request to Infra, right?
--
Jacques Le Roux
400E Chemin de la Mouline
34560 Poussan
04 67 51 19 38
06 11 79 50 28
Re: Git history problem
Posted by Pierre Smits <pi...@apache.org>.
The remark about 'not acceptable when working within a community' reminds
me of the the joke about 'How many community members does it take to get
four wheel nuts loosened'.
It takes 4: 1 loosening the nuts and 3 others discussing....
JFDI (putting on the earplugs, and doing it) is part of the Apache Way. It
applies to contributing code changes and to people having the need to
discuss stuff.
But in this project some need to have discussions on everything. In tickets
with statements like 'we should discuss this' or in specific threads on a
side tracking remark, without taking that 'need' forward to a new thread
(maybe hoping the other community member does that). Some have even brought
forward that issues (whether they be bugs or improvements) need to be
discussed before they are registered as issues. A result of this
side-tracking (bike shedding??) of JFDI, is not going for accepting 'good
enough' in many cases and an almost unclimbable mountain of open tickets.
That is not the way to go in an Apache project, as it alienates
contributors (leading to drastic measures taken - as seen again recently).
Going down that road - all/most of the time - is not beneficial to the
project, as seems to bring moving forward to a halt.
Paraphrasing Alec Steele here: at a certain moment in time it is time to
stop yacking and start whacking.
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 Wed, Mar 11, 2020 at 12:33 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> Hello Jacques,
>
> Jacques Le Roux <ja...@les7arts.com> writes:
>
> > 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.
>
> Your opinion is always worth telling on this topic since to my knowledge
> you are the most active reviewer which really valuable.
>
> > 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.
>
> Thanks for double checking.
>
> >> 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
>
> AIUI this page is only collection of Git/Github tips and fuzzy
> "maybe"/"you can" rules. Moreover it does not propose to
> replace/deprecate/simplify existing contribution procedures/tools.
>
> So it misses the point that adopting Github workflow only makes sense if
> it simplifies the contribution process for both contributors and
> reviewers.
>
> > 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.
>
> Yes things seems to happen not magically but by putting earplugs on and
> going ahead, which is certainly more effective but IMO not acceptable
> when working within a community.
>
> > 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.
>
> ‘git bisect’ handles non-linear history nicely but it achieves this with
> a more complex algorithm than basic binary search [1][2].
>
> The difficulty is when a commit identified as introducing the regression
> is a merge commit because it requires analysing each branch up to their
> common ancestor.
>
> The major issue is more social, because once people adopts the practice
> of merging branches without rebasing and cleaning that branch first,
> since contributors often branch from another development branch, this
> will eventually lead to have the same commit present multiple times but
> with different hashes.
>
> The simple solution to prevent this is to get into the habit of
> linearizing history, meaning always rebasing and clean history before
> merging into trunk.
>
> > 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 ;)
>
> :-)
>
> [1]
> https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html#_git_bisect_details
> [2] https://www.wikipedia.org/wiki/Binary_search_algorithm
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>
Re: Adopting Github Workflow (was: Git history problem)
Posted by Pierre Smits <pi...@apache.org>.
As the philosopher Yoda once stated: "Do or Do Not, There is no try'.
Having a restriction on how (potential) non-privileged contributors can
contribute is not a good thing for this project. What it will lead to is
more instead of less hurdles to contribute. Some may report a bug in an
email (even though not subscribed to a mailing list). Disregarding that and
hammering on 'follow the dictates' does not get issues resolved faster. So
given current state of the project, such does not benefit the project or
potential adopters/contribot) more. It only benefits those not willing to
collaborate/contribute (and/or bureaucrats).
This applies to the first 3 aspects raised by Mathieu.
As for the 4th: The availability of an API (whether for Github or JIRA -
and yes JIRA has such as well) doesn't make OFBiz reports (quarterly, not
monthly) better by itself. It needs commitment on various levels to have it
used consistently. AFAICT, this is not going to happen soon in this 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
On Wed, Mar 11, 2020 at 4:30 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> Jacques Le Roux <ja...@les7arts.com> writes:
>
> > Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
> >>>> 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
> >> AIUI this page is only collection of Git/Github tips and fuzzy
> >> "maybe"/"you can" rules. Moreover it does not propose to
> >> replace/deprecate/simplify existing contribution procedures/tools.
> >
> > Yes, that's really missing, I agree. I once created OFBIZ-1129 (Tools to
> backport), but finally closed it for 2 reasons:
> >
> > 1. Not enough interest (most important reason by far)
> > 2. Spent some time, did not find easy way to replace scripts, I don't
> think fits.
> >
> > I think Pierre's effort is a try for the procedure aspect. Why not
> > joining there and improve?
>
> You are right. I should be more constructive than just acknowledging
> that the requirements I expressed were not properly considered.
>
> Let me try joining Pierre's effort by providing a simple but radical
> proposal for our contribution procedure :
>
> - Adopt Github Pull Request (PR) as the unique channel for code
> contribution
> - Require tickets only for bug reports
> - Replace JIRA with Github issues
> - Use Github API to get the stats for OFBiz monthly reports
>
> @Pierre: What do you think ?
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 12/03/2020 à 10:30, Jacques Le Roux a écrit :
> It then offers the same possibilities than Jira (which adapted)
It then offers the same possibilities than Jira (which adapted during its evolution)
Jacques
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi All,
I created INFRA-20424 for that.
Food for thought: I also noticed some more information in Arrow README.md file.
[](https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/branch/master)
[](https://codecov.io/gh/apache/arrow?branch=master)
[](https://bugs.chromium.org/p/oss-fuzz/issues/list?sort=-opened&can=1&q=proj:arrow)
[](https://github.com/apache/arrow/blob/master/LICENSE.txt)
[](https://twitter.com/apachearrow)
We could maybe provide something similar in our README.adoc?
With commit 26bb8f602fcb7bd3a3d4a8b4cfab67df35a45764 I added an image with a link to the license at least. I'm unsure how to do the rest, tweeter
notably would be cool...
I also thought that we have no README.adoc in ofbiz-plugins repo. We could copy the one in ofbiz-framework. That mean to copy it regularly to maintain
the sync, what do you think?
Jacques
Le 28/05/2020 à 08:20, Aditya Sharma a écrit :
>>> So maybe Infra can use the description there
> +1 for using the description
>
>>> For the link to Jira it depends on README.adoc. But if we put a link to
> OFBiz site then the link to Jira is there.
> Makes sense
>
> Thanks and regards,
> Aditya Sharma
>
> On Tue, May 26, 2020 at 7:22 PM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Thanks All,
>>
>> I will put the wiki page in Attic.
>>
>> I totally agree Aditya, good idea. It seems we need to ask Infra for that.
>> I see no way to do it ourselves. Also it seems the "labels" comes from
>> doap_OFBiz.rdf under site repo.
>> So maybe Infra can use the description there or, as you suggest, something
>> more elaborated to welcome users that we would define (tht maybe put in
>> doap_OFBiz.rdf) with a link to OFBiz site
>>
>> For the link to Jira it depends on README.adoc. But if we put a link to
>> OFBiz site then the link to Jira is there.
>>
>> Opinions?
>>
>> Jacques
>>
>> Le 26/05/2020 à 14:25, Aditya Sharma a écrit :
>>> +1 Jacques. I think we are good with Jira for now and if needed we can
>> add
>>> a link to Jira in description like Apache Arrow[1]
>>> Also, I would suggest that we should change the description of the
>>> repository[2] from "Mirror of Apache OFBiz Framework" to a description of
>>> OFBiz and the official website link similar to Apache Arrow.
>>>
>>> 1. https://github.com/apache/arrow#getting-involved
>>> 2. https://github.com/apache/ofbiz-framework
>>>
>>> Thanks and Regards,
>>> Aditya Sharma
>>>
>>> On Tue, May 26, 2020 at 5:42 PM Michael Brohl <mi...@ecomify.de>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> Thanks Jacques,
>>>>
>>>> Michael Brohl
>>>>
>>>> ecomify GmbH - www.ecomify.de
>>>>
>>>>
>>>> Am 25.05.20 um 18:53 schrieb 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
>>>>>>> <ja...@les7arts.com> 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
>>>>>>>>>>>
>>>>>>>>>>>
Re: Adopting Github Workflow
Posted by Aditya Sharma <ad...@apache.org>.
>> So maybe Infra can use the description there
+1 for using the description
>> For the link to Jira it depends on README.adoc. But if we put a link to
OFBiz site then the link to Jira is there.
Makes sense
Thanks and regards,
Aditya Sharma
On Tue, May 26, 2020 at 7:22 PM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Thanks All,
>
> I will put the wiki page in Attic.
>
> I totally agree Aditya, good idea. It seems we need to ask Infra for that.
> I see no way to do it ourselves. Also it seems the "labels" comes from
> doap_OFBiz.rdf under site repo.
> So maybe Infra can use the description there or, as you suggest, something
> more elaborated to welcome users that we would define (tht maybe put in
> doap_OFBiz.rdf) with a link to OFBiz site
>
> For the link to Jira it depends on README.adoc. But if we put a link to
> OFBiz site then the link to Jira is there.
>
> Opinions?
>
> Jacques
>
> Le 26/05/2020 à 14:25, Aditya Sharma a écrit :
> > +1 Jacques. I think we are good with Jira for now and if needed we can
> add
> > a link to Jira in description like Apache Arrow[1]
> > Also, I would suggest that we should change the description of the
> > repository[2] from "Mirror of Apache OFBiz Framework" to a description of
> > OFBiz and the official website link similar to Apache Arrow.
> >
> > 1. https://github.com/apache/arrow#getting-involved
> > 2. https://github.com/apache/ofbiz-framework
> >
> > Thanks and Regards,
> > Aditya Sharma
> >
> > On Tue, May 26, 2020 at 5:42 PM Michael Brohl <mi...@ecomify.de>
> > wrote:
> >
> >> +1
> >>
> >> Thanks Jacques,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 25.05.20 um 18:53 schrieb 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
> >>>>> <ja...@les7arts.com> 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
> >>>>>>>>>
> >>>>>>>>>
> >>
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks All,
I will put the wiki page in Attic.
I totally agree Aditya, good idea. It seems we need to ask Infra for that. I see no way to do it ourselves. Also it seems the "labels" comes from
doap_OFBiz.rdf under site repo.
So maybe Infra can use the description there or, as you suggest, something more elaborated to welcome users that we would define (tht maybe put in
doap_OFBiz.rdf) with a link to OFBiz site
For the link to Jira it depends on README.adoc. But if we put a link to OFBiz site then the link to Jira is there.
Opinions?
Jacques
Le 26/05/2020 à 14:25, Aditya Sharma a écrit :
> +1 Jacques. I think we are good with Jira for now and if needed we can add
> a link to Jira in description like Apache Arrow[1]
> Also, I would suggest that we should change the description of the
> repository[2] from "Mirror of Apache OFBiz Framework" to a description of
> OFBiz and the official website link similar to Apache Arrow.
>
> 1. https://github.com/apache/arrow#getting-involved
> 2. https://github.com/apache/ofbiz-framework
>
> Thanks and Regards,
> Aditya Sharma
>
> On Tue, May 26, 2020 at 5:42 PM Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> +1
>>
>> Thanks Jacques,
>>
>> Michael Brohl
>>
>> ecomify GmbH - www.ecomify.de
>>
>>
>> Am 25.05.20 um 18:53 schrieb 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
>>>>> <ja...@les7arts.com> 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
>>>>>>>>>
>>>>>>>>>
>>
Re: Adopting Github Workflow
Posted by Aditya Sharma <ad...@apache.org>.
+1 Jacques. I think we are good with Jira for now and if needed we can add
a link to Jira in description like Apache Arrow[1]
Also, I would suggest that we should change the description of the
repository[2] from "Mirror of Apache OFBiz Framework" to a description of
OFBiz and the official website link similar to Apache Arrow.
1. https://github.com/apache/arrow#getting-involved
2. https://github.com/apache/ofbiz-framework
Thanks and Regards,
Aditya Sharma
On Tue, May 26, 2020 at 5:42 PM Michael Brohl <mi...@ecomify.de>
wrote:
> +1
>
> Thanks Jacques,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 25.05.20 um 18:53 schrieb 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
> >>> <ja...@les7arts.com> 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
> >>>>>>>
> >>>>>>>
> >>
>
>
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
+1
Thanks Jacques,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 25.05.20 um 18:53 schrieb 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
>>> <ja...@les7arts.com> 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
>>>>>>>
>>>>>>>
>>
Re: Adopting Github Workflow
Posted by Pierre Smits <pi...@apache.org>.
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 <
jacques.le.roux@les7arts.com> 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 <ja...@les7arts.com>
> 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
> >>>>>>
> >>>>>>
> >
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@les7arts.com> 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
>>>>>>
>>>>>>
>
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
+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 <ja...@les7arts.com> 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
>>>>>
>>>>>
Re: Adopting Github Workflow
Posted by James Yong <ja...@apache.org>.
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 <ja...@les7arts.com> 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
> >>>
> >>>
> >>
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>>
>>>
>>
Re: Adopting Github Workflow
Posted by Pierre Smits <pi...@apache.org>.
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
Re: Adopting Github Workflow
Posted by Benjamin Jugl <be...@ecomify.de>.
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 +49 521 448 157-94
Fax +49 521 448 157-99
Mobil +49 160 807 8611
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: +49 521 448157-90, Fax: +49 521 448157-99,www.ecomify.de
Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
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
>
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <
>>> jacques.le.roux@les7arts.com> 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
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <
>> jacques.le.roux@les7arts.com> 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
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 12/03/2020 à 12:17, Jacopo Cappellato a écrit :
> On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
> jacques.le.roux@les7arts.com> 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
Re: Adopting Github Workflow
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Thu, Mar 12, 2020 at 11:47 AM Jacques Le Roux <
jacques.le.roux@les7arts.com> 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
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 12/03/2020 à 11:40, Jacopo Cappellato a écrit :
> On Thu, Mar 12, 2020 at 10:32 AM Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> [...]
>> 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]
>>
> Jacques, I am not sure what kind confirmation you are seeking from me but I
> will try to provide an answer to the questions I *think* you are asking me
> to respond.
> Question: 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.
>
> Jacopo
>
> [*] http://www.apache.org/dev/release-distribution
Thanks Jacopo,
It indeed clarifies my question.
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
and its byproducts?
Jacques
Re: Adopting Github Workflow
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Thu, Mar 12, 2020 at 10:32 AM Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> [...]
> 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]
>
Jacques, I am not sure what kind confirmation you are seeking from me but I
will try to provide an answer to the questions I *think* you are asking me
to respond.
Question: 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.
Jacopo
[*] http://www.apache.org/dev/release-distribution
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 12/03/2020 à 09:12, Michael Brohl a écrit :
> Hi Jacques,
>
> I will just pick out one topic here, see inline:
>
> Am 12.03.20 um 08:32 schrieb Jacques Le Roux:
>>
>> The most important question to answer is: what does Jira offers that GH does not?
>
> To justify the need of making a change, to me the question is quite the opposite: what does GitHub offer which Jira does not in the domain of
> contributing/ project management/ issue tracking?
>
> What makes it desirable for the community as a whole to work on a switch to GitHub?
>
> What do we gain? What do we lose?
>
> What processes are optimized or made easier for contributors (both technical skilled and not so technical skilled)?
>
> What problems do we have with the current setting and how are they solved with a new solution?
>
> Are there good examples or experience by other Apache projects who made the switch?
>
>
> I am not talking about personal preferences, speculations or just doing it because it's more up-to-date, but good, justified arguments which I have
> not seen yet.
>
> For a vote, we should collect all arguments with pro and cons side-by-side to have everyone taking part of it well informed.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
Hi Michael,
Yes it's also good to see from the other side too, even if it blurs things a bit for now...
Starting with not too much details to not be drown:
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.
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) 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)
Waiting completing pro and cons before starting a vote...
[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
Jacques
Re: Adopting Github Workflow
Posted by Samuel Tr��gou��t <sa...@nereide.fr>.
> I think you cannot make the tool responsible for how it is used in this
> particular case.
of course the tool is responsible! Jira is not a tool to review code!
"Jira: Issue & Project Tracking Software"
so nothing to do with code ;)
Just imagine how it would be possible with another tool. For example
with github each time James pushes new changes I will able to check only
this new changes, we will be able to make discussion
(question/answer/comment) on different points, I mean different threads
in same PullRequest
> The issue was opened for review only after the feature branch from
> Jacques was opened, before the exchange was meant to be just between
> Jacques and James.
don't understand this statement. You mean sometimes jira discussion is
understandable only by two people (so noone is able to enter discussion
afterward) and we should consider this a normal process?
What do you mean with `feature branch`? feature branch is related to git
only, no? here we are talking about jira and github and how these tools
are well suited for reviewing code.
>
> The contributors could have created a feature branch and work on it
> together but chose to exchange patch files.
>
> Jira is not to be blamed here.
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
Samuel,
I think you cannot make the tool responsible for how it is used in this
particular case.
The issue was opened for review only after the feature branch from
Jacques was opened, before the exchange was meant to be just between
Jacques and James.
The contributors could have created a feature branch and work on it
together but chose to exchange patch files.
Jira is not to be blamed here.
Regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 12.03.20 um 09:53 schrieb Samuel Trégouët:
> Hi Michael,
>
>> To justify the need of making a change, to me the question is quite the
>> opposite: what does GitHub offer which Jira does not in the domain of
>> contributing/ project management/ issue tracking?
> Jira review process is awfull!
>
> I tried to review OFBIZ-11306 and give up after 3 revisions… Now there
> are 40 patches attached. How can you tell which one is ok? Tell me which
> one is fixing another after which discussion? …
>
> If we care about reviewing patches/contribution we should stop using
> jira.
>
> Samuel
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 12/03/2020 à 09:53, Samuel Trégouët a écrit :
> Hi Michael,
>
>> To justify the need of making a change, to me the question is quite the
>> opposite: what does GitHub offer which Jira does not in the domain of
>> contributing/ project management/ issue tracking?
> Jira review process is awfull!
>
> I tried to review OFBIZ-11306 and give up after 3 revisions… Now there
> are 40 patches attached. How can you tell which one is ok? Tell me which
> one is fixing another after which discussion? …
>
> If we care about reviewing patches/contribution we should stop using
> jira.
>
> Samuel
Hi Samuel,
This is indeed a good example and forks should be added as a pro for GH...
At the moment it started James was not aware of our use of Git, see my "19/Dec/19 15:05" comment there, so not even telling about GH.
I guess you know the last comment redirects to the right way ;) I have some more to tell about that soon...
Jacques
Re: Adopting Github Workflow
Posted by Samuel Tr��gou��t <sa...@nereide.fr>.
Hi Michael,
>
> To justify the need of making a change, to me the question is quite the
> opposite: what does GitHub offer which Jira does not in the domain of
> contributing/ project management/ issue tracking?
Jira review process is awfull!
I tried to review OFBIZ-11306 and give up after 3 revisions… Now there
are 40 patches attached. How can you tell which one is ok? Tell me which
one is fixing another after which discussion? …
If we care about reviewing patches/contribution we should stop using
jira.
Samuel
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Jacques,
I will just pick out one topic here, see inline:
Am 12.03.20 um 08:32 schrieb Jacques Le Roux:
>
> The most important question to answer is: what does Jira offers that
> GH does not?
To justify the need of making a change, to me the question is quite the
opposite: what does GitHub offer which Jira does not in the domain of
contributing/ project management/ issue tracking?
What makes it desirable for the community as a whole to work on a switch
to GitHub?
What do we gain? What do we lose?
What processes are optimized or made easier for contributors (both
technical skilled and not so technical skilled)?
What problems do we have with the current setting and how are they
solved with a new solution?
Are there good examples or experience by other Apache projects who made
the switch?
I am not talking about personal preferences, speculations or just doing
it because it's more up-to-date, but good, justified arguments which I
have not seen yet.
For a vote, we should collect all arguments with pro and cons
side-by-side to have everyone taking part of it well informed.
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/03/2020 à 16:29, Mathieu Lirzin a écrit :
> Jacques Le Roux <ja...@les7arts.com> writes:
>
>> Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
>>>>> 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
>>> AIUI this page is only collection of Git/Github tips and fuzzy
>>> "maybe"/"you can" rules. Moreover it does not propose to
>>> replace/deprecate/simplify existing contribution procedures/tools.
>> Yes, that's really missing, I agree. I once created OFBIZ-1129 (Tools to backport), but finally closed it for 2 reasons:
>>
>> 1. Not enough interest (most important reason by far)
>> 2. Spent some time, did not find easy way to replace scripts, I don't think fits.
>>
>> I think Pierre's effort is a try for the procedure aspect. Why not
>> joining there and improve?
> You are right. I should be more constructive than just acknowledging
> that the requirements I expressed were not properly considered.
>
> Let me try joining Pierre's effort by providing a simple but radical
> proposal for our contribution procedure :
>
> - Adopt Github Pull Request (PR) as the unique channel for code contribution
> - Require tickets only for bug reports
> - Replace JIRA with Github issues
> - Use Github API to get the stats for OFBiz monthly reports
>
> @Pierre: What do you think ?
Hi All,
After reading all opinions so far, some fast, some more elaborated, I think we need to focus on gist and KISS.
TL;DR: we don't need more contributor best practices, but less.
At this stage a vote seems required. And before starting a vote we need 1st to clearly identify the pro and cons of the 2 solutions which are:
1. Only GH
2. Both Jira and GH
I'll not take into account other possibilities, as mentioned by Pierre, like patches in emails, and what not, because in such cases we most of the
time ask people to use Jira.
1. Only GH
The most important question to answer is: what does Jira offers that GH does not? I think all the rest depends on that and could simplify much things.
For instance seriously read https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices, and think about newbies... We may
also need to define the pros and cons. I think here it's subaltern because if GH fulfils the gist of what Jira does there is no point arguing. Again
we need to focus on the essential, things really needed, and not bikeshedding. We did that too much already, code is the gist, not administrate it.
2. Both Jira and GH
The most important point here is mental overload. If you want to quickly have an idea about mental overload, pick a tool from
https://techagainstcoronavirus.com/ You may try APL language too ;). Here we need to define the pros and cons.
Then we can and should vote, it's really an important topic that Mathieu raised and clearly we will not reach a lazy consensus.
Let me know if you think I missed something, but please don't bikeshed. What we want is to be effective and JFDI, not arguing. This project is riddled
with sterile discussions, and yes I'm part of it :/
Thanks
Jacques
Re: Adopting Github Workflow (was: Git history problem)
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Wed, Mar 11, 2020 at 4:30 PM Mathieu Lirzin <ma...@nereide.fr>
wrote:
> [...]
> - Adopt Github Pull Request (PR) as the unique channel for code
> contribution
>
+1
> - Require tickets only for bug reports
>
+1
> - Replace JIRA with Github issues
>
I am not sure about this: we have a huge backlog of existing Jira tickets
and we may have to verify if, as an Apache project, we can rely on a non
ASF resource as the primary source of information about bug/enhancement
reports.
- Use Github API to get the stats for OFBiz monthly reports
>
+1
Jacopo
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Mathieu,
> Am 11.03.2020 um 23:04 schrieb Mathieu Lirzin <ma...@nereide.fr>:
>
> Michael Brohl <mi...@ecomify.de> writes:
>
>>> Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
>>>
>>> So to “manage” stuff you could still use tickets and ML discussion like
>>> before, but it would just be done when necesarry not to follow the
>>> “everything as to be attached to JIRA” policy which was often justified
>>> by the fact that they serves in the Monthly reports.
>>
>> Do you speak of the monthly blog posts?
>
> Yes,
>
>> They are solely derived from the Git commit history, Jira is not used
>> for it.
>
> I was unaware of that. This is interesting because now I am realizing
> that all the arguments I heard in the past about the “the need to create
> a JIRA ticket for each meaningful code contribution because otherwise it
> will not appear in the Monthly blog posts” was even more bureaucratic
> non-sense…
Can you point us to the conversation where this was stated? From the beginning, the Blog post details are pulled from the commit history (svn and later git), that‘s why we have the commit message template.
The Jira issues are pulled for the release notes, maybe you have confused these?
>
> I will not response in details to the others points you made, because I
> am now convinced that we simply leave in alternate realities and that
> there is no way we can possibly have a constructive discussion together.
You are confusing me. What are those alternate realities?
Michael
Re: Adopting Github Workflow
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Michael Brohl <mi...@ecomify.de> writes:
> Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
>
>> So to “manage” stuff you could still use tickets and ML discussion like
>> before, but it would just be done when necesarry not to follow the
>> “everything as to be attached to JIRA” policy which was often justified
>> by the fact that they serves in the Monthly reports.
>
> Do you speak of the monthly blog posts?
Yes,
> They are solely derived from the Git commit history, Jira is not used
> for it.
I was unaware of that. This is interesting because now I am realizing
that all the arguments I heard in the past about the “the need to create
a JIRA ticket for each meaningful code contribution because otherwise it
will not appear in the Monthly blog posts” was even more bureaucratic
non-sense…
I will not response in details to the others points you made, because I
am now convinced that we simply leave in alternate realities and that
there is no way we can possibly have a constructive discussion together.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 13/03/2020 à 11:40, Jacopo Cappellato a écrit :
> On Fri, Mar 13, 2020 at 11:33 AM Jacques Le Roux <
> jacques.le.roux@les7arts.com> 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
Re: Adopting Github Workflow
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Fri, Mar 13, 2020 at 11:33 AM Jacques Le Roux <
jacques.le.roux@les7arts.com> 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?"
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 13/03/2020 à 11:29, Jacopo Cappellato a écrit :
> On Wed, Mar 11, 2020 at 10:20 PM Pierre Smits <pi...@apache.org>
> 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
Re: Adopting Github Workflow
Posted by Jacopo Cappellato <ja...@gmail.com>.
On Wed, Mar 11, 2020 at 10:20 PM Pierre Smits <pi...@apache.org>
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
Re: Adopting Github Workflow
Posted by Pierre Smits <pi...@apache.org>.
Mathieu, Michael, all,
Please try to keep an open mind.... Sticking to own dictats about one or
the other set of 'rules' and tools is not helping this project.
It is better to find a compromise that works best (or is least restrictive)
for all, seasoned contributors (whether privileged or not) and others.
Neither does expressing perjorative sentiments. Neither derogatory wording,
nor strong words were used in the section where it hinted to.
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). Several project have only Github tools
as above-the-line services working for them. And the INFRA ensuring that,
with below-the-line services, everything is retained within the ASF
architecture and infrastructure.
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 Wed, Mar 11, 2020 at 10:01 PM Michael Brohl <mi...@ecomify.de>
wrote:
> Hi Mathieu,
>
> Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
> > Hello Michael,
> >
> > Michael Brohl <mi...@ecomify.de> writes:
> >
> >> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
> >>> You are right. I should be more constructive than just acknowledging
> >>> that the requirements I expressed were not properly considered.
> >>>
> >>> Let me try joining Pierre's effort by providing a simple but radical
> >>> proposal for our contribution procedure :
> >>>
> >>> - Adopt Github Pull Request (PR) as the unique channel for code
> contribution
> >> -1
> >>
> >> I don't see a reason why we should not allow patches also. It will
> >> make it easier for people to contribute who are not able (or willing)
> >> to run their own GitHub repository.
> >>
> >> We should encourage people to use PR's but not force it (at least, not
> >> immediately...).
> > The reason I see for requiring a unique code contribution channel is
> > lowering cognitive overload for everyone.
>
> I don't see any cognitive overload in having a choice between an
> accepted channel which is used for years and using a new tool.
>
> >
> > If a community ends up “requiring” certain contribution procedures that
> > people are not forced to conform. It is then up to the reviewers to
> > adapt or not to the choices made by the contributor.
> >
> > If you are willing to adapt and continue review patches attached to a
> > ticket in parallel of the PR then those contributors will be happy.
>
> I don't see a need for a PR *and* a patch in parallel but would be happy
> to deal with either a patch or a PR as a reviewer and committer.
>
> We should allow both ways and give people the choice how they want to
> contribute.
>
> > - Require tickets only for bug reports
> >> -1
> >>
> >> Jira tickets for improvements/new features are extremely helpful to
> >> have everything in one place (with the addition to a link to the
> >> mailing list discussion), track the efforts, watch issues etc.
> >>
> >> How would you manage the work then?
> > I think you misinterpreted the proposition, it is not because something
> > is not required for every code contribution that it cannot happen when
> > it matters, indeed in the case of long term efforts like for instance
> > the “Groovy migration” it would make sense to have an issue associated
> > with it, but for small code/documentation improvements having a ticket
> > serves only a review medium which is far inferior than Github PR
> > mechanism.
> >
> > So to “manage” stuff you could still use tickets and ML discussion like
> > before, but it would just be done when necesarry not to follow the
> > “everything as to be attached to JIRA” policy which was often justified
> > by the fact that they serves in the Monthly reports.
>
> Do you speak of the monthly blog posts?
>
> They are solely derived from the Git commit history, Jira is not used
> for it.
>
>
> >>> - Replace JIRA with Github issues
> >> -1
> >>
> >> Why should we have two different issue management systems when we can
> >> have everything in one place? What advantages do you see for doing so?
> >> I also would not rely too heavily on GitHub because it is not an
> >> official ASF resource and IMO Jira is a huge knowledge base of the
> >> project.
> > The advantage with Github issues is that they are well integrated with
> > the Pull Request mechanism so it is easier to reference Github issues in
> > PR (the reverse is also true).
>
> The GitHub - Jira integration with PR's works fine so I cannot see this
> as a valid argument to switch the issue tracker.
>
> >
> > IME Jira does not help avoiding the “Cognitive overload” because its
> > features are thought for the enteprise context with time tracked
> > employee and managers producing reports to their superior which is far
> > too burdensome to work with in the context of a community project.
>
> ?! We don't use these features and therefore there is no burden
> introduced with them.
>
> Are you really feeling challenged by the use of Jira?
>
> > AFAIK the “everything in one place” you talk about is mostly fantasized
> > and has never existed IME. People often have to cross reference
> > parallel discussion happening on Jira and Mailing list.
>
> I don't understand why you need to use derogatory wording here. Strong
> words don't help and the fact that *you* don't like certain
> processes/tools/opinions does not mean that they are crap and not useful
> for others.
>
> There is no contradiction in my statement. Discussion on the mailing
> lists are hold to reach a wider audience, elaborate an issue/topic and
> reach consensus. They should be referenced in the Jira where the work is
> tracked so that everything is in one place.
>
> > The adoption of Github PR in the contribution framework I am proposing
> > will not improve that issue but at least it will not make it worse as it
> > would be if OFBiz adopts Github PR as “yet another” contribution option
> > ontop of existing ones.
> >
> >>> - Use Github API to get the stats for OFBiz monthly reports
> >> Can you elaborate what you mean/ how you would do it?
> > I don't know and I don't want to know ;-). I am just aware that Github
> > has a Web API which enables the retrieval of statistics on
> > Issues/PR/Contributors/... which can be useful for satisfying the
> > requirement of assisting the creation of monthly reports which some
> > people in this community care about (full disclosure I don't).
>
> This seems to be a misunderstanding as I explained above (if you talk
> about the monthly dev details for the blog).
>
> As always, I'm happy to hear more opinions.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
>
>
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Mathieu,
Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
> Hello Michael,
>
> Michael Brohl <mi...@ecomify.de> writes:
>
>> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
>>> You are right. I should be more constructive than just acknowledging
>>> that the requirements I expressed were not properly considered.
>>>
>>> Let me try joining Pierre's effort by providing a simple but radical
>>> proposal for our contribution procedure :
>>>
>>> - Adopt Github Pull Request (PR) as the unique channel for code contribution
>> -1
>>
>> I don't see a reason why we should not allow patches also. It will
>> make it easier for people to contribute who are not able (or willing)
>> to run their own GitHub repository.
>>
>> We should encourage people to use PR's but not force it (at least, not
>> immediately...).
> The reason I see for requiring a unique code contribution channel is
> lowering cognitive overload for everyone.
I don't see any cognitive overload in having a choice between an
accepted channel which is used for years and using a new tool.
>
> If a community ends up “requiring” certain contribution procedures that
> people are not forced to conform. It is then up to the reviewers to
> adapt or not to the choices made by the contributor.
>
> If you are willing to adapt and continue review patches attached to a
> ticket in parallel of the PR then those contributors will be happy.
I don't see a need for a PR *and* a patch in parallel but would be happy
to deal with either a patch or a PR as a reviewer and committer.
We should allow both ways and give people the choice how they want to
contribute.
> - Require tickets only for bug reports
>> -1
>>
>> Jira tickets for improvements/new features are extremely helpful to
>> have everything in one place (with the addition to a link to the
>> mailing list discussion), track the efforts, watch issues etc.
>>
>> How would you manage the work then?
> I think you misinterpreted the proposition, it is not because something
> is not required for every code contribution that it cannot happen when
> it matters, indeed in the case of long term efforts like for instance
> the “Groovy migration” it would make sense to have an issue associated
> with it, but for small code/documentation improvements having a ticket
> serves only a review medium which is far inferior than Github PR
> mechanism.
>
> So to “manage” stuff you could still use tickets and ML discussion like
> before, but it would just be done when necesarry not to follow the
> “everything as to be attached to JIRA” policy which was often justified
> by the fact that they serves in the Monthly reports.
Do you speak of the monthly blog posts?
They are solely derived from the Git commit history, Jira is not used
for it.
>>> - Replace JIRA with Github issues
>> -1
>>
>> Why should we have two different issue management systems when we can
>> have everything in one place? What advantages do you see for doing so?
>> I also would not rely too heavily on GitHub because it is not an
>> official ASF resource and IMO Jira is a huge knowledge base of the
>> project.
> The advantage with Github issues is that they are well integrated with
> the Pull Request mechanism so it is easier to reference Github issues in
> PR (the reverse is also true).
The GitHub - Jira integration with PR's works fine so I cannot see this
as a valid argument to switch the issue tracker.
>
> IME Jira does not help avoiding the “Cognitive overload” because its
> features are thought for the enteprise context with time tracked
> employee and managers producing reports to their superior which is far
> too burdensome to work with in the context of a community project.
?! We don't use these features and therefore there is no burden
introduced with them.
Are you really feeling challenged by the use of Jira?
> AFAIK the “everything in one place” you talk about is mostly fantasized
> and has never existed IME. People often have to cross reference
> parallel discussion happening on Jira and Mailing list.
I don't understand why you need to use derogatory wording here. Strong
words don't help and the fact that *you* don't like certain
processes/tools/opinions does not mean that they are crap and not useful
for others.
There is no contradiction in my statement. Discussion on the mailing
lists are hold to reach a wider audience, elaborate an issue/topic and
reach consensus. They should be referenced in the Jira where the work is
tracked so that everything is in one place.
> The adoption of Github PR in the contribution framework I am proposing
> will not improve that issue but at least it will not make it worse as it
> would be if OFBiz adopts Github PR as “yet another” contribution option
> ontop of existing ones.
>
>>> - Use Github API to get the stats for OFBiz monthly reports
>> Can you elaborate what you mean/ how you would do it?
> I don't know and I don't want to know ;-). I am just aware that Github
> has a Web API which enables the retrieval of statistics on
> Issues/PR/Contributors/... which can be useful for satisfying the
> requirement of assisting the creation of monthly reports which some
> people in this community care about (full disclosure I don't).
This seems to be a misunderstanding as I explained above (if you talk
about the monthly dev details for the blog).
As always, I'm happy to hear more opinions.
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Re: Adopting Github Workflow
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Mathieu Lirzin <ma...@nereide.fr> writes:
> The reason I see for requiring a unique code contribution channel is
> lowering cognitive overload for everyone.
>
> If a community ends up “requiring” certain contribution procedures that
^^^
then
> people are not forced to conform. It is then up to the reviewers to
^^^^^^^
should be
> adapt or not to the choices made by the contributor.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Adopting Github Workflow
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello Michael,
Michael Brohl <mi...@ecomify.de> writes:
> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
>> You are right. I should be more constructive than just acknowledging
>> that the requirements I expressed were not properly considered.
>>
>> Let me try joining Pierre's effort by providing a simple but radical
>> proposal for our contribution procedure :
>>
>> - Adopt Github Pull Request (PR) as the unique channel for code contribution
>
> -1
>
> I don't see a reason why we should not allow patches also. It will
> make it easier for people to contribute who are not able (or willing)
> to run their own GitHub repository.
>
> We should encourage people to use PR's but not force it (at least, not
> immediately...).
The reason I see for requiring a unique code contribution channel is
lowering cognitive overload for everyone.
If a community ends up “requiring” certain contribution procedures that
people are not forced to conform. It is then up to the reviewers to
adapt or not to the choices made by the contributor.
If you are willing to adapt and continue review patches attached to a
ticket in parallel of the PR then those contributors will be happy.
>> - Require tickets only for bug reports
>
> -1
>
> Jira tickets for improvements/new features are extremely helpful to
> have everything in one place (with the addition to a link to the
> mailing list discussion), track the efforts, watch issues etc.
>
> How would you manage the work then?
I think you misinterpreted the proposition, it is not because something
is not required for every code contribution that it cannot happen when
it matters, indeed in the case of long term efforts like for instance
the “Groovy migration” it would make sense to have an issue associated
with it, but for small code/documentation improvements having a ticket
serves only a review medium which is far inferior than Github PR
mechanism.
So to “manage” stuff you could still use tickets and ML discussion like
before, but it would just be done when necesarry not to follow the
“everything as to be attached to JIRA” policy which was often justified
by the fact that they serves in the Monthly reports.
>> - Replace JIRA with Github issues
>
> -1
>
> Why should we have two different issue management systems when we can
> have everything in one place? What advantages do you see for doing so?
> I also would not rely too heavily on GitHub because it is not an
> official ASF resource and IMO Jira is a huge knowledge base of the
> project.
The advantage with Github issues is that they are well integrated with
the Pull Request mechanism so it is easier to reference Github issues in
PR (the reverse is also true).
IME Jira does not help avoiding the “Cognitive overload” because its
features are thought for the enteprise context with time tracked
employee and managers producing reports to their superior which is far
too burdensome to work with in the context of a community project.
AFAIK the “everything in one place” you talk about is mostly fantasized
and has never existed IME. People often have to cross reference
parallel discussion happening on Jira and Mailing list.
The adoption of Github PR in the contribution framework I am proposing
will not improve that issue but at least it will not make it worse as it
would be if OFBiz adopts Github PR as “yet another” contribution option
ontop of existing ones.
>> - Use Github API to get the stats for OFBiz monthly reports
>
> Can you elaborate what you mean/ how you would do it?
I don't know and I don't want to know ;-). I am just aware that Github
has a Web API which enables the retrieval of statistics on
Issues/PR/Contributors/... which can be useful for satisfying the
requirement of assisting the creation of monthly reports which some
people in this community care about (full disclosure I don't).
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Adopting Github Workflow
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Jacques Le Roux <ja...@les7arts.com> writes:
> Le 11/03/2020 à 17:08, Michael Brohl a écrit :
>>
>> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
>>> - Adopt Github Pull Request (PR) as the unique channel for code contribution
>>
>> -1
>>
>> I don't see a reason why we should not allow patches also. It will
>> make it easier for people to contribute who are not able (or
>> willing) to run their own GitHub repository.
>>
>> We should encourage people to use PR's but not force it (at least, not immediately...).
>
> I agree with Michael, using only GitHub (GH) is too radical, IMO even in the future.
>
> Also the Jacopo's remark about using (only?) a 3rd party tool should
> be checked if ever we get this way. Jira is also a 3rd party tool but
> it's donated by Atlassian to the ASF and handled/customised/maintained
> by the Infra team. Also it uses a customised version of the OFBiz
> Entity Engine, own dog food? :)
> [...]
> +1 with Michael's comment, Jira is very handy when it comes to details
> like uploading info, etc. Not sure GH provides the same
>
If seasoned PMC members like you or Michael are not ready to give up on
considering JIRA as a central tool to “manage” every code contribution
the discussion is over on my side.
Adopting the Github Workflow ontop of an already indigest cake of
contribution requirements can only make things worse.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
On top of that, I though agree that 2 ways to do the same thing is always confusing, especially for newbies.
I had this experience with the APL language. There you have not 2 ways but almost as much as your imagination allows to do things. And yes it's
confusing, it's also fun, but that's another story :).
Le 11/03/2020 à 17:28, Jacques Le Roux a écrit :
> Le 11/03/2020 à 17:08, Michael Brohl a écrit :
>> Hi Mathieu,
>>
>> inline...
>
> Inline too...
>
>
>>
>> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
>>> - Adopt Github Pull Request (PR) as the unique channel for code contribution
>>
>> -1
>>
>> I don't see a reason why we should not allow patches also. It will make it easier for people to contribute who are not able (or willing) to run
>> their own GitHub repository.
>>
>> We should encourage people to use PR's but not force it (at least, not immediately...).
>
> I agree with Michael, using only GitHub (GH) is too radical, IMO even in the future.
>
> Also the Jacopo's remark about using (only?) a 3rd party tool should be checked if ever we get this way. Jira is also a 3rd party tool but it's
> donated by Atlassian to the ASF and handled/customised/maintained by the Infra team. Also it uses a customised version of the OFBiz Entity Engine,
> own dog food? :)
>
>
>>
>>> - Require tickets only for bug reports
>>
>> -1
>>
>> Jira tickets for improvements/new features are extremely helpful to have everything in one place (with the addition to a link to the mailing list
>> discussion), track the efforts, watch issues etc.
>>
>> How would you manage the work then?
>
> +1 with Michael's comment, Jira is very handy when it comes to details like uploading info, etc. Not sure GH provides the same
>
>
>>
>>> - Replace JIRA with Github issues
>>
>> -1
>>
>> Why should we have two different issue management systems when we can have everything in one place? What advantages do you see for doing so?
>>
>> I also would not rely too heavily on GitHub because it is not an official ASF resource and IMO Jira is a huge knowledge base of the project.
>
> I agree with Michael, I believe GH is there to stay (as a Microsoft product now), but you never know with 3rd party tool. Sometimes they don't even
> provide way to migrate (yes, you Google!)
>
> Jacques
>
Re: Adopting Github Workflow
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/03/2020 à 17:08, Michael Brohl a écrit :
> Hi Mathieu,
>
> inline...
Inline too...
>
> Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
>> - Adopt Github Pull Request (PR) as the unique channel for code contribution
>
> -1
>
> I don't see a reason why we should not allow patches also. It will make it easier for people to contribute who are not able (or willing) to run
> their own GitHub repository.
>
> We should encourage people to use PR's but not force it (at least, not immediately...).
I agree with Michael, using only GitHub (GH) is too radical, IMO even in the future.
Also the Jacopo's remark about using (only?) a 3rd party tool should be checked if ever we get this way. Jira is also a 3rd party tool but it's
donated by Atlassian to the ASF and handled/customised/maintained by the Infra team. Also it uses a customised version of the OFBiz Entity Engine, own
dog food? :)
>
>> - Require tickets only for bug reports
>
> -1
>
> Jira tickets for improvements/new features are extremely helpful to have everything in one place (with the addition to a link to the mailing list
> discussion), track the efforts, watch issues etc.
>
> How would you manage the work then?
+1 with Michael's comment, Jira is very handy when it comes to details like uploading info, etc. Not sure GH provides the same
>
>> - Replace JIRA with Github issues
>
> -1
>
> Why should we have two different issue management systems when we can have everything in one place? What advantages do you see for doing so?
>
> I also would not rely too heavily on GitHub because it is not an official ASF resource and IMO Jira is a huge knowledge base of the project.
I agree with Michael, I believe GH is there to stay (as a Microsoft product now), but you never know with 3rd party tool. Sometimes they don't even
provide way to migrate (yes, you Google!)
Jacques
Re: Adopting Github Workflow
Posted by Gil Portenseigne <gi...@nereide.fr>.
Hi,
On Wed, Mar 11, 2020 at 05:08:47PM +0100, Michael Brohl wrote:
> >
> > - Adopt Github Pull Request (PR) as the unique channel for code contribution
>
> -1
>
> I don't see a reason why we should not allow patches also. It will make it
> easier for people to contribute who are not able (or willing) to run their
> own GitHub repository.
>
> We should encourage people to use PR's but not force it (at least, not
> immediately...).
Agree encouraging is better, but that will become invalid if it is
chosen to use Github as the new way to report issues/improvement
contribution. In that case the patch is a more complex way to
contribute and discuss contributions.
>
>
> > - Require tickets only for bug reports
>
> -1
>
> Jira tickets for improvements/new features are extremely helpful to have
> everything in one place (with the addition to a link to the mailing list
> discussion), track the efforts, watch issues etc.
>
> How would you manage the work then?
>
Agree that being restrictive is not good.
>
> > - Replace JIRA with Github issues
>
> -1
>
> Why should we have two different issue management systems when we can have
> everything in one place? What advantages do you see for doing so?
>
> I also would not rely too heavily on GitHub because it is not an official
> ASF resource and IMO Jira is a huge knowledge base of the project.
>
If i understood well the proposal is to *replace* one by another, to
avoid the usage of multiple tools (for PR and issues).
The problematic is the lost of history and like was said github being
external to Apache.
But what Jira do offer that github do not ? Is that possible to keep
Jira as a legacy bugTracker for history sake ? Is that to much work for
us to adapt to this new tool. Do other apache project use github as
their bugTracker, and is that an issue ? This has to be analysed.
>
> > - Use Github API to get the stats for OFBiz monthly reports
>
> Can you elaborate what you mean/ how you would do it?
>
I guess that building reports onto number of PR merged/closed, number of
commit, listing of github issue by type (those that exists, that
matters), etc.
Thanks
Re: Adopting Github Workflow
Posted by Michael Brohl <mi...@ecomify.de>.
Hi Mathieu,
inline...
Am 11.03.20 um 16:29 schrieb Mathieu Lirzin:
> You are right. I should be more constructive than just acknowledging
> that the requirements I expressed were not properly considered.
>
> Let me try joining Pierre's effort by providing a simple but radical
> proposal for our contribution procedure :
>
> - Adopt Github Pull Request (PR) as the unique channel for code contribution
-1
I don't see a reason why we should not allow patches also. It will make
it easier for people to contribute who are not able (or willing) to run
their own GitHub repository.
We should encourage people to use PR's but not force it (at least, not
immediately...).
> - Require tickets only for bug reports
-1
Jira tickets for improvements/new features are extremely helpful to have
everything in one place (with the addition to a link to the mailing list
discussion), track the efforts, watch issues etc.
How would you manage the work then?
> - Replace JIRA with Github issues
-1
Why should we have two different issue management systems when we can
have everything in one place? What advantages do you see for doing so?
I also would not rely too heavily on GitHub because it is not an
official ASF resource and IMO Jira is a huge knowledge base of the project.
> - Use Github API to get the stats for OFBiz monthly reports
Can you elaborate what you mean/ how you would do it?
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Adopting Github Workflow (was: Git history problem)
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Jacques Le Roux <ja...@les7arts.com> writes:
> Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
>>>> 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
>> AIUI this page is only collection of Git/Github tips and fuzzy
>> "maybe"/"you can" rules. Moreover it does not propose to
>> replace/deprecate/simplify existing contribution procedures/tools.
>
> Yes, that's really missing, I agree. I once created OFBIZ-1129 (Tools to backport), but finally closed it for 2 reasons:
>
> 1. Not enough interest (most important reason by far)
> 2. Spent some time, did not find easy way to replace scripts, I don't think fits.
>
> I think Pierre's effort is a try for the procedure aspect. Why not
> joining there and improve?
You are right. I should be more constructive than just acknowledging
that the requirements I expressed were not properly considered.
Let me try joining Pierre's effort by providing a simple but radical
proposal for our contribution procedure :
- Adopt Github Pull Request (PR) as the unique channel for code contribution
- Require tickets only for bug reports
- Replace JIRA with Github issues
- Use Github API to get the stats for OFBiz monthly reports
@Pierre: What do you think ?
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 11/03/2020 à 12:33, Mathieu Lirzin a écrit :
>>> 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
> AIUI this page is only collection of Git/Github tips and fuzzy
> "maybe"/"you can" rules. Moreover it does not propose to
> replace/deprecate/simplify existing contribution procedures/tools.
Yes, that's really missing, I agree. I once created OFBIZ-1129 (Tools to backport), but finally closed it for 2 reasons:
1. Not enough interest (most important reason by far)
2. Spent some time, did not find easy way to replace scripts, I don't think fits.
I think Pierre's effort is a try for the procedure aspect. Why not joining there and improve?
> So it misses the point that adopting Github workflow only makes sense if
> it simplifies the contribution process for both contributors and
> reviewers.
At 1st glance it simplifies committers work: just a button to click \o/
But reviewing in the GH env. is not easy. Eclipse and other tools used locally make things much easier. And reviewing is of course the most important
thing, everybody can click a button ;)
Jacques
Re: Git history problem
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Hello Jacques,
Jacques Le Roux <ja...@les7arts.com> writes:
> 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.
Your opinion is always worth telling on this topic since to my knowledge
you are the most active reviewer which really valuable.
> 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.
Thanks for double checking.
>> 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
AIUI this page is only collection of Git/Github tips and fuzzy
"maybe"/"you can" rules. Moreover it does not propose to
replace/deprecate/simplify existing contribution procedures/tools.
So it misses the point that adopting Github workflow only makes sense if
it simplifies the contribution process for both contributors and
reviewers.
> 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.
Yes things seems to happen not magically but by putting earplugs on and
going ahead, which is certainly more effective but IMO not acceptable
when working within a community.
> 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.
‘git bisect’ handles non-linear history nicely but it achieves this with
a more complex algorithm than basic binary search [1][2].
The difficulty is when a commit identified as introducing the regression
is a merge commit because it requires analysing each branch up to their
common ancestor.
The major issue is more social, because once people adopts the practice
of merging branches without rebasing and cleaning that branch first,
since contributors often branch from another development branch, this
will eventually lead to have the same commit present multiple times but
with different hashes.
The simple solution to prevent this is to get into the habit of
linearizing history, meaning always rebasing and clean history before
merging into trunk.
> 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 ;)
:-)
[1] https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html#_git_bisect_details
[2] https://www.wikipedia.org/wiki/Binary_search_algorithm
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: Git history problem
Posted by Mathieu Lirzin <ma...@nereide.fr>.
Michael Brohl <mi...@ecomify.de> writes:
> I tried to follow the instructions found behind the link Mathieu
> provided and see that I cannot change the project settings.
>
> Who has access to the project settings and can grant me permission to
> change settings?
Thanks Michael for this attempt.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Jacopo Cappellato <ja...@gmail.com>.
I think that the ASF Infra will have to take care of this configuration
change.
I have noticed that Jacques already filed a request a few minutes ago [*]
so let's wait and see.
Jacopo
[*] https://issues.apache.org/jira/browse/INFRA-19950
On Tue, Mar 10, 2020 at 7:25 AM Michael Brohl <mi...@ecomify.de>
wrote:
> I tried to follow the instructions found behind the link Mathieu
> provided and see that I cannot change the project settings.
>
> Who has access to the project settings and can grant me permission to
> change settings?
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 09.03.20 um 22:39 schrieb Michael Brohl:
> > +1
> >
> > It is easy to prevent this by using rebase merging but committers have
> to care about it. If Github can be configured to prevent merge commits we
> should do so.
> >
> > Thanks,
> > Michael
> >
> >> Am 09.03.2020 um 17:58 schrieb Mathieu Lirzin <
> mathieu.lirzin@nereide.fr>:
> >>
> >> 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.
> >>
> >> --
> >> Mathieu Lirzin
> >> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
>
>
Re: Git history problem
Posted by Michael Brohl <mi...@ecomify.de>.
I tried to follow the instructions found behind the link Mathieu
provided and see that I cannot change the project settings.
Who has access to the project settings and can grant me permission to
change settings?
Thanks,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 09.03.20 um 22:39 schrieb Michael Brohl:
> +1
>
> It is easy to prevent this by using rebase merging but committers have to care about it. If Github can be configured to prevent merge commits we should do so.
>
> Thanks,
> Michael
>
>> Am 09.03.2020 um 17:58 schrieb Mathieu Lirzin <ma...@nereide.fr>:
>>
>> 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.
>>
>> --
>> Mathieu Lirzin
>> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Re: Git history problem
Posted by Michael Brohl <mi...@ecomify.de>.
+1
It is easy to prevent this by using rebase merging but committers have to care about it. If Github can be configured to prevent merge commits we should do so.
Thanks,
Michael
> Am 09.03.2020 um 17:58 schrieb Mathieu Lirzin <ma...@nereide.fr>:
>
> 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.
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37