On Thu, 26 Oct 2017 17:35:39 +0100 Tom Hacohen <t...@stosb.com> 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 > <michael.blumenkra...@gmail.com> 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 <t...@stosb.com> 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 <t...@stosb.com> 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 +0000 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 <ras...@rasterman.com> > >> wrote: > >> >>> > >> >>> > On Wed, 25 Oct 2017 20:15:45 +0000 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 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 <a...@andywilliams.me > >> > > >> >>> > 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 <t...@stosb.com> 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 > >> >>> > > >> > 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 > >> >>> > > > >> >>> > > >> >>> > > >> >>> > -- > >> >>> > ------------- Codito, ergo sum - "I code, therefore I am" > >> -------------- > >> >>> > Carsten Haitzler - ras...@rasterman.com > >> >>> > > >> >>> > -- > >> >>> http://andywilliams.me > >> >>> http://ajwillia.ms > >> >> > >> >> > >> >> -- > >> >> ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >> >> Carsten Haitzler - ras...@rasterman.com > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------------ > >> >> 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 > >> > > ------------------------------------------------------------------------------ > > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ 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
