Re: Adopting Github Workflow

[Michael Brohl]

Hi Mathieu,

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

[Mathieu Lirzin]

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

[Pierre Smits]

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  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Wed, Mar 11, 2020 at 10:01 PM Michael Brohl 
wrote:

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

Re: Adopting Github Workflow

[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



signature.asc
Description: PGP signature

Re: Adopting Github Workflow

[Michael Brohl]

Hi Mathieu,

Am 11.03.20 um 19:13 schrieb Mathieu Lirzin:

Hello Michael,

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

Re: Adopting Github Workflow

[Mathieu Lirzin]

Jacques Le Roux  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 (was: Git history problem)

[Pierre Smits]

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  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Wed, Mar 11, 2020 at 4:30 PM Mathieu Lirzin 
wrote:

> Jacques Le Roux  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

[Mathieu Lirzin]

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

[Mathieu Lirzin]

Hello Michael,

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

[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

Re: Adopting Github Workflow

[Jacques Le Roux]

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: Git history problem

[Gil Portenseigne]

+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  
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: Adopting Github Workflow

[Michael Brohl]

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





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Git history problem

[Mathieu Lirzin]

Jacques Le Roux  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: Adopting Github Workflow (was: Git history problem)

[Jacopo Cappellato]

On Wed, Mar 11, 2020 at 4:30 PM Mathieu Lirzin 
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

Adopting Github Workflow (was: Git history problem)

[Mathieu Lirzin]

Jacques Le Roux  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

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Pierre Smits]

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  since
2008 (without privileges)

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
Apache Steve , committer


On Wed, Mar 11, 2020 at 12:33 PM Mathieu Lirzin 
wrote:

> Hello Jacques,
>
> Jacques Le Roux  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
> > 

Re: Git commits email notification problem

[Jacques Le Roux]

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



Improved: Convert DimensionServices.xml minilang to groovy (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
" 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

Re: Git history problem

[Mathieu Lirzin]

Hello Jacques,

Jacques Le Roux  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

Git commits email notification problem (was: Git history problem)

[Mathieu Lirzin]

Hello Jacques,

Here is a first answer on the specific point of the commit notification
issue.

Jacques Le Roux  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:
>
>< 
>
>Improved: Convert DimensionServices.xml minilang to groovy (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
> " 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: buildbot exception in on ofbizBranch17FrameworkPlugins

[Jacques Le Roux]

Hi Michael,

To be totally honest, this time it's not an intrinsic Buidbot issue, it just 
could not grab a resource ;)

This does not excuse the cases where it fails on integration tests when they pass locally. With machines working almost 100% all time it's not a 
surprise though.


Jacques

Le 10/03/2020 à 17:56, Michael Brohl a écrit :

This is just another buildbot problem and does not seem to be related to the 
commit:

FAILURE: Build failed with an exception. * Where: Build file '/home/buildslave/slave/ofbizBranch17FrameworkPlugins/build/build.gradle' line: 1096 * 
What went wrong: A problem occurred evaluating root project 'ofbiz'. > Could not resolve all dependencies for configuration ':runtime'. > Could not 
download batik-anim.jar (org.apache.xmlgraphics:batik-anim:1.9) > Could not get resource 
'https://jcenter.bintray.com/org/apache/xmlgraphics/batik-anim/1.9/batik-anim-1.9.jar'. > Could not GET 
'https://jcenter.bintray.com/org/apache/xmlgraphics/batik-anim/1.9/batik-anim-1.9.jar'. Received status code 504 from server: Gateway Time-out


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 10.03.20 um 16:53 schrieb build...@apache.org:

The Buildbot has detected a build exception on builder 
ofbizBranch17FrameworkPlugins while building ofbiz-framework. Full details are 
available at:
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/480

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: asf947_ubuntu

Build Reason: downstream
Build Source Stamp: [branch release17.12] 
0c7be39acb089433a252adf9f34ed72ab34654d2
Blamelist: Dennis Balkir 

BUILD FAILED: exception shell upload_2

Sincerely,
  -The Buildbot