-
-
Notifications
You must be signed in to change notification settings - Fork 811
Dev meeting 2016 03 22
Gawain Lynch edited this page Mar 22, 2016
·
18 revisions
- [RFC] Limit thumb sizes to config presets (2.x) https://github.com/bolt/bolt-thumbs/pull/28
- v2 is feature blocked. Does this count as a bug / security fix?
- [RFC] Translate with an online translation platform #5042
- [RFC] Translation stuff #5056
- Tagging bolt/thumbs & bolt/filesystem
- Should we revert #3005 ? see #5071 & see #5073
- New docs coming together: https://docs-v3.bolt.cm
- New Base theme in progress
- Deprecation notices
<carsonfull> Here! :D
<slick0> pong
<phillipp> still here xD
<rarila> Bong
<SahAssar> pong
<phillipp> *looking at pizza*
<gawainlynch> Bopp is just… um… let's run with "grabbing beer"
<phillipp> no comment xD
<gawainlynch> Waiting a couple of seconds for Ross
<slick0> let's run with "scissors"
<gawainlynch> rarila: You in Amsterdam? ;-)
<gawainlynch> OK… First order… https://github.com/bolt/bolt-thumbs/pull/28
<rossriley> hello
<rarila> gawainlynch: not that I know of
<Bopp> Pong!
<carsonfull> -1
<gawainlynch> Anyone want to argue that 2.2 is a) *NOT* feature frozen; and b) that *IS* a security bug that can *NOT* be dealt with at the lower level?
<SahAssar> :silence:
<Bopp> I am in general in favor of that feature.
<phillipp> i am for adding thumbnail sizes to 2.2
<Bopp> but FOR 3.1 AT THE EARLIEST
<rossriley> I can see the arguement that it is a security exploit that some users might not be able to fix at a lower level
<carsonfull> But how easy is that to fix?
<Bopp> phillipp: 2.2 is feature-frozen, not going to happen.
<rossriley> best advice is to get fail2ban installed on your server, but not everyone can do it
<gawainlynch> SahAssar: Please speak up… I probably sound more gruff that I am :-)
<SahAssar> gawainlynch: nah, I just thought nobody would argue that ;) I'm not for pushing it on 2.2
<rossriley> but I am personally -1 on the approach, I much prefer the url digest protection
<gawainlynch> rossriley: But you can still put explicit allows for sub routes
<gawainlynch> …and the web server level
<slick0> agree with ross
<Bopp> rossriley: "url digest"? Is that with hashes or something similar?
<slick0> it's a workaround
<gawainlynch> *at the
<rossriley> yes you use a secret key to create a two way encryption of the url
<gawainlynch> slick0: So you're in favour of said work around?
<rossriley> then you know that only the server created the url and noone else can guess it
<Bopp> I really don't like that.. I like my URLs clean and evident.
<slick0> gawainlynch: meaning the PR is a workaround, where a key would be a better approach if the goal is to prevent ddos
<slick0> gawainlynch: but if the goal is a feature, then it should go to bolt next
<carsonfull> I'm in favor of the key hash
<rossriley> Bopp: but then you can leave it as is and install fail2ban on your server
<Bopp> something like /400x300/image-of-bridge.jpg _means_ something.
<Bopp> whitelisting the allowed sizes would too
* rarila hash url +1
<rossriley> so does: /xyzsecret/400x300/image-of-bridge.jpg
<rarila> You never type the url, you never see it: so what
<carsonfull> Yeah it really doesn't matter where in the url it's located
<Bopp> rossriley: i could live with that.
<phillipp> so if 2.2 wont be patched. can someone write down some ways to protect the server?
<gawainlynch> OK… someone slap me… but isn't this two different conversations?
<rarila> phillipp: update to 3.x ;-))
<slick0> may be worth looking at glide's implementation: https://github.com/thephpleague/glide/tree/master/src/Signatures
<rossriley> gawainlynch: kind of.. I said I was -1 on putting it in 2.2 and neutral on doing it at all
<phillipp> rarila: can you tag 3.x stable after the meeting? thanks :)
<carsonfull> Yeah thumbs #28 does not address that issue
-[BoltIssueBall]/#boltcms- #28 [closed] Use tagging for Packagist https://github.com/bolt/bolt/issues/28
<gawainlynch> rossriley: OK… same
<Bopp> Ok, consensus is NOT FOR 2.2
<slick0> yep :)
<carsonfull> Agreed
<Bopp> and let's re-visit when 3.1 features are open
<gawainlynch> OK… the fun stuff
<gawainlynch> Translations
<gawainlynch> #5042
-[BoltIssueBall]/#boltcms- #5042 [open] [RFC] Translate with an online translation platform https://github.com/bolt/bolt/issues/5042
<gawainlynch> #5056
-[BoltIssueBall]/#boltcms- #5056 [open] [RFC] Translation stuff https://github.com/bolt/bolt/issues/5056
<Bopp> I am - in general - FOR a translation service.
<phillipp> i loke crowdin but i wouldnt restrict all translations to it
<phillipp> *like
<carsonfull> -1 for 3.0
<gawainlynch> -1 for 3.0
<phillipp> -1 for 3.0
<slick0> -1 for 3.0
<Bopp> If there's one thing this recent kerfluffle has shown, is that's it's seemingly quite easy to get people enthousiastic about using a web interface to translate strings. ¯\_(ツ)_/¯
<slick0> +1 for 3.1
<Bopp> more so than YAML
<Bopp> but very firm -1 for 3.0
<gawainlynch> OK… I am keen to see what people have done "for real" on this
<SahAssar> +1 for as soon as realistic (so 3.1 I guess)
<gawainlynch> i.e. bigger projects that ours
<carsonfull> People are very quick to give their opinion but not so much when it comes to writing the code for it
<Bopp> I say we look into seeing what Drupal, JoomPress and Wordla are using.
<Bopp> not because "we should do the same", but just to get a feel for the options.
<rossriley> and then avoid whatever they are doing ;-)
<rarila> I hope we never do what they do
<gawainlynch> what rossriley said!
<rarila> rossriley: lol +1
<carsonfull> Regardless of what we do, it needs to fit into symfony translator
<phillipp> #karma rossriley
<[BoltIssueBall]> BoltKarma for rossriley is now 206
<gawainlynch> I more so meant in terms of having to integrate
<Bopp> rossriley: rarila: We "use PHP", so do they..
<rarila> Bopp: #1
-[BoltIssueBall]/#boltcms- #1 Port Bolt to Go to keep [BoltIssueBall] happy https://github.com/bolt/bolt/issues/1
* [BoltIssueBall] is written in Go, and therefore isn't allowed to like PHP
<Bopp> rossriley: rarila: "Because word/press does it" should NEVER be and argument to do something.. At the same time, it should also NEVER be an argument NOT do something. :-)
<gawainlynch> carsonfull: Tagging bolt/thumbs & bolt/filesystem … want to lead?
<carsonfull> Chyes
<carsonfull> fileystem needs to come first
<carsonfull> I have a branch almost done that changes interface slightly (removes caching from handlers)
<carsonfull> Once that's in we can tag beta there
<carsonfull> then thumbs after that
<GDmacWeb> Irccloud working on old iphone, live from pub
<Bopp> GDmacWeb: Cheers, mate!
<gawainlynch> #beer
* [BoltIssueBall] $this->app['bartender']->setDrink('beer')->setTab('gawainlynch')->serveAll();
<gawainlynch> carsonfull: Deprecation notices
<GDmacWeb> 25% battery, may i vote on 3005?
<carsonfull> gawainlynch? config first?
<gawainlynch> carsonfull: Sure
<Bopp> GDmacWeb: one sec.. that's the next point after this one
<rossriley> #3005
-[BoltIssueBall]/#boltcms- #3005 [closed] added config var replacement ability https://github.com/bolt/bolt/pull/3005
<gawainlynch> GDmacWeb: Fire away
<Bopp> ok. so now. :-)
<carsonfull> Also note ross's PR
<carsonfull> #5073
-[BoltIssueBall]/#boltcms- #5073 [open] Improve config replacement performance https://github.com/bolt/bolt/pull/5073
* gawainlynch hands rossriley a beer and a whisky
<Bopp> Ok, If Ross' PR fixes the performance issues, i'm cool.
<Bopp> There's one thing i'd like to note, though..
<carsonfull> Could this be enabled with an experimental flag?
<GDmacWeb> My question is, current doreplacements is recursive for arrays and succesive calls to same get are not cached
<Bopp> I've heard from a few different people that this implementation is fundamentally flawed..
<carsonfull> That way those who want it get it and those who don't don't suffer performance
<carsonfull> GDmacWeb: rossriley's PR fixes that
<Bopp> We should be 100% sure that _IF_ this is going in 3.0, we don't get support-nightmares from it.
<Bopp> If there's a change for that, i'd rather rip it out NOW, and implement something solid later.
<carsonfull> Also note that I'm refactoring all of Config in 3.1
<Bopp> <chance
<rossriley> Bopp: with that PR it’s a single pass of the array and if you don’t use it it will have zero effect on performance
<carsonfull> So maybe better to wait
<gawainlynch> carsonfull: NO! *I* am! :-P
<GDmacWeb> Have a link
<Bopp> carsonfull: yes, you mentioned. Will this one cause support issues.
<carsonfull> GDmacWeb: haha
<GDmacWeb> Huh¿
<carsonfull> Bopp: refactoring in 3.1? or replacements in 3.0?
<gawainlynch> ¿qué?
<rossriley> but I wanted to keep the principle of it in, because there’s a number of feature requests we get that may need it
<Bopp> i don't doubt Ross' PR fixes the performance issues.. Just not sure about support in upcoming versions.
<GDmacWeb> Can I have a link to ross' new pr (am on iPhone)
<gawainlynch> #5073
-[BoltIssueBall]/#boltcms- #5073 [open] Improve config replacement performance https://github.com/bolt/bolt/pull/5073
<Bopp> If y'all say this won't be another "templatefields", let's roll with it.
<carsonfull> I think the concept is solid
<gawainlynch> So is TF
<gawainlynch> …but implementation
<carsonfull> Exactly
<rossriley> well we can always change the implementation as long as the definition syntax is ok?
<carsonfull> rossriley: Can you expand on that
<carsonfull> I'm iffy on the service:params thing
<rossriley> as in as long as we’re happy supporting dynamic config with the syntax: `%var%` then how we map that at an implementation level is irrelevant
<Bopp> Assuming "definition syntax" is that we can change the implementation down the line, without Breaking Shit™.
<GDmacWeb> Comment: do it recursive once on boot and also on set.
<carsonfull> Which is why I bring up the service thing
<phillipp> i amfor blade syntax :P
<phillipp> *am for
<slick0> gawainlynch: ops
>ChanServ< op #boltcms slick0
* ChanServ gives channel operator status to slick0
<Bopp> {{! no !}}
<rossriley> popcorn
<phillipp> :D
* slick0 has kicked phillipp from #boltcms (NO BLADE)
<SahAssar> :D
<phillipp> lol
<carsonfull> rossriley: How do you feel about leaving that part out for now?
>ChanServ< op #boltcms gawainlynch
* ChanServ gives channel operator status to gawainlynch
<GDmacWeb> I'll test when home again. Not against dynamic vars. but must not cost many ms
<Bopp> GDmacWeb: This implementation will not, I promise. :-)
<gawainlynch> carsonfull: Deprecation notices
* slick0 feels the power
* phillipp (5b60622e@gateway/web/cgi-irc/kiwiirc.com/ip.91.96.98.46) has joined #boltcms
<Bopp> Welcome back, phillipp ;-)
<carsonfull> I'm not sold on current syntax as ross' pr implements
<phillipp> note to myself: avoid trolling with blade in dev meetings
<rossriley> carsonfull: we can finalise it on the PR thread if you like…
<gawainlynch> #karma phillipp
<GDmacWeb> Also, I need replacement inside strings. Eg. %rootpath%/foo/bar not sole strings (end and start with %)
<[BoltIssueBall]> BoltKarma for phillipp is now 4
<gawainlynch> rossriley & carsonfull: can you do that please
<carsonfull> GDmacWeb: I'm going to be working on that too. Again, a feature
<rossriley> GDmacWeb: yes, that’s what I was hoping to solve with passing params to callable
<carsonfull> Yeah we can finish offline
<Bopp> GDmacWeb: Add it to the PR / Issue, and we'll discuss it there. :-)
<GDmacWeb> I need them in menu.yml link
<gawainlynch> Deprecation notices…
<carsonfull> Deprecation notices!
<GDmacWeb> No compare de
<carsonfull> So much has changed in the past year. I doubt our users are going to look at all our docblocks to see this thing is deprecated. We need to log them to a place where they can be easily seen by users
<gawainlynch> https://github.com/bolt/bolt/wiki/Deprecations-Tracker
<GDmacWeb> No comprende (damn you autocorrect)
<carsonfull> I don't think this blocks beta but I want to get it in the final version
<gawainlynch> I've been compiling that to use for this
<Bopp> GDmacWeb: in menu.yml that's something entirely different..
<carsonfull> And I definitely want a clean break in 4.0.
<carsonfull> Having these notices allows us to say "we warned you"
<GDmacWeb> That menu yaml replace is why I supported dynamic replace. I still have doubts that ALL of app[] should be accessible
<Bopp> I'd say we get the Beta out, and we'll see how people respond..
<gawainlynch> Oh… doesn't this go into the exception handling we're doing?
<carsonfull> GDmacWeb: Dude. Feature. Come back in a month
<Bopp> might be that nobody is concerned about the deprecations. less work for us
<carsonfull> Bopp: But we will have users saying "I upgrade and now it doesn't work"
<gawainlynch> carsonfull: High level… what are you thinking of?
<carsonfull> gawainlynch: Not exactly the same as exception handling
<Bopp> carsonfull: for _most_ users that will be extensions breaking.. We can help them.
<GDmacWeb> Ok Carson, going inside pub in a minute. Will comment on pr for substring. See y'all in an hour or so.
<carsonfull> Bopp: They won't notice anything wrong because we are maintaining BC (mostly) for now
<carsonfull> That's not going to be the case for 4.0
<Bopp> true, true.
<carsonfull> High level:
<gawainlynch> carsonfull: Weren't we thinking in terms of the deprecation trigger errors?
<gawainlynch> …continue
<carsonfull> Deprecated::method(3.0, 'use foo instead');
<carsonfull> Also something to wrap $app values
<gawainlynch> Yes, that is what I was talking about
<carsonfull> But yeah under the covers trigger error. Which is what Symfony does too
<gawainlynch> Back on page
<carsonfull> Then those get hooked up to the logger either in backend or profiler
<gawainlynch> carsonfull: 3.0 or ^3.1.0 ?
<carsonfull> Hmm? Which version for?
<carsonfull> I would like to get it into 3.0
<gawainlynch> Are you trying to…
<Bopp> This is non-breaking, so they cn go in anytime before 3.0.0 RC afaic
<gawainlynch> No
<gawainlynch> Oh
<carsonfull> Bopp: Yes I agree
<rossriley> plus Bolt users are surprisingly quick to adapt… we changed a lot of stuff for the 2.0 release and the old stuff vanished fairly quickly
<carsonfull> rossriley: Good to hear!
<Bopp> carsonfull: on second thought.. yeah, no.. let's not for 3.0.0.
<gawainlynch> OK… here's the deal… this will one way or another potentially create a "blocker"
<carsonfull> Bopp: Do you have a reason?
<gawainlynch> i.e. let's draw a line in the sand for 3.0 and start this mission with that
<carsonfull> Reason for, is in this version a bunch of stuff is being deprecated
<Bopp> carsonfull: yeah, 3.0 has taken to long, we need to get it out.
<carsonfull> We still need a beta period though
<gawainlynch> Ture
<gawainlynch> *True
<Bopp> carsonfull: we've been _VERY_ strict over the last few weeks to people who wanted to "sneak in" minor things, and we should set an example for that.
<Bopp> (i'm guilty too)
* gawainlynch 3
<carsonfull> I don't disagree. But I feel like this isn't a feature
<Bopp> let's deprecate those things in 3.1, and still kill them for 4. :-)
<gawainlynch> carsonfull: My question to you though… do you have the time to get this in during that period, including bug fix stuff that only you and I know about
<gawainlynch> *help bugfix
<gawainlynch> carsonfull: I agree on the "feature" part
<carsonfull> I think so
<carsonfull> I almost had the implementation done last time I took a stab at it
<gawainlynch> (as in I wouldn't call it a feature and otherwise think the idea is OK)
<gawainlynch> Yeah, but mate… I had you up until nearly 05:00 your time today getting beta in line
<gawainlynch> I'm honestly worried that this is over capitalising
<carsonfull> Well that's because "me 4. sneeking in stuff"
<gawainlynch> …of your time
<gawainlynch> carsonfull: NOTHING WAS SNUCK IT… IT WAS ALL *NEEDED* :-P
<rarila> ppsssst
<gawainlynch> Anyway… this is dragging
<carsonfull> Ok let me see what I can come up with in the next week. Can we revisit then?
<gawainlynch> carsonfull: Let's take it up offline
<slick0> i think it's time to call it… v3 feature/change freeze, bug/security fixes only
<gawainlynch> Yes
<slick0> sound good?
* slick0 hides
<rossriley> lets do a beta then
<gawainlynch> slick0: That's where I am going
<slick0> ;)
<gawainlynch> Yeah, one las thing
<carsonfull> One last thing
<gawainlynch> Bopp: You bits… you have 120 seconds
<Bopp> one thing!
<rossriley> gawainlynch: doing his Columbo impression
<Bopp> If next week we'll have Symfony 2.9, and nothing apparent breaks.
<Bopp> will we update to that?
<GDmacWeb> This feature is in needs fixing lets but fix beta and ship :-)
<gawainlynch> ^2.8
<Bopp> check!
<GDmacWeb> Bug fix ( damn you autocorrect)
<carsonfull> Talk about a feature...
<carsonfull> I'm ok with it though
<Bopp> SahAssar: you here?
<gawainlynch> SahAssar: Bopp wants you to … that
<carsonfull> I would rather not limit to <2.8
<SahAssar> yuuup
<gawainlynch> Theme
<Bopp> carsonfull: we are on 2.8.x now, so it'll get bumped to 2.9 because of `^2.8`
<Bopp> Yes, theme.
<gawainlynch> Everyone… theme discussion from Bopp & SahAssar… then call on beta… then beer
<Bopp> Because SahAssar isn't here
<carsonfull> Right. If nothing breaks then sure
<SahAssar> yep, I've started and gotten partway. I'll hopefully finish in this week
<Bopp> Great!
<carsonfull> gawainlynch: Wait we can't tag a beta before thumbs and filesystem
<Bopp> I like where the looks are going for the theme.
<Bopp> but we need _something_ in for beta
<gawainlynch> carsonfull: IMHO, yes we can… release no
<carsonfull> It doesn't make sense. A dev version in a beta
<SahAssar> Bopp: ah, what are your thoughts?
<carsonfull> Let me just tag those first and update the references in core
<Bopp> SahAssar: So, it'd be awesome if you could wrap up something by - let's say - thursday noon, we can include that.
<Bopp> i dont want beta 1 and beta 2 to be completely different
<SahAssar> Yep, gotcha. that should be doable :)
<Bopp> "more finished" sure.. But we need a version by then. ;-)
<GDmacWeb> Start a beta, update existing sites in dev to beta. Find bugs. Fix bugs. New beta. Iterate.
<gawainlynch> carsonfull: We called the 17th last month, we've slipped and we need this out the door… how many 5am finishes do you want to do? ;-)
<carsonfull> As many as it takes lol
<Bopp> GDmacWeb: yes, but we also want the beta to be a bit stable too
* gawainlynch hugs carsonfull
<gawainlynch> carsonfull: Looks like we have a few days up our sleeves
<carsonfull> I thought we were doing beta tomorrow. else I would've had them tagged. We never talked about it
<Bopp> let's set the date for thursday!
<carsonfull> what time?
<gawainlynch> I'm calling Saturday
<rossriley> if we’re not careful it’ll be april fools day
<Bopp> ok, saturday then.
<gawainlynch> rossriley: I think you might have made that call about 9 months ago from memory
<gawainlynch> i.e. +1
<Bopp> but saturday it IS then.
<rossriley> ha, I wanted St Paddy’s day
<GDmacWeb> I'm for April 1 for next beta
<gawainlynch> Yeah, also your idea
<Bopp> i don't care if we ship shit that's broken all over, satuday is beta
<GDmacWeb> Go
<phillipp> xD
<SahAssar> #shipit!
<Bopp> yes.
<gawainlynch> Deary me
<GDmacWeb> It compiles, ship it
<Bopp> FATAL ERROR -> tough luck, try beta 2.
<Bopp> ;-)
<gawainlynch> </meeting>
- Bolt Wiki Home
- Tuesday Dev meetings
- Curated list of articles and tutorials
- Bolt internationalisation (i18n)
- Bolt Style Guide
- Roadmap
- TODOs
- [Tests] Unit & Functional Split
- [Tests] Code Coverage
- Core Team
- Bug/feature Process
-
Release Process
- Branching
- Packaging release builds