Git history problem

[Jacques Le Roux]

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
>

[Mathieu Lirzin]

Hello Michael,

Michael Brohl <[hidden email]> 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

[Mathieu Lirzin]

Mathieu Lirzin <[hidden email]> 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

[Pierre Smits-3]

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 <[hidden email]>
wrote:

> Jacques Le Roux <[hidden email]> 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
>

[Mathieu Lirzin]

Jacques Le Roux <[hidden email]> 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

[Michael Brohl-3]

Hi Mathieu,

Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:

> Hello Michael,
>
> Michael Brohl <[hidden email]> 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

[Gil Portenseigne]

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

[Pierre Smits-3]

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 <[hidden email]>
wrote:

> Hi Mathieu,
>
> Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:
> > Hello Michael,
> >
> > Michael Brohl <[hidden email]> 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
>
>
>
>

[Mathieu Lirzin]

Michael Brohl <[hidden email]> 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

[Michael Brohl-3]

Hi Mathieu,

> Am 11.03.2020 um 23:04 schrieb Mathieu Lirzin <[hidden email]>:
>
> Michael Brohl <[hidden email]> 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

[Jacques Le Roux]

Le 11/03/2020 à 16:29, Mathieu Lirzin a écrit :

> Jacques Le Roux <[hidden email]> 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

[Michael Brohl-3]

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

[Samuel-2]

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

[Michael Brohl-3]

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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Samuel-2]

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

[Jacques Le Roux]

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

[Jacopo Cappellato-3]

On Thu, Mar 12, 2020 at 10:32 AM Jacques Le Roux <
[hidden email]> 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

[Jacques Le Roux]

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

> On Thu, Mar 12, 2020 at 10:32 AM Jacques Le Roux <
> [hidden email]> 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