Dev meeting 2017 07 04

Agenda

• 3.3 beta/release progress see tracker #6001 (@Bob)
• [RFC] Twig relationship/taxonomy/contentype functions & filters #6774
• Proposal: Permanently ban all self-merges that do not have a approve review from another member of the team (@SahAssar)
• Removing {{ fields() }} in v4
  • #6780
  • #6781

e.g.

• Status on drop bear invasion (@YourGitHubID)

Actionable Items

Outcomes

Log

bob 
[7:30 PM] 
Ping @ross, @gawainlynch, @sahassar, @carson

sahassar [7:30 PM] 
Pong

bob [7:30 PM] 
19:30 o' clock!

[7:31] 
I suspect neither Gawain or Carson will attend tonight.

[7:31] 
So, depending on whether or not Ross will show, i guess it's going to be a short one! :slightly_smiling_face:

[7:32] 
Ok, off we go..

[7:32] 
#6001 :

boltissueball [7:32 PM] 
#6001 [open] [Tracker] Bolt 3.3 Release Blocking Issues https://github.com/bolt/bolt/issues/6001

bob 
[7:32 PM] 
Two issues open that have @ross' name on it, before we can move to RC.

sahassar [7:32 PM] 
Right, have you caught up on that?

[7:32] 
Ah, great

bob 
[7:33 PM] 
.. and one open PR that needs some work from Carson.

[7:34] 
I'll nudge both of them to work on it, when I see them.

[7:34] 
Next:

[7:34] 
> [RFC] Twig relationship/taxonomy/contentype functions & filters #6774

boltissueball [7:34 PM] 
#6774 [open] [RFC] Twig relationship/taxonomy functions & filters https://github.com/bolt/bolt/pull/6774

sahassar [7:34 PM] 
Me and carson had a discussion in that area, not sure it you saw it?

bob 
[7:35 PM] 
yes.

[7:35] 
I personally see no benefits to it, only downsides.

[7:35] 
1) It'll be like #6566 only more so.

boltissueball [7:35 PM] 
#6566 [open] [RFC] Asset() replacing Paths variable makes templating more obscure https://github.com/bolt/bolt/issues/6566

bob 
[7:35 PM] 
2) we lose the ability to "dump" a record to inspect it, unless we do some more magic to provide that.

[7:36] 
But, if we do, the point of it is gone again.

[7:36] 
So, why should we want this?

sahassar [7:36 PM] 
The dumpability was what my and carsons discussion was about (edited)

bob 
[7:36 PM] 
Yes, that I saw

[7:36] 
Are you in favor of it?

sahassar [7:37 PM] 
Dump is basically a bad solution for the use case that it is used for. it shows things that you can't access and does not show things you can

[7:37] 
I think we can't merge it until we have a proper replacement for dump, which will probably be `|explain`, but when we have that I'm all for it

bob 
[7:38 PM] 
Ok. fair enough.

[7:38] 
Let's leave it on the agenda for now, so one of the proponents can explain what's to gain from doing this. :slightly_smiling_face:

[7:39] 
> Proposal: Permanently ban all self-merges that do not have a approve review from another member of the team (@sahassar)

[7:39] 
Ok, let's put it to a vote.. I vote 'aye'.

sahassar [7:39 PM] 
Right, I think this one is crucial, but we need the whole team to agree on it IMO.

bob 
[7:39 PM] 
Let's leave it on the agenda as well, then.

[7:40] 
I think merges like "Adding a single line to the changelog" or "fixing a typo" should be exempt, but anything _functional_ needs to be approved and merged properly

[7:40] 
Finally for today:

[7:40] 
> Removing {{ fields() }} in v4

[7:41] 
Since #6788 was already merged in, I think this is a done deal.

boltissueball [7:41 PM] 
#6788 [closed] [3.3] Deprecate {{ fields() }} and move to a block call https://github.com/bolt/bolt/pull/6788

sahassar [7:41 PM] 
I'm for it since it can be pretty easily replaced with a block call and IMO it makes it harder to learn bolt templating since it obscures how to access individual fields.

bob 
[7:42 PM] 
This new approach is workable for what we use it for, so i'm fine with it.

sahassar [7:42 PM] 
But I also think that it should not be decided by a one-man-merge

bob 
[7:42 PM] 
In this case it isn't.

[7:42] 
Gawain did it in a few steps.

[7:43] 
1) Move from "macros" to "blocks" -> self merged.

[7:43] 
2) Made a PR to _remove_ `{{ fields() }}`, basically, which wasn't merged. (edited)

[7:44] 
3) After some discussion, made a replacement PR to _replace_ `{{ fields() }}`with a working solution using blocks.

[7:44] 
4) I merged it in, tweaked it a bit.

[7:44] 
5) only remaining part is the PR to remove from 4.0

[7:45] 
So, while it went a bit bumpy, there's no real harm done, and the resulting situation is better.

sahassar [7:46 PM] 
Right, I'm still not comfortable with 1, but that is covered in a previous point in the agenda. If it were up to me we would not use it in the default template (block, function or macro or whatever), but I understand that is somewhat contentious.

bob 
[7:47 PM] 
Step 1 i would've merged in without any hesitation either.. If only it had been a PR for anyone to review, i'm sure it would've been merged in without much friction

sahassar [7:47 PM] 
agreed, that is not the point

bob 
[7:47 PM] 
A nice thing about the _current_ situation is, is that it's entirely contained to the theme..

[7:47] 
Which makes it so much easier to ignore / remove by people who have no need for it.

sahassar [7:48 PM] 
The *default* theme.

bob 
[7:48 PM] 
yes, and it is absolutely required there, because it leads to confusion for novices.

[7:49] 
Anyhow, I'm sure this makes it _less_ of an issue, because there's less magic involved, and easier to follow for people who want to figure out what's going on there.

sahassar [7:51 PM] 
Yeah, agree. I think we might do well to market the default theme not as a "building base" and have something like bolt-extension-starter for that though, it feels to me like we have clashing goals in there

bob 
[7:51 PM] 
Yes, that's been on my wishlist for a long time..

[7:52] 
Basically two themes: One that works "out of the box" and looks nice for novices..

[7:52] 
and one that is a good foundation to build your own themes on.

[7:52] 
But, time..

sahassar [7:53 PM] 
Well, three IMO:
* Default theme that just works and looks nice
* Minimal base that one can build on if you know what you are doing
* "Showcase" theme that can show what bolt/twig has to offer and serve as a copy-paste repo for some stuff (edited)

bob 
[7:54 PM] 
Sure, but would cost even more time. ^_^

sahassar [7:54 PM] 
Yeah, agreed

bob 
[7:54 PM] 
Meanwhile, we're halfway 2017, and still on 'base-2016' :slightly_smiling_face:

sahassar [7:55 PM] 
We were on base-2014 for two years, right? :smile: (edited)

bob 
[7:55 PM] 
yeah...

[7:55] 
but that shouldn't become the norm

sahassar [7:56 PM] 
The nice thing about a "tiered" approach is that we can reference down though, and keep a common base for all of them

bob 
[7:56 PM] 
I can also see a "bare bones" theme needing less maintenance.

sahassar [7:56 PM] 
Yeah, and that maintenance could be merged up into the other themes.

bob 
[7:57 PM] 
Agreed.

sahassar [7:58 PM] 
Not to put any kind of pressure on this, but you started on base-2016-deluxe/base-2017, right?

bob 
[7:59 PM] 
Yes, i did.

[7:59] 
i have also a slightly more bare-bones Foundation theme.

[7:59] 
Just not enough time to finish it all up.

sahassar [8:00 PM] 
How do you feel about that becoming the "looks-nice, just works" theme, and reworking your foundation theme to become the base?

bob 
[8:00 PM] 
I've been hoping to get 3.3 off my plate for a while now, so i can get back to working on those

sahassar [8:00 PM] 
Right, let's pick it up after 3.3

bob 
[8:01 PM] 
It could even be stripped down further, but sure.

sahassar [8:01 PM] 
I hope to have more time after I rework the work stuff into the 20th century

bob 
[8:01 PM] 
Yes, getting 3.3 out of the door is priority no 1, now. :slightly_smiling_face:

[8:01] 
PSR-2 is a start! :wink:

sahassar [8:02 PM] 
Yep :slightly_smiling_face: Guessing we are pretty much done here?

bob 
[8:02 PM] 
This book is pretty OK: https://leanpub.com/mlaphp

[8:02] 
You know how i feel about the guy, so that means a lot coming from me. :wink:

[8:03] 
Yes, we're done i think!

[8:03] 
</meeting>