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 <[email protected]> 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 <[email protected]> wrote: > > It is possible, yes. > > > > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler <[email protected]> > wrote: > >> On Thu, 26 Oct 2017 07:19:51 +0000 Andrew Williams < > [email protected]> 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 <[email protected]> > wrote: > >>> > >>> > On Wed, 25 Oct 2017 20:15:45 +0000 Andrew Williams < > [email protected]> > >>> > 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 <[email protected] > > > >>> > 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 <[email protected]> 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 < > >>> > [email protected]> > >>> > > >> 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 > >>> > > >> > [email protected] > >>> > > >> > > 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 > >>> > > >> [email protected] > >>> > > >> > 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 > >>> > > [email protected] > >>> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > > > >>> > > >>> > > >>> > -- > >>> > ------------- Codito, ergo sum - "I code, therefore I am" > -------------- > >>> > Carsten Haitzler - [email protected] > >>> > > >>> > -- > >>> http://andywilliams.me > >>> http://ajwillia.ms > >> > >> > >> -- > >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >> Carsten Haitzler - [email protected] > >> > >> > >> > ------------------------------------------------------------------------------ > >> 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 > >> [email protected] > >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
