Re: [E-devel] GitFlow

2017-10-28 Thread 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

Re: [E-devel] GitFlow

2017-10-28 Thread 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

Re: [E-devel] GitFlow

2017-10-27 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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.

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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. > >

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-26 Thread 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

Re: [E-devel] GitFlow

2017-10-25 Thread 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

Re: [E-devel] GitFlow

2017-10-25 Thread 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

Re: [E-devel] GitFlow

2017-10-25 Thread 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

Re: [E-devel] GitFlow

2017-10-25 Thread 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

Re: [E-devel] GitFlow

2017-10-25 Thread 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

Re: [E-devel] GitFlow

2017-10-23 Thread 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

Re: [E-devel] GitFlow

2017-10-23 Thread 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

[E-devel] GitFlow

2017-10-21 Thread Andrew Williams
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