Skip to content

Dev meeting 2017 07 18

Jump to bottom
Gawain Lynch edited this page Jul 18, 2017 · 8 revisions

Agenda

e.g.

  • Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

  • Decline:
  • Accepted
    • Renaming branches to drop "release/"

Log

19:29] 
ping @bob @carson @ross @sahassar … @@ @lukeskywalker


[19:29] 
bob
Poing!


[19:29] 
sahassar pong


[19:29] 
bob @gawainlynch Don't forget to refresh the wiki page with the agenda this week. :wink:


[19:30] 
gawainlynch Yes, got the strike though's … thanks mate


[19:30] 
bob
:smile:


[19:30] 
sahassar Hey! Then I don't get to hold it over him! :wink:


[19:30] 
gawainlynch Okies … Lets roll … Ross will appear like the ninja soon enough :slightly_smiling_face:


[19:30] 
@sahassar Yeah, fair point :smile:


[19:31] 
ross ninja arrives


[19:31] 
gawainlynch OK, well 3.3.0-beta/rc was the first point … but #teamwork got that out the door today!


[19:31] 
boltissueball Woo, teamwork! https://koala.kx.nu/teamwork.gif


[19:31] 
boltissueball has boiled some water, and begins to brew gawainlynch a nice cup of tea.

[19:31] 
bob
whoohoooo

[19:31] 
gawainlynch I'd like to thank everyone for a long hard effort getting that one out

[19:32] 
carson Here!


[19:32] 
gawainlynch I'll update the non-Bob's on a few things later, but thank you all for sticking with it though a hard 6+ months!


[19:32] 
Carson, you continue to make my day … Good to see you!

[19:33] 
As you're here … First real point: Renaming branches to drop "release/"

[19:33] 
c.f. https://boltcms.slack.com/files/gawainlynch/F68NTB0U8/image.png


[19:33] 
gawainlynch mentioned this image: GitHub branches
Add Comment



[19:33] 
bob
What would be the benefit of that?


[19:33] 
carson Because they aren’t really releases

[19:33] 
releases are tags

[19:34] 
`release/3.2` is really `3.2.x`

[19:34] 
gawainlynch Well ^ that … and it is getting harder and harder to find the branch you want to PR against

[19:34] 
bob
https://github.com/symfony/symfony

[19:34] 
gawainlynch … and Bob's point :wink:

[19:34] 
bob
https://github.com/doctrine/dbal

[19:34] 
Just some random, anecdotal projects..

[19:35] 
They use it without `release/` too, so I guess.. Let's go with the flow. :slightly_smiling_face:

[19:35] 
gawainlynch Yes, and this is not a "hard and fast" call on my part … but increasingly it is becoming a hassle … it _did_ make sense when the repo was the common point for end users

[19:35] 
… but now, we've got a year plus of changing that in people's minds

[19:36] 
Oh … well that was easy :smile:

[19:36] 
OK, better question then … does anyone on the team object?

[19:36] 
bob
Not me

[19:36] 
ross don't really mind either way

[19:36] 
gawainlynch Svante?

[19:37] 
sahassar nah, go ahead :slightly_smiling_face:

[19:37] 
gawainlynch WFM … Moving on then

[19:37] 
PR clean up:
#6754
#6192

[19:37] 
boltissueball #6754 [open] $content type issue in UploadContainer->save https://github.com/bolt/bolt/pull/6754

[19:37] 
#6192 [open] [WIP] Live editor modals https://github.com/bolt/bolt/pull/6192

[19:38] 
bob
The "live editor" thing is flimsy at best.

[19:38] 
gawainlynch What to do with those two … 6192 isn't much to get over the line, but will need feedback/review

[19:38] 
Funnily enough, that is what I would have said about 6754

[19:39] 
bob
I'm afraid that merging in #6192 will lead to a shit-ton of work, to keep it working when moving to 4.0

[19:39] 
boltissueball #6192 [open] [WIP] Live editor modals https://github.com/bolt/bolt/pull/6192

[19:39] 
gawainlynch Personally, I'd like to see the end of LE, but I am not obsessive about that

[19:39] 
bob
And we're considering dropping live-editing, until someone (preferably someone new) steps up to take ownership of that.

[19:39] 
sahassar How much of #6192 is "NIH"'ed?

[19:39] 
boltissueball #6192 [open] [WIP] Live editor modals https://github.com/bolt/bolt/pull/6192

[19:40] 
gawainlynch I think it is a good idea, just an unmaintained feature

[19:40] 
bob
so, sam

[19:40] 
Yes.

[19:41] 
gawainlynch @sahassar: Not sure that it is NIH, but haven't thought it though that much … it just kinda went by the wayside for months, and we neglected to address it … much like that thing I missed of yours in Feb :confused:

[19:41] 
sahassar To me it looks like quite a bit, and if we are going that route we should look for a more complete solution to it, cause this is just a rabbithole that wont stop IMO

[19:41] 
gawainlynch ^ :+1: (edited)

[19:42] 
bob
Agreed.

[19:42] 
Let's :fire: the Live Editing for now.

[19:42] 
gawainlynch With 6754 same comment about the contributor being left out … The PR is the wrong approach, but we haven't followed up

[19:43] 
bob
That is, until the time someone can and will make time to spearhead it.

[19:43] 
When it comes to 6754: I don't see the harm in it, and it straightens a quirk from somewhere upstream we have no control over.. I wouldn't mind merging that one.

[19:43] 
gawainlynch It is 100% wrong though

[19:43] 
We will break things on our side to make Guzzle 3 work for one person

[19:44] 
bob
If that's the case then we def shouldn't merge it in, no

[19:44] 
gawainlynch That's been my personal objection since day 1 … but nothing more was communicated, partly my fault

[19:45] 
OK, well is there any "no" votes to politely rejecting both?

[19:45] 
bob
Double negatives, hard.

[19:45] 
gawainlynch Touché

[19:45] 
bob
I'd say "Yes, let's reject both"

[19:45] 
sahassar I'm okay with it

[19:45] 
gawainlynch I can't English any longer

[19:46] 
WFM… Last one then

[19:46] 
* Renaming some route parameter names in v4 for better semantics, e.g. $contenttypeslug -> $contentType (and using ->convert() to pass-in objects)

[19:46] 
This will introduce a BC break in v4

[19:46] 
But … IMHO make things a been more clear

[19:47] 
ross what sort of timescale are we talking about till 4.0 do we think?

[19:47] 
gawainlynch The 'T' camel case isn't a concern in the point, just for illustration

[19:47] 
@ross At this stage, Q1 2018

[19:48] 
Last night's SF & Pimple releases fixed something that I thought would take Carson and/or myself a while to fix … I had allocated 2-3 months in my head :smile:

[19:48] 
We still have a tonne of work to do though

[19:48] 
carson Which was what?

[19:48] 
gawainlynch The profiler slow down

[19:49] 
I don't have the PR number handy … but when I tested it untagged it still wasn't behaving … but once tagged the problem went away

[19:50] 
Also one of the "problems" I was seeing was some idiot leaving the debug logging on :facepalm:

[19:50] 
ross if we advertise it well enough in advance I guess that's ok, route name parameters are just a bit tricky because the routing.yml files tend to stick around for years

[19:50] 
gawainlynch You have a very good point

[19:50] 
That said, we did break some in "2.3"

[19:50] 
carson I want to work on routing too.

[19:51] 
gawainlynch can't keystroke

[19:51] 
carson replace controller event with a _priority_ attribute in routes. and have the router sort by priorities before matching

[19:51] 
Also I want to remove before/after events in routing.yml

[19:52] 
ross there's a few bugs with before/after settings too

[19:52] 
gawainlynch Way ahead of you on that desire, Carson … Not claiming the job, just the co-desire

[19:52] 
A lot of the contents of before methods will die with SF Sec. too (edited)

[19:53] 
ross what will the replacement be? all on events instead?

[19:53] 
carson Yeah

[19:54] 
I just don’t seem them as being used/needed in routing.yml. Am I wrong?

[19:54] 
ross well to be fair they don't work too well anyway so I'm not sure how many people are using them

[19:54] 
gawainlynch Events are a bit trickier to debug in some cases, I'll admit, but over all they are far more flexible

[19:54] 
ross i had to add a before called `::preAuth` to get it to work

[19:55] 
and getting one working on a service / another class doesn't seem to work either (edited)

[19:55] 
carson We aren’t saying for or against events. It’s just whether they can be defined in routing.yml

[19:55] 
@ross that is _supposed_ to work

[19:55] 
ross that's the only one I could get to work

[19:56] 
I was under the impression that just `before: preAuth` should work

[19:56] 
but it needed the `before: '::preAuth'` to work

[19:56] 
sahassar I'd like for them to be available there, but it also seems like they don't get much use, so... (edited)

[19:56] 
carson What I would rather see is more flexibility in the actual controllers. that way if a user needs to change something they can just write a custom controller without a lot of pain

[19:57] 
gawainlynch Yeah … My agenda item came from having to go though the pain of doing exactly that this week

[19:57] 
ross yes, I kind of like the idea of defining before/after style things in routing.yml

[19:58] 
but it could be solved in middlewares / events

[19:58] 
carson They _are_ middlewares/events

[19:58] 
gawainlynch @sahassar I think the lack of use is two-fold; a) They're currently _really_ hard to use; b) not documented, see point a)

[19:59] 
sahassar Yeah, agreed, but I think that If b is solved it could provide a lot of flexibility

[19:59] 
gawainlynch It sort of stuck me this week that if I am finding this hard … What hope is there for the average Bolt user?

[19:59] 
sahassar And the current bugs are worked out

[20:00] 
But still, not much current use and no real users asking for it probably means we shouldn't spend too much time on it

[20:00] 
ross yes, it took me a couple of hours to get it working too

[20:00] 
so pretty hard I think

[20:01] 
gawainlynch OK … Well I think this should be a "living discussion point" … I think we all want to see improvement, we just need to clarify and communicate internally how we're going to approach it (edited)

[20:01] 
carson There may have been /currently are bugs with it

[20:01] 
I know i fixed something relatively recently in that code

[20:02] 
Sounds like it could still be a good thing.

[20:02] 
gawainlynch Totally

[20:02] 
ross my thinking was that on the controllers we support both `Class::action` and `controller.service:action` and that the same syntax would flow through the before/after

[20:02] 
carson Yes it should

[20:02] 
ross but I think we haven't ported the before / after to the new syntax

[20:02] 
carson *is supposed to be coded that way

[20:03] 
ross but, it may be fixed in 3.3.... this was in 3.2 a couple of weeks ago I tried

[20:03] 
gawainlynch I was trying in 3.4

[20:03] 
carson Hmm maybe not

[20:04] 
Yeah ok nvm. Ross is right. before/after were never updated to work with services too

[20:04] 
But they also have special syntax too

[20:04] 
`::before` - the class name can be left out of the “callable” and it uses the controller class (edited)

[20:06] 
Ok I can fix that for whichever versions we deem important

[20:06] 
gawainlynch Well this very quickly out grew my point :slightly_smiling_face:

I think we have some ground to work on, esp. when you're able to come back on board Carson

[20:06] 
carson Yeah sorry for the rabbit trail

[20:06] 
ross oh, yes... we can change the names too

[20:06] 
that sounds like the easy part now

[20:06] 
gawainlynch Haha … Zero stress, this is fantastic!

[20:07] 
OK, does anyone have anything more to raise then?

[20:08] 
Oh … One thing from me … Current agreement, that I'd like us to stick to, is 3.4.0-beta1 next week with the release of 3.3.0

[20:08] 
bob
Nope, all good.. :slightly_smiling_face:

[20:08] 
ross I was gonna do a BoltForms RC/Release to match Bolt 3.3 too if everyone is ok with that

[20:08] 
bob
Yes, let's move forward with 3.4!

[20:08] 
:train:

[20:08] 
gawainlynch Good with me, Ross

[20:08] 
ross so RC this week and final next week

[20:08] 
bob
yes, the plan is 3.3.0 stable next tuesday,

[20:09] 
which is one week before i'll be offline for 2.5 weeks

[20:09] 
so, there's time to sneak in a 3.3.1, if needed.

[20:09] 
gawainlynch @bob: Friendly nudge on the access, plus an email with dates so I can put them in my calendar pretty please :slightly_smiling_face:

[20:09] 
bob
apart from that, i've updated the docs on how to make releases.

[20:09] 
Ah, yes..

[20:10] 
gawainlynch The latter preventing endless brain-dead questions from me :smile:

[20:10] 
bob
@sahassar I'd like to add you to the small list of people (me, currently) that has access to the @boltcm twitter account, and the news.bolt.cm/pilex news feed

[20:11] 
sahassar @bob: Alrightio :slightly_smiling_face:

[20:11] 
gawainlynch You'd be back up for Bob and I

[20:11] 
bob
I don't expect anything urgent, but it might be good for more people to have access to it.. Am going to add gawain too.

[20:11] 
Thanks!

[20:11] 
gawainlynch … or if you want, 2IC … just don't want to overload you

[20:11] 
bob
2ic?

[20:12] 
sahassar second-in-command

[20:12] 
bob
ah. :slightly_smiling_face:

[20:12] 
gawainlynch Well, traditionally ^ that … but more second in line (edited)

[20:12] 
sahassar I have no problems with either :slightly_smiling_face:

[20:12] 
ross we have our own Royal Line

[20:12] 
gawainlynch Haha!

[20:12] 
ross that means you can't travel on the same plane

[20:13] 
sahassar does that also mean that my plane will be called bolt-force-two? (edited)

[20:13] 
bob
We should make our own "nuclear football"

[20:13] 
ross the codes are hunter2

[20:13] 
gawainlynch can barely type from laughing

[20:14] 
gawainlynch Perfect … OK then … as we're finally getting a bit more cohesive again … who'd like the honours tonight?

[20:14] 
bob
I vote Ross

[20:14] 
gawainlynch hands Ross the hashtag

[20:14] 
ross #meeting

[20:14] 
boltissueball </meeting> Failed parsing XML: 'hug' expected, No 'love' shown for bot. Program 'meeting' terminated.

[20:15] 
gawainlynch Thanks everyone

[20:15] 
bob
:beer:

[20:15] 
gawainlynch :beers:

[20:15] 
ross :beers: #beer

[20:15] 
boltissueball $this->app['bartender']->setDrink('beer')->setTab('ross')->serveAll();

[20:15] 
gawainlynch #water

[20:15] 
boltissueball pours water over gawainlynch…  That is what they wanted, right?
Clone this wiki locally