Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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 [~firstname.lastname@example.org] 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.18.104.22.168] 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 [~email@example.com] 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 [~firstname.lastname@example.org] 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.22.214.171.124] 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 http://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 [~email@example.com] 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 [~firstname.lastname@example.org] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )] 08:56 -!- DevenB [73f91219@gateway/web/freenode/ip.126.96.36.199] 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.188.8.131.52] 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!
Clone this wiki locally
Press h to open a hovercard with more details.