2015 09_Meeting_IRC_Log

07:59 < ibennetch> The monthly developer meeting will begin in about a minute; the meeting will be logged and posted to the wiki.
07:59 < ibennetch> I can run the meeting if you'd like.
08:00 -!- madhuracj [~kvirc@39.147.240.220.dynamic.dsl.comindico.com.au] has joined #phpmyadmin
08:00 < ibennetch> Hello madhuracj
08:00 -!- Irssi: #phpmyadmin: Total of 32 nicks [1 ops, 0 halfops, 0 voices, 31 normal]
08:01 < madhuracj> Hello ibennetch
08:01 -!- zixtor [74cb4c84@gateway/web/freenode/ip.116.203.76.132] has joined #phpmyadmin
08:01 < ibennetch> Let's begin. Happy birthday to version 0.9.0!
08:01 < ibennetch> hi zixtor
08:01 < zixtor> Hi ibennetch and all
08:02 < zixtor> Happy B'day PMA :)
08:02 < Marc9> Hi zixtor
08:02 < ibennetch> Marc has a list of proposed issues to close, let's look at 4451
08:02 < ibennetch> Fixing HTTP basic logout
08:03 < Marc9> Fix looked too complex to me
08:03 < nijel> I agree to close it, cookie one is anyway preferred method
08:03 < zixtor> I am fine with closing it, seems not be problem for most users
08:03 < ibennetch> The user submitted code, but it's not a patch file so figuring out what he/she did is a bit difficult.
08:04 < madhuracj> And it's quite old.
08:04 < ibennetch> I don't remember any user complaining about this, so I agree to close it
08:04 < Marc9> Closed
08:04 < ibennetch> Okay, 4699, grouping databases
08:04 < madhuracj> I agree to close it
08:05 < nijel> I agree to close it, it seems too complex and not widely useful.
08:05 < ibennetch> Agreed
08:05  * Marc9 implicitely agrees to close all of these issues
08:06 < Marc9> Closed
08:06 < zixtor> I agree too
08:06 < ibennetch> Next is 5283, exporting multiple row query with variables
08:06 < ibennetch> Would this have changed with the new parser?
08:06 < madhuracj> This may be useful. But I suppose it wouldn't be easy to implement
08:07 < Marc9> edge case
08:07 < ibennetch> It seems to me that if we can fix this without too much work or difficult code, it's worth fixing.
08:07 < nijel> Having the export working for this might be useful, but probably not an easy task to implement...
08:07 < ibennetch> But yeah, it's a bit of an edge case, also.
08:07 < Marc9> 11 years old
08:08 < Marc9> I say, if it's important it'll come back
08:08 < madhuracj> And no one else has indicated that it's important to them.
08:08 < ibennetch> If it's important, I'd expect more than one reporter in 11 years :)
08:08 < madhuracj> Marc9: agreed
08:08 < ibennetch> Okay to close.
08:08 < nijel> Okay, let's close it
08:09 < Marc9> closed
08:09 < ibennetch> 5731 query collation in sorted browse mode
08:09 < Marc9> edge case and UI possible bloat
08:09 < ibennetch> I feel the UI is already full enough in browse mode that I don't know how we could implement this
08:10 < nijel> Sounds useful, but I don't see how to reasonably add this to the UI
08:10 < zixtor> I agree can't reserve space in UI for an edge case
08:11 < Marc9> or we would add a sort popup
08:11 < madhuracj> Yes, we can close it as well
08:11 < ibennetch> Okay, let's move on then to 5852, export records and relations.
08:12 < Marc9> out of scope IMO
08:12 < ibennetch> Maybe I don't fully understand this, I guess the person wants to select a MySQL user and export anything that user has permission to as one export, including the user privileges and all databases and relations.
08:13 < Marc9> ibennetch no it's about data itself
08:13 < ibennetch> Unless they mean inside of their custom database, which we surely can't do.
08:13 < Marc9> invoice, invoice items, etc
08:13 < Marc9> items descriptions
08:13 < zixtor> sounds useful but also too much work maybe
08:13 < ibennetch> Oh, then let's close it. It isn't phpMyAdmin's job to know about the data inside a database, this is way beyond the scope and too error prone to try to guess.
08:13 < madhuracj> I think it is indeed useful. I've come across situations where I wanted to do exactly this.
08:14 < madhuracj> But when I had a look at implementing this, the clutter it brings to the export logic seemed too much
08:14 < Marc9> maybe a GSoC project?
08:14 < nijel> It seems useful, I'd leave this one open (though I see it as very low priority)
08:15 < Marc9> we would only follow the existing relations
08:15 < madhuracj> I also agree to keep this open for now
08:15 < zixtor> I am okay with keeping it open
08:15 < Marc9> ok let's keep it open for now
08:16 < ibennetch> Okay, let's discuss the upgrade notification.
08:16 < ibennetch> 11464
08:16 < ibennetch> The easy -- and what seems to me the proper -- solution is to disable the version check for packaged distributions.
08:16 < nijel> But this is not only for packaged software...
08:17 < nijel> if your hosting runs some old PHP version, you can upgrade as well
08:17 < ibennetch> Good point.
08:17 < ibennetch> I was only thinking about Robert's case, but you're right.
08:17 < nijel> The problem is that in order to get updated code to users, we would have to release all branches, what sounds like an overkill for such thing....
08:18 < ibennetch> Yeah, I don't think we need a new release to implement this; just moving forward. I guess starting with 4.5 or if there are anymore 4.4 releases.
08:18 < Marc9> nijel and it's not sure that distros would pick the latest branch
08:19 < nijel> Marc9: most likely they will stick to branch they had at release time
08:19 -!- dstorm [~dstorm@14.140.151.110] has joined #phpmyadmin
08:19 < Marc9> There is also the point Michal made: difficult to see whether "PHP 5.3.3" included backported fixes
08:19 < dstorm> Hi everyone
08:19 < Marc9> Hi dstorm
08:20 < Marc9> nijel am I confusing this issue with another one?
08:22 < zixtor> I agree on packaged distros, there should not be version checks in PMA
08:22 < Marc9> zixtor you mean it's up to them to deactivate it, like Debian does?
08:23 < nijel> Marc9: the issue is only about version check, so I'd ignore the problem with PHP
08:23 < zixtor> yes Marc9, we leave it to package management
08:23 < nijel> what we could do is to include more information in version.json with PHP/MySQL versions required for each branch and the version checker would pick correct branch out of that
08:25 < zixtor> nijel: that seems what the reporter wants us to do?
08:25 < Marc9> nijel yes this would solve the problem for everyone; maybe, version.json should also indicate which is the latest version in each branch
08:25 < zixtor> makes more sense
08:26 < nijel> extending information in version.json is not a problem, problem is how to get updated code to users and whether it's worth of it :-)
08:26 < Marc9> nijel, with this in place, would you reactivate checks in Debian? :)
08:26 < nijel> Marc9: no I would not enable the check in Debian
08:26 < Marc9> nijel as ibennetch said, it could start in 4.5
08:26 < Marc9> nijel why?
08:26 < nijel> IMHO this feature is more for individuals installing phpMyAdmin than for distributions
08:27 < Marc9> nijel but Robert is asking this for Fedora/RH
08:27 < nijel> because if you rely on distribution packages, you want updates from the distribution and do not want to install something manually
08:27 < ibennetch> If a user has the distribution's version, the version check doesn't matter because (hopefully) the maintainer will keep the packaged version updated.
08:28 < Marc9> hopefully is the keywork here
08:28 < Marc9> keyword
08:28 < Marc9> so we leave the issue open?
08:28 < nijel> ibennetch: it won't get updates for anything else than security bugs if that's stable distribution
08:29 < Marc9> about getting the updated code, the best we can do is publish another release for 4.0 and 4.4
08:30 < Marc9> nijel, ah, good point
08:30 < ibennetch> Yeah, I phrased it poorly, I did mean security updates when I said "updated" -- not latest release.
08:31 < Marc9> nijel updated the issue
08:31 < ibennetch> Anyway, yes I think we should leave this open and I like the idea to add PHP and MySQL information to version.json.
08:31 < zixtor> seems fine
08:32 < Marc9> As 4.5.0-rc1 was released, I suggest to target 4.6 for this
08:32 < madhuracj> Marc9: fair enough
08:33 < ibennetch> Then let's discuss LTS
08:34 < Marc9> LTS for phpMyAdmin 4.0 and 4.4
08:34 < Marc9> (maybe an upgrade to LTS for 4.0)
08:34 -!- DevenB [~androirc@1.39.13.241] has joined #phpmyadmin
08:35 < Marc9> We have some LTS data for Redhat, what about Debian?
08:36 < ibennetch> Currently 4.0 is supported through January 2017
08:36 < Marc9> Hello DevenB
08:36 < ibennetch> 4.3 through October 2015
08:36 < DevenB> Hello all. Sorry for the delay.
08:36 < Marc9> 4.3 is not a problem, no LTS needed
08:36 < ibennetch> Hi DevenB and welcome
08:37 < Marc9> For 4.0 I suggest April 2017 to match with Redhat requirements
08:37 < ibennetch> Also hi dstorm
08:37 < dstorm> Hi ibennetch
08:37 < nijel> Debian Wheezy has 5.4 (supported till 2018), Jessie has 5.6 (supported till 2020), so that's non issue for us
08:37 -!- gigo1980 [~gigo1980@pD954D118.dip0.t-ipconnect.de] has joined #phpmyadmin
08:38 < Marc9> nijel are there older Debian with LTS?
08:39 -!- smita786 [4a7d3f21@gateway/web/freenode/ip.74.125.63.33] has joined #phpmyadmin
08:39 < Marc9> Hello smita786
08:39 < smita786> Hello Marc
08:39 < nijel> yes, squeeze until 2016 (PHP 5.3)
08:40 < ibennetch> Once Debian's official support ends, there's another LTS team that takes over support so Debian 6 is supported through them until Feb 2016 -- they package phpMyAdmin version 3.3.7 !
08:40 < ibennetch> Hi smita786
08:40 < nijel> ibennetch: I've already mentioned LTS dates here
08:41 < smita786> hello ibennetch and team
08:41 < dstorm> Hi smita786
08:41 < smita786> sorry for coming in late
08:42 -!- gigo1980 [~gigo1980@pD954D118.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
08:42 < Marc9> Smita we are discussing https://wiki.phpmyadmin.net/pma/2015-09_Meeting#Long_time_support
08:42 < ibennetch> nijel: I think we both hit enter at the same time, since I didn't see your response until just after I sent mine :) My point though is that with a release that old, I don't feel a responsibility to maintain it; at some point security support has to end.
08:42 < zixtor> Marc9: So does proposed April '17 fit with Debian?
08:43 < ibennetch> I think moving the date back to April 2017 is a good idea. It's only a few months and it helps the community.
08:43 < Marc9> zixtor which Debian?
08:44 < Marc9> Let's first discuss LTS for phpMyAdmin 4.0
08:44 < nijel> I don't see problem with April 2017 for 4.0
08:44 < dstorm> April 2017 is fine for 4.0
08:45 < zixtor> Marc9: ah, that I am not sure, as per LTS dates for whichever Debian that match
08:45 < ibennetch> So everyone seems okay with moving the date back to April 2017
08:45 < Marc9> fine with me (this is for 4.0)
08:46 < ibennetch> Correct, only for 4.0 at this point.
08:46 < madhuracj> Fine
08:46 < zixtor> I am fine with it too
08:46 < ibennetch> 4.3 will still expire in October and 4.4 will probably  get a date assigned at the next meeting, after 4.5 is released.
08:47 < Marc9> why not assign a date now for 4.4 ?
08:47 < dstorm> IMHO, 4.4 can end with 4.3
08:47 < dstorm> a little more than that if required
08:47 < nijel> 4.4 will be last version supporting PHP 5.4, so that will have to live a bit longer...
08:48 < Marc9> dstorm RHEL/CentOS 6 will support PHP 5.3 and MySQL 5.1 until 2020-11-30
08:48 < Marc9> but our 4.4 requires MySQL 5.5 !
08:49 -!- udan11 [~udan11@92.85.146.206] has joined #phpmyadmin
08:49 < Marc9> This would mean change phpMyAdmin 4.0 to Dec. 2020
08:49 < Marc9> Hello udan11
08:49 < udan11> Hello!
08:50 < madhuracj> 2020 is far into the future. I'm not sure about providing security support for such a long time
08:50 < nijel> I also don't feel like we should promise something like this
08:50 < Marc9> if we don't, it means we leave it to distros to backport security fixes if they apply
08:51 < nijel> we really can't serve the commercial LTS distributions in this...
08:52 < Marc9> So, keeping 4.4 supported for a long term is not required; let's say, 6 months
08:52 < Marc9> 4.5.0 is due on September 23, so 6 months after that for 4.4
08:53 < nijel> (seeing this in SUSE, basically no upstream supports what we still support and the dates for our support still extend as long as there some customer willing to pay enormous amount for extending them)
08:53 < ibennetch> ha ha
08:53 < Marc9> nijel so SUSE does not backport security fixes?
08:54 < ibennetch> I suppose users with old PHP/MySQL versions can run 4.0 as long as it's supported, instead of 4.4. They'll miss some features, but have security support.
08:54 < ibennetch> Not that I'd publish that, but it's a sort of workaround for an older distribution.
08:54 < nijel> Marc9: SLES doesn't include phpMyAdmin
08:55 < Marc9> nijel, but Novell Filr does
08:55 < nijel> but of course there are security fixes for supported software, in some cases it's only reactive  - the fix is released if some customer wants it
08:56 < nijel> Novell Filr is completely different part where I have no knowledge, sorry
08:56 < Marc9> I agree that 2020 is too far, so April 2017 for 4.0 and April 2016 for 4.4 ?
08:56 -!- DevenB [~androirc@1.39.13.241] has quit [Quit: AndroIRC - Android IRC Client ( https://www.androirc.com )]
08:56 -!- DevenB [73f91219@gateway/web/freenode/ip.115.249.18.25] has joined #phpmyadmin
08:57 < ibennetch> We're nearly an hour in to the meeting, let's try to wrap up the LTS discussion for today please.
08:57 < nijel> Marc9: these dates look okay to me
08:57 < dstorm> I am fine with April 2016 for 4.4
08:58 < ibennetch> That's six months, which seems reasonable to me.
08:58 < madhuracj> April 2016 sounds reasonable to me as well
08:58 < ibennetch> I worry if we have users who have older PHP or MySQL versions and will be stuck without security support, but it's not practical to maintain four different versions at once.
08:59 < ibennetch> Okay, so let's see about sponsorship, then.
09:00 < Marc9> We got a new Bronze sponsor (waiting for confirmation)
09:00 < ibennetch> Despite running a deficit, I don't have a strong desire to change sponsorship levels (aside from adding another silver level, as Marc mentioned on the mailing list a few days ago)
09:00 < dstorm> One question here, since when the rates are not changed?
09:00 < zixtor> But we can adjust the rates a bit?
09:01 < Marc9> For example, 100 -> 105 ?
09:02 < Marc9> dstorm they never changed
09:02 < nijel> I can see space for increasing them, however the question is how much and how to handle this most gracefully with existing sponsors.
09:02 < zixtor> yeah only slight increase maybe adjusted to make up for monthly deficit of 170 USD?
09:02 < dstorm> Marc9: In that case, when we started having sponsors?
09:02 < Marc9> 3 years I think?
09:03 < madhuracj> I also agree we can increase the rates, but not the number of slots
09:03 < Marc9> nijel yes this is problematic but "We reserve the right to change sponsorship levels in the future"
09:03 < dstorm> Then we can have some slight increase in rates.
09:04 < Marc9> zixtor we are now down to 70 USD deficit, due to the new sponsor
09:04 < nijel> did I understood it correctly that there is no deficit when we count yearly sponsorships as well?
09:04 < dstorm> We can increase monthly rates and keep yearly same
09:04 < zixtor> nijel: right as far as I know
09:05 < dstorm> or decrease discount on yearly rates
09:05 < zixtor> Marc9: great, so do we still need an increase ?
09:05 < Marc9> nijel how would you count yearly sponsorships?
09:05 < ibennetch> dstorm has interesting ideas, I like both of those.
09:06 < nijel> Marc9: just add 1/12 of them to monthly balance, that's not exact, but it's close enough to reality
09:06 < Marc9> nijel, when we do that, we don't have a deficit
09:07 < Marc9> dstorm I prefer to keep the yearly discount as it is
09:07 < nijel> I'd keep the yearly discount as they are - yearly payments makes processing much easier on our side
09:07 < Marc9> dstorm it's a good incentive for sponsors and it gives us an amount that we can count on
09:08 < nijel> also we don't want sponsors to come and go away every month...
09:08 < zixtor> I agree not to disturb yearly receipts
09:08 < Marc9> so, let's not do anything about sponsorshipts levels
09:08 < Marc9> (for now)
09:09 < dstorm> Marc9: when we increase monthly rates and keep yearly same then we are increasing incentives for yearly sponsors :)
09:09 < Marc9> dstorm true
09:10 < zixtor> So we can decide about small increase in monthly on the mailing list?
09:10 < ibennetch> I feel that the amount of income/expenses is close enough that I don't have a strong desire to change sponsorship costs just because of our accounting. If it's because rates haven't changed in three years or to push people to become yearly sponsors, that's fine, but our deficit is close enough to zero that it's okay for me right now.
09:10 < Marc9> zixtor let's do that
09:10 < nijel> I wouldn't mind raising the money to something like 200 / 400 / 800 / 1600 (and yearly rates accordingly) - we would loose some sponsors, but probably get more money
09:10 < zixtor> on to next issue?
09:11 < nijel> okay
09:11 < ibennetch> Okay, who can move this to the mailing list? Marc9 ?
09:11 < Marc9> sure
09:11 < ibennetch> Last issue is Drizzle
09:11 < ibennetch> Thanks
09:11 < nijel> let's drop support for Drizzle
09:11 < zixtor> fine for me as well
09:11 < Marc9> this item will be fast :)
09:11 < madhuracj> Agreed to drop support for Drizzle
09:11 < Marc9> we have a pull request :)
09:11 < madhuracj> :)
09:12 < Marc9> For 4.6 I mean
09:12 < dstorm> We can drop it in 4.6
09:12 < Marc9> (or maybe this will be phpMyAdmin 5.0)
09:12 < Marc9> due to full templating ;)
09:13 < ibennetch> I hate to remove code that works, but Drizzle doesn't seem very relevant or active right now.
09:13 < ibennetch> I'm okay with removing the support as well
09:13 < Marc9> ibennetch, with no users, does the code work? :)
09:14 < ibennetch> That's a very good point
09:15 < ibennetch> Okay, nothing else then?
09:16 < ibennetch> I propose that we close the meeting, then.
09:16 < zixtor> sure
09:16 < ibennetch> Thank you all for attending!
09:16 < zixtor> Bye all :)
09:16 -!- zixtor [74cb4c84@gateway/web/freenode/ip.116.203.76.132] has left #phpmyadmin []
09:16 < nijel> great, good bye everybody
09:16 < Marc9> Bye!
09:16 < udan11> Good bye!
09:16 < DevenB> Goodbye !
09:16 < smita786> Bye everyone! :-)
09:17 < dstorm> Bye everyone
09:18 < madhuracj> Bye!