16:59:51 #startmeeting 16:59:51 Meeting started Tue Nov 22 16:59:51 2016 UTC. The chair is OdyX. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:51 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:04 Is everyone around ? 17:00:38 Philip Hands here 17:00:39 * marga is here 17:00:44 Ah, sorry 17:00:49 Margarita Manterola here 17:01:09 hartmans, keithp, Mithrandir, dondelelcaro, aba ? 17:01:19 yup, just fighting another machine 17:01:27 Let's get started 17:01:31 Sam Hartman 17:01:31 #topic Next Meetings? 17:02:44 There are two ties, for both December (18 UTC, 20 or 22) and January (18 UTC, 24 or 26) 17:02:59 Let's sort that out after the meeting, everyone. 17:03:04 I don't think I've voted for jan; will update 17:03:15 #topic Review of previous meetings' TODOs 17:03:24 I mean presumably our election procedure gives an answer for ties. 17:03:34 hartmans: it does: I decide :-P 17:03:55 I haven't had time to work on any of systemd, menu-system or the policy process. 17:03:56 o actual casting vote ties. How cool. I think this will be less...fraught than the last casting vote:-) 17:04:31 marga: you progressed quite a lot on the nominations, we can say. 17:04:33 Thanks for that. 17:04:34 hi, sorry I'm a tad late. 17:04:55 OdyX, happy to help. I do still have a couple of pending emails to send. 17:05:12 Let's keep the beefy detail for this topic. 17:05:23 Let's move on the big part of that meeting. 17:05:28 #topic #841294 Maintainership of 'global' package 17:06:07 that's not actually what the bug title is, mind. 17:06:27 that's right. 17:06:39 #topic #841294 Overrule maintainer of "global" to package a new upstream version 17:06:46 Sorry for that. 17:07:00 I've sent a long mail with my opinion, and Ron's answer hasn't altered my conviction yet. 17:07:41 In short; I think 'global' user have a valid expectation of getting new upstream releases between Debian releases. 17:08:19 hypothetical regressions aren't reasonable explanations for not uploading to unstable (or experimental if these are really foreseable). 17:08:23 while I think that's true, we also change stuff, sometimes in spite of upstream wishes if we believe that's warranted. 17:08:32 removing htags is not a hypothetical regression, though. 17:08:36 so, do we allow Ron to provide an old version under the 'global' name, or a different name? 17:08:54 As for what Debian is concerned, the removal of htag (and the impact of that removal) is hypothetical. 17:08:58 I don't think we need to allow that 17:09:17 As in, maintainers are allowed to provide versions of programs as they see fit 17:09:24 And claiming that there are users of that functionality who will regret its absence is not backed by actual facts (that is, _Debian_ bugs) 17:09:41 OdyX: there's been bugs about htags in the period, so no, it's not. 17:09:54 Mithrandir: bugs about versions not in Debian, you mean ? 17:10:49 no 17:11:14 keithp: I don't care about the possibility of a 'global5' package. If Ron wants to fork 'global' at version 5, and maintain a separate package, I'm entirely fine with that. 17:11:33 I'd say we should say: upload 5 to get into stretch with a "htags is going!" warning, also upload 6 to sid with an RC bug to keep it there for now -- do that _soon_ or give the package to someone that will 17:12:07 I'm not fine with letting him block the 'global' name at version 5 forever (which is what he's been doing for 6+ years and 3 releases) 17:12:20 and which is not what he's saying he'll do. 17:12:50 I don't see why the sudden rush is here. 17:12:53 Losing functionality is _common_ in all software we maintain in Debian, the case in favour of an old 'global' isn't convincing to me. 17:13:37 Mithrandir: there's no particular rush, but it would be nice to come to conclusion about this bug, which is only 1 month old, in a reasonable time frame, assuming we have rough consensus 17:13:40 Mithrandir: it's no sudden rush, people have been asking for new versions for a long time. The hope to get that situation fixed for stretch is what apparently triggered the TC question. 17:13:42 keithp: re with a different name, I don't think we need to rule on that. Basically standards rules apply 17:13:43 OdyX: I find it somewhat convincing, if it is true that there's little real difference (he did just fix bugs, once reported) 17:13:55 aba: not rule on, but offer advice 17:14:08 keithp: agreed on advice 17:14:11 Is htags still used by doxygen 17:14:21 If so, has the doxygen maintainer been involved in the discussion?+ 17:14:23 OdyX: numbers are just that. 5 isn't inherently worse than 6. 17:14:32 keithp: deciding on it, sure, but it seems there's a rush to push in a new upstream version for stretch. 17:14:36 fil: if there had been a new upstream version in experimental, I'd agree. 17:14:45 hartmans: it's optionally used by doxygen, yes. 17:15:06 OK, and the upgrade means you can no longer use global with doxygen? 17:15:20 yes, given htags is removed upstream. 17:15:30 AIUI, anyway, I haven't actually tested it mysefl. 17:15:32 myself. 17:15:36 nod 17:15:38 Mithrandir: well, yes, there's the usual 'please fix this for next release', which has happened with tech-ctte bugs in the past. If we don't decide, the value of the process is lessened to some degree 17:15:41 jcristau: sure. It's just too easy to dismiss 'please package a new upstream release' requests from users for being "just about numbers". There are at least three bugs on src:global that have been fixed by upstream. 17:16:07 * hartmans is behind on this but will catch up and offer an opinion in the next couple of days 17:16:49 OdyX: and yet presumably it's possible to fix those three bugs without packaging the new upstream 17:16:53 so, for now, it would be reasonable to have a new upstream packaged with a new name (global6?). That could be included in unstable and tested 17:16:58 jcristau: it hasn't happend, but yes. 17:17:05 * fil had the impression that htags was still in 6, but the CGI is an insecure mess 17:17:21 jcristau: it's also possible to forward-port 'htags' to version 6, if that's a serious enough regression. 17:17:26 My general feeling is that this is a social issue. The maintainer has responded to bugs, but not to "please package new upstream release" bugs. It's not like the maintainer was MIA, just that he has a very strong stance against packing the new upstream 17:17:47 which is ok for some time, or if he presents good reasons. 17:18:19 The problem with htags is not that it's not present, but -as fil says- that the way it's used is insecure in version 6. 17:18:28 I feel it's okay for one Debian release, sure. Not for 3+, no. 17:18:35 why not? 17:19:37 because (but that's my current opinion, I don't want to sound authoritative about that) Debian users have a rightful expectation to get an up-to-date (or updated) 'global' when they migrate to a new Debian release. 17:20:01 OdyX: I agree that users have an expectation to get current software. 17:20:15 Yes, but they also have a rightful expectation that software packaged in Debian will not make their machines totally insecure. 17:20:17 OdyX: we also have a responsibility to preserve upgrades, and it seems like there is a conflict between those here 17:20:29 though I agree with OdyX it also depends on how much new thinggs are in the next version 17:20:35 and because one issue (htags) should not block and entire set of bugfixes and new functionalities that are presumably in the new versions. 17:20:48 keithp: I think that balance is the question 17:21:06 and with more and more time elapsing the reasons for upgradings usually become more relevant 17:21:29 keithp: what I'm unhappy with in the current situation, is that it's entirely hypothetical. Through failing to update the package (at least) in experimental, the Debian 'consumers' don't get to assess the quality of that new version package. 17:21:34 aba: as a first proposal, it seems like having both versions available for a transition period might be necessary 17:22:15 also a possiblity. make general a meta-pacage on general5, and change that post-release 17:22:52 s/general/global/g 17:22:53 so, an easy thing for stretch would be to provide the new version under a new name, right? 17:23:02 Where did our "release early, release often" mantra go ? I mean: unstable is precisely the suite we have to discover, fix and enhance packages. There was no upload for 6+ years. 17:24:02 I am very likely to support a decision that makes the new global available to users assuming there is someone to do the work. I am unlikely to support insisting the old global go away. 17:24:07 I fail to see how it'd have been better to have had a new upstream version in unstable with an RC bug saying "CGI is generated and is insecure" would have been better. 17:24:16 which I think is what we'd have had instead. 17:25:10 Mithrandir: a new package in unstable would trigger its own fleet of fixed and new bugs. 17:25:42 Mithrandir: I'm not sure we need to be controlling things at that level; advice to the packagers of the new version about fixing the security disaster seems sufficient to me 17:26:06 It seems everyon is assuming this 'htags' thing is un-patchable by anyone. We're patching software on a routine basis in Debian... 17:26:07 yes, and I think Ron would be receptive to guidance about "it's ok to drop htags". 17:26:41 OdyX: sure, we can advise to fix or redact the relevant code 17:27:08 OdyX, it's not htags that's not patchable. It's global's cgi support. 17:27:51 But I feel like we are going down the rabbit hole here. 17:27:56 we are. :) 17:28:36 For me, the advice that we should give is that it would make sense to have a the old global as it is, and the new global without the insecure parts 17:28:47 agreed 17:29:05 or with the security problems resolved in some fashion; either removed, or (better) fixed 17:29:05 Whether one is global5 and the other global, or one is global and the other global6, I feel it's up to the maintainer. 17:29:20 marga: it may be that we have two maintainers for the two packages? 17:29:28 sounds reasonable. The question is if we need both in a transition period or if we can just say "we'll have the old for stretch and the new should hit early in buster". 17:29:29 It doesn't look like we have a consensus, but there are three options on the table: a) remove maintainership from ron, let someone else adopt it; b) hand maintainership to someone else; c) issue advice on how to maintain these two versions. 17:30:06 OdyX: starting with advice seems like a good option for now; give the people involved time to decide if that advice is workable 17:30:09 keithp, do we? The person that filed the bug with us was not volunteering to maintain the package. 17:30:43 marga: he also said he was proxying a request for someone not feeling good enough about going to the TC. 17:31:08 (about english fluency, and public arguing; not about 'this is not what I'd do') 17:31:50 yeah, ok, I'm a bit suspcious of this, but ok. 17:32:20 it seems to me that the "CGI is insecure" RC bug is exactly what should be keeping global_6* in unstable, so Ron just needs to be nudged into uploading it -- then he ought to get the feedback he's after and can decide whether to fix the CGI, drop it, or fix the breakage in 5 17:32:23 Frankly, I don't feel Ron has been missing advice, or has been short of occasions to get the new global 6 in the hands of users (even in experimental), and I don't feel comfortable rewarding the stop-energy he has put in the 'new upstream release' bugs. 17:33:12 OdyX: we can encourage anyone interested to package the new version for upload, under a new name 17:33:14 I think the project-wide stop energy of taking a package away from someone and not giving it to someone specific is close to really really high 17:33:32 hartmans: that's a very important point, I agree. 17:33:34 I think we can give advice like 17:33:35 I don't think we're the right people to tell people off for dragging their feet, providing stop energy or being less-than-stellarly reactive. Both because we're the pot calling the kettle black, but also what hartman says. 17:33:47 if he refuses to be nudged (promptly), get a new maintainer, and encourage Ron to upload global5 if he sees fit 17:33:53 "we'd be happy to facilitate getting global6 available to users, including helping negotiate package names and maintainership if that benefits the project" 17:34:56 Is this attached to more text before? 17:34:58 I think providing a temporary global6 package for the next N months seems a tad pointless, but that might just be me. 17:35:56 Mithrandir: why is that? Removing htag would break existing users, so using a new name makes some sense. If the new package could replace the existing package, then the name could be transferred at a later time 17:36:06 marga: No, I was just writing a brief sententce here. 17:36:12 "we encourage the 'global' maintainer to upload a recent new upstream version to experimental, and file Debian bugs for issues he feels are intenable for letting that version in any next stable release" ? 17:36:24 OdyX: sure 17:36:41 or what? 17:36:58 It seems to me that all maintainers are encouraged to upload new upstream release versions 17:37:08 Not encouraged enough, apparently. 17:37:08 keithp: because Ron has said he's willing to do that once stretch is out, so it's a very temporary thing, and I think the chance of the social dynamics between the maintainers (if we go the "two maintainers" route) is likely to not be great. 17:37:37 OdyX: yup -- that would give people somewhere to focus constructive energy 17:38:05 My point is that we need to be a bit more specific 17:38:14 Mithrandir: Ron said he'd be willing to do that for Squeeze, Wheezy, and Jessie. 17:38:25 i.e. encourage having both global5 and global6 minus htags 17:38:36 OdyX: where has he said that? 17:39:41 Mithrandir: in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#59 he said "now is not the time to be pushing for a major update" That was in 2013. 17:41:06 Are we done with this topic? 17:41:15 So, I reformulate: he said during the stretch freeze, in a bug filed 3 years earlier, that it was not the time for a major update, because of the freeze. 17:41:35 I feel we are, but I'd like to have #action's for someone to propose a ballot with options on it. 17:42:11 OdyX: and then he points out that the earlier concerns have not been addressed, yes. 17:42:36 earlier concerns that he only shared in private, but yes. 17:43:14 Would anyone feel good enough about summarizing this conversation (with its various possible outcomes) as a ballot proposal ? 17:44:07 #action OdyX to try summarizing this conversation (with its various possible outcomes) as a ballot proposal during the end of this week. 17:44:22 #action everyone getting up-to-speed with the subject :) 17:44:28 I think the end of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574947#141 points out the concerns quite well. "you need a world-writable directory", btw. 17:44:33 but sure, let's move on. 17:45:16 Mithrandir: that certainly doesn't sound like something impossible to patch in 6+ years. 17:45:20 #topic #839570 Browserified javascript and DFSG 2 (reopening) 17:45:56 This IMHO just lacks someone with small time to thank Pirate, FTP Master, and close the bug, IMHO. 17:46:02 too-much-IMHO 17:46:28 anyone ? 17:46:45 Will do 17:47:31 #action hartmans to writing closing mail for #839570 17:47:41 #topic #839172 TC decision regarding menu policy not reflected yet 17:47:53 I've had no time there. Still on my radar, somewhat, but no time. 17:48:33 #topic #836127 New TC members 17:48:48 * hartmans replied to the question outstanding for me. 17:48:49 Do you have energy for that one, or did everyone go to sleep ? :) 17:48:52 hartmans: don't be to effusive with your thanks to Praveen, given that he's _still_ not responded to e.g.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840295#67 17:49:10 So, here, I still need to mail a couple of new suggested names and acknowledge some of the replies we got. 17:49:41 it feels to me we have a good set of people I'd be comfortable having on a ballot for a private vote. 17:49:58 Can we set a timeline? 17:50:06 (or do we have one and I'm not aware of it?) 17:50:22 The two seats become available on Jan 1. 17:50:32 so a DPL decision before that is good 17:50:34 Yeah, I meant for discussing and voting 17:50:47 So, we have a set of people but I don't think we have much information about any of them. 17:51:02 Right, that's why I'd like to have a timeline 17:51:16 I grow increasingly uncomfortable with the perpetuation of the good-old-boys-club nature of our process. 17:51:35 hartmans: indeed 17:52:03 So, eg: we can say: Nov 30th - Last day to accept nominations. Dec 1st to Dec 15th: discussion period. Dec 16th to Dec 25th: vote period... 17:52:15 works for me 17:52:25 The dates are pretty awful, but well, it's Nov 22nd right now :) 17:52:50 Well, in the past we've gotten inadequate discussion in that short of a period. 17:52:58 But sure. 17:53:47 Uhm. We could make it Nov 25th: last day to receive nominations. Not that it adds THAT much, but well, it's 5 more days 17:54:08 and we pinged the project twice already. 17:54:28 I just want to make sure that I mail the last names that were suggested 17:55:47 nod, makes sense. 17:56:02 I think your timeline is OK, although we may end up voting FD if we have had inadequate discussion. 17:56:16 ok 17:56:30 So we go with Nov 30th? 17:56:41 Nov 25 is good 17:56:44 k 17:57:15 #action marga to set timeline 17:57:15 I'm totally fivne with Nov 25 17:57:29 #action everyone building their opinions on the candidates 17:57:36 I disappear in 3 min 17:57:38 #agreed Timeline for decisions: Nov 25th, last day for accepting nominations. Nov 26th - Dec 15th, discussion period. Dec 16th - Dec 25th voting period. 17:57:45 #topic Additional Business 17:57:56 hartmans: yeah, 1h meeting target for me as well 17:59:06 If there's nothing, I guess we can close the meeting 17:59:30 +1 17:59:33 #action OdyX to announce the December meeting, and setup February meeting poll. 17:59:51 #endmeeting