You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Michael Brohl <mi...@ecomify.de> on 2020/03/11 16:08:47 UTC
Re: Adopting Github Workflow
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
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