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
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
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)
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
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
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
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
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
^^^
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
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
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
+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
>>>
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
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,
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
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
>>>
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 :)
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
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
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:
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
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
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
23 matches
Mail list logo
