Dev meeting 2016 11 15

Agenda

• base-2017 weekly status report (@GawainLynch)
• Thumbnail aliases in back end, better approach (@GawainLynch)
• Review of proposed 3.x & 4.x branching strategy (@GawainLynch)
  • Concern: master would become "unknown" on remote, and anyone with write access could accidentally recreate it
• Local file system handling (@GawainLynch)
• Local Extension Replacement Plan #5964 (@GawainLynch)
• Diagram for the Boot-request-thingamajig-response cycle (@Bob)

e.g.

• Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

Log

<gawainlynch> ping carsonfull SahAssar slick0 Bopp gawainlynch rossriley etc
<Bopp> pong
<gawainlynch> msg ChanServ voice #boltcms gawainlynch Bopp slick0 carsonfull SahAssar rossriley 
>ChanServ< voice #boltcms gawainlynch Bopp slick0 carsonfull SahAssar rossriley 
* ChanServ gives voice to gawainlynch Bopp slick0 carsonfull
* ChanServ gives voice to SahAssar rossriley
* rarilaDroid (~rarila@dslb-088-065-063-065.088.065.pools.vodafone-ip.de) has joined #boltcms
<gawainlynch> Ugh … I suck at typing
<gawainlynch> Evening, rarilaDroid 
<Bopp> :-)
<rarilaDroid> Nothing new
<Bopp> hey rarilaDroid
<gawainlynch> Fair point, rarilaDroid :-)
>ChanServ< voice #boltcms gawainlynch Bopp slick0 carsonfull SahAssar rossriley rarilaDroid 
* ChanServ gives voice to gawainlynch Bopp slick0 carsonfull
* ChanServ gives voice to SahAssar rossriley rarilaDroid
<rossriley> sorry, I’m late…. checking in
<gawainlynch> Expellent … Bopp … base-2017 weekly status report (others are in channel)
<Bopp> Not much news, other than some ideas floating in my head. :-)
<Bopp> in short, i want to _build_ on the things we have in base-2016 that are good, 
<Bopp> but complementary to that one, base-2017 should be pretty looking and ready-for-use
<Bopp> where base-2016 is more bare-bones
<rossriley> base-2016 has finally made it to try-bolt.cm
<Bopp> Nive
<rossriley> just in time for 2017
<Bopp> <nice, even
<gawainlynch> rossriley: Thumbnail aliases in back end, better approach — is that now in-hand?
<rossriley> depends whether everyone is content with what we have now….
<rossriley> I personally don’t see the need to go too purist on it, but others may disagree
<Bopp> ideally we'd use aliased images only in the backend, but the urgency is gone
<gawainlynch> I added that item when things were pretty much in flux … but ^ 
<rossriley> problem with doing that is that we need to handle two scenarios
<rossriley> one for users that have aliases and one that doesn't
<gawainlynch> Yeah, Carson suggested (well, one of the ones) was a route hash
<rossriley> yes, the security key is the ideal way to go….
<gawainlynch> Not even sure if that makes sense tbh
<Bopp> i think that defeats the purpose of the thumbnails
<rossriley> we said that from the start
<gawainlynch> Ah
<rossriley> but…. time and motivation
<rossriley> there’s other complications too to consider… in the wysiwyg I allow users to resize thumbnail images
<rossriley> and that means they can be any size in the backend
<gawainlynch> So really for b-e we shouldn't at all limit them?
<rossriley> I’m personally in favour of allowing the backend free-rein
<gawainlynch> Same
<Bopp> makes sense to me to
<gawainlynch> I'm already nervous toward limits we place on be
<Bopp> It never ceases to amaze how different some peoples workflow is from what I'm used to. :-)
* netrace_ has quit (Quit: Textual IRC Client: www.textualapp.com)
<gawainlynch> rossriley: One of the other things on the list was (well, I didn't add it now I looked) the roadmap … largely my fault as busy … but I am getting close to wanting to create the 4.x-dev branch, so it would be good to find some time to hash out what we want/don't for 4.0
<Bopp> so, yes. most limits we place on BE use will break somebodies workflow
<SahAssar> here now
<gawainlynch> SahAssar: Scroll up and comment as needed
<rossriley> yes, shoot some times at me and we can have an hour
<gawainlynch> Sweet, I am off to the US in 15 hours … but am planning on using part of that for non-physical interaction time
<gawainlynch> Apologies on my part
<gawainlynch> So next one I really wanted Carson here for but … 
<gawainlynch> Review of proposed 3.x & 4.x branching strategy (@GawainLynch)
<gawainlynch> Concern: master would become "unknown" on remote, and anyone with write access could accidentally recreate it
<SahAssar> How about renaming base-2016 to 'basic' or 'default' when base-2017 is done, so that people get that they are for different purposes and not just a more dated version of base-2017?
<gawainlynch> SahAssar first :)
<SahAssar> treat that one as 'async'
<Bopp> SahAssar: would work for me. 
<gawainlynch> I am not too much in favour, but not my area … my concern is "what happened to my 2016?"
<Bopp> gawainlynch: _existing_ installs won't change. 
<[BoltGitHubBot]> [bolt] graham73may opened issue #6050: [BUG] getContent can't handle multiple contenttypes with a taxonomy where clause if all post types do not have the  https://git.io/vXMDo
<Bopp> only _new_ installs will have a new default theme. 
<gawainlynch> Bopp: I get that, but new ones won't line up with docs, correct?
<Bopp> (which they will have anyway, whether it's named `base-2017` or `base-ready-to-go` )
<gawainlynch> Plus … OhEmGee … tests
<SahAssar> Does the docs even mention the theme?
<Bopp> gawainlynch: We'll udate docs for 3.3 or 3.4 or whatever minor is ships with
<gawainlynch> SahAssar: No idea, thinking ahead :-D
<Bopp> *it
<gawainlynch> Whiny b-e person is whiny 
<SahAssar> :D
<gawainlynch> You all gt most of the load on this, so if you're happy, so am I
<gawainlynch> *get
<Bopp> It's mentioned in a tiny few places, will take the better part of 10 minutes to fix. 
<gawainlynch> rarilaDroid: Can I Have my keyboard back? 
<SahAssar> So, the one thing I'd like (that is within my personal grasp) for 4.0 is the changes in config structure
<gawainlynch> Well, interesting you should mention that , SahAssar 
<gawainlynch> I wanted Carson here for that one too … but lets roll
<rarilaDroid> gawainlynch: you need some direct brain control interface
<rarilaDroid> gawainlynch: oh, no… "me cant't think"
<gawainlynch> So … what we can't fully answer, but rossriley  is part of the story, is that I think we should call a day on features for 3.3 and "normal" cycle it
<gawainlynch> There is a lot in 3.3 now, but one of the hidden features is RFS … it is close to GTG
<Bopp> gawainlynch: My only concern would be "local extensions" which are present in 3.2, and gone from 3.3, without a replacement yet.
<gawainlynch> Bopp: That's included in above plan
<rossriley> I had got my named repeater blocks penciled in for 3.3 too, but I’ll prob work on that over xmas, so if it gets bumped to 3.4 thats fine too
<gawainlynch> …also why I wanted to get buy-in from Team Texas
* marcusj_ (~textual@x4d0c43da.dyn.telefonica.de) has joined #boltcms
* SahAssar was I supposed to start rolling on that one gawainlynch?
<gawainlynch> rossriley: Yeah … what I was explaining to Bopp the other night is … you, Carson *and especially* me … can't leave things alone with feature branches … and my config work alone sill needs a log of time
<Bopp> gawainlynch: How? Not wanting to be annoying, but what's the fallback / replacement?
<gawainlynch> #5964
-[BoltIssueBall]/#boltcms- #5964 [open] Local Extension Replacement Plan https://github.com/bolt/bolt/issues/5964 
<rossriley> ok, since we’re talking about extensions….
<gawainlynch> Fire away, Ross
<rossriley> we are sorely in need of an official public API for how to add extensions to the app….
<gawainlynch> +1
<rossriley> I’ve been trying to upgrade my 2.x sites, to 3.x
<gawainlynch> c.f. Team Texas
<rossriley> and already the stuff that was working in 3.0 is not in 3.2
<gawainlynch> Exceptions though?
<gawainlynch> FWIW allowing requests to fail again is only going to heighten some of the hidden problems too
<rossriley> it’s not that I don’t think… we did discuss that: $app['extensions']->add(new MyExtension()); would work
<rossriley> but it’s back to requiring a filesystem setting to be passed in now as the second arg
<gawainlynch> I had mixed results with that one, and that was part of what I hoped would get LE for 3.3 over the line :-/
<rossriley> plus, you can’t add extensions inbetween $app->initialize() and $app->run() 
<rossriley> and you can’t add them before $app->initialise() either
<gawainlynch> Yeah, that is two fold … initialize() is pretty broken in terms of cycle
<rossriley> so it’s quite clunky if you want to do it you have to extend the Bolt app object and overload initExtensions
<gawainlynch> :ears: btw
<gawainlynch> rossriley: Do you have ideas yet that don't break cycle?
<Bopp> (this conversation is an amazing bridge for the point I added to the agenda this afternoon, BTW. :-) )
<gawainlynch> Bopp: That is one of the ones I deleted :-D
<Bopp> wut?
<gawainlynch> (branches)
<rossriley> well if we can’t mess with the cycle at all, the only idea I can think of is have a separate stack that we can push to that handles manually added extensions
<SahAssar> "Diagram for the Boot-request-thingamajig-response cycle"
<Bopp> ^ that one ;-)
<rossriley> something like $app[‘extension.queue’]->add(new MyExtension());
<gawainlynch> Bopp & SahAssar: I just meant I had a long-running docs branch 
<rossriley> that is ready after app construction
<gawainlynch> rossriley: That would work
<gawainlynch> *wold/could
<gawainlynch> Ugh
<gawainlynch> rossriley: One of the breakers that you're hitting was trying to prevent people abusing cycles
<gawainlynch> …your suggestion doesn't
<rossriley> for manually added extensions there’s no need to worry about paths, root can default to the dir the extension class is in
<gawainlynch> Agreed
<Bopp> gawainlynch: As i mentioned this afternoon, i'd think it be good to salvage those, but not precisely what I mean.. I'll explain what I meant when we get there. 
<rossriley> web root can default to public/extensions/extname
<gawainlynch> rossriley: Exactly my current thought 
<gawainlynch> rossriley: The hard part was initially tying in the mess that is LE
<gawainlynch> s/is/was/
<rossriley> and then we also have a replacement for local extensions to
<rossriley> too
<gawainlynch> Yes, agreed
<rossriley> ok, so I can do that, but perhaps bump named repeaters to 3.4?
<gawainlynch> OK … so how is this for a meta-suggestion … 3.3 closed, sans LE replacement?
<gawainlynch> Snap
* marcusj_ has quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
<gawainlynch> rossriley: Has my vote
<Bopp> Would that mean that all our sites with local extensions would break on 3.3, with no easy way to fix? 
<SahAssar> 3.3 without LE replacement does not have my vote...
<rossriley> no, I’ll patch it so that the local extension dir is iterated over 
<gawainlynch> One of the points that is going to (maybe?) raise ire from Team Texas is the LFS 
<rossriley> and gets pushed to the above extension.queue
<Bopp> Ok, then I'm fine with that idea. 
<rossriley> so local extensions and manually added ones work the same
<Bopp> ^ 👍
<SahAssar> Oh, yeah, that sounds good
<rossriley> and then I will spend some time writing tutorials about how to manage extensions like a pro
<gawainlynch> rossriley: As long as it is queued, and doesn't break the cycle (esp. for the config work) then :+1:
<Bopp> Even more 👍👍
<gawainlynch> rossriley: So very serious question, what's your *practical* time-line
<rossriley> what’s the deadline?
<rossriley> I’ll get it done, I need to get my 2.x sites upgraded to 3 soon
<rossriley> and extensions are the blocker
<gawainlynch> None yet, but I would (if we can) like to do 3.3 EoY
<gawainlynch> (circa) 
<gawainlynch> Sounds like motivation for a result to me ;-)
<rossriley> my contract work for the year finishes on 9th December so I should have some time then to get this stuff sorted
<Bopp> If we're going to _shorten_ the 3.3 cycle, it should actually be shorter than our original plan, yes. :-)
<rossriley> so, yes mid december hopefully
<gawainlynch> Bopp: Yes, back to a normal cycle 
<gawainlynch> "normal"
<Bopp> So far, sounds good.. Was a tiny bit worried, but I like this plan. 
<gawainlynch> Scare/ironic quotes above
<gawainlynch> Yeah, more about refocusing, Bopp 
<Bopp> Still 👍
<gawainlynch> We've done well with focused releasing/branching … 3.3 is/was starting to worry me
<Bopp> I still think 3.2 is pretty nice. Let's keep that up. :-)
<gawainlynch> Personally, my drive here is to get/keep short focused cycles and not have a 2.3-dev
<Bopp> I'm sure we all agree on that
* gawainlynch screwed the proverbial pooch (with help) on that one
<gawainlynch> Bopp: On the diagram thing … one of the reasons it never PRed is that I was never clear on how much detail is needed
<Bopp> ok, right. 
<gawainlynch> It is kinda complex right now … but assuming we get 4.0 right, it is easy
<Bopp> If I recall, the last time I had a hissyfit about it, 
<gawainlynch> But getting across to people the "correct way" versus a lot of what *actually* happens is kinda tough to explain
<Bopp> Carson said "How about I draft something up, and then you make it look nice and understandable?"
<gawainlynch> Bopp: Yes you did … that is why I started said branch 
* SahAssar would benefit from one of those too... I sorta think I have a handle on the basic concept and then it flies off.
<gawainlynch> OK … 2 second job here …
<Bopp> So, if you have something, i'll gladly go over it, and see if 
<Bopp> a) i can follow
<Bopp> b) apply some pretty-sauce
<gawainlynch> Bootstrap -> registration cycle (nothing, and I mean *nothing*) should be touched/queried/loaded at that point … then boot -> then request … in boot services can be invoked, but things like request data must not be needed
<gawainlynch> Problem is, until 3.2 we invoked most everything in bootstrap
<Bopp> 🤔
* SahAssar needs to install noto on my web IRC client to see that emoji :D
<gawainlynch> Registration is about telling the application *what* it can *set up*… boot starts stuff and builds routes/controllers … request is the point where you know what route your might be on, what database to connect to, etc
<gawainlynch> But we don't do that yet
<gawainlynch> Hence why documenting this is so hard
<Bopp> But even with those caveats, we can make a nice diagram of that. 
<SahAssar> gawainlynch: EARLY_EVENT is just before request, right?
<gawainlynch> Yeah, until "why is my DB slave not registering… you cik!"
<Bopp> To actually document why it's hard. 
<gawainlynch> s/sik/suck/
<gawainlynch> SahAssar: In request 
<SahAssar> In request, before normal before middleware which is before controller then?
<Bopp> And even then, i'm sure any diagram would help me, even if it's flawed
<Bopp> I found two examples online: https://www.elefantcms.com/docs/2.0/developers/request-response-cycle
<gawainlynch> SahAssar: EARLY_EVENT is priority 512 … controllers are later at (circa) 38 … LATE_EVENT is -512
<Bopp> http://book.cakephp.org/3.0/en/intro.html#cakephp-request-cycle
<gawainlynch> s/38/37/ (I think)
<gawainlynch> Bopp: Remove that bookmark :-D
<Bopp> gawainlynch: I'm no fan of either cake or that cms, just an example of the sort of diagram i have in mind
<gawainlynch> Bopp: Yeah … but if I was to draw you what we did pre-3.2 … OMG
<Bopp> We are post 3.2 now. ;-)
<gawainlynch> I am stil driving Ross mental with what I did in 3.2 :-/
<gawainlynch> (not his fault)
<SahAssar> gawainlynch: so the 'before', 'after' and the priority stuff like 'EARLY_EVENT' are just aliases for the same cycle? I though the difference between before and after was bigger.
* SahAssar should perhaps do these after the meeting
<gawainlynch> SahAssar: https://github.com/silexphp/Silex/blob/1.3/src/Silex/Application.php#L329-L344
<gawainlynch> SahAssar: The key is after is literally part of the response 
<gawainlynch> http://symfony.com/doc/current/introduction/http_fundamentals.html#the-symfony-application-flow
<gawainlynch> ^ hence the "burn that bookmark"
<SahAssar> I'll read that through, thanks :)
<Bopp> I'll _add_ that symfony bookmark. :-p
<gawainlynch> Even better: http://symfony.com/doc/current/components/http_kernel.html
<gawainlynch> Above is request cycle
<Bopp> Oh, nice.. 
<Bopp> I'd _really_ like to have that for Bolt :-)
<gawainlynch> We're getting there … it is part of why the B-E's get tetchy 
<Bopp> tetchy?
<SahAssar> Okay, I gotta go deal with my laundry... Will check the rest of the log when back
<gawainlynch> Ugh … apostrophe abuse 
<gawainlynch> http://www.merriam-webster.com/dictionary/tetchy
<SahAssar> And thanks gawainlynch for the links and explanation!
<gawainlynch> SahAssar: Zero stress … it is a communication thing :-/
<Bopp> BTW, i'm not trying to nag on about this, just the sooner this information is out of the heads of only a few people, the more helpful others like me can be. :-)
<gawainlynch> Well, the thing is … it is *really* obvious when you look at the SF classes  … Yes, I know … but it is how some of us learn and said people struggle explaining it past code 
<gawainlynch> But quite seriously, the SF docs have come a *long* way in the last 2-3 years … worth a re-look
<gawainlynch> In defence of those-that-are-not-Carson-Gawain-and-Ross … I still remember how hard it was reading what used to be there and getting my head around it too :-/
<Bopp> That is also sort-of the point i'm trying to make.. I can go only so far just by reading the code. But, once I do have a grasp on in, i'll happily help in improving scarce docs. 
<gawainlynch> Bopp: Funnily enough … one of the things that held me back PRing what I previously had, was; a) it is on symfony.com and b) we're not there yet
<gawainlynch> That is not currently how Bolt totally behaves … we're *really* close now though
<Bopp> Ok. 
<gawainlynch> Last bits of DI & config (and statics0 and we're there
<Bopp> Is it our goal to match the Symfony behaviour fully, then?
<rossriley> There's still some complications with the register / boot phases though
<rossriley> Like some services need config values on register
<gawainlynch> rossriley: Yeah, Carson & I are (mostly) on it … but Team Texas is overwhelmed 
<gawainlynch> rossriley: Yeah, and that is part of the config stuff that C & I have coming 
<gawainlynch> (help welcome btw)
<Bopp> So, if that's done, we can sit down, and make a diagram like the on symfony.com? 
<rossriley> Doesn't symfony solve it by having multiple compile passes
<gawainlynch> Bopp: When that is done, we don't need to
<gawainlynch> rossriley: Yeah, part of the hard problem … Silex 1 isn't up to the task 
<Bopp> Well, if only to make the lingo match up. 
<Bopp> that symfony page has no mention of "boot", "register" which i hear often about in our cycle. 
<gawainlynch> rossriley: C & I have thrown around a proper DI solution … but that would mean rewriting Silex, or moving to full stack 
<gawainlynch> …and he doesn't like my suggestion, I am not sold in his :-D
<gawainlynch> To be fair, Carson's is better 
<gawainlynch> Anyway … I am not seeing a lot more we can resolve tonight … does anyone have points to raise?
<Bopp> I had one thing, i thought..
<Bopp> .. but I seem to have forgotten.. 
<Bopp> ¯\_(ツ)_/¯ 
<gawainlynch> #beer ?
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('gawainlynch')->serveAll();
<rossriley> #beer
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('rossriley')->serveAll();
<Bopp> nah, not until thursday in copenhagen
<Bopp>  :-)
<Bopp> for me that is
<gawainlynch> I cheated … I came of my "diet" as I am travelling tomorrow 
<gawainlynch> …and Sunday
<gawainlynch> Bopp: Been a long time, would you like to do the honours? 
<Bopp> Sure thing 
<Bopp> <a href="javascript:meeting.close()">Close</a>
<gawainlynch> Touché