On Thu, 26 Oct 2017 13:38:12 +0100 Tom Hacohen <[email protected]> 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 <[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 > > ------------------------------------------------------------------------------ > 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] ------------------------------------------------------------------------------ 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
