Re: [E-devel] GitFlow

[Andrew Williams]

Hi,

So I guess this is quite a lot of work and folk are concerned it has not
yet been proven. To try and progress this experiment I propose that I
instead move Edi to our GitHub account where we do not have restrictions or
expectations of branching models etc.

Assuming no objections I will set this up once Stefan is back online and
can invite me to the organisation.

I hope that makes for a better compromise to try this out.
Andy

On Thu, 26 Oct 2017 at 13:38, Tom Hacohen  wrote:

> I accidentally hit send, didn't mean to.
> Here is my full reply:
> It's possible, yes, but it doesn't address my initial concerns, which
> are that edi will stick out compared to the other e projects. This
> will be considered a success by you for sure, and I don't see us
> changing the efl to follow, so it'll stay different.
> Furthermore, once you publish a tag/branch they should remain there,
> so even if we don't like it, it'll have to stay in edi or at least edi
> will be different.
> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> intrusive and painful.
>
> Additionally, I just took a look at this gitflow thing, and noticed
> that it's pretty much what we do but worse (apart of the poor mistake
> that we did which is having the stable branches be named per repo
> rather than having a consistent name, that is, efl-1.7 instead of
> stable-1.17).
> We never needed a "hotfix" branch, the "release" branch has always
> proved sufficient for us (I can see the potential need, we just never
> hit it). After taking a second look, he deletes branches afterwards,
> so it's a workflow we can and already do here.
> Release branches we already have.
> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> I don't see the advantage of having a "develop" branch in addition to
> master given our workflow. Our master is already considered "stable"
> and in a release state, so it really doesn't match our workflow.
>
> So I'm not really impressed with this suggestion (and in particular
> GitFlow), and I don't think it can be done in a way that is possible
> to revert or is compatible with what we do.
> As I said, if you want to test it, test it with your own dev branches,
> show us that the workflow works and just configure your tools for this
> testing period, I don't see why the test period needs to have the
> formal names.
>
> You mentioned having tools that work with it, what exactly?
>
> As a side note, I'm OK with changing the stable release branches to
> "release-x.y" if people are OK with that, instead of the per repo
> naming, this will make it slightly more compatible for you, and
> actually makes sense regardless (was a mistake in the first place).
>
> --
> Tom
>
> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> > It is possible, yes.
> >
> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
> wrote:
> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
> a...@andywilliams.me> said:
> >>
> >>> Hi,
> >>>
> >>> You are absolutely right - the “show it with a smaller project and
> prove
> >>> it’s worth is exactly why I brought it up. I was in the process of
> doing so
> >>> and hit this roadblock. No intention to beat a dead horse - I actually
> >>> thought I was doing what was agreed.
> >>>
> >>> Apologies if I got the wrong end of the stick.
> >>
> >> Well I think doing this with edi is fine. is it possible to have just
> edi have
> >> different branch naming schemes? i don't know. if it's not then we have
> >> problems. but i think we;re on the same page atm "try this in a smaller
> scale
> >> and show it improves things - us that to convince everyone else". :)
> >>
> >>> Andy
> >>>
> >>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler 
> wrote:
> >>>
> >>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams <
> a...@andywilliams.me>
> >>> > said:
> >>> >
> >>> > We had this discussion before in just one place I believe until you
> asked
> >>> > for
> >>> > specific branch names to be allowed. You wanted us to change how we
> branch
> >>> > and
> >>> > work with efl/e etc. the last time. I don't remember there being
> agreement
> >>> > with
> >>> > you on needing a change as I don't see our current model being bad or
> >>> > broken
> >>> > or causing trouble (discussion already had) vs gitflow. I don't know
> why
> >>> > you're
> >>> > bringing it back up as if there wasn't a consensus already. I
> believe the
> >>> > last
> >>> > discussion was roughly:
> >>> >
> >>> > "There is no agreement that any change is needed. The change you
> propose
> >>> > does
> >>> > nothing to actually improve anything by it's proposal. It just
> shuffles
> >>> > chairs,
> >>> > BUT if you really think it's so much better, try it on smaller
> projects
> >>> > first
> >>> > and show/prove it to be worth it".
> >>> >
> >>> > Or something to that effect. Most people were just silent on the
> topic.
> >>> >
> >>> > > Hi 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Fri, 27 Oct 2017 14:32:40 + Mike Blumenkrantz
 said:

> On Thu, Oct 26, 2017 at 8:27 PM Carsten Haitzler 
> wrote:
> 
> > On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:
> >
> > > Two things,
> > >
> > > Calling efl-master unmanagable and unrunable is just spreading a
> > > apocalyptic mood and does not really tell what is going on. There are
> >
> > I absolutely agree. I and many others use master all day every day. For
> > wayland
> > work it has issues and That is specific to that set of code. Sometimes eo
> > work
> > disrupts something. But it gets fixed.
> >
> > > bugs and a few crashes, yes, but the same happened a few years back when
> > > i started with efl stuff. (Also, how can you call efl master unstable if
> > > you havnt run it in a long time ? :D)
> >
> > Ooooh. nice catch there. :)
> >
> 
> It is indeed inconceivable that I could have periodically tested master,
> found it unusable each time, and then gone back to using stable. You've
> certainly caught me; well done everyone, and thanks for your hard work in
> keeping this mailing list so honest. Let's wrap it up and call it a /thread.

You did say exactly: "I haven't run efl master in a long time". That precludes
testing as that would be running. Marcel makes a very very very good point. If
you claim you have not run it for a very long time, does any evaluation of
stability or correctness matter?

> > > I guess you are refering to enlightenment when writing
> >
> > Well actually enlightenment is the far worse offender. It actively chooses
> > to
> > crash instead of recover. I had a fight with mike about this when i was
> > left
> > trying to resize a window and every time I did it E crashed. I could never
> > resize it. It literally was unusable by explicit CHOICE to crash instead of
> > log and move on.
> >
> > EFL and E policy has always been to be defensive and recover as much as
> > possible at all times. Just look at the code with all the magic/eoid, null
> > checks and more.
> 
> As a result I received a bug report about this issue and it was resolved,
> unlike the current behavior with other EFL-based apps where they just throw
> errors, nobody reports them, and master continually regresses to function
> worse than the previous release. I'm completely fine with annoying users of
> development builds in order to force them to report bugs. If it becomes
> intolerable for you then you should be running a release build since that's
> what they're for.

And yet when you get annoyed by EFL causing you problems that are not nearly as
bad you claim it's unusable? Where a bug in EFL in unintentional, your decision
to crash is intentional. I'm trying to point out a double standard here. In
fact extra worse.

First a "Well it's so bad I just don't use it anymore and haven't in a long
time" == "I don't want to help or work with EFL development" and in addition:
"But hey - anyone who uses E which I work on has to deal with crashes and
unsalability by design and that's fine, but I will not tolerate it from EFL
where it's unintentional" ?

That's what it comes off as.

Now if efl is "unusable" is entirely debatable. At least 2 people here disagree
with you on that. I use it all day, every day this way and I do not see what
you are complaining about.

> > > "current workflow of write code -> commit directly to master without any
> > > form of testing". I try to test my changes before in enlightenment
> > > before commiting something, but do you really expect a dev that pushes a
> > > commit to start every single window / setting in e ? Test every single
> > > configuration before committing anything ?! Thats not really doable, and
> > > as long as there is no automated testsuite noone will ever start to do
> > > that.
> >
> > Indeed the last bit here is the positive part. If we want to make it
> > harder to
> > break things, having more tests is what we need. Mike - I know you have
> > worked
> > on some e test stuff. If it's ready for people to use, then perhaps a mail
> > about it and docs on how to use it to catch errors would be good.
> > Something not
> > too invasive (can be run in a window for example which I believe it can
> > be... ?
> > ).
> >
> 
> It has been (and continues to be) completely functional in all engines
> since this past March, but I gave up on it within a month or two since
> constant EFL regressions made getting even a baseline set of correct image
> data for tests impossible. I've been quite busy since then and have not had
> the time or interest to revisit the project.

One downside of image comparison is that changes can be made that are not
regressions or bugs. For example fixing the emoji sizing in text to scale
properly if they are color emoji's ... that would change output if previously
color emojis were rendered. It's a bug fix from Youngbok. All image comparison
does is tell you something changed. It MAY be that the change was 

Re: [E-devel] GitFlow

[Mike Blumenkrantz]

On Thu, Oct 26, 2017 at 8:27 PM Carsten Haitzler 
wrote:

> On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:
>
> > Two things,
> >
> > Calling efl-master unmanagable and unrunable is just spreading a
> > apocalyptic mood and does not really tell what is going on. There are
>
> I absolutely agree. I and many others use master all day every day. For
> wayland
> work it has issues and That is specific to that set of code. Sometimes eo
> work
> disrupts something. But it gets fixed.
>
> > bugs and a few crashes, yes, but the same happened a few years back when
> > i started with efl stuff. (Also, how can you call efl master unstable if
> > you havnt run it in a long time ? :D)
>
> Ooooh. nice catch there. :)
>

It is indeed inconceivable that I could have periodically tested master,
found it unusable each time, and then gone back to using stable. You've
certainly caught me; well done everyone, and thanks for your hard work in
keeping this mailing list so honest. Let's wrap it up and call it a /thread.


>
> > I guess you are refering to enlightenment when writing
>
> Well actually enlightenment is the far worse offender. It actively chooses
> to
> crash instead of recover. I had a fight with mike about this when i was
> left
> trying to resize a window and every time I did it E crashed. I could never
> resize it. It literally was unusable by explicit CHOICE to crash instead of
> log and move on.
>
> EFL and E policy has always been to be defensive and recover as much as
> possible at all times. Just look at the code with all the magic/eoid, null
> checks and more.
>

As a result I received a bug report about this issue and it was resolved,
unlike the current behavior with other EFL-based apps where they just throw
errors, nobody reports them, and master continually regresses to function
worse than the previous release. I'm completely fine with annoying users of
development builds in order to force them to report bugs. If it becomes
intolerable for you then you should be running a release build since that's
what they're for.


>
> > "current workflow of write code -> commit directly to master without any
> > form of testing". I try to test my changes before in enlightenment
> > before commiting something, but do you really expect a dev that pushes a
> > commit to start every single window / setting in e ? Test every single
> > configuration before committing anything ?! Thats not really doable, and
> > as long as there is no automated testsuite noone will ever start to do
> > that.
>
> Indeed the last bit here is the positive part. If we want to make it
> harder to
> break things, having more tests is what we need. Mike - I know you have
> worked
> on some e test stuff. If it's ready for people to use, then perhaps a mail
> about it and docs on how to use it to catch errors would be good.
> Something not
> too invasive (can be run in a window for example which I believe it can
> be... ?
> ).
>

It has been (and continues to be) completely functional in all engines
since this past March, but I gave up on it within a month or two since
constant EFL regressions made getting even a baseline set of correct image
data for tests impossible. I've been quite busy since then and have not had
the time or interest to revisit the project.


>
> > Greetings,
> >bu5hm4n
> >
> > On Thu, Oct 26, 2017 at 04:48:24PM +, Mike Blumenkrantz wrote:
> > > I haven't run efl master in a long time, and I know there are others
> who
> > > have stopped running it for the same reasons that I have.
> > >
> > > I am not necessarily advocating changing to gitflow, but several years
> of
> > > the current development methodology has definitely proven that it is
> > > unmanageable and that some change is needed.
> > >
> > > On Thu, Oct 26, 2017 at 12:36 PM Tom Hacohen  wrote:
> > >
> > > > Intended to be would maybe be more appropriate, and then the
> statement
> > > > would still apply. With that being said, I'm sorry to hear that it
> has
> > > > changed, you guys should be spanking b0rokers more, don't let them
> > > > win.
> > > >
> > > > Regardless of that, as said on IRC, the reason why we do trunk
> > > > (master) based development is that we all run master all the time and
> > > > thus test as many configurations as possible all the time. I don't
> see
> > > > why we need a rolling-branch that is more stable (master in the
> > > > gitflow terminology) than the development trunk, because we'll all
> > > > just switch to develop and that's it.
> > > > Andy claims that there are compelling cases. I've read some blog
> posts
> > > > over the years about it, and I'm not convinced.
> > > >
> > > > --
> > > > Tom.
> > > >
> > > >
> > > > On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
> > > >  wrote:
> > > > > 'Our master is already considered "stable" and in a release state,
> so it
> > > > > really doesn't match our workflow.'
> > > > >
> > 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 19:02:58 +0200 marcel-hollerb...@t-online.de said:

> Two things,
> 
> Calling efl-master unmanagable and unrunable is just spreading a
> apocalyptic mood and does not really tell what is going on. There are

I absolutely agree. I and many others use master all day every day. For wayland
work it has issues and That is specific to that set of code. Sometimes eo work
disrupts something. But it gets fixed.

> bugs and a few crashes, yes, but the same happened a few years back when
> i started with efl stuff. (Also, how can you call efl master unstable if
> you havnt run it in a long time ? :D)

Ooooh. nice catch there. :)

> I guess you are refering to enlightenment when writing

Well actually enlightenment is the far worse offender. It actively chooses to
crash instead of recover. I had a fight with mike about this when i was left
trying to resize a window and every time I did it E crashed. I could never
resize it. It literally was unusable by explicit CHOICE to crash instead of
log and move on.

EFL and E policy has always been to be defensive and recover as much as
possible at all times. Just look at the code with all the magic/eoid, null
checks and more.

> "current workflow of write code -> commit directly to master without any 
> form of testing". I try to test my changes before in enlightenment
> before commiting something, but do you really expect a dev that pushes a
> commit to start every single window / setting in e ? Test every single
> configuration before committing anything ?! Thats not really doable, and
> as long as there is no automated testsuite noone will ever start to do
> that.

Indeed the last bit here is the positive part. If we want to make it harder to
break things, having more tests is what we need. Mike - I know you have worked
on some e test stuff. If it's ready for people to use, then perhaps a mail
about it and docs on how to use it to catch errors would be good. Something not
too invasive (can be run in a window for example which I believe it can be... ?
).

> Greetings,
>bu5hm4n
> 
> On Thu, Oct 26, 2017 at 04:48:24PM +, Mike Blumenkrantz wrote:
> > I haven't run efl master in a long time, and I know there are others who
> > have stopped running it for the same reasons that I have.
> > 
> > I am not necessarily advocating changing to gitflow, but several years of
> > the current development methodology has definitely proven that it is
> > unmanageable and that some change is needed.
> > 
> > On Thu, Oct 26, 2017 at 12:36 PM Tom Hacohen  wrote:
> > 
> > > Intended to be would maybe be more appropriate, and then the statement
> > > would still apply. With that being said, I'm sorry to hear that it has
> > > changed, you guys should be spanking b0rokers more, don't let them
> > > win.
> > >
> > > Regardless of that, as said on IRC, the reason why we do trunk
> > > (master) based development is that we all run master all the time and
> > > thus test as many configurations as possible all the time. I don't see
> > > why we need a rolling-branch that is more stable (master in the
> > > gitflow terminology) than the development trunk, because we'll all
> > > just switch to develop and that's it.
> > > Andy claims that there are compelling cases. I've read some blog posts
> > > over the years about it, and I'm not convinced.
> > >
> > > --
> > > Tom.
> > >
> > >
> > > On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
> > >  wrote:
> > > > 'Our master is already considered "stable" and in a release state, so it
> > > > really doesn't match our workflow.'
> > > >
> > > > Things have changed a bit since you've been gone, and this is not even
> > > > remotely close to being true anymore. As far as all of my use cases go
> > > > (everyday use on X, testing on Wayland, basic application
> > > > functionality), master has been completely unusable for this entire
> > > > release cycle. Based
> > > on
> > > > the current workflow of write code -> commit directly to master without
> > > any
> > > > form of testing, it seems like this will continue to be the case for the
> > > > foreseeable future.
> > > >
> > > > I am in no way directing this at you personally, but for us to be basing
> > > > any decision on the above statement is, at this time, nothing more than
> > > > a false premise (https://en.wikipedia.org/wiki/False_premise) argument.
> > > >
> > > > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
> > > >
> > > >> I accidentally hit send, didn't mean to.
> > > >> Here is my full reply:
> > > >> It's possible, yes, but it doesn't address my initial concerns, which
> > > >> are that edi will stick out compared to the other e projects. This
> > > >> will be considered a success by you for sure, and I don't see us
> > > >> changing the efl to follow, so it'll stay different.
> > > >> Furthermore, once you publish a tag/branch they should remain there,
> > > >> so even if we don't like it, it'll 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 13:38:12 +0100 Tom Hacohen  said:

> I accidentally hit send, didn't mean to.
> Here is my full reply:
> It's possible, yes, but it doesn't address my initial concerns, which
> are that edi will stick out compared to the other e projects. This
> will be considered a success by you for sure, and I don't see us
> changing the efl to follow, so it'll stay different.
> Furthermore, once you publish a tag/branch they should remain there,
> so even if we don't like it, it'll have to stay in edi or at least edi
> will be different.
> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> intrusive and painful.
> 
> Additionally, I just took a look at this gitflow thing, and noticed
> that it's pretty much what we do but worse (apart of the poor mistake
> that we did which is having the stable branches be named per repo
> rather than having a consistent name, that is, efl-1.7 instead of
> stable-1.17).

yeah. this is really my only gripe with what we do. stable-xxx or release-xxx
or rel-xxx or ver-xxx would have been just fine and easier to deal with.

> We never needed a "hotfix" branch, the "release" branch has always
> proved sufficient for us (I can see the potential need, we just never
> hit it). After taking a second look, he deletes branches afterwards,
> so it's a workflow we can and already do here.
> Release branches we already have.
> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> I don't see the advantage of having a "develop" branch in addition to
> master given our workflow. Our master is already considered "stable"
> and in a release state, so it really doesn't match our workflow.
> 
> So I'm not really impressed with this suggestion (and in particular
> GitFlow), and I don't think it can be done in a way that is possible
> to revert or is compatible with what we do.
> As I said, if you want to test it, test it with your own dev branches,
> show us that the workflow works and just configure your tools for this
> testing period, I don't see why the test period needs to have the
> formal names.
> 
> You mentioned having tools that work with it, what exactly?
> 
> As a side note, I'm OK with changing the stable release branches to
> "release-x.y" if people are OK with that, instead of the per repo
> naming, this will make it slightly more compatible for you, and
> actually makes sense regardless (was a mistake in the first place).

it'd make for a not so nice history though... releases older than X are a
different naming scheme for the branches, but i guess it's a hiccup we'd have
to live with for such a change.

> --
> Tom
> 
> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> > It is possible, yes.
> >
> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
> > wrote:
> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams 
> >> said:
> >>
> >>> Hi,
> >>>
> >>> You are absolutely right - the “show it with a smaller project and prove
> >>> it’s worth is exactly why I brought it up. I was in the process of doing
> >>> so and hit this roadblock. No intention to beat a dead horse - I actually
> >>> thought I was doing what was agreed.
> >>>
> >>> Apologies if I got the wrong end of the stick.
> >>
> >> Well I think doing this with edi is fine. is it possible to have just edi
> >> have different branch naming schemes? i don't know. if it's not then we
> >> have problems. but i think we;re on the same page atm "try this in a
> >> smaller scale and show it improves things - us that to convince everyone
> >> else". :)
> >>
> >>> Andy
> >>>
> >>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler 
> >>> wrote:
> >>>
> >>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams
> >>> >  said:
> >>> >
> >>> > We had this discussion before in just one place I believe until you
> >>> > asked for
> >>> > specific branch names to be allowed. You wanted us to change how we
> >>> > branch and
> >>> > work with efl/e etc. the last time. I don't remember there being
> >>> > agreement with
> >>> > you on needing a change as I don't see our current model being bad or
> >>> > broken
> >>> > or causing trouble (discussion already had) vs gitflow. I don't know why
> >>> > you're
> >>> > bringing it back up as if there wasn't a consensus already. I believe
> >>> > the last
> >>> > discussion was roughly:
> >>> >
> >>> > "There is no agreement that any change is needed. The change you propose
> >>> > does
> >>> > nothing to actually improve anything by it's proposal. It just shuffles
> >>> > chairs,
> >>> > BUT if you really think it's so much better, try it on smaller projects
> >>> > first
> >>> > and show/prove it to be worth it".
> >>> >
> >>> > Or something to that effect. Most people were just silent on the topic.
> >>> >
> >>> > > Hi list,
> >>> > >
> >>> > > This conversation seems to have now happened in many places and it
> >>> > > seems 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 17:35:39 +0100 Tom Hacohen  said:

> Intended to be would maybe be more appropriate, and then the statement
> would still apply. With that being said, I'm sorry to hear that it has
> changed, you guys should be spanking b0rokers more, don't let them
> win.
> 
> Regardless of that, as said on IRC, the reason why we do trunk
> (master) based development is that we all run master all the time and
> thus test as many configurations as possible all the time. I don't see
> why we need a rolling-branch that is more stable (master in the
> gitflow terminology) than the development trunk, because we'll all
> just switch to develop and that's it.

This was my thought too. we all switch and ADD the work of having to
cherrypick/merge patches from develop (and deal with conflicts and whatever) to
master(stable) AND now almost no developers use master/stable anymore so this
gets little to no testing.

> Andy claims that there are compelling cases. I've read some blog posts
> over the years about it, and I'm not convinced.
> 
> --
> Tom.
> 
> 
> On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
>  wrote:
> > 'Our master is already considered "stable" and in a release state, so it
> > really doesn't match our workflow.'
> >
> > Things have changed a bit since you've been gone, and this is not even
> > remotely close to being true anymore. As far as all of my use cases go
> > (everyday use on X, testing on Wayland, basic application functionality),
> > master has been completely unusable for this entire release cycle. Based on
> > the current workflow of write code -> commit directly to master without any
> > form of testing, it seems like this will continue to be the case for the
> > foreseeable future.
> >
> > I am in no way directing this at you personally, but for us to be basing
> > any decision on the above statement is, at this time, nothing more than a
> > false premise (https://en.wikipedia.org/wiki/False_premise) argument.
> >
> > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
> >
> >> I accidentally hit send, didn't mean to.
> >> Here is my full reply:
> >> It's possible, yes, but it doesn't address my initial concerns, which
> >> are that edi will stick out compared to the other e projects. This
> >> will be considered a success by you for sure, and I don't see us
> >> changing the efl to follow, so it'll stay different.
> >> Furthermore, once you publish a tag/branch they should remain there,
> >> so even if we don't like it, it'll have to stay in edi or at least edi
> >> will be different.
> >> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> >> intrusive and painful.
> >>
> >> Additionally, I just took a look at this gitflow thing, and noticed
> >> that it's pretty much what we do but worse (apart of the poor mistake
> >> that we did which is having the stable branches be named per repo
> >> rather than having a consistent name, that is, efl-1.7 instead of
> >> stable-1.17).
> >> We never needed a "hotfix" branch, the "release" branch has always
> >> proved sufficient for us (I can see the potential need, we just never
> >> hit it). After taking a second look, he deletes branches afterwards,
> >> so it's a workflow we can and already do here.
> >> Release branches we already have.
> >> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> >> I don't see the advantage of having a "develop" branch in addition to
> >> master given our workflow. Our master is already considered "stable"
> >> and in a release state, so it really doesn't match our workflow.
> >>
> >> So I'm not really impressed with this suggestion (and in particular
> >> GitFlow), and I don't think it can be done in a way that is possible
> >> to revert or is compatible with what we do.
> >> As I said, if you want to test it, test it with your own dev branches,
> >> show us that the workflow works and just configure your tools for this
> >> testing period, I don't see why the test period needs to have the
> >> formal names.
> >>
> >> You mentioned having tools that work with it, what exactly?
> >>
> >> As a side note, I'm OK with changing the stable release branches to
> >> "release-x.y" if people are OK with that, instead of the per repo
> >> naming, this will make it slightly more compatible for you, and
> >> actually makes sense regardless (was a mistake in the first place).
> >>
> >> --
> >> Tom
> >>
> >> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> >> > It is possible, yes.
> >> >
> >> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
> >> wrote:
> >> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
> >> a...@andywilliams.me> said:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> You are absolutely right - the “show it with a smaller project and
> >> prove
> >> >>> it’s worth is exactly why I brought it up. I was in the process of
> >> doing so
> >> >>> and hit 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 16:14:14 + Mike Blumenkrantz
 said:

> 'Our master is already considered "stable" and in a release state, so it
> really doesn't match our workflow.'
> 
> Things have changed a bit since you've been gone, and this is not even
> remotely close to being true anymore. As far as all of my use cases go
> (everyday use on X, testing on Wayland, basic application functionality),
> master has been completely unusable for this entire release cycle. Based on
> the current workflow of write code -> commit directly to master without any
> form of testing, it seems like this will continue to be the case for the
> foreseeable future.

i think we have 2 artefacts of our current state:

1. wayland work is still ongoing and in flux. it will settle down eventually
2. eo/interfaces work is very invasive and is going to be creating little
hiccups all over.

when these 2 settle down it'll be back to normal.

the INTENT is for master to be changing and of course have little issues here
and there BUT to be usable day to day. the idea is that you write new code and
test before it goes into master and/or when you do land changes you are around
to fix them ASAP so the instability is very transient.

that's the intent, point and it is actually how svn and cvs worked for over a
decade.

> I am in no way directing this at you personally, but for us to be basing
> any decision on the above statement is, at this time, nothing more than a
> false premise (https://en.wikipedia.org/wiki/False_premise) argument.
> 
> On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
> 
> > I accidentally hit send, didn't mean to.
> > Here is my full reply:
> > It's possible, yes, but it doesn't address my initial concerns, which
> > are that edi will stick out compared to the other e projects. This
> > will be considered a success by you for sure, and I don't see us
> > changing the efl to follow, so it'll stay different.
> > Furthermore, once you publish a tag/branch they should remain there,
> > so even if we don't like it, it'll have to stay in edi or at least edi
> > will be different.
> > Btw, changing HEAD to be "develop" rather than "master" is a bit more
> > intrusive and painful.
> >
> > Additionally, I just took a look at this gitflow thing, and noticed
> > that it's pretty much what we do but worse (apart of the poor mistake
> > that we did which is having the stable branches be named per repo
> > rather than having a consistent name, that is, efl-1.7 instead of
> > stable-1.17).
> > We never needed a "hotfix" branch, the "release" branch has always
> > proved sufficient for us (I can see the potential need, we just never
> > hit it). After taking a second look, he deletes branches afterwards,
> > so it's a workflow we can and already do here.
> > Release branches we already have.
> > We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> > I don't see the advantage of having a "develop" branch in addition to
> > master given our workflow. Our master is already considered "stable"
> > and in a release state, so it really doesn't match our workflow.
> >
> > So I'm not really impressed with this suggestion (and in particular
> > GitFlow), and I don't think it can be done in a way that is possible
> > to revert or is compatible with what we do.
> > As I said, if you want to test it, test it with your own dev branches,
> > show us that the workflow works and just configure your tools for this
> > testing period, I don't see why the test period needs to have the
> > formal names.
> >
> > You mentioned having tools that work with it, what exactly?
> >
> > As a side note, I'm OK with changing the stable release branches to
> > "release-x.y" if people are OK with that, instead of the per repo
> > naming, this will make it slightly more compatible for you, and
> > actually makes sense regardless (was a mistake in the first place).
> >
> > --
> > Tom
> >
> > On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> > > It is possible, yes.
> > >
> > > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
> > wrote:
> > >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
> > a...@andywilliams.me> said:
> > >>
> > >>> Hi,
> > >>>
> > >>> You are absolutely right - the “show it with a smaller project and
> > prove
> > >>> it’s worth is exactly why I brought it up. I was in the process of
> > doing so
> > >>> and hit this roadblock. No intention to beat a dead horse - I actually
> > >>> thought I was doing what was agreed.
> > >>>
> > >>> Apologies if I got the wrong end of the stick.
> > >>
> > >> Well I think doing this with edi is fine. is it possible to have just
> > edi have
> > >> different branch naming schemes? i don't know. if it's not then we have
> > >> problems. but i think we;re on the same page atm "try this in a smaller
> > scale
> > >> and show it improves things - us that to convince everyone else". :)
> > >>
> > >>> 

Re: [E-devel] GitFlow

[marcel-hollerbach]

Two things,

Calling efl-master unmanagable and unrunable is just spreading a
apocalyptic mood and does not really tell what is going on. There are
bugs and a few crashes, yes, but the same happened a few years back when
i started with efl stuff. (Also, how can you call efl master unstable if
you havnt run it in a long time ? :D)

I guess you are refering to enlightenment when writing
"current workflow of write code -> commit directly to master without any 
form of testing". I try to test my changes before in enlightenment
before commiting something, but do you really expect a dev that pushes a
commit to start every single window / setting in e ? Test every single
configuration before committing anything ?! Thats not really doable, and
as long as there is no automated testsuite noone will ever start to do
that.

Greetings,
   bu5hm4n

On Thu, Oct 26, 2017 at 04:48:24PM +, Mike Blumenkrantz wrote:
> I haven't run efl master in a long time, and I know there are others who
> have stopped running it for the same reasons that I have.
> 
> I am not necessarily advocating changing to gitflow, but several years of
> the current development methodology has definitely proven that it is
> unmanageable and that some change is needed.
> 
> On Thu, Oct 26, 2017 at 12:36 PM Tom Hacohen  wrote:
> 
> > Intended to be would maybe be more appropriate, and then the statement
> > would still apply. With that being said, I'm sorry to hear that it has
> > changed, you guys should be spanking b0rokers more, don't let them
> > win.
> >
> > Regardless of that, as said on IRC, the reason why we do trunk
> > (master) based development is that we all run master all the time and
> > thus test as many configurations as possible all the time. I don't see
> > why we need a rolling-branch that is more stable (master in the
> > gitflow terminology) than the development trunk, because we'll all
> > just switch to develop and that's it.
> > Andy claims that there are compelling cases. I've read some blog posts
> > over the years about it, and I'm not convinced.
> >
> > --
> > Tom.
> >
> >
> > On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
> >  wrote:
> > > 'Our master is already considered "stable" and in a release state, so it
> > > really doesn't match our workflow.'
> > >
> > > Things have changed a bit since you've been gone, and this is not even
> > > remotely close to being true anymore. As far as all of my use cases go
> > > (everyday use on X, testing on Wayland, basic application functionality),
> > > master has been completely unusable for this entire release cycle. Based
> > on
> > > the current workflow of write code -> commit directly to master without
> > any
> > > form of testing, it seems like this will continue to be the case for the
> > > foreseeable future.
> > >
> > > I am in no way directing this at you personally, but for us to be basing
> > > any decision on the above statement is, at this time, nothing more than a
> > > false premise (https://en.wikipedia.org/wiki/False_premise) argument.
> > >
> > > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
> > >
> > >> I accidentally hit send, didn't mean to.
> > >> Here is my full reply:
> > >> It's possible, yes, but it doesn't address my initial concerns, which
> > >> are that edi will stick out compared to the other e projects. This
> > >> will be considered a success by you for sure, and I don't see us
> > >> changing the efl to follow, so it'll stay different.
> > >> Furthermore, once you publish a tag/branch they should remain there,
> > >> so even if we don't like it, it'll have to stay in edi or at least edi
> > >> will be different.
> > >> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> > >> intrusive and painful.
> > >>
> > >> Additionally, I just took a look at this gitflow thing, and noticed
> > >> that it's pretty much what we do but worse (apart of the poor mistake
> > >> that we did which is having the stable branches be named per repo
> > >> rather than having a consistent name, that is, efl-1.7 instead of
> > >> stable-1.17).
> > >> We never needed a "hotfix" branch, the "release" branch has always
> > >> proved sufficient for us (I can see the potential need, we just never
> > >> hit it). After taking a second look, he deletes branches afterwards,
> > >> so it's a workflow we can and already do here.
> > >> Release branches we already have.
> > >> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> > >> I don't see the advantage of having a "develop" branch in addition to
> > >> master given our workflow. Our master is already considered "stable"
> > >> and in a release state, so it really doesn't match our workflow.
> > >>
> > >> So I'm not really impressed with this suggestion (and in particular
> > >> GitFlow), and I don't think it can be done in a way that is possible
> > >> to revert or is compatible with what we do.
> > >> As I said, 

Re: [E-devel] GitFlow

[Mike Blumenkrantz]

I haven't run efl master in a long time, and I know there are others who
have stopped running it for the same reasons that I have.

I am not necessarily advocating changing to gitflow, but several years of
the current development methodology has definitely proven that it is
unmanageable and that some change is needed.

On Thu, Oct 26, 2017 at 12:36 PM Tom Hacohen  wrote:

> Intended to be would maybe be more appropriate, and then the statement
> would still apply. With that being said, I'm sorry to hear that it has
> changed, you guys should be spanking b0rokers more, don't let them
> win.
>
> Regardless of that, as said on IRC, the reason why we do trunk
> (master) based development is that we all run master all the time and
> thus test as many configurations as possible all the time. I don't see
> why we need a rolling-branch that is more stable (master in the
> gitflow terminology) than the development trunk, because we'll all
> just switch to develop and that's it.
> Andy claims that there are compelling cases. I've read some blog posts
> over the years about it, and I'm not convinced.
>
> --
> Tom.
>
>
> On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
>  wrote:
> > 'Our master is already considered "stable" and in a release state, so it
> > really doesn't match our workflow.'
> >
> > Things have changed a bit since you've been gone, and this is not even
> > remotely close to being true anymore. As far as all of my use cases go
> > (everyday use on X, testing on Wayland, basic application functionality),
> > master has been completely unusable for this entire release cycle. Based
> on
> > the current workflow of write code -> commit directly to master without
> any
> > form of testing, it seems like this will continue to be the case for the
> > foreseeable future.
> >
> > I am in no way directing this at you personally, but for us to be basing
> > any decision on the above statement is, at this time, nothing more than a
> > false premise (https://en.wikipedia.org/wiki/False_premise) argument.
> >
> > On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
> >
> >> I accidentally hit send, didn't mean to.
> >> Here is my full reply:
> >> It's possible, yes, but it doesn't address my initial concerns, which
> >> are that edi will stick out compared to the other e projects. This
> >> will be considered a success by you for sure, and I don't see us
> >> changing the efl to follow, so it'll stay different.
> >> Furthermore, once you publish a tag/branch they should remain there,
> >> so even if we don't like it, it'll have to stay in edi or at least edi
> >> will be different.
> >> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> >> intrusive and painful.
> >>
> >> Additionally, I just took a look at this gitflow thing, and noticed
> >> that it's pretty much what we do but worse (apart of the poor mistake
> >> that we did which is having the stable branches be named per repo
> >> rather than having a consistent name, that is, efl-1.7 instead of
> >> stable-1.17).
> >> We never needed a "hotfix" branch, the "release" branch has always
> >> proved sufficient for us (I can see the potential need, we just never
> >> hit it). After taking a second look, he deletes branches afterwards,
> >> so it's a workflow we can and already do here.
> >> Release branches we already have.
> >> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> >> I don't see the advantage of having a "develop" branch in addition to
> >> master given our workflow. Our master is already considered "stable"
> >> and in a release state, so it really doesn't match our workflow.
> >>
> >> So I'm not really impressed with this suggestion (and in particular
> >> GitFlow), and I don't think it can be done in a way that is possible
> >> to revert or is compatible with what we do.
> >> As I said, if you want to test it, test it with your own dev branches,
> >> show us that the workflow works and just configure your tools for this
> >> testing period, I don't see why the test period needs to have the
> >> formal names.
> >>
> >> You mentioned having tools that work with it, what exactly?
> >>
> >> As a side note, I'm OK with changing the stable release branches to
> >> "release-x.y" if people are OK with that, instead of the per repo
> >> naming, this will make it slightly more compatible for you, and
> >> actually makes sense regardless (was a mistake in the first place).
> >>
> >> --
> >> Tom
> >>
> >> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> >> > It is possible, yes.
> >> >
> >> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler <
> ras...@rasterman.com>
> >> wrote:
> >> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
> >> a...@andywilliams.me> said:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> You are absolutely right - the “show it with a smaller project and
> >> prove
> >> >>> it’s worth is exactly why I 

Re: [E-devel] GitFlow

[Tom Hacohen]

Intended to be would maybe be more appropriate, and then the statement
would still apply. With that being said, I'm sorry to hear that it has
changed, you guys should be spanking b0rokers more, don't let them
win.

Regardless of that, as said on IRC, the reason why we do trunk
(master) based development is that we all run master all the time and
thus test as many configurations as possible all the time. I don't see
why we need a rolling-branch that is more stable (master in the
gitflow terminology) than the development trunk, because we'll all
just switch to develop and that's it.
Andy claims that there are compelling cases. I've read some blog posts
over the years about it, and I'm not convinced.

--
Tom.


On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
 wrote:
> 'Our master is already considered "stable" and in a release state, so it
> really doesn't match our workflow.'
>
> Things have changed a bit since you've been gone, and this is not even
> remotely close to being true anymore. As far as all of my use cases go
> (everyday use on X, testing on Wayland, basic application functionality),
> master has been completely unusable for this entire release cycle. Based on
> the current workflow of write code -> commit directly to master without any
> form of testing, it seems like this will continue to be the case for the
> foreseeable future.
>
> I am in no way directing this at you personally, but for us to be basing
> any decision on the above statement is, at this time, nothing more than a
> false premise (https://en.wikipedia.org/wiki/False_premise) argument.
>
> On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:
>
>> I accidentally hit send, didn't mean to.
>> Here is my full reply:
>> It's possible, yes, but it doesn't address my initial concerns, which
>> are that edi will stick out compared to the other e projects. This
>> will be considered a success by you for sure, and I don't see us
>> changing the efl to follow, so it'll stay different.
>> Furthermore, once you publish a tag/branch they should remain there,
>> so even if we don't like it, it'll have to stay in edi or at least edi
>> will be different.
>> Btw, changing HEAD to be "develop" rather than "master" is a bit more
>> intrusive and painful.
>>
>> Additionally, I just took a look at this gitflow thing, and noticed
>> that it's pretty much what we do but worse (apart of the poor mistake
>> that we did which is having the stable branches be named per repo
>> rather than having a consistent name, that is, efl-1.7 instead of
>> stable-1.17).
>> We never needed a "hotfix" branch, the "release" branch has always
>> proved sufficient for us (I can see the potential need, we just never
>> hit it). After taking a second look, he deletes branches afterwards,
>> so it's a workflow we can and already do here.
>> Release branches we already have.
>> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
>> I don't see the advantage of having a "develop" branch in addition to
>> master given our workflow. Our master is already considered "stable"
>> and in a release state, so it really doesn't match our workflow.
>>
>> So I'm not really impressed with this suggestion (and in particular
>> GitFlow), and I don't think it can be done in a way that is possible
>> to revert or is compatible with what we do.
>> As I said, if you want to test it, test it with your own dev branches,
>> show us that the workflow works and just configure your tools for this
>> testing period, I don't see why the test period needs to have the
>> formal names.
>>
>> You mentioned having tools that work with it, what exactly?
>>
>> As a side note, I'm OK with changing the stable release branches to
>> "release-x.y" if people are OK with that, instead of the per repo
>> naming, this will make it slightly more compatible for you, and
>> actually makes sense regardless (was a mistake in the first place).
>>
>> --
>> Tom
>>
>> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
>> > It is possible, yes.
>> >
>> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
>> wrote:
>> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
>> a...@andywilliams.me> said:
>> >>
>> >>> Hi,
>> >>>
>> >>> You are absolutely right - the “show it with a smaller project and
>> prove
>> >>> it’s worth is exactly why I brought it up. I was in the process of
>> doing so
>> >>> and hit this roadblock. No intention to beat a dead horse - I actually
>> >>> thought I was doing what was agreed.
>> >>>
>> >>> Apologies if I got the wrong end of the stick.
>> >>
>> >> Well I think doing this with edi is fine. is it possible to have just
>> edi have
>> >> different branch naming schemes? i don't know. if it's not then we have
>> >> problems. but i think we;re on the same page atm "try this in a smaller
>> scale
>> >> and show it improves things - us that to convince everyone else". :)
>> >>
>> >>> Andy
>> 

Re: [E-devel] GitFlow

[Mike Blumenkrantz]

'Our master is already considered "stable" and in a release state, so it
really doesn't match our workflow.'

Things have changed a bit since you've been gone, and this is not even
remotely close to being true anymore. As far as all of my use cases go
(everyday use on X, testing on Wayland, basic application functionality),
master has been completely unusable for this entire release cycle. Based on
the current workflow of write code -> commit directly to master without any
form of testing, it seems like this will continue to be the case for the
foreseeable future.

I am in no way directing this at you personally, but for us to be basing
any decision on the above statement is, at this time, nothing more than a
false premise (https://en.wikipedia.org/wiki/False_premise) argument.

On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen  wrote:

> I accidentally hit send, didn't mean to.
> Here is my full reply:
> It's possible, yes, but it doesn't address my initial concerns, which
> are that edi will stick out compared to the other e projects. This
> will be considered a success by you for sure, and I don't see us
> changing the efl to follow, so it'll stay different.
> Furthermore, once you publish a tag/branch they should remain there,
> so even if we don't like it, it'll have to stay in edi or at least edi
> will be different.
> Btw, changing HEAD to be "develop" rather than "master" is a bit more
> intrusive and painful.
>
> Additionally, I just took a look at this gitflow thing, and noticed
> that it's pretty much what we do but worse (apart of the poor mistake
> that we did which is having the stable branches be named per repo
> rather than having a consistent name, that is, efl-1.7 instead of
> stable-1.17).
> We never needed a "hotfix" branch, the "release" branch has always
> proved sufficient for us (I can see the potential need, we just never
> hit it). After taking a second look, he deletes branches afterwards,
> so it's a workflow we can and already do here.
> Release branches we already have.
> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
> I don't see the advantage of having a "develop" branch in addition to
> master given our workflow. Our master is already considered "stable"
> and in a release state, so it really doesn't match our workflow.
>
> So I'm not really impressed with this suggestion (and in particular
> GitFlow), and I don't think it can be done in a way that is possible
> to revert or is compatible with what we do.
> As I said, if you want to test it, test it with your own dev branches,
> show us that the workflow works and just configure your tools for this
> testing period, I don't see why the test period needs to have the
> formal names.
>
> You mentioned having tools that work with it, what exactly?
>
> As a side note, I'm OK with changing the stable release branches to
> "release-x.y" if people are OK with that, instead of the per repo
> naming, this will make it slightly more compatible for you, and
> actually makes sense regardless (was a mistake in the first place).
>
> --
> Tom
>
> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> > It is possible, yes.
> >
> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler 
> wrote:
> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
> a...@andywilliams.me> said:
> >>
> >>> Hi,
> >>>
> >>> You are absolutely right - the “show it with a smaller project and
> prove
> >>> it’s worth is exactly why I brought it up. I was in the process of
> doing so
> >>> and hit this roadblock. No intention to beat a dead horse - I actually
> >>> thought I was doing what was agreed.
> >>>
> >>> Apologies if I got the wrong end of the stick.
> >>
> >> Well I think doing this with edi is fine. is it possible to have just
> edi have
> >> different branch naming schemes? i don't know. if it's not then we have
> >> problems. but i think we;re on the same page atm "try this in a smaller
> scale
> >> and show it improves things - us that to convince everyone else". :)
> >>
> >>> Andy
> >>>
> >>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler 
> wrote:
> >>>
> >>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams <
> a...@andywilliams.me>
> >>> > said:
> >>> >
> >>> > We had this discussion before in just one place I believe until you
> asked
> >>> > for
> >>> > specific branch names to be allowed. You wanted us to change how we
> branch
> >>> > and
> >>> > work with efl/e etc. the last time. I don't remember there being
> agreement
> >>> > with
> >>> > you on needing a change as I don't see our current model being bad or
> >>> > broken
> >>> > or causing trouble (discussion already had) vs gitflow. I don't know
> why
> >>> > you're
> >>> > bringing it back up as if there wasn't a consensus already. I
> believe the
> >>> > last
> >>> > discussion was roughly:
> >>> >
> >>> > "There is no agreement that any change is needed. The change you
> propose
> >>> > 

Re: [E-devel] GitFlow

[Tom Hacohen]

I accidentally hit send, didn't mean to.
Here is my full reply:
It's possible, yes, but it doesn't address my initial concerns, which
are that edi will stick out compared to the other e projects. This
will be considered a success by you for sure, and I don't see us
changing the efl to follow, so it'll stay different.
Furthermore, once you publish a tag/branch they should remain there,
so even if we don't like it, it'll have to stay in edi or at least edi
will be different.
Btw, changing HEAD to be "develop" rather than "master" is a bit more
intrusive and painful.

Additionally, I just took a look at this gitflow thing, and noticed
that it's pretty much what we do but worse (apart of the poor mistake
that we did which is having the stable branches be named per repo
rather than having a consistent name, that is, efl-1.7 instead of
stable-1.17).
We never needed a "hotfix" branch, the "release" branch has always
proved sufficient for us (I can see the potential need, we just never
hit it). After taking a second look, he deletes branches afterwards,
so it's a workflow we can and already do here.
Release branches we already have.
We name our tags v1.17.0 compared to 1.17.0 which I think is better.
I don't see the advantage of having a "develop" branch in addition to
master given our workflow. Our master is already considered "stable"
and in a release state, so it really doesn't match our workflow.

So I'm not really impressed with this suggestion (and in particular
GitFlow), and I don't think it can be done in a way that is possible
to revert or is compatible with what we do.
As I said, if you want to test it, test it with your own dev branches,
show us that the workflow works and just configure your tools for this
testing period, I don't see why the test period needs to have the
formal names.

You mentioned having tools that work with it, what exactly?

As a side note, I'm OK with changing the stable release branches to
"release-x.y" if people are OK with that, instead of the per repo
naming, this will make it slightly more compatible for you, and
actually makes sense regardless (was a mistake in the first place).

--
Tom

On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen  wrote:
> It is possible, yes.
>
> On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler  
> wrote:
>> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams  
>> said:
>>
>>> Hi,
>>>
>>> You are absolutely right - the “show it with a smaller project and prove
>>> it’s worth is exactly why I brought it up. I was in the process of doing so
>>> and hit this roadblock. No intention to beat a dead horse - I actually
>>> thought I was doing what was agreed.
>>>
>>> Apologies if I got the wrong end of the stick.
>>
>> Well I think doing this with edi is fine. is it possible to have just edi 
>> have
>> different branch naming schemes? i don't know. if it's not then we have
>> problems. but i think we;re on the same page atm "try this in a smaller scale
>> and show it improves things - us that to convince everyone else". :)
>>
>>> Andy
>>>
>>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler  wrote:
>>>
>>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
>>> > said:
>>> >
>>> > We had this discussion before in just one place I believe until you asked
>>> > for
>>> > specific branch names to be allowed. You wanted us to change how we branch
>>> > and
>>> > work with efl/e etc. the last time. I don't remember there being agreement
>>> > with
>>> > you on needing a change as I don't see our current model being bad or
>>> > broken
>>> > or causing trouble (discussion already had) vs gitflow. I don't know why
>>> > you're
>>> > bringing it back up as if there wasn't a consensus already. I believe the
>>> > last
>>> > discussion was roughly:
>>> >
>>> > "There is no agreement that any change is needed. The change you propose
>>> > does
>>> > nothing to actually improve anything by it's proposal. It just shuffles
>>> > chairs,
>>> > BUT if you really think it's so much better, try it on smaller projects
>>> > first
>>> > and show/prove it to be worth it".
>>> >
>>> > Or something to that effect. Most people were just silent on the topic.
>>> >
>>> > > Hi list,
>>> > >
>>> > > This conversation seems to have now happened in many places and it seems
>>> > > that a few key individuals don't really see why we should be looking at
>>> > > different branching models. I understand that opinion but if we don't 
>>> > > try
>>> > > new things then we will never be able to engage with new process or
>>> > > technologies so I am keen to try gitflow nonetheless.
>>> > >
>>> > > So at this point I would like this thread to record a definitive
>>> > decision.
>>> > > Will we allow reduced branch name restrictions on our git repositories 
>>> > > or
>>> > > not?
>>> > > Thanks,
>>> > > Andy
>>> > >
>>> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 

Re: [E-devel] GitFlow

[Tom Hacohen]

It is possible, yes.

On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler  wrote:
> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams  
> said:
>
>> Hi,
>>
>> You are absolutely right - the “show it with a smaller project and prove
>> it’s worth is exactly why I brought it up. I was in the process of doing so
>> and hit this roadblock. No intention to beat a dead horse - I actually
>> thought I was doing what was agreed.
>>
>> Apologies if I got the wrong end of the stick.
>
> Well I think doing this with edi is fine. is it possible to have just edi have
> different branch naming schemes? i don't know. if it's not then we have
> problems. but i think we;re on the same page atm "try this in a smaller scale
> and show it improves things - us that to convince everyone else". :)
>
>> Andy
>>
>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler  wrote:
>>
>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
>> > said:
>> >
>> > We had this discussion before in just one place I believe until you asked
>> > for
>> > specific branch names to be allowed. You wanted us to change how we branch
>> > and
>> > work with efl/e etc. the last time. I don't remember there being agreement
>> > with
>> > you on needing a change as I don't see our current model being bad or
>> > broken
>> > or causing trouble (discussion already had) vs gitflow. I don't know why
>> > you're
>> > bringing it back up as if there wasn't a consensus already. I believe the
>> > last
>> > discussion was roughly:
>> >
>> > "There is no agreement that any change is needed. The change you propose
>> > does
>> > nothing to actually improve anything by it's proposal. It just shuffles
>> > chairs,
>> > BUT if you really think it's so much better, try it on smaller projects
>> > first
>> > and show/prove it to be worth it".
>> >
>> > Or something to that effect. Most people were just silent on the topic.
>> >
>> > > Hi list,
>> > >
>> > > This conversation seems to have now happened in many places and it seems
>> > > that a few key individuals don't really see why we should be looking at
>> > > different branching models. I understand that opinion but if we don't try
>> > > new things then we will never be able to engage with new process or
>> > > technologies so I am keen to try gitflow nonetheless.
>> > >
>> > > So at this point I would like this thread to record a definitive
>> > decision.
>> > > Will we allow reduced branch name restrictions on our git repositories or
>> > > not?
>> > > Thanks,
>> > > Andy
>> > >
>> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
>> > wrote:
>> > >
>> > > > Hi TAsn,
>> > > >
>> > > > Thanks for the reply. In gitflow these are the standards and they need
>> > to
>> > > > work across different users hence why having the developer namespace
>> > is not
>> > > > quite enough. Additionally the hotfix is not catered for in our current
>> > > > scheme (as I understand it).
>> > > > One nice thing with gitflow is the plugin that manages all the branches
>> > > > for you. If you have custom schemes then every person looking to take
>> > up
>> > > > development has to configure it before getting started, so the
>> > defaults are
>> > > > best if possible.
>> > > >
>> > > > I appreciate that consistency is important but taken so stringently it
>> > > > means we can never try anything new... An earlier discussion on
>> > GitFlow led
>> > > > to raster saying that he would need to see it working to understand the
>> > > > value - so I would like to do just that.
>> > > >
>> > > > I understand that folk don't necessarily see the value, but I have done
>> > > > and would like to try it for the projects that I am managing. That
>> > > > shouldn't be too onerous I think? Also as apps move from autotools to
>> > meson
>> > > > we already have a reduced consistency between projects.
>> > > >
>> > > > Thanks,
>> > > > Andy
>> > > >
>> > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
>> > > >
>> > > >> Heya,
>> > > >>
>> > > >> I don't quite understand what you are trying to do here. I mean, I
>> > > >> understand you are trying to have these, but what are these branches
>> > > >> for? If it's for you developing your own features why not put it in a
>> > > >> dev branch?
>> > > >>
>> > > >> We have these enforcements because we want to enforce branch names to
>> > > >> follow a consistent pattern across the repos. I don't mind changing it
>> > > >> per se,
>> > > >> though:
>> > > >> 1. I don't really see an obvious value with gitflow.
>> > > >> 2. I'd prefer if it was consistent across repos.
>> > > >>
>> > > >> Maybe people don't agree with this, but my take towards the e repos is
>> > > >> similar to that
>> > > >> of the GNU project. Have everything follow similar guidelines and be
>> > > >> mostly similar,
>> > > >> making it easier for devs to jump across projects. Yes, that
>> > > >> consistency 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 07:19:51 + Andrew Williams  said:

> Hi,
> 
> You are absolutely right - the “show it with a smaller project and prove
> it’s worth is exactly why I brought it up. I was in the process of doing so
> and hit this roadblock. No intention to beat a dead horse - I actually
> thought I was doing what was agreed.
>
> Apologies if I got the wrong end of the stick.

Well I think doing this with edi is fine. is it possible to have just edi have
different branch naming schemes? i don't know. if it's not then we have
problems. but i think we;re on the same page atm "try this in a smaller scale
and show it improves things - us that to convince everyone else". :)

> Andy
> 
> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler  wrote:
> 
> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
> > said:
> >
> > We had this discussion before in just one place I believe until you asked
> > for
> > specific branch names to be allowed. You wanted us to change how we branch
> > and
> > work with efl/e etc. the last time. I don't remember there being agreement
> > with
> > you on needing a change as I don't see our current model being bad or
> > broken
> > or causing trouble (discussion already had) vs gitflow. I don't know why
> > you're
> > bringing it back up as if there wasn't a consensus already. I believe the
> > last
> > discussion was roughly:
> >
> > "There is no agreement that any change is needed. The change you propose
> > does
> > nothing to actually improve anything by it's proposal. It just shuffles
> > chairs,
> > BUT if you really think it's so much better, try it on smaller projects
> > first
> > and show/prove it to be worth it".
> >
> > Or something to that effect. Most people were just silent on the topic.
> >
> > > Hi list,
> > >
> > > This conversation seems to have now happened in many places and it seems
> > > that a few key individuals don't really see why we should be looking at
> > > different branching models. I understand that opinion but if we don't try
> > > new things then we will never be able to engage with new process or
> > > technologies so I am keen to try gitflow nonetheless.
> > >
> > > So at this point I would like this thread to record a definitive
> > decision.
> > > Will we allow reduced branch name restrictions on our git repositories or
> > > not?
> > > Thanks,
> > > Andy
> > >
> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
> > wrote:
> > >
> > > > Hi TAsn,
> > > >
> > > > Thanks for the reply. In gitflow these are the standards and they need
> > to
> > > > work across different users hence why having the developer namespace
> > is not
> > > > quite enough. Additionally the hotfix is not catered for in our current
> > > > scheme (as I understand it).
> > > > One nice thing with gitflow is the plugin that manages all the branches
> > > > for you. If you have custom schemes then every person looking to take
> > up
> > > > development has to configure it before getting started, so the
> > defaults are
> > > > best if possible.
> > > >
> > > > I appreciate that consistency is important but taken so stringently it
> > > > means we can never try anything new... An earlier discussion on
> > GitFlow led
> > > > to raster saying that he would need to see it working to understand the
> > > > value - so I would like to do just that.
> > > >
> > > > I understand that folk don't necessarily see the value, but I have done
> > > > and would like to try it for the projects that I am managing. That
> > > > shouldn't be too onerous I think? Also as apps move from autotools to
> > meson
> > > > we already have a reduced consistency between projects.
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> > > >
> > > >> Heya,
> > > >>
> > > >> I don't quite understand what you are trying to do here. I mean, I
> > > >> understand you are trying to have these, but what are these branches
> > > >> for? If it's for you developing your own features why not put it in a
> > > >> dev branch?
> > > >>
> > > >> We have these enforcements because we want to enforce branch names to
> > > >> follow a consistent pattern across the repos. I don't mind changing it
> > > >> per se,
> > > >> though:
> > > >> 1. I don't really see an obvious value with gitflow.
> > > >> 2. I'd prefer if it was consistent across repos.
> > > >>
> > > >> Maybe people don't agree with this, but my take towards the e repos is
> > > >> similar to that
> > > >> of the GNU project. Have everything follow similar guidelines and be
> > > >> mostly similar,
> > > >> making it easier for devs to jump across projects. Yes, that
> > > >> consistency sometimes
> > > >> comes with a price, but I think that it's worth it.
> > > >>
> > > >> Looking forward to hearing what other people think.
> > > >>
> > > >> --
> > > >> Tom.
> > > >>
> > > >> On Sat, Oct 21, 2017 at 4:18 PM, 

Re: [E-devel] GitFlow

[Andrew Williams]

Hi,

You are absolutely right - the “show it with a smaller project and prove
it’s worth is exactly why I brought it up. I was in the process of doing so
and hit this roadblock. No intention to beat a dead horse - I actually
thought I was doing what was agreed.

Apologies if I got the wrong end of the stick.

Andy

On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler  wrote:

> On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
> said:
>
> We had this discussion before in just one place I believe until you asked
> for
> specific branch names to be allowed. You wanted us to change how we branch
> and
> work with efl/e etc. the last time. I don't remember there being agreement
> with
> you on needing a change as I don't see our current model being bad or
> broken
> or causing trouble (discussion already had) vs gitflow. I don't know why
> you're
> bringing it back up as if there wasn't a consensus already. I believe the
> last
> discussion was roughly:
>
> "There is no agreement that any change is needed. The change you propose
> does
> nothing to actually improve anything by it's proposal. It just shuffles
> chairs,
> BUT if you really think it's so much better, try it on smaller projects
> first
> and show/prove it to be worth it".
>
> Or something to that effect. Most people were just silent on the topic.
>
> > Hi list,
> >
> > This conversation seems to have now happened in many places and it seems
> > that a few key individuals don't really see why we should be looking at
> > different branching models. I understand that opinion but if we don't try
> > new things then we will never be able to engage with new process or
> > technologies so I am keen to try gitflow nonetheless.
> >
> > So at this point I would like this thread to record a definitive
> decision.
> > Will we allow reduced branch name restrictions on our git repositories or
> > not?
> > Thanks,
> > Andy
> >
> > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
> wrote:
> >
> > > Hi TAsn,
> > >
> > > Thanks for the reply. In gitflow these are the standards and they need
> to
> > > work across different users hence why having the developer namespace
> is not
> > > quite enough. Additionally the hotfix is not catered for in our current
> > > scheme (as I understand it).
> > > One nice thing with gitflow is the plugin that manages all the branches
> > > for you. If you have custom schemes then every person looking to take
> up
> > > development has to configure it before getting started, so the
> defaults are
> > > best if possible.
> > >
> > > I appreciate that consistency is important but taken so stringently it
> > > means we can never try anything new... An earlier discussion on
> GitFlow led
> > > to raster saying that he would need to see it working to understand the
> > > value - so I would like to do just that.
> > >
> > > I understand that folk don't necessarily see the value, but I have done
> > > and would like to try it for the projects that I am managing. That
> > > shouldn't be too onerous I think? Also as apps move from autotools to
> meson
> > > we already have a reduced consistency between projects.
> > >
> > > Thanks,
> > > Andy
> > >
> > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> > >
> > >> Heya,
> > >>
> > >> I don't quite understand what you are trying to do here. I mean, I
> > >> understand you are trying to have these, but what are these branches
> > >> for? If it's for you developing your own features why not put it in a
> > >> dev branch?
> > >>
> > >> We have these enforcements because we want to enforce branch names to
> > >> follow a consistent pattern across the repos. I don't mind changing it
> > >> per se,
> > >> though:
> > >> 1. I don't really see an obvious value with gitflow.
> > >> 2. I'd prefer if it was consistent across repos.
> > >>
> > >> Maybe people don't agree with this, but my take towards the e repos is
> > >> similar to that
> > >> of the GNU project. Have everything follow similar guidelines and be
> > >> mostly similar,
> > >> making it easier for devs to jump across projects. Yes, that
> > >> consistency sometimes
> > >> comes with a price, but I think that it's worth it.
> > >>
> > >> Looking forward to hearing what other people think.
> > >>
> > >> --
> > >> Tom.
> > >>
> > >> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams <
> a...@andywilliams.me>
> > >> wrote:
> > >> > Hi git admins,
> > >> >
> > >> > I'm setting up gitflow on Edi but I can't push to origin because of
> the
> > >> > branch naming rules. Can you please open up the ability to have
> remote
> > >> > branches matching the patterns "develop", "feature/*", "bugfix/*",
> > >> > "release/*", "hotfix/*" and "support/*"?
> > >> >
> > >> > I'd really appreciate it thanks.
> > >> > Oh and to those who worried about "changing to develop branch is an
> > >> extra
> > >> > step" don't fear as HEAD can be pointed to develop instead of
> master if
> > >> > 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Thu, 26 Oct 2017 12:25:12 +0900 Jean-Philippe André  said:

> I fail to see why we wouldn't allow Andy & Co to test out this workflow on
> EDI and use this as an experience?
> Is it impossible to allow those branch names only on EDI's repo?

I think I covered that with:

"BUT if you really think it's so much better, try it on smaller projects first
and show/prove it to be worth it".

The general decision is to not change at this point ... except for the above
from my recollection of the prior threads. So I thought it was clear already.

> 2017-10-26 8:35 GMT+09:00 Carsten Haitzler :
> 
> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
> > said:
> >
> > We had this discussion before in just one place I believe until you asked
> > for
> > specific branch names to be allowed. You wanted us to change how we branch
> > and
> > work with efl/e etc. the last time. I don't remember there being agreement
> > with
> > you on needing a change as I don't see our current model being bad or
> > broken
> > or causing trouble (discussion already had) vs gitflow. I don't know why
> > you're
> > bringing it back up as if there wasn't a consensus already. I believe the
> > last
> > discussion was roughly:
> >
> > "There is no agreement that any change is needed. The change you propose
> > does
> > nothing to actually improve anything by it's proposal. It just shuffles
> > chairs,
> > BUT if you really think it's so much better, try it on smaller projects
> > first
> > and show/prove it to be worth it".
> >
> > Or something to that effect. Most people were just silent on the topic.
> >
> > > Hi list,
> > >
> > > This conversation seems to have now happened in many places and it seems
> > > that a few key individuals don't really see why we should be looking at
> > > different branching models. I understand that opinion but if we don't try
> > > new things then we will never be able to engage with new process or
> > > technologies so I am keen to try gitflow nonetheless.
> > >
> > > So at this point I would like this thread to record a definitive
> > decision.
> > > Will we allow reduced branch name restrictions on our git repositories or
> > > not?
> > > Thanks,
> > > Andy
> > >
> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
> > wrote:
> > >
> > > > Hi TAsn,
> > > >
> > > > Thanks for the reply. In gitflow these are the standards and they need
> > to
> > > > work across different users hence why having the developer namespace
> > is not
> > > > quite enough. Additionally the hotfix is not catered for in our current
> > > > scheme (as I understand it).
> > > > One nice thing with gitflow is the plugin that manages all the branches
> > > > for you. If you have custom schemes then every person looking to take
> > up
> > > > development has to configure it before getting started, so the
> > defaults are
> > > > best if possible.
> > > >
> > > > I appreciate that consistency is important but taken so stringently it
> > > > means we can never try anything new... An earlier discussion on
> > GitFlow led
> > > > to raster saying that he would need to see it working to understand the
> > > > value - so I would like to do just that.
> > > >
> > > > I understand that folk don't necessarily see the value, but I have done
> > > > and would like to try it for the projects that I am managing. That
> > > > shouldn't be too onerous I think? Also as apps move from autotools to
> > meson
> > > > we already have a reduced consistency between projects.
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> > > >
> > > >> Heya,
> > > >>
> > > >> I don't quite understand what you are trying to do here. I mean, I
> > > >> understand you are trying to have these, but what are these branches
> > > >> for? If it's for you developing your own features why not put it in a
> > > >> dev branch?
> > > >>
> > > >> We have these enforcements because we want to enforce branch names to
> > > >> follow a consistent pattern across the repos. I don't mind changing it
> > > >> per se,
> > > >> though:
> > > >> 1. I don't really see an obvious value with gitflow.
> > > >> 2. I'd prefer if it was consistent across repos.
> > > >>
> > > >> Maybe people don't agree with this, but my take towards the e repos is
> > > >> similar to that
> > > >> of the GNU project. Have everything follow similar guidelines and be
> > > >> mostly similar,
> > > >> making it easier for devs to jump across projects. Yes, that
> > > >> consistency sometimes
> > > >> comes with a price, but I think that it's worth it.
> > > >>
> > > >> Looking forward to hearing what other people think.
> > > >>
> > > >> --
> > > >> Tom.
> > > >>
> > > >> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams <
> > a...@andywilliams.me>
> > > >> wrote:
> > > >> > Hi git admins,
> > > >> >
> > > >> > I'm setting up gitflow on Edi but I can't push to 

Re: [E-devel] GitFlow

[Stephen Houston]

I agree. This really isn't a big deal. You all have control of the git
projects. If someone manages branches in a project you are working on in a
way you don't like... revert it or remove it? We are being too difficult
about really small unimportant issues lately I think. If someone is willing
to do documentation, by all means let them do it how they feel it's best,
especially if the consensus is documentation is a priority need and they
are the ones willing to step up and fill that void. If someone is managing
a project that by size and variety is one of the best exhibitions of our
toolkit and philosophy, let them branch as they see fit, as their project
and development, however they are comfortable with it, is to the advantage
of the E population as a whole.

On Wed, Oct 25, 2017, 10:26 PM Jean-Philippe André 
wrote:

> I fail to see why we wouldn't allow Andy & Co to test out this workflow on
> EDI and use this as an experience?
> Is it impossible to allow those branch names only on EDI's repo?
>
> 2017-10-26 8:35 GMT+09:00 Carsten Haitzler :
>
> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams  >
> > said:
> >
> > We had this discussion before in just one place I believe until you asked
> > for
> > specific branch names to be allowed. You wanted us to change how we
> branch
> > and
> > work with efl/e etc. the last time. I don't remember there being
> agreement
> > with
> > you on needing a change as I don't see our current model being bad or
> > broken
> > or causing trouble (discussion already had) vs gitflow. I don't know why
> > you're
> > bringing it back up as if there wasn't a consensus already. I believe the
> > last
> > discussion was roughly:
> >
> > "There is no agreement that any change is needed. The change you propose
> > does
> > nothing to actually improve anything by it's proposal. It just shuffles
> > chairs,
> > BUT if you really think it's so much better, try it on smaller projects
> > first
> > and show/prove it to be worth it".
> >
> > Or something to that effect. Most people were just silent on the topic.
> >
> > > Hi list,
> > >
> > > This conversation seems to have now happened in many places and it
> seems
> > > that a few key individuals don't really see why we should be looking at
> > > different branching models. I understand that opinion but if we don't
> try
> > > new things then we will never be able to engage with new process or
> > > technologies so I am keen to try gitflow nonetheless.
> > >
> > > So at this point I would like this thread to record a definitive
> > decision.
> > > Will we allow reduced branch name restrictions on our git repositories
> or
> > > not?
> > > Thanks,
> > > Andy
> > >
> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
> > wrote:
> > >
> > > > Hi TAsn,
> > > >
> > > > Thanks for the reply. In gitflow these are the standards and they
> need
> > to
> > > > work across different users hence why having the developer namespace
> > is not
> > > > quite enough. Additionally the hotfix is not catered for in our
> current
> > > > scheme (as I understand it).
> > > > One nice thing with gitflow is the plugin that manages all the
> branches
> > > > for you. If you have custom schemes then every person looking to take
> > up
> > > > development has to configure it before getting started, so the
> > defaults are
> > > > best if possible.
> > > >
> > > > I appreciate that consistency is important but taken so stringently
> it
> > > > means we can never try anything new... An earlier discussion on
> > GitFlow led
> > > > to raster saying that he would need to see it working to understand
> the
> > > > value - so I would like to do just that.
> > > >
> > > > I understand that folk don't necessarily see the value, but I have
> done
> > > > and would like to try it for the projects that I am managing. That
> > > > shouldn't be too onerous I think? Also as apps move from autotools to
> > meson
> > > > we already have a reduced consistency between projects.
> > > >
> > > > Thanks,
> > > > Andy
> > > >
> > > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> > > >
> > > >> Heya,
> > > >>
> > > >> I don't quite understand what you are trying to do here. I mean, I
> > > >> understand you are trying to have these, but what are these branches
> > > >> for? If it's for you developing your own features why not put it in
> a
> > > >> dev branch?
> > > >>
> > > >> We have these enforcements because we want to enforce branch names
> to
> > > >> follow a consistent pattern across the repos. I don't mind changing
> it
> > > >> per se,
> > > >> though:
> > > >> 1. I don't really see an obvious value with gitflow.
> > > >> 2. I'd prefer if it was consistent across repos.
> > > >>
> > > >> Maybe people don't agree with this, but my take towards the e repos
> is
> > > >> similar to that
> > > >> of the GNU project. Have everything follow similar guidelines and be
> > 

Re: [E-devel] GitFlow

[Jean-Philippe André]

I fail to see why we wouldn't allow Andy & Co to test out this workflow on
EDI and use this as an experience?
Is it impossible to allow those branch names only on EDI's repo?

2017-10-26 8:35 GMT+09:00 Carsten Haitzler :

> On Wed, 25 Oct 2017 20:15:45 + Andrew Williams 
> said:
>
> We had this discussion before in just one place I believe until you asked
> for
> specific branch names to be allowed. You wanted us to change how we branch
> and
> work with efl/e etc. the last time. I don't remember there being agreement
> with
> you on needing a change as I don't see our current model being bad or
> broken
> or causing trouble (discussion already had) vs gitflow. I don't know why
> you're
> bringing it back up as if there wasn't a consensus already. I believe the
> last
> discussion was roughly:
>
> "There is no agreement that any change is needed. The change you propose
> does
> nothing to actually improve anything by it's proposal. It just shuffles
> chairs,
> BUT if you really think it's so much better, try it on smaller projects
> first
> and show/prove it to be worth it".
>
> Or something to that effect. Most people were just silent on the topic.
>
> > Hi list,
> >
> > This conversation seems to have now happened in many places and it seems
> > that a few key individuals don't really see why we should be looking at
> > different branching models. I understand that opinion but if we don't try
> > new things then we will never be able to engage with new process or
> > technologies so I am keen to try gitflow nonetheless.
> >
> > So at this point I would like this thread to record a definitive
> decision.
> > Will we allow reduced branch name restrictions on our git repositories or
> > not?
> > Thanks,
> > Andy
> >
> > On Mon, 23 Oct 2017 at 11:43 Andrew Williams 
> wrote:
> >
> > > Hi TAsn,
> > >
> > > Thanks for the reply. In gitflow these are the standards and they need
> to
> > > work across different users hence why having the developer namespace
> is not
> > > quite enough. Additionally the hotfix is not catered for in our current
> > > scheme (as I understand it).
> > > One nice thing with gitflow is the plugin that manages all the branches
> > > for you. If you have custom schemes then every person looking to take
> up
> > > development has to configure it before getting started, so the
> defaults are
> > > best if possible.
> > >
> > > I appreciate that consistency is important but taken so stringently it
> > > means we can never try anything new... An earlier discussion on
> GitFlow led
> > > to raster saying that he would need to see it working to understand the
> > > value - so I would like to do just that.
> > >
> > > I understand that folk don't necessarily see the value, but I have done
> > > and would like to try it for the projects that I am managing. That
> > > shouldn't be too onerous I think? Also as apps move from autotools to
> meson
> > > we already have a reduced consistency between projects.
> > >
> > > Thanks,
> > > Andy
> > >
> > > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> > >
> > >> Heya,
> > >>
> > >> I don't quite understand what you are trying to do here. I mean, I
> > >> understand you are trying to have these, but what are these branches
> > >> for? If it's for you developing your own features why not put it in a
> > >> dev branch?
> > >>
> > >> We have these enforcements because we want to enforce branch names to
> > >> follow a consistent pattern across the repos. I don't mind changing it
> > >> per se,
> > >> though:
> > >> 1. I don't really see an obvious value with gitflow.
> > >> 2. I'd prefer if it was consistent across repos.
> > >>
> > >> Maybe people don't agree with this, but my take towards the e repos is
> > >> similar to that
> > >> of the GNU project. Have everything follow similar guidelines and be
> > >> mostly similar,
> > >> making it easier for devs to jump across projects. Yes, that
> > >> consistency sometimes
> > >> comes with a price, but I think that it's worth it.
> > >>
> > >> Looking forward to hearing what other people think.
> > >>
> > >> --
> > >> Tom.
> > >>
> > >> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams <
> a...@andywilliams.me>
> > >> wrote:
> > >> > Hi git admins,
> > >> >
> > >> > I'm setting up gitflow on Edi but I can't push to origin because of
> the
> > >> > branch naming rules. Can you please open up the ability to have
> remote
> > >> > branches matching the patterns "develop", "feature/*", "bugfix/*",
> > >> > "release/*", "hotfix/*" and "support/*"?
> > >> >
> > >> > I'd really appreciate it thanks.
> > >> > Oh and to those who worried about "changing to develop branch is an
> > >> extra
> > >> > step" don't fear as HEAD can be pointed to develop instead of
> master if
> > >> > that's what folk are looking to have set up :)
> > >> >
> > >> > Cheers,
> > >> > Andrew
> > >> >
> > >> > --
> > >> > http://andywilliams.me
> > >> > 

Re: [E-devel] GitFlow

[Carsten Haitzler]

On Wed, 25 Oct 2017 20:15:45 + Andrew Williams  said:

We had this discussion before in just one place I believe until you asked for
specific branch names to be allowed. You wanted us to change how we branch and
work with efl/e etc. the last time. I don't remember there being agreement with
you on needing a change as I don't see our current model being bad or broken
or causing trouble (discussion already had) vs gitflow. I don't know why you're
bringing it back up as if there wasn't a consensus already. I believe the last
discussion was roughly:

"There is no agreement that any change is needed. The change you propose does
nothing to actually improve anything by it's proposal. It just shuffles chairs,
BUT if you really think it's so much better, try it on smaller projects first
and show/prove it to be worth it".

Or something to that effect. Most people were just silent on the topic.

> Hi list,
> 
> This conversation seems to have now happened in many places and it seems
> that a few key individuals don't really see why we should be looking at
> different branching models. I understand that opinion but if we don't try
> new things then we will never be able to engage with new process or
> technologies so I am keen to try gitflow nonetheless.
> 
> So at this point I would like this thread to record a definitive decision.
> Will we allow reduced branch name restrictions on our git repositories or
> not?
> Thanks,
> Andy
> 
> On Mon, 23 Oct 2017 at 11:43 Andrew Williams  wrote:
> 
> > Hi TAsn,
> >
> > Thanks for the reply. In gitflow these are the standards and they need to
> > work across different users hence why having the developer namespace is not
> > quite enough. Additionally the hotfix is not catered for in our current
> > scheme (as I understand it).
> > One nice thing with gitflow is the plugin that manages all the branches
> > for you. If you have custom schemes then every person looking to take up
> > development has to configure it before getting started, so the defaults are
> > best if possible.
> >
> > I appreciate that consistency is important but taken so stringently it
> > means we can never try anything new... An earlier discussion on GitFlow led
> > to raster saying that he would need to see it working to understand the
> > value - so I would like to do just that.
> >
> > I understand that folk don't necessarily see the value, but I have done
> > and would like to try it for the projects that I am managing. That
> > shouldn't be too onerous I think? Also as apps move from autotools to meson
> > we already have a reduced consistency between projects.
> >
> > Thanks,
> > Andy
> >
> > On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
> >
> >> Heya,
> >>
> >> I don't quite understand what you are trying to do here. I mean, I
> >> understand you are trying to have these, but what are these branches
> >> for? If it's for you developing your own features why not put it in a
> >> dev branch?
> >>
> >> We have these enforcements because we want to enforce branch names to
> >> follow a consistent pattern across the repos. I don't mind changing it
> >> per se,
> >> though:
> >> 1. I don't really see an obvious value with gitflow.
> >> 2. I'd prefer if it was consistent across repos.
> >>
> >> Maybe people don't agree with this, but my take towards the e repos is
> >> similar to that
> >> of the GNU project. Have everything follow similar guidelines and be
> >> mostly similar,
> >> making it easier for devs to jump across projects. Yes, that
> >> consistency sometimes
> >> comes with a price, but I think that it's worth it.
> >>
> >> Looking forward to hearing what other people think.
> >>
> >> --
> >> Tom.
> >>
> >> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams 
> >> wrote:
> >> > Hi git admins,
> >> >
> >> > I'm setting up gitflow on Edi but I can't push to origin because of the
> >> > branch naming rules. Can you please open up the ability to have remote
> >> > branches matching the patterns "develop", "feature/*", "bugfix/*",
> >> > "release/*", "hotfix/*" and "support/*"?
> >> >
> >> > I'd really appreciate it thanks.
> >> > Oh and to those who worried about "changing to develop branch is an
> >> extra
> >> > step" don't fear as HEAD can be pointed to develop instead of master if
> >> > that's what folk are looking to have set up :)
> >> >
> >> > Cheers,
> >> > Andrew
> >> >
> >> > --
> >> > http://andywilliams.me
> >> > http://ajwillia.ms
> >> >
> >> --
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > ___
> >> > enlightenment-devel mailing list
> >> > enlightenment-devel@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >>
> >> 

Re: [E-devel] GitFlow

[Andrew Williams]

Hi list,

This conversation seems to have now happened in many places and it seems
that a few key individuals don't really see why we should be looking at
different branching models. I understand that opinion but if we don't try
new things then we will never be able to engage with new process or
technologies so I am keen to try gitflow nonetheless.

So at this point I would like this thread to record a definitive decision.
Will we allow reduced branch name restrictions on our git repositories or
not?
Thanks,
Andy

On Mon, 23 Oct 2017 at 11:43 Andrew Williams  wrote:

> Hi TAsn,
>
> Thanks for the reply. In gitflow these are the standards and they need to
> work across different users hence why having the developer namespace is not
> quite enough. Additionally the hotfix is not catered for in our current
> scheme (as I understand it).
> One nice thing with gitflow is the plugin that manages all the branches
> for you. If you have custom schemes then every person looking to take up
> development has to configure it before getting started, so the defaults are
> best if possible.
>
> I appreciate that consistency is important but taken so stringently it
> means we can never try anything new... An earlier discussion on GitFlow led
> to raster saying that he would need to see it working to understand the
> value - so I would like to do just that.
>
> I understand that folk don't necessarily see the value, but I have done
> and would like to try it for the projects that I am managing. That
> shouldn't be too onerous I think? Also as apps move from autotools to meson
> we already have a reduced consistency between projects.
>
> Thanks,
> Andy
>
> On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:
>
>> Heya,
>>
>> I don't quite understand what you are trying to do here. I mean, I
>> understand you are trying to have these, but what are these branches
>> for? If it's for you developing your own features why not put it in a
>> dev branch?
>>
>> We have these enforcements because we want to enforce branch names to
>> follow a consistent pattern across the repos. I don't mind changing it
>> per se,
>> though:
>> 1. I don't really see an obvious value with gitflow.
>> 2. I'd prefer if it was consistent across repos.
>>
>> Maybe people don't agree with this, but my take towards the e repos is
>> similar to that
>> of the GNU project. Have everything follow similar guidelines and be
>> mostly similar,
>> making it easier for devs to jump across projects. Yes, that
>> consistency sometimes
>> comes with a price, but I think that it's worth it.
>>
>> Looking forward to hearing what other people think.
>>
>> --
>> Tom.
>>
>> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams 
>> wrote:
>> > Hi git admins,
>> >
>> > I'm setting up gitflow on Edi but I can't push to origin because of the
>> > branch naming rules. Can you please open up the ability to have remote
>> > branches matching the patterns "develop", "feature/*", "bugfix/*",
>> > "release/*", "hotfix/*" and "support/*"?
>> >
>> > I'd really appreciate it thanks.
>> > Oh and to those who worried about "changing to develop branch is an
>> extra
>> > step" don't fear as HEAD can be pointed to develop instead of master if
>> > that's what folk are looking to have set up :)
>> >
>> > Cheers,
>> > Andrew
>> >
>> > --
>> > http://andywilliams.me
>> > http://ajwillia.ms
>> >
>> --
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > enlightenment-devel mailing list
>> > enlightenment-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> http://andywilliams.me
> http://ajwillia.ms
>
-- 
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GitFlow

[Andrew Williams]

Hi TAsn,

Thanks for the reply. In gitflow these are the standards and they need to
work across different users hence why having the developer namespace is not
quite enough. Additionally the hotfix is not catered for in our current
scheme (as I understand it).
One nice thing with gitflow is the plugin that manages all the branches for
you. If you have custom schemes then every person looking to take up
development has to configure it before getting started, so the defaults are
best if possible.

I appreciate that consistency is important but taken so stringently it
means we can never try anything new... An earlier discussion on GitFlow led
to raster saying that he would need to see it working to understand the
value - so I would like to do just that.

I understand that folk don't necessarily see the value, but I have done and
would like to try it for the projects that I am managing. That shouldn't be
too onerous I think? Also as apps move from autotools to meson we already
have a reduced consistency between projects.

Thanks,
Andy

On Mon, 23 Oct 2017 at 11:34 Tom Hacohen  wrote:

> Heya,
>
> I don't quite understand what you are trying to do here. I mean, I
> understand you are trying to have these, but what are these branches
> for? If it's for you developing your own features why not put it in a
> dev branch?
>
> We have these enforcements because we want to enforce branch names to
> follow a consistent pattern across the repos. I don't mind changing it per
> se,
> though:
> 1. I don't really see an obvious value with gitflow.
> 2. I'd prefer if it was consistent across repos.
>
> Maybe people don't agree with this, but my take towards the e repos is
> similar to that
> of the GNU project. Have everything follow similar guidelines and be
> mostly similar,
> making it easier for devs to jump across projects. Yes, that
> consistency sometimes
> comes with a price, but I think that it's worth it.
>
> Looking forward to hearing what other people think.
>
> --
> Tom.
>
> On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams 
> wrote:
> > Hi git admins,
> >
> > I'm setting up gitflow on Edi but I can't push to origin because of the
> > branch naming rules. Can you please open up the ability to have remote
> > branches matching the patterns "develop", "feature/*", "bugfix/*",
> > "release/*", "hotfix/*" and "support/*"?
> >
> > I'd really appreciate it thanks.
> > Oh and to those who worried about "changing to develop branch is an extra
> > step" don't fear as HEAD can be pointed to develop instead of master if
> > that's what folk are looking to have set up :)
> >
> > Cheers,
> > Andrew
> >
> > --
> > http://andywilliams.me
> > http://ajwillia.ms
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-- 
http://andywilliams.me
http://ajwillia.ms
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GitFlow

[Tom Hacohen]

Heya,

I don't quite understand what you are trying to do here. I mean, I
understand you are trying to have these, but what are these branches
for? If it's for you developing your own features why not put it in a
dev branch?

We have these enforcements because we want to enforce branch names to
follow a consistent pattern across the repos. I don't mind changing it per se,
though:
1. I don't really see an obvious value with gitflow.
2. I'd prefer if it was consistent across repos.

Maybe people don't agree with this, but my take towards the e repos is
similar to that
of the GNU project. Have everything follow similar guidelines and be
mostly similar,
making it easier for devs to jump across projects. Yes, that
consistency sometimes
comes with a price, but I think that it's worth it.

Looking forward to hearing what other people think.

--
Tom.

On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams  wrote:
> Hi git admins,
>
> I'm setting up gitflow on Edi but I can't push to origin because of the
> branch naming rules. Can you please open up the ability to have remote
> branches matching the patterns "develop", "feature/*", "bugfix/*",
> "release/*", "hotfix/*" and "support/*"?
>
> I'd really appreciate it thanks.
> Oh and to those who worried about "changing to develop branch is an extra
> step" don't fear as HEAD can be pointed to develop instead of master if
> that's what folk are looking to have set up :)
>
> Cheers,
> Andrew
>
> --
> http://andywilliams.me
> http://ajwillia.ms
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel