[Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)
Hi,
We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit

I submitted the following:
> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.

But there is no consensus on the formulation at least, and apparently on the restrictions themselves.

I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Dr. Sassafras
I don't see [REF] as low value. It's just not the right time for it.

I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.

Did I miss something?

Brendan

> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>
> Hi,
> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>
> I submitted the following:
>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>
> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>
> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

lindon-4
That's the way I think about it.
Regards,
lindon

> On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:
>
> I don't see [REF] as low value. It's just not the right time for it.
>
> I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.
>
> Did I miss something?
>
> Brendan
>
>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>>
>> Hi,
>> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>>
>> I submitted the following:
>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>>
>> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>>
>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

luciash d' being
Same here.

luci


On 7.6.2017 3:12, [hidden email] wrote:

> That's the way I think about it.
> Regards,
> lindon
>
>> On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:
>>
>> I don't see [REF] as low value. It's just not the right time for it.
>>
>> I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.
>>
>> Did I miss something?
>>
>> Brendan
>>
>>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>>>
>>> Hi,
>>> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>>>
>>> I submitted the following:
>>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>>> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>>>
>>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Jonny Bradley-4
+1

> On 7 Jun 2017, at 10:16, luciash <[hidden email]> wrote:
>
> Same here.
>
> luci
>
>
> On 7.6.2017 3:12, [hidden email] wrote:
>> That's the way I think about it.
>> Regards,
>> lindon
>>
>>> On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:
>>>
>>> I don't see [REF] as low value. It's just not the right time for it.
>>>
>>> I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.
>>>
>>> Did I miss something?
>>>
>>> Brendan
>>>
>>>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>>>>
>>>> I submitted the following:
>>>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>>>> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>>>>
>>>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Jean-Marc Libs
+1

On Wed, Jun 7, 2017 at 12:17 PM, Jonny Bradley <[hidden email]> wrote:
+1

> On 7 Jun 2017, at 10:16, luciash <[hidden email]> wrote:
>
> Same here.
>
> luci
>
>
> On 7.6.2017 3:12, [hidden email] wrote:
>> That's the way I think about it.
>> Regards,
>> lindon
>>
>>> On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:
>>>
>>> I don't see [REF] as low value. It's just not the right time for it.
>>>
>>> I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.
>>>
>>> Did I miss something?
>>>
>>> Brendan
>>>
>>>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>>>>
>>>> I submitted the following:
>>>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>>>> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>>>>
>>>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> TikiWiki-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Bernard Sfez-3
In reply to this post by Jonny Bradley-4
Hello Chealer,

As it has been said many times, we all appreciate your hard work on Tiki and you are doing what hasn’t been done for month controlling the commits one by one.
It have helped to improve and to "educate" new developer joining Tiki.


However, as community, we agreed and set the way we want commit, tags and release process to run.
You may disagree with part of it or the entire process and that's ok.

There are many option to redefine the process or for you to handle a part of it actively, etc.

For the actual release I’m asking to conform to the actual process and "ways" we want it done so we can complete it.


After the release is done… everything can be discussed and changed if the community wish to.
We have a roundtable meeting on the 15 June, may be you could explain us your ideas about this.

Thanks for your understanding,
Bernard



On 7 Jun 2017, at 13:17 , Jonny Bradley <[hidden email]> wrote:

+1

On 7 Jun 2017, at 10:16, luciash <[hidden email]> wrote:

Same here.

luci


On 7.6.2017 3:12, [hidden email] wrote:
That's the way I think about it.
Regards,
lindon

On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:

I don't see [REF] as low value. It's just not the right time for it.

I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.

Did I miss something?

Brendan

On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:

Hi,
We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit

I submitted the following:
During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
But there is no consensus on the formulation at least, and apparently on the restrictions themselves.

I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Bernard Sfez | bsfez.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)

Thank you Bernard,

Please see inline remarks below and excuse the awkward formatting.

 

De : Bernard Sfez [mailto:[hidden email]]
Envoyé : 7 juin 2017 07:06
À : Tiki developers <[hidden email]>
Cc : Philippe Cloutier <[hidden email]>
Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

 

Hello Chealer,

 

As it has been said many times, we all appreciate your hard work on Tiki and you are doing what hasn’t been done for month controlling the commits one by one.

It have helped to improve and to "educate" new developer joining Tiki.

 

 

However, as community, we agreed and set the way we want commit, tags and release process to run.

You may disagree with part of it or the entire process and that's ok.

 

There are many option to redefine the process or for you to handle a part of it actively, etc.

 

For the actual release I’m asking to conform to the actual process and "ways" we want it done so we can complete it.

[Philippe Cloutier] I understand but note that « actuel » and « actual » are false friends. I wish this thread stays focused on determining the volunteers and their commitment, but don’t worry; if anyone asks me to resolve a conflict which may not have arised if it wasn’t for a commit of mine which does not respect a plausible interpretation of the documentation of trunk restriction as it stood as the beginning of the release, I will.

 

 

After the release is done… everything can be discussed and changed if the community wish to.

We have a roundtable meeting on the 15 June, may be you could explain us your ideas about this.

[Philippe Cloutier] Thanks for the invitation, but my message meant to collect the ideas from volunteers (I do not intend to volunteer, so I do not want my viewpoint to weight too much).

 

 

 

Thanks for your understanding,

Bernard

 

 

 

On 7 Jun 2017, at 13:17 , Jonny Bradley <[hidden email]> wrote:

 

+1


On 7 Jun 2017, at 10:16, luciash <[hidden email]> wrote:

Same here.

luci


On 7.6.2017 3:12, [hidden email] wrote:

That's the way I think about it.
Regards,
lindon


On Jun 6, 2017, at 1:57 PM, Dr. Sassafras <[hidden email]> wrote:

I don't see [REF] as low value. It's just not the right time for it.

I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here. New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit if you don't.

Did I miss something?

Brendan


On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:

Hi,
We have been revising the commit guidelines for trunk during the semi-automatic merging period: <a href="https://dev.tiki.org/Where&#43;to&#43;commit">https://dev.tiki.org/Where+to+commit

I submitted the following:

During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.

But there is no consensus on the formulation at least, and apparently on the restrictions themselves.

I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 

Bernard Sfez | bsfez.com

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)
In reply to this post by Dr. Sassafras
Hi Brendan,
Please see inline remarks below and excuse the awkward formatting.

> -----Message d'origine-----
> De : Dr. Sassafras [mailto:[hidden email]]
> Envoyé : 6 juin 2017 13:58
> À : Tiki developers <[hidden email]>
> Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)
>
> I don't see [REF] as low value. It's just not the right time for it.

Fair enough. I'm afraid this gets a little complicated, but the following is more precise than my proposition:
        During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, some changes should be avoided/postponed. The more lines a change modifies, the more it should be avoided/postponed. The lower the value (the least it improves Tiki) and the lower it costs to develop, the more it should be avoided/postponed. In particular, this means automated code reformatting should be postponed.

I struggled to keep the language not too technical, so thanks in advance if someone can fix or confirm the English.

>
> I'm not really sure what you mean in the rest of your email. I'm also confused what the issue is here.
> New features go into trunk, fixes go into 17 and ref is put off until auto-merge is complete. Your
> encouraged to do your own auto merges, but be prepared to fix conflicts related to your own commit
> if you don't.

It's quite problematic to tell someone they can push a fix but may be forced at an time they do not know to resolve a conflict which they do not know that they would contribute to create. There's a risk that people won't contribute, or that they will not comply.

>
> Did I miss something?

Well, debating between non-volunteers is not necessarily useless, but the first goal was to identify responsibles. Does your intervention imply you volunteer? If not, I think it's more efficient to let volunteers specify their restrictions first.

>
> Brendan
>
> > On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <Philippe.Cloutier.externe@mern-
> mffp.gouv.qc.ca> wrote:
> >
> > Hi,
> > We have been revising the commit guidelines for trunk during the semi-automatic merging period:
> https://dev.tiki.org/Where+to+commit
> >
> > I submitted the following:
> >> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk,
> changes with a low value and a low cost to postpone should be avoided. In particular, this means
> automated code reformatting should be postponed.
> >
> > But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
> >
> > I suppose this is a good opportunity to establish both who commits to semi-automatic merges and
> which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized,
> please say when your commitment stops and which restrictions on trunk you demand to maintain that
> commitment. Please try demanding the same restrictions as other voluntees if you agree with them,
> to facilitate convergence.
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > TikiWiki-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Jean-Marc Libs
In reply to this post by Cloutier, Philippe (DGARI-Consultant)
-1 for reorganising our way of releasing during a release.

On Tue, Jun 6, 2017 at 7:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
Hi,
We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit

I submitted the following:
> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.

But there is no consensus on the formulation at least, and apparently on the restrictions themselves.

I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Gary Cunningham-Lee
In reply to this post by Cloutier, Philippe (DGARI-Consultant)
Hi,

On 6/7/2017 2:27 AM, Cloutier, Philippe (DGARI-Consultant) wrote:
> Hi,
> We have been revising the commit guidelines for trunk during the semi-automatic merging period: https://dev.tiki.org/Where+to+commit
>
> I submitted the following:
>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.
>
> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>
> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

The Tiki project has a more organic, informal system than what you're
describing here, I would say, and people are comfortable with it. What
we do is "making software the wiki way", right? I think each contributor
just has (or should have) a sense of personal responsibility to try to
do the right thing, and then the group has a kind of "it takes a
village" collective oversight function (though admittedly this falls too
much on too few individuals).

Your talk about establishing who can commit and about restrictions and
demands seems better suited to a more formal, explicitly structured code
contribution/maintenance system than what Tiki has - or wants, I'd say.

-- Gary

>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)
In reply to this post by Jean-Marc Libs

Hi Jean-Marc,

Does this mean you are volunteering, and if so, what are your conditions?

 

De : Jean-Marc Libs [mailto:[hidden email]]
Envoyé : 7 juin 2017 10:59
À : Tiki developers <[hidden email]>
Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

 

-1 for reorganising our way of releasing during a release.

 

On Tue, Jun 6, 2017 at 7:27 PM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:

Hi,
We have been revising the commit guidelines for trunk during the semi-automatic merging period: <a href="https://dev.tiki.org/Where&#43;to&#43;commit" target="_blank">https://dev.tiki.org/Where+to+commit

I submitted the following:
> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, changes with a low value and a low cost to postpone should be avoided. In particular, this means automated code reformatting should be postponed.

But there is no consensus on the formulation at least, and apparently on the restrictions themselves.

I suppose this is a good opportunity to establish both who commits to semi-automatic merges and which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized, please say when your commitment stops and which restrictions on trunk you demand to maintain that commitment. Please try demanding the same restrictions as other voluntees if you agree with them, to facilitate convergence.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Dr. Sassafras
In reply to this post by Cloutier, Philippe (DGARI-Consultant)


Brendan

> On Jun 7, 2017, at 10:42 AM, Cloutier, Philippe (DGARI-Consultant) <[hidden email]> wrote:
>
> Hi Brendan,
> Please see inline remarks below and excuse the awkward formatting.
>
>> -----Message d'origine-----
>> De : Dr. Sassafras [mailto:[hidden email]]
>> Envoyé : 6 juin 2017 13:58
>> À : Tiki developers <[hidden email]>
>> Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)
>>
>> I don't see [REF] as low value. It's just not the right time for it.
>
> Fair enough. I'm afraid this gets a little complicated, but the following is more precise than my proposition:
>    During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk, some changes should be avoided/postponed. The more lines a change modifies, the more it should be avoided/postponed. The lower the value (the least it improves Tiki) and the lower it costs to develop, the more it should be avoided/postponed. In particular, this means automated code reformatting should be postponed.
>
> I struggled to keep the language not too technical, so thanks in advance if someone can fix or confirm the English.


This still does not reflect my feelings on the issue and I'm sure other developers here, so -1 to the changes.

>> if you don't.
>
> It's quite problematic to tell someone they can push a fix but may be forced at an time they do not know to resolve a conflict which they do not know that they would contribute to create. There's a risk that people won't contribute, or that they will not comply.

It's a well crafted argument, but I see many implied situations which I don't see as a reality. So although the logic of the argument is impeccable, I don't see it applying to tiki. So again -1 to the changes.

I'm also don't think that this I the right  time to debate changes to these types of processes. It's not a clarification your proposing but a whole reworking of a tiki process. -1 to any such change, beneficial or not, during a release.

>
>>
>> Did I miss something?
>
> Well, debating between unon-volunteers is not necessarily useless, but the first goal was to identify responsibles. Does your intervention imply you volunteer? If not, I think it's more efficient to let volunteers specify their restrictions first.
>
>>
>> Brendan
>>
>>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant) <Philippe.Cloutier.externe@mern-
>> mffp.gouv.qc.ca> wrote:
>>>
>>> Hi,
>>> We have been revising the commit guidelines for trunk during the semi-automatic merging period:
>> https://dev.tiki.org/Where+to+commit
>>>
>>> I submitted the following:
>>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk,
>> changes with a low value and a low cost to postpone should be avoided. In particular, this means
>> automated code reformatting should be postponed.
>>>
>>> But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
>>>
>>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and
>> which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized,
>> please say when your commitment stops and which restrictions on trunk you demand to maintain that
>> commitment. Please try demanding the same restrictions as other voluntees if you agree with them,
>> to facilitate convergence.
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)
> -----Message d'origine-----
> De : Dr. Sassafras [mailto:[hidden email]]
> Envoyé : 7 juin 2017 12:19
> À : Tiki developers <[hidden email]>
> Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)
>
>
>
> Brendan
>
> > On Jun 7, 2017, at 10:42 AM, Cloutier, Philippe (DGARI-Consultant)
> <[hidden email]> wrote:
> >
> > Hi Brendan,
> > Please see inline remarks below and excuse the awkward formatting.
> >
> >> -----Message d'origine-----
> >> De : Dr. Sassafras [mailto:[hidden email]]
> >> Envoyé : 6 juin 2017 13:58
> >> À : Tiki developers <[hidden email]>
> >> Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)
> >>
> >> I don't see [REF] as low value. It's just not the right time for it.
> >
> > Fair enough. I'm afraid this gets a little complicated, but the following is more precise than my
> proposition:
> >    During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk,
> some changes should be avoided/postponed. The more lines a change modifies, the more it should be
> avoided/postponed. The lower the value (the least it improves Tiki) and the lower it costs to develop,
> the more it should be avoided/postponed. In particular, this means automated code reformatting
> should be postponed.
> >
> > I struggled to keep the language not too technical, so thanks in advance if someone can fix or
> confirm the English.
>
>
> This still does not reflect my feelings on the issue and I'm sure other developers here, so -1 to the
> changes.

I hope you realize that no one intends to do that change. A possibility was offered, but it's up to volunteers to decide.

>
> >> if you don't.
> >
> > It's quite problematic to tell someone they can push a fix but may be forced at an time they do not
> know to resolve a conflict which they do not know that they would contribute to create. There's a risk
> that people won't contribute, or that they will not comply.
>
> It's a well crafted argument, but I see many implied situations which I don't see as a reality.

Well, it's a proposal, of course the consequences are not reality currently, I was just pointing out that your suggestion would be quite problematic.

> [...]
>
> I'm also don't think that this I the right  time to debate changes to these types of processes.

If there is a problem with the timing, feel free to report it.

> It's not a
> clarification your proposing but a whole reworking of a tiki process.

A whole reworking? I don't see any work involved.

> [...]
> >
> >>
> >> Did I miss something?
> >
> > Well, debating between unon-volunteers is not necessarily useless, but the first goal was to identify
> responsibles. Does your intervention imply you volunteer? If not, I think it's more efficient to let
> volunteers specify their restrictions first.
> >
> >>
> >> Brendan
> >>
> >>> On Jun 6, 2017, at 1:27 PM, Cloutier, Philippe (DGARI-Consultant)
> <Philippe.Cloutier.externe@mern-
> >> mffp.gouv.qc.ca> wrote:
> >>>
> >>> Hi,
> >>> We have been revising the commit guidelines for trunk during the semi-automatic merging
> period:
> >> https://dev.tiki.org/Where+to+commit
> >>>
> >>> I submitted the following:
> >>>> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk,
> >> changes with a low value and a low cost to postpone should be avoided. In particular, this means
> >> automated code reformatting should be postponed.
> >>>
> >>> But there is no consensus on the formulation at least, and apparently on the restrictions
> themselves.
> >>>
> >>> I suppose this is a good opportunity to establish both who commits to semi-automatic merges and
> >> which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized,
> >> please say when your commitment stops and which restrictions on trunk you demand to maintain
> that
> >> commitment. Please try demanding the same restrictions as other voluntees if you agree with
> them,
> >> to facilitate convergence.
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> _______________________________________________
> >>> TikiWiki-devel mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >>
> >> ------------------------------------------------------------------------------
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> TikiWiki-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > TikiWiki-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)

Cloutier, Philippe (DGARI-Consultant)
In reply to this post by Gary Cunningham-Lee
Hi Gary,

> -----Message d'origine-----
> De : Gary Cunningham-Lee [mailto:[hidden email]]
> Envoyé : 7 juin 2017 11:43
> À : [hidden email]
> Objet : Re: [Tiki-devel] Semi-automatic merging responsibles and restrictions (Tiki 17)
>
> Hi,
>
> On 6/7/2017 2:27 AM, Cloutier, Philippe (DGARI-Consultant) wrote:
> > Hi,
> > We have been revising the commit guidelines for trunk during the semi-automatic merging period:
> https://dev.tiki.org/Where+to+commit
> >
> > I submitted the following:
> >> During this period, changes to trunk increase the risks of merge conflicts. To minimize this risk,
> changes with a low value and a low cost to postpone should be avoided. In particular, this means
> automated code reformatting should be postponed.
> >
> > But there is no consensus on the formulation at least, and apparently on the restrictions themselves.
> >
> > I suppose this is a good opportunity to establish both who commits to semi-automatic merges and
> which restrictions these volunteers have. If you volunteer to maintain 17.x and trunk synchronized,
> please say when your commitment stops and which restrictions on trunk you demand to maintain that
> commitment. Please try demanding the same restrictions as other voluntees if you agree with them,
> to facilitate convergence.
>
> The Tiki project has a more organic, informal system than what you're
> describing here, I would say, and people are comfortable with it. What
> we do is "making software the wiki way", right?

I must admit that I have never read The Wiki Way. But if The Wiki Way is the way WikiWikiWeb was built, i.e. without organization, I don't think that's how we make Tiki, no. I have personally and recently been harassed for not following (supposed) rules. We have had documented rules for more than a decade.

Now, WikiWikiWeb is dead. If The Wiki Way rather means the way of today's best known wiki, i.e. Wikipedia, then maybe. But Wikipedia is probably the wiki which has the most rules: https://en.wikipedia.org/wiki/Criticism_of_Wikipedia#Excessive_rule-making

Whatever "making software the wiki way" means, it should remain (or not) a slogan, not become an objective. Software is more complex than wikis. WikiWikiWeb didn't have branches (although wikis evolved and some wikis now have branches and need to get even more organized).

> I think each contributor
> just has (or should have) a sense of personal responsibility to try to
> do the right thing, and then the group has a kind of "it takes a
> village" collective oversight function (though admittedly this falls too
> much on too few individuals).
>
> Your talk about establishing who can commit and about restrictions and
> demands seems better suited to a more formal, explicitly structured code
> contribution/maintenance system than what Tiki has - or wants, I'd say.

I did not talk about establishing who can commit, I asked who made the *commitment* of ensuring changes to 17.x will not be lost.

The set of restrictions we will agree on will be what the responsibles want it to be, and I will not be a responsible. It can have more restrictions than the current set, less restrictions or even no restrictions. If you want no rules, just say you volunteer and demand no restrictions. I will (from a selfish perspective) be most happy with that.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel