Hi eflers :)
So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead to less stability than ideal and also makes stabilisatio
Hi Andrew,
This is a good idea and I use it in my personal projects and highly
recommend it.
I woudl also like to propose another change at the phab level and to
onboard more devs. Libreoffice does things in an interest manner. They
classify the issues according to varying difficulty and then a
On Sat, 22 Jul 2017 21:22:43 + Andrew Williams said:
> Hi eflers :)
>
> So after thinking about issue management and planning milestones I thought
> more about our source control. We currently have various different models
> used but the bottom line is that it all hits master all the time wh
I second raster here.
For years I pushed for more stable master, development in branches.
While I tend to work in a branch myself, and test it before merging...
what happens is that once you merge, hell breaks loose... so I tend to
land and reserve some time to track reports on IRC/mailing list...
On 07/26/2017 05:19 PM, Gustavo Sverzut Barbieri wrote:
I second raster here.
...
On Sat, Jul 22, 2017 at 11:32 PM, Carsten Haitzler wrote:
i like the simplicity of our model...
Well, maybe the point is not master branch.
The point maybe : will e remain an experimental fine tool (I was ab
On Wed, Jul 26, 2017 at 4:21 PM Pierre Couderc wrote:
>
>
> On 07/26/2017 05:19 PM, Gustavo Sverzut Barbieri wrote:
> > I second raster here.
> >
> > ...
> > On Sat, Jul 22, 2017 at 11:32 PM, Carsten Haitzler
> wrote:
> >>
> >> i like the simplicity of our model...
> Well, maybe the point is not
Hi,
I understand the reasoning behind the social convention of the master
stabilisation period but what seems to be evolving as git standard is that
master should always be stable / releasable - not stable, but something
that can be relied upon. From where we are the equivalent is not to push
stab
Hi,
An interesting point. I guess I figure there is something between massive
merges and the alternative of breaking master. Isn't it fair to say that we
shouldn't ever be breaking master even if we're doing cool new stuff? (yes,
I know I have done it too, it's the way things are just now).
When
Hi Mike,
One of the strengths of GitFlow is that all release branches merge back
fully so you can't miss fixes. Additionally all releases are tagged on
master so there is a clear record of where all releases were cut from.
Hot fixes such as we currently back port are created in a place to be
immed
On Wed, 26 Jul 2017 22:44:03 + Andrew Williams said:
> Hi,
>
> An interesting point. I guess I figure there is something between massive
> merges and the alternative of breaking master. Isn't it fair to say that we
> shouldn't ever be breaking master even if we're doing cool new stuff? (yes,
On Wed, 26 Jul 2017 22:36:53 + Andrew Williams said:
> Hi,
>
> I understand the reasoning behind the social convention of the master
> stabilisation period but what seems to be evolving as git standard is that
> master should always be stable / releasable - not stable, but something
> that c
On Wed, 26 Jul 2017 22:03:04 +0200 Pierre Couderc said:
>
>
> On 07/26/2017 05:19 PM, Gustavo Sverzut Barbieri wrote:
> > I second raster here.
> >
> > ...
> > On Sat, Jul 22, 2017 at 11:32 PM, Carsten Haitzler
> > wrote:
> >>
> >> i like the simplicity of our model...
> Well, maybe the point
On 07/26/2017 10:28 PM, Mike Blumenkrantz wrote:
There are multiple release branches, the latest of which receives
backports
for bug fixes only: see
https://git.enlightenment.org/core/enlightenment.git/refs/ for any branch
with the format 'enlightenment-0.XX'.
I know that.
But are bad bugs ba
On 07/27/2017 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
i think what you mean is that the method and "process" is there, but
enlightenment is not as stable as you would like it to be? is what what you
mean? because the model/process is there exactly as you describe.
Yes, and I think t
On 27/07/17 16:43, Pierre Couderc wrote:
>
> On 07/26/2017 10:28 PM, Mike Blumenkrantz wrote:
>> There are multiple release branches, the latest of which receives
>> backports
>> for bug fixes only: see
>> https://git.enlightenment.org/core/enlightenment.git/refs/ for any branch
>> with the form
Hello.
On 07/22/2017 11:22 PM, Andrew Williams wrote:
Hi eflers :)
So after thinking about issue management and planning milestones I thought
more about our source control. We currently have various different models
used but the bottom line is that it all hits master all the time which can
lead
Hello.
On 07/27/2017 12:49 AM, Andrew Williams wrote:
Hi Mike,
One of the strengths of GitFlow is that all release branches merge back
fully so you can't miss fixes.
We apply fixes to master first and then backport. No chance to miss them
in master.
Additionally all releases are tagged on
On 27/07/17 17:33, Stefan Schmidt wrote:
> Hello.
>
> On 07/22/2017 11:22 PM, Andrew Williams wrote:
>> Hi eflers :)
>>
>> So after thinking about issue management and planning milestones I
>> thought
>> more about our source control. We currently have various different models
>> used but the bo
On 27/07/17 17:37, Stefan Schmidt wrote:
> Hello.
>
> On 07/27/2017 12:49 AM, Andrew Williams wrote:
>> Hi Mike,
>>
>> One of the strengths of GitFlow is that all release branches merge back
>> fully so you can't miss fixes.
>
> We apply fixes to master first and then backport. No chance to mis
Hello.
On 07/27/2017 12:44 AM, Andrew Williams wrote:
Hi,
An interesting point. I guess I figure there is something between massive
merges and the alternative of breaking master. Isn't it fair to say that we
shouldn't ever be breaking master even if we're doing cool new stuff? (yes,
I know I ha
Hello.
On 07/27/2017 12:36 AM, Andrew Williams wrote:
Whilst I can't argue with the simplicity of our branching model I don't
know that I completely agree that stopping for a month every release is
indicative of a good process...
Who is really stopping his work? If you look at the sheer amoun
Hello.
On 07/27/2017 10:20 AM, Simon Lees wrote:
On 27/07/17 17:37, Stefan Schmidt wrote:
Hello.
On 07/27/2017 12:49 AM, Andrew Williams wrote:
Hi Mike,
One of the strengths of GitFlow is that all release branches merge back
fully so you can't miss fixes.
We apply fixes to master first a
Hello.
On 07/27/2017 10:18 AM, Simon Lees wrote:
On 27/07/17 17:33, Stefan Schmidt wrote:
Hello.
On 07/22/2017 11:22 PM, Andrew Williams wrote:
Hi eflers :)
So after thinking about issue management and planning milestones I
thought
more about our source control. We currently have various d
On 27/07/17 18:14, Stefan Schmidt wrote:
> Hello.
>
> On 07/27/2017 10:18 AM, Simon Lees wrote:
>>
>>
>> On 27/07/17 17:33, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> On 07/22/2017 11:22 PM, Andrew Williams wrote:
Hi eflers :)
So after thinking about issue management and planning mi
On 07/27/2017 09:28 AM, Simon Lees wrote:
Then you were likely told the wrong thing, every bugfix should go into
enlightenment-0.XX, it that doesn't happen let us know and we will make
sure it does.
You are right, I am wrong, I does not find what I thought to be a
counter exemple.
Sorry f
Hello.
Reading my mails from yesterday again I think one might be able to get
the impression I actually want to shoot this idea down before it
actually has a chance to proof itself. That is not what I wanted to
bring across. :)
I'm actually very much interested to get the workflow improved
On 28/07/17 16:30, Stefan Schmidt wrote:
> Hello.
>
> Reading my mails from yesterday again I think one might be able to get
> the impression I actually want to shoot this idea down before it
> actually has a chance to proof itself. That is not what I wanted to
> bring across. :)
>
> I'm actual
Hello.
On 07/28/2017 09:09 AM, Simon Lees wrote:
On 28/07/17 16:30, Stefan Schmidt wrote:
Hello.
Reading my mails from yesterday again I think one might be able to get
the impression I actually want to shoot this idea down before it
actually has a chance to proof itself. That is not what I w
On 28/07/17 16:54, Stefan Schmidt wrote:
> Hello.
>
> On 07/28/2017 09:09 AM, Simon Lees wrote:
>>
>>
>> On 28/07/17 16:30, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> Reading my mails from yesterday again I think one might be able to get
>>> the impression I actually want to shoot this idea down b
On 28/07/17 17:35, Simon Lees wrote:
>
>
> On 28/07/17 16:54, Stefan Schmidt wrote:
>> Hello.
>>
>> On 07/28/2017 09:09 AM, Simon Lees wrote:
>>>
>>>
>>> On 28/07/17 16:30, Stefan Schmidt wrote:
Hello.
Reading my mails from yesterday again I think one might be able to get
th
On Fri, 28 Jul 2017 09:00:39 +0200 Stefan Schmidt said:
> Hello.
>
> Reading my mails from yesterday again I think one might be able to get
> the impression I actually want to shoot this idea down before it
> actually has a chance to proof itself. That is not what I wanted to
> bring across.
Hi,
I'm really struggling with this thread - there is so much contradiction and
a sprinkling of irony to boot...
Firstly the idea that GitFlow is only good if you force people to use it is
plain nonsense - how would it become popular if people only used it when
forced? Every team I've worked with
On 07/27/2017 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
On Wed, 26 Jul 2017 22:03:04 +0200 Pierre Couderc said:
that is exactly how our policy works today. efl is done exactly this way.
enlightenment should/does also run this way. mike does maintain stable branches
for releases and
On 17-08-07 08:49, Pierre Couderc wrote:
>
>
> On 07/27/2017 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 26 Jul 2017 22:03:04 +0200 Pierre Couderc said:
> >
> >>
> > that is exactly how our policy works today. efl is done exactly this way.
> > enlightenment should/does also run
On 08/07/2017 05:10 PM, Boris Faure wrote:
I can't find enough time to make a proper 1.1.0 release, so even less
time to do proper maintenance releases.
"Que celui de vous qui est sans péché jette le premier la pierre contre
elle." (John8,7).
Merci Boris pour terminology..
-
35 matches
Mail list logo
