2015 11_Meeting_IRC_Log

<Marc9> Start of meeting
<Marc9> 1. Dividing the work
<Marc9> Is there something to discuss here
<Marc9> ?
<Marc9> Security coordinator = Madhura?
<madhuracj> On the mailing list we discussed that it would be best to use trackers for this
<nijel> I'm not sure, security coordinator has been agreed already and for rest the issue tracker should be good enough
<madhuracj> I'll be happy to
<ibennetch> My opinion is that this solution is satisfactory to me as well
<Marc9> Will the two developers do a good balance of bugfix and development?
<nijel> Marc9: it always depends on number of incoming bugs ;-)
<madhuracj> @nijel Indeed
<Marc9> ok, nothing else on that?
<Marc9> 2. Vote
<Marc9> Who agrees to Chirayu's resignation?
<madhuracj> Vote in favor for both proposals
<Marc9> I do
<ibennetch> I also accept his resignation
<nijel> I vote for all three changes
<Marc9> Hugues and Atul do (by email)
<ibennetch> And I vote to accept both Deven and Dan as new members
<Marc9> Marc, Hugues and Atul accept both Deven and Dan
<Marc9> So it's done, congratulations to Deven and Dan
<ibennetch> Congratulations!
<Marc9> 3. Theme configuration directives
<DevenB> Thanks to all the team! :) I am honored.
<Marc9> Switching away from $cfg for these
<nijel> Do we really need these settings? I think it should be part of theme, otherwise things will most likely look bad...
<ibennetch> I am interested in Hugues' suggestion and wonder if anyone sees any potential problems with that implementation
<Marc9> nijel, someone wanted to just change the main background in metro I think
<Marc9> ibennetch which suggesiton?
<ibennetch> Hm, then they should edit the theme directly, I think.
<ibennetch> Marc, one moment while I find it
<DevenB> Marc9, ibennetch was talking about "thinking about using an object (maybe a singleton), instead of a global variable"
<ibennetch> > Theme configuration directives: shouldn't we think about using an object (maybe a singleton), instead of a global variable?
<Marc9> nijel, do you mean we would remove these directives from the doc and let people on their own?
<DevenB> I think so
<ibennetch> Thanks Deven
<madhuracj> Marc9 He came up with a new theme. So, I'm not sure how often these directives are used
<Marc9> ok I see, but maybe we should just get rid of them
<Marc9> switching to an object would be lots of changes for all of the themes
<Marc9> I agree with madhuracj that I'm not sure how often these directives are used
<nijel> Marc9: yes, if somebody wants different theme, just edit it. making theme work nicely with background changes is extra effort and I don't think any current theme is actually prepared for this...
<Marc9> (also related to the next point (theme creation tool) )
<Marc9> OK to remove the doc on these and just refer people to change directly in layout.inc.php?
<ibennetch> That's what I think is best right now
<madhuracj> Agreed
<nijel> ok
<Marc9> I can work on that
<Marc9> Moving on
<Marc9> 4. GSoC 2016
<Marc9> I suggest a two-week period starting from now,
<Marc9> where potential mentors update the ideas list
<Marc9> sounds good ?
<nijel> Good idea
<ibennetch> It sounds reasonable
<Marc9> After which, we would know who are the potential mentors :)
<madhuracj> sounds good
<Marc9> How about the Theme creation tool idea for GSoC?
<Marc9> I think it's worth adding it to the list
<ibennetch> Seems good to me as well.
<nijel> Sounds interesting
<ibennetch> I think it fits the Google requirements for a project and we might get a good proposal
<nijel> Maybe it could be complete download customization tool, something like javascript toolkits have
<nijel> one could also choose which parts to include in the download (optional parts, languages, themes)...
<Marc9> Well, in the list we might give some clues about how the tool will work
<ibennetch> Where the user can select that they want the charts plugin and this theme and that theme, but no other languages? Interesting idea.
<Marc9> I'm not sure that we should mix these two ideas
<nijel> Something like this: https://getbootstrap.com/customize/
<Marc9> because if someone creates a theme, he might want to offer it to others
<nijel> okay, I was thinking about theme customization, not creating new themes, so it indeed is different thing :-)
<Marc9> I suggest that potential mentors add these two ideas to the list;
<madhuracj> May be both ideas can be projects on their own
<Marc9> if there are more that one potential mentor, just add your name
<Marc9> madhuracj, I think the theme creation tool is enough for GSoC but I'm not sure about the download one
* udan11 (~udan1107@109.166.137.190) vient de rentrer
<madhuracj> Yes, will have to evaluate the workload
<Marc9> look what I did in Enhancements collection A
<Marc9> Hi udan11, you have been accepted to the PLC
<udan11> Hello
<udan11> Thanks.
<Marc9> we are at point 4
<ibennetch> Congratulations udan11
<Marc9> in collection A I added a big point and smaller points for GSoC
<nijel> I think it can be big enough (it needs to implement way to customize themes, possibly also add more strip down options)
<Marc9> https://wiki.phpmyadmin.net/pma/GSoC_2016_Ideas_List
<ibennetch> Yes, I like what you've done there Marc.
<Marc9> nijel, a way to customize themes?
<Marc9> ibennetch thanks
<Marc9> (by the way, when someone picks an enhancement issue, even for GSoC, he assigns himself to it)
<Marc9> nijel what do you mean by customizing theme? I think that the theme creation tool would also have the edit theme feature
<nijel> maybe these two would fit nicely together....
<Marc9> in one idea you mean, or in one tool?
<nijel> maybe they could share same backend - for theme creating you IMHO need more control than for customized downloads...
<Marc9> nijel, ok; moving on?
<nijel> ok
<Marc9> Who will be our org admin and backup org admin?
<nijel> I can do it as usual, but I'd happily leave it to somebody else :-)
<Marc9> I can do it
<ibennetch> I could be the backup
<nijel> okay, we seem to have admins now
<Marc9> Looks like nijel will have a vacation of org/backup this year :)
<Marc9> moving on
<ibennetch> Congratulations to nijel ;)
<Marc9> 5. Packagist (follow-up)
<Marc9> Dan?
<udan11> Well, i've asked the team, but they are not going to implement anything
<udan11> That we want
<udan11> Or that's the way it seemed.
<udan11> The issue is still open in their GitHub repo
<Marc9> udan11 do you think there's still hope?
<udan11> No, I do not think so.
<Marc9> we have an issue of our own on this, right?
<udan11> Maybe we can add installation instructions that specify the composer command with our package in the readme
<udan11> Yes.
<Marc9> udan11, can you work on this?
<udan11> Yes, sure.
<Marc9> moving on :)
<ibennetch> I think we should document a bit of our efforts in our own issue item, just so we can remember later what difficulties we encountered
<ibennetch> Or at least refer to the meeting notes from last month
<Marc9> ibennetch I agree
<Marc9> 6. Ability to disable the navigationhiding Feature
<Marc9> One of my users got bitten by that one
<madhuracj> Not sure it's worth adding a new configuration
<Marc9> "Lost some tables"
<Marc9> I'm not sure either but I'm 55% in favor :)
<nijel> maybe have special value for users not wanting particular feature? Setting $cfg['Servers'][$i]['navigationhiding'] = null would disable it without warning
<madhuracj> That sounds quite generic
<Marc9> or just = 'disable'
<Marc9> I like the idea
<ibennetch> I'm having trouble deciding about this, on one hand I do not feel we should add an extra directive to disable _each_ possible option, but I also very much understand the user's complaint.
<ibennetch> I really like nijel's idea. Is such a thing reasonable?
<Marc9> ibennetch, with nijel's idea no need for extra directive
<Marc9> ibennetch it's reasonable, we need to tweak the logic that gives warnings
<Marc9> and that generates the *works thing
<Marc9> madhuracj "quite generic" means you're in favor?
<madhuracj> Yes
<Marc9> other opinions?
<Marc9> Moving on
<DevenB> I agree Nijel's suggestions seems nice.
<Marc9> 7. Suggestion for milestone 4.6.0
<Marc9> I suggest March 1, 2016 for 4.6.0. At this point I believe we'll have enough new features and refactoring in the master branch.
<Marc9> This would mean that GSoC 2016 would target a 4.7.0 release.
<nijel> sounds like reasonable target date
<madhuracj> Sounds good to me as well
<ibennetch> Sounds like a good plan, as I recall we try to do a release before GSoC and then again after the summer
<Marc9> ibennetch yes that what we have been doing in recent years
<ibennetch> Then it makes sense to continue as that seems to have worked quite well
<ibennetch> I agree to your proposal
<Marc9> By the way, being a team member does not block one from being a student for GSoC
<Marc9> other opinions on the milestone date?
<udan11> It seems to be ok. :)
<DevenB> I am in favor too, given that it seems to have worked well this year too.
<Marc9> Anything else to discuss today?
<ibennetch> No, I think that's it for today
<Marc9> End of meeting