Dev meeting 2015 12 15

Agenda

• Deprecations
• New extension model
• Vote on setting default branch to release/2.2

Log

* gawainlynch makes the secret 60 second Ninja Call of the Bolt Clan
<slick0> #ninja
* [BoltIssueBall] visits http://slick0.is-a-sneaky.ninja/
* SahAssar is preemptively saying "pong"
<carsonfull> pong
<gawainlynch> zing Bopp carsonfull rarila rossriley SahAssar 
<rarila> zong
<rossriley> rolls up his wizard sleeve
<gawainlynch> Lovely!
<gawainlynch> OK… rock on
<gawainlynch> rossriley: #4588
-[BoltIssueBall]/#boltcms- #4588 [open] Fixes for field persistence errors https://github.com/bolt/bolt/pull/4588 
<rossriley> i have #tea and biscuits instead of beer, terrible
* [BoltIssueBall] has boiled some water, and begins to brew rossriley a nice cup of tea.
<gawainlynch> rossriley: What are you thinking!
<gawainlynch> rossriley: Also #4533 
-[BoltIssueBall]/#boltcms- #4533 [open] Leaving fields "empty" tends to throw errors https://github.com/bolt/bolt/issues/4533  — assigned to GawainLynch
<gawainlynch> …which is apparently assigned to me
<rossriley> #4588 shouldn’t really be failing any tests… let me rebase / push again
-[BoltIssueBall]/#boltcms- #4588 [open] Fixes for field persistence errors https://github.com/bolt/bolt/pull/4588 
<gawainlynch> rossriley: There is a PR against your branch from me as… well… Texan
<gawainlynch> carsonfull & rossriley: are we happy that #3831 is close-worthy and/or addressed in the FS work?
-[BoltIssueBall]/#boltcms- #3831 [open] Potential BC/Functionality Break in Uploads https://github.com/bolt/bolt/issues/3831  — assigned to CarsonF
<gawainlynch> carsonfull: #4095 … same deal
-[BoltIssueBall]/#boltcms- #4095 [open] [Feature] Thumbnails/Uploads/FileManager with remote filesystems https://github.com/bolt/bolt/issues/4095  — assigned to CarsonF
<carsonfull> There's still more work needed on filesystem usage in core
<gawainlynch> carsonfull: That's a "no" then
<carsonfull> Additionally I want to move it up into ResourceManager as it will eventually replace the $paths part of it
<carsonfull> "nein"
<gawainlynch> Bopp: Do you know if TK is still seeing #4095, as it slipped of my radar somehow?
-[BoltIssueBall]/#boltcms- #4095 [open] [Feature] Thumbnails/Uploads/FileManager with remote filesystems https://github.com/bolt/bolt/issues/4095  — assigned to CarsonF
<gawainlynch> Ugh
<gawainlynch> Bopp: Sorry… #4518
-[BoltIssueBall]/#boltcms- #4518 [open] unexpected behaviour of content type listing in frontpage controller https://github.com/bolt/bolt/issues/4518  — assigned to CarsonF
<Bopp> .. is assigned to Carson.
<Bopp> :-)_
<carsonfull> Yeah why is this...
<gawainlynch> Bopp: More "has it been covered and left open" question
<gawainlynch> Bopp: But well called ;-)
<Bopp> Anyhow, i'm happy to dig in, but this is getting into the "feel like i'm more in the way than helping" territory. 
<carsonfull> Bopp: I would love for you to dig in
<carsonfull> And answer any questions I can
<gawainlynch> Bopp: Yes and welcome… just unsure if it is still a problem as some of these might have been covered in other PRs
<gawainlynch> rossriley: You probably want to re-rebase that
<Bopp> I'll look into, then! assigned to me now.
<gawainlynch> Bopp: If it breaks… blame… the koala first… the Texan second
<gawainlynch> rossriley: #4422 #4581 can be assassinated?
-[BoltIssueBall]/#boltcms- #4422 [open] [Tracker] Repeating Fields Push to the Finish https://github.com/bolt/bolt/issues/4422 
-[BoltIssueBall]/#boltcms- #4581 [open] Missing variable error in repeating fields data https://github.com/bolt/bolt/issues/4581 
<gawainlynch> OK… while waiting on the now-overloaded question queue assigned to rossriley…
<gawainlynch> Vote on setting default branch to release/2.2… objections?
<Bopp> plz do. 
<carsonfull> agreed
<gawainlynch> 5… 4… 3…
<gawainlynch> Done
<rossriley> ok gawainlynch #4422 / #4581 done
-[BoltIssueBall]/#boltcms- #4422 [open] [Tracker] Repeating Fields Push to the Finish https://github.com/bolt/bolt/issues/4422 
-[BoltIssueBall]/#boltcms- #4581 [open] Missing variable error in repeating fields data https://github.com/bolt/bolt/issues/4581 
<rossriley> yes
<gawainlynch> #karma rossriley 
<rossriley> is racial here
<[BoltIssueBall]> BoltKarma for rossriley is now 193
<rossriley> ha
<rossriley> autocorrect * rarila
<Bopp> haha, you had me puzzled there for a bit. 
<rarila> yep
* rarila too
<rossriley> one very tiny bug with the geolocation field…..
<rossriley> can we get it so that snap is not posted if a field is otherwise empty
<rarila> rossriley: hmm, actual no need to post it at all
<rossriley> oh yes… even better
<rarila> rossriley: we don't save it anyway?!
<rarila> so I guess just removing the name attribute will do
<rossriley> that was my last major issue with repeating fields….
<SahAssar> #karma rossriley
<rarila> rossriley: is there no filtering against allowed posted fields?
<[BoltIssueBall]> BoltKarma for rossriley is now 194
* gawainlynch hands the champagne bottle to SahAssar 
<rarila> rossriley: so whatever is sent get's saved?
* SahAssar opens and #champagne
<rossriley> rarila: it gets posted as part of the allowed field though
<rossriley> so post[geolocationname][snap]
<rossriley> and that gets saved in json in the db
<rossriley> so we just had instead of empty {’snap’:’on’}
<rossriley> showing up in the db
<rarila> rossriley: can't we filter such things against a list of wanted names?
* carsonfull mumbles something about being off topic
<rossriley> rarila: we could possibly… just at the moment we share across all json fields, eg lists / geo / video etc
<rossriley> back on topic :-)
<gawainlynch> OK… so the two or three the big ones for tonight… 
<gawainlynch> New extension model… #4596 … concerns… feedback… complaints… #beer
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('gawainlynch')->serveAll();
-[BoltIssueBall]/#boltcms- #4596 [open] v3.0 Extensions https://github.com/bolt/bolt/issues/4596 
* carsonfull goes to read it
<Bopp> I have some concerns about that one, but Gawain told me it'll be fine :-)
<gawainlynch> Hehe… 
<carsonfull> Bopp: Which part?
<SahAssar> My only issue with this is that to an outsider it seems very sudden. Just a few weeks ago 2.2 extensions would be compatible with 2.3 which is now 3.0. 2.2 being LTS helps the issue though
<rossriley> what specifically does 'ALL DA THINGZ!’ include in the BC break
<Bopp> carsonfull: 1) `initialize` being removed.
<Bopp> 2)  • Global twig variable for extension is no longer added
* evertalbers (~evertalbe@a82-161-236-249.adsl.xs4all.nl) has joined #boltcms
<rossriley> shouldn’t we deprecate them in the next version and then remove in 4.0
<gawainlynch> SahAssar: Yes, but part of the problem is that we had 3.0 scheduled for a lot of changes… we need to break hard with the Symfony 3 / Silex 2 update
<Bopp> SahAssar: frankly, 2.2 extension weren't _really_ compatible with 2.3 either..
<gawainlynch> rossriley: Honestly that line got left in by accident
<rossriley> ha
<gawainlynch> rossriley: I was being funny and taking the piss at carsonfull 
<rossriley> that’s ok then
<carsonfull> If devs stick to the helper methods silex 2 won't affect them
<rossriley> in future please try to treat an RFC with the attention it deserves
<Bopp> SahAssar: now they're just officially not compatible, and we can fix them for 3.0
<gawainlynch> rossriley: Noted ;-)
<SahAssar> Bopp: Sure, just trying to see this from the perspective of an outsider.
<gawainlynch> SahAssar: The plan was to use 2.4 & 2.5 as transition to the big breaks
<gawainlynch> SahAssar: Please do! It is needed!
<gawainlynch> Basically making a last minute change to v3 kinda is hard to plan around… it is nice for marketing but kinda sucks when you're trying to track a lot of things at once
<carsonfull> BC breaks are mostly the registration changes and base class they are extending
<gawainlynch> One of the things I have maintained (to carsonfull's ongoing hell) is that the transition from v2 to v3+ extension should be "easy"
<SahAssar> I'm all for the changes, I just think we need to communicate them well (on all of our channels) to all effected. Also, when communicating to non-developers we need to stress that 2.2 *is* LTS.
<Bopp> Yeah, they won't be hard to fix, but it makes them break nonetheless
<gawainlynch> But it should set up the v4 model
<carsonfull> ^this 
<carsonfull> We were more so trying to highlight the new model 
<gawainlynch> SahAssar: Agreed… I just personally want to get the model sorted then we can notify everyone… and PR like crazy on popular extensions to get them acorss the line
<rossriley> gawainlynch, carsonfull pretty much everything else in there agree with 100%, just would be nice if we could come up with some legacy adapter to enable transition
<carsonfull> A lot of that is baked in already
<gawainlynch> rossriley: Yeah… most is already th ^ this
<Bopp> I don't mind a clean break in 3.0. 
<carsonfull> The initialize method could be added back in if that's the tripping point
<gawainlynch> rossriley: The hard part is ensuing request cycle behaviour
<Bopp> .. and putting in a saturday to PR fixes to a lot of well-used extensions
<gawainlynch> carsonfull: If so, can we puh-lease call it late
<gawainlynch> …if we do that
<carsonfull> ?
<gawainlynch> ^ which still breaks stuff anyway
<gawainlynch> carsonfull: If we keep initialize()
<carsonfull> What stuff will break?
<carsonfull> Sorry I'm also on my phone because my laptop decided to crap out 
<gawainlynch> carsonfull: If we move init() to later in the cycle, things that need LLA will likely not work
<carsonfull> LLA?
<gawainlynch> Low level access
<carsonfull> And it's not later in the cycle. It's the same place
<gawainlynch> bokay
<carsonfull> rossriley: what do you think about putting extension class name in composer.json
<gawainlynch> Deprecations… I have tried to list them all as we go long here https://github.com/bolt/bolt/wiki/Deprecations-Tracker and collect current ones from the code base
<rossriley> I don’t mind that… (class in composer) as long as there’s a code api to do it too
<carsonfull> to register extensions?
<rossriley> I don’t know about everyone else, but most of my extensions just start as part of a normal app, until I think they can be refactored out to an ext
<carsonfull> Yes absolutely. I'm still thinking about the "bundled" extensions concept for composer installs
<carsonfull> Bopp: What is it that concerns you about removing global twig variable for extension class?
<Bopp> That it will break existing extensions. 
<rossriley> so mostly I start an extension with `$app[‘extensions’]->register(new Local\Class())`
<Bopp> I know a few of mine will 
<Bopp> carsonfull: regardless, I see why we should do this, and i won't mind spending some time helping people fix it for 3.0
<carsonfull> rossriley: You'll still be good with that (other than maybe the method name changing)
<SahAssar> Bopp: won't they break anyway because of the other changes?
<Bopp> SahAssar: yes, just another way they might break. ;-)
<carsonfull> Bopp: I am fine deprecating it for now. and breaking in 4.0
<Bopp> I could live with either. 
<carsonfull> I also didn't know how many people used it
<gawainlynch> Globalisation… redefined
<carsonfull> I also want to deprecate the pimple definition as well
<SahAssar> I'm probably not the right guy to ask this, but any GA input on this?
<gawainlynch> GA?
<SahAssar> Aka slick0
<gawainlynch> CA
<slick0> oh, CA!
<SahAssar> Ah, typo
<slick0> yea, basically, from what i can tell with the current extensions here
<slick0> there will be breaks
<slick0> (as noted already)
<slick0> but overall, migration doesn't look too difficult
<carsonfull> $app['extensions.BoltForms'] to $app['extensions']->get('BoltForms')
<slick0> and in general, i reallly like the direction extensions take here
<Bopp> Yes, that's my take on it too: it will break, but rather straightforward to fix. 
<carsonfull> Bopp: exactly
<gawainlynch> Bopp: With the future in mind too!
<carsonfull> Yeah so in our migration doc we'll the minium changes needed to work. and then how they should redesign for v4.0
<Bopp> :-)
<gawainlynch> carsonfull: Yeah, we should probably have a "this is to make it 'just work' from v2" and a "How to to it in v3+" section(s)
<carsonfull> Agreed
<gawainlynch> So… seeing as CA are in this discussion… this brings up our branching strategy 
<carsonfull> Any problems with the structure standardization proposal?
<gawainlynch> Does "can we have it today" equal a problem?
<gawainlynch> I would like to prose that we thing about branching soon
<gawainlynch> *propse
* gawainlynch just can't type
<gawainlynch> **pro-pose
<slick0> extra hyphen
<carsonfull> Ummmm....
<Bopp> branching for what? 
<slick0> ok, i'm not sure what you mean by branching, though
<slick0> what's the current vs what you have in mind?
<gawainlynch> Establish the 3.0 branch
<carsonfull> That's what master is for
<Bopp> isn't that just master?
<slick0> however you want to do it shouldn't really effect CA… from what i can tell, it's a zip baased install
<slick0> *based
<carsonfull> I guess I'm fine with that as long as we keep 3.x and master mergable
<gawainlynch> slick0: CA isn't my "reason"… just a convenient excuse
<gawainlynch> I mean… as in branching at beta, and opening 3.1 at that point
<carsonfull> I don't think we are there yet
<gawainlynch> Not even clsoe
<gawainlynch> But… Getting our branches shorter
<carsonfull> That doesn't mean we are ready for a beta
<gawainlynch> carsonfull: "branching at beta" would mean when we are ready to beta
<slick0> oh, in terms of overall dev cycle between releases
<gawainlynch> …not "OK, it's Monday"
<gawainlynch> slick0: Yes
<carsonfull> Oh...well of course. How else would it be done?
<gawainlynch> carsonfull: I don't know… I am just answering your assertion
<carsonfull> My only concern is which branch people submit PRs to. Once we branch they should submit to the 3.x branch and then we would merge 3.x to master after that
<carsonfull> (or periodically)
<carsonfull> This isn't how it was was done for 2.2 and it has been painful.
<gawainlynch> OK… given the silent thought… my thinking being, we have things like further points of progression for things like storage that are potentially being held up "'cause carsonfull hasn't finished foo"
<gawainlynch> carsonfull: Yeah, it needs refinement
<carsonfull> further points of progression for 4.0?
<gawainlynch> My problem is that there is a short window for feature… that blows out… while everyone else either waits or fixes
<Bopp> i'm not sure branching is a good idea.. I clearly remember the "fun" we had last time we did. 
<gawainlynch> Get the people "waiting" able to do stuff and iterate faster
<gawainlynch> carsonfull: Yes
<carsonfull> Well we need to stop merging branches that are half done
<gawainlynch> carsonfull: I know, I'll talk to the Texan
<carsonfull> It's just hard for us when they are so massive. Which we've had a lot of this round
<gawainlynch> Yes… and it has been a "special" round
<carsonfull> I'm still unsure what you are getting at though?
<gawainlynch> But we can either release once a year, or fine tune
<gawainlynch> Beta -> branch -> master is open for feature -> beta branch is bug fix -> stable branch is bug fix
<carsonfull> The thing is we have not been fine tuning. We've been rewriting
<gawainlynch> I know
<carsonfull> Yes I'm fine with that branching
<rossriley> personally I think we just branch when we release and always have master as development
<slick0> just a heads up, have a meeting in 1 min here, so will be on that
<carsonfull> We are just in a cluster fuck right now with this 3.0/4.0 release
<carsonfull> It's hard to know if we can break BC on master or not
<gawainlynch> carsonfull: Yeah… a major version bump is hard at this point, but it is what we have :-/
<carsonfull> So once we branch for 3.0 what is master? 3.1 or 4.0?
<gawainlynch> Let's call this idea a "no fly"
<gawainlynch> 3.1
<gawainlynch> As is done by Symfony
* Krands (~Nicolas@2a02:a03f:ce0:b000:ed1b:7602:c01d:78cc) has joined #boltcms
<rossriley> BC breaks stay on feature branch until ready to work on a major release
<Bopp> yes
<carsonfull> I'm fine with having multiple branches like Symfony does. As long as we maintain them correctly
<Krands> hi
<gawainlynch> carsonfull: yeah… agreed… but I don't think we have enough buy in 
<carsonfull> rossriley: You are against?
<Bopp> I'm just worried we'll spend more time keeping branches in sync than actually developing
<carsonfull> It's really easy actually.
<gawainlynch> Bopp: Totally get your point… and it is genuinely a risk
<gawainlynch> ^also what carsonfull said
<Bopp> the last time we did it proved otherwise
<carsonfull> If the branch applies to 3.0 it gets PRed to 3.0 and then 3.0 is merged to master.
<gawainlynch> Yeah, poor coordination on our combined part
<carsonfull> canary did not follow that model at all, if that's what you're talking about
<Bopp> regardless, we're not disciplined enough for that.. 
<Bopp> When did you late update changelog.md? 
<Bopp> <last
<gawainlynch> Possibly… but my concern for raising this Bopp is that we waste a lot of valuable peoples time in over extended freezes
<carsonfull> ^ this
<gawainlynch> Bopp: You called ownership on the changelog a while back to be fair
<Bopp> they should suck it, as far as i'm concerned. 
<gawainlynch> Suck?
<Bopp> we spend way too much time as it is supporting the unstable 'master'
<carsonfull> We do?
<gawainlynch> Yes… but we've just made the default branch the stable one
<carsonfull> I've never helped anyone on master branch
<gawainlynch> `git clone` will now give you `release/2.2`
<SahAssar> Bopp: that's a choice, right? supporting an unreleased version is not "mandatory".
<carsonfull> I tell them it's unreleased
<Bopp> carsonfull: yes.
<carsonfull> yes to what?
<Bopp> carsonfull: be here more during the day CET, and you can do your share. ;-)
<gawainlynch> Bopp: He does plenty in US time zones from my logs
<carsonfull> Bopp: Just tell them it's not released and point them to 2.2
<Bopp> SahAssar: true, but in practice we still help them out, even though we've told a million times not to use 2.3 / 3.0
<gawainlynch> carsonfull: Yes… but until 40 minutes ago, cloning gave you master… that is no longer valid
<carsonfull> Also, this iteration should be an exception since it has been entirely too long
<Bopp> ok, this is _not_ an attack on you, carsonfull.. Just pointing out that we spend too much time supporting 'master' to people using it when they shouldn't 
<SahAssar> If this is an issue then setting the default branch to 2.2 should help. It's a clear indication that, unless you *opt in* into a dev version you get stable.
<carsonfull> Bopp: I know. And I'm just saying "why? and just don't"
<gawainlynch> Yes… but I think that last week's suggestion to change the default was the one to solve most of that problem
<Bopp> carsonfull: because we're too nice.
<gawainlynch> #insult everyone
* [BoltIssueBall] calls out everyone, the wayward swag-bellied bladder!
<carsonfull> Bopp: You just said "tell them to suck it" haha
<Bopp> Yes. 
<gawainlynch> OK… everyone… if it is OK… this is not achieving an outcome… let's put it on ice for a bit and think
<Bopp> yes, move on. 
<carsonfull> gawainlynch: Let's write it up and come back to it
<gawainlynch> Well… I think the remainder can wait until next week
<gawainlynch> We want slick0 for both the remaining points
<gawainlynch> Anyone object to calling beer time?
<Bopp> I'm pooped
* gawainlynch hugs Bopp 
<carsonfull> Yes, this is exhausting
<gawainlynch> This was always going to be a hard meeting