[20:59:57] hi there [21:00:55] i'm here too [21:01:27] dilfridge: ping [21:01:34] dilfridge|mobile: ping [21:01:46] probably he is still on the train [21:01:56] ah [21:02:34] -*- K_F propose to give it a few more minutes to see if he gets in [21:02:38] --> tetromino (~quassel@gentoo/developer/tetromino) hat #gentoo-council betreten [21:02:57] i've gotten stuck in traffic myself [21:03:54] K_F: works for me [21:04:06] I don't think we have much on the agenda [21:04:40] not really [21:04:47] do we actually have an agenda? [21:04:49] I'm only aware of the two topics, gtk/qt/etc and project/team leads [21:05:13] that's what I know of [21:06:42] can we begin an unofficial discussion of gtk/qt because i really don't know how to proceed forward with that [21:07:33] sure, I am perfectly in line with rich0 suggestion. [21:07:33] blueness_: sounds like a good idea.. [21:07:33] https://wiki.gentoo.org/wiki/Toolkit_USE_Flags is a nice summary of previous discussion [21:07:33] blueness_: sure [21:07:34] I'd suggest that we support the qa policy on that [21:07:41] from the users side, and that is the only view which counts is the USE=gui think the best [21:07:44] i.e. gtk2/gtk3 and qt4/qt5 [21:07:46] here [21:07:52] ah good [21:07:58] take over dilfridge [21:08:05] ok [21:08:32] so since I never sent an agenda around (sorry) [21:08:47] let's take the project thread as agenda [21:09:04] which basically means. [21:09:09] 0. Roll call. [21:09:12] who's here? [21:09:15] -*- ulm here [21:09:16] -*- K_F here [21:09:17] -*- jlec here [21:09:22] -*- blueness_ here [21:09:34] rich0: WilliamH [21:09:49] -*- rich0 here [21:09:49] rich0: was here [21:09:56] yes I see the backlog [21:10:09] anyone seen williamh recently? [21:10:27] not yet [21:10:51] last seen by willkins is ~2h ago [21:10:53] :( ok let's proceed for now, I'd say [21:10:58] anyone can text him? [21:11:45] I'll text him... [21:11:57] thanks [21:12:01] so [21:12:09] 1. Use flag policies [21:12:53] http://thread.gmane.org/gmane.linux.gentoo.project/4775 [21:13:17] there's the excellent summary of current, old and prehistoric (qt3! gtk1! yay!!!) discussion [21:13:26] -*- WilliamH is here, late, sorry [21:13:31] https://wiki.gentoo.org/wiki/Toolkit_USE_Flags [21:13:42] WilliamH: not much later than I was, you didnt miss anything yet. [21:14:06] I am totally supporting USE=gui for any gui and very specific gtk2 gtk3 qt4 qt5 for the specific toolkit(version) used. Which the maintainers setting preferred with + [21:14:07] dilfridge: heh, ok [21:14:20] so how do you want to proceed? do we want to discuss here? do we want to issue a recommendation, or do we want to set a policy? [21:14:24] I'm opposed against USE=gui [21:14:43] That might be more work for the maintainer when setting REQUIERED_USE but it is the simplest version for the user [21:14:52] e.g. emacs has "X" and "aqua" flags and I don't see how USE=gui would map to this [21:14:55] ulm: why? [21:15:10] anything that *needs* REQUIRED_USE is bad [21:15:23] and I guess it's the same for any package supporting multiple guis [21:15:50] ulm: fair point. [21:16:12] also USE=X has served us well and I don't think we should be changing it at this time [21:16:27] So, at some point we should have a desktop/x11/gnome/systemd profile and a desktop/wayland/kde/openrc profile? [21:16:31] if/when wayland will take off this may change [21:16:35] and the other 32 permutations? [21:16:44] well what about going with just the unversions gtk and qt flags, and picking the best installed version of each? [21:17:10] blueness_: best installed? as in automagic? [21:17:11] blueness_: that breaks with libraries [21:17:14] e.g. poppler [21:17:22] has qt4 and qt5 bindings [21:17:33] I still see a single USE to switch the gui on/off is the most convenient for the user. [21:17:37] hmm ... some have both bindings? [21:17:53] yes, you want to compile both qt4 and qt5 apps with poppler [21:17:57] The main reason to have a USE=gui is because that is what the user ultimately cares about. [21:18:05] They don't really care about gtk or qt most of the time. [21:18:07] rich0 + [21:18:17] They end up setting it because that is how to get it to work with X11. [21:18:20] I always thought use=X was for that. [21:18:27] rich0: yeah, that is my initial reaction as well, that is mostly maintainers and some power users caring [21:18:35] Well, we could go with USE=X, but then wayland... [21:18:59] WilliamH: USE=X comes from the old configure options —enable-x for the x11 support [21:19:05] But, aqua/etc are legitimate examples of where this breaks down. [21:19:09] I also like the USE=gui approach [21:19:28] You'd almost want a USE=gui whose meaning is conditional on the profile, but that needs a lot more thought. [21:19:35] but approached in a consequent way, this would mean "no gtk useflag and no qt useflag" [21:19:37] i'm unclear how that USE=gui would work, would it pull in all gtk and qt bindings for a package? [21:19:51] blueness_: it might or might not. [21:19:57] gui = some toolkit (if a GUI is optional) [21:20:08] So, USE=-gui might STILL pull in gtk or qt, if it is needed for the console application. [21:20:16] dilfridge: no we need to let the user choose the toolkit [21:20:25] gui != toolkit [21:20:35] packages can use X without toolkit [21:20:40] rich0: gtk/qt should never be needed for a comsole app? [21:20:41] What if hte user doesn't care what toolkit is in use? [21:20:45] dilfridge: As a kde use you don't want to be forced to gtk if qt is available because the gentoo maintainer uses gnome [21:20:57] WilliamH: why not? qt does string handling. Console apps need string handling? [21:20:59] qt can be very well used for a console application [21:21:14] (just not dev-qt/qtgui :) [21:21:16] And that is where this all gets very messy [21:21:31] rich0: indeed [21:21:47] The problem with non-versioned use flags as I see it is, [21:21:53] Soemtimes the user does want to control the toolkit, and sometimes they even want to do so with version granularity [21:21:58] so we should probably first define what we want, and then think about how to do it best [21:22:04] Often they just want "what works" [21:22:16] say one package uses qt3 another qt4. [21:22:17] right now we're debating step 2 while step 1 is still missing [21:22:34] dilfridge: my strongest point would be to avoid REQUIRED_USE whereever possible [21:22:42] yes [21:22:44] ++ [21:22:46] So, I'd say a goal is that a user shouldn't HAVE to specify any of this stuff to just get a desktop, especially if they use a profile. [21:22:46] Is it possible to install both? [21:23:01] The user should DEFINITELY not have to set lots of package.use settings just to have a bunch of qt/gtk stuff installed. [21:23:07] WilliamH: depends on "library versus application" [21:23:16] I want to have a simple control for the user yes/no of gui on a first level and on a second a fine graded selection of the toolkit. [21:23:23] so please no USE="gui X wayland"; REQUIRED_USE="X? ( gui) wayland? ( gui )" [21:23:53] ulm/dilfridge what is your argument against REQUIERED_USE? [21:24:02] it needs manual intervention [21:24:14] not necessarily, if proper defaults are set [21:24:19] exactly [21:24:21] jlec: it requires a lot of flag micromanagement by users [21:24:23] certain flag combinations cause failure and that's messy [21:24:26] dilfridge: sure, but would people be setting USE=X and not setting USE=gui? Or whatever? [21:24:33] ulm: not necessarily [21:24:43] the maintainer needs ot set default via + [21:24:49] If the user wants to set something like USE=gtk3, then they're going to have to accept a lot of micromanagement. [21:24:50] imho REQUIRED_USE should get banned or replaced in a future EAPI [21:25:10] dilfridge: that means we could use it until then [21:25:19] dilfridge: I thought pkg_pretend was supposed to be the way we did that... [21:25:22] and future solutions then [21:25:49] dilfridge: not sure it even affects EAPI, but if it were up to me USE flags would be like package dependencies. If something needs a/b[foo] then portage rebuilds a/b with USE=foo and nothing goes in any config file. [21:25:51] dilfridge: I wouldn't go so far, but it should be limited to where it's needed for dependencies [21:25:53] jlec: but it doesnt help if we multiply the use cases now [21:26:14] Then REQUIRED_USE doesn't need any manual intervention. If the package needs USE=gui, the PM just sets it. [21:26:28] whenever REQUIRED_USE pops up not even autounmask helps [21:26:33] ok [21:26:47] but let's NOT talk about future EAPI or non-existing portage features now [21:26:48] btw, I don't really expect us to vote on something today. [21:26:52] rich0: We had a feature like that years ago. if a package was installed, a use flag could be set... [21:27:03] so [21:27:05] How about letting the users vote? Defining some clear solutions with defined implications for the users and setting a poll? [21:27:06] first [21:27:15] jlec: no. [21:27:26] why? [21:27:27] because the problem is more complex than the greek referendum. [21:27:31] jlec: I'm in principle not in favor of user votes like that, I doubt they get the proper attention for a good solution [21:27:34] rich0: i wouldn't mind see how your three tiered gui - gtk/qt - gtkN/qtN might be implemented either with or without REQUIRED_USE [21:27:41] (after the meeting of course) [21:27:58] then the "user need to micromanage USE" doesn't hold [21:28:35] Another concern about non-versioned use flags... I remember a while back when we had the non-versioned qt use flag... [21:28:41] s/qt/gtk/ [21:28:48] basically, in real world someone would now be tasked to write a whitepaper on 1) use cases, 2) objectives, and 3) comparison of implementations [21:28:54] blueness_: good idea. I actually wouldn't mind some qt/gnome team feedback on the idea as well [21:29:11] The gnome team made the decision to start dropping gtk-2 support... [21:29:11] while I'm not too happy about generating extra piles of paper, [21:29:26] caused a lot of upset on -user. [21:29:37] rich0: i think this is a case where theimplementation details would clarify what you are proposing evne if the final implementation is different [21:30:00] I'd suggest we first think about what we *want* [21:30:05] WilliamH: I don't want to dictate what toolkits any team has to support,. [21:30:16] and write that down. [21:30:22] That isn't the purpose of this. This is about HOW to support multiple toolkits/etc. [21:30:26] (not how we want to do it) [21:30:45] And if the gnome team wants to drop gtk2 and somebody else wants to start the gtk2 team to keep them, more power to them. [21:31:00] A. What types of packages exist where this discussion is relevant? [21:31:01] dilfridge: agree [21:31:03] rich0: i don't get the sense we're imposing anything, we just are clarifying what our use flags are going to be doing uniformly across packages [21:31:08] rich0: Sure, I'm not saying that, I'm just saying that when they started changing the gtk flag meaning to support gtk3, some users were upset because they still wanted gtk2 [21:31:22] A.1 libraries, e.g. app-text/poppler [21:31:32] A.2 ... [21:31:32] blueness_: sure, I was just getting at the "wanting to drop gtk2" thing. I get WilliamH's point though - redefining the flag in-place. [21:31:45] ah yes [21:32:07] that is a problem with unversioned use flag in the first place, which is likely what we need to clarify [21:32:14] dilfridge: agree on approach. Use cases, objectives, comparisons makes sense. Can you have that done in a week? :) [21:32:20] :P [21:32:46] I can collect use cases, if someone else defines objectives. Afterwards we can talk about solutions. [21:33:02] we could ask maintainers of affected packages to describe their use cases [21:33:06] Seriously though - this was fairly last-minute. I think we've benefitted from this discussion at least - I don't expect it to get finalized as this has a huge impact. [21:33:09] --> genstorm (~andreas@91-119-22-139.dynamic.adsl-line.inode.at) hat #gentoo-council betreten [21:33:14] ulm: sure [21:33:24] dilfridge: I suggest we do all this on the wiki [21:33:27] my contribution will be poppler, libreoffice, kde ... [21:33:35] rich0: yeah, I'd actually like to hear what gnome and QA teams have to say about it as well, as iirc they have established policies [21:33:48] --> Polynomial-C (~Poly-C@gentoo/developer/Polynomial-C) hat #gentoo-council betreten [21:33:49] Also, I'm fine with tackling kde/qt now and X/wayland later. [21:33:54] I would like to see more clearly what are really the drawbacks for ever solution. [21:34:10] However, I brought it up mainly because the solution for X/wayland may also apply to gtk vs qt. [21:34:17] rich0: isn't that the same problem? [21:34:18] --> awilfox (awilfox@awos/maintainer/awilcox) hat #gentoo-council betreten [21:34:20] in the end [21:34:38] jlec: yup, hence my brining it up. I just don't want to over-complicate. [21:34:42] partially, yes [21:35:05] But then you also get into aqua, svga, and who knows what else. [21:35:11] win32? [21:35:16] E.g., we always will have packages that only support one toolkit only (e.g. Qt5 only) [21:35:35] so that is simple [21:35:41] USE=gui :/ [21:36:16] jlec: as pointed out, qt != gui [21:36:23] But I am also for gathering and writting down all that more clearly before deciding [21:36:25] Without wanting to get into it, I bet there are other cases where a sort-of-heirarchy exists. I just think that the term "heirarchy" isn't entirely correct since the relationship isn't strict. [21:36:32] jlec: no useflag at all, pulling in Qt5 unconditionally [21:37:07] WilliamH: normally if qt != gui, then USE=qt impliments some support which could be covered under some other USE name [21:37:15] I think the case where a package supports exactly one toolkit is simple. It just unconditionally pulls it in. How we do this might affect what its USE deps look like, but that's it. [21:37:25] dilfridge: I assumed there is a non gui version [21:37:42] jlec: rich0: my point is, even if USE=-qt5, users may still end up pulling in Qt5 [21:37:44] A package could unconditionally require qt, but optionally install a gui. [21:37:49] dilfridge: sure [21:38:04] heh, right, special qt case [21:38:14] Just as setting USE=-X could pull in X today if you're installing xterm. [21:38:52] I agree that we really need use cases, objectives, etc for this. [21:38:52] That is just user education - USE flags can't change reality. [21:39:28] i wonder if the use cases won't reveal just how complex a mess this is [21:39:35] exactly [21:39:41] that's why I want to see them first [21:39:43] that has value in itself [21:39:46] I think we need to keep the use cases brief to start. Let's look at the high level first [21:40:04] but at least we'd have some documentation as a basis for dicussion [21:40:08] I think the objectives are at least as important. [21:40:12] so who's trying to define objectives? [21:40:19] I don't mind taking a crack at them. [21:40:22] ++ [21:40:38] In theory I've been paid to write business requirements. :) [21:40:46] well the ojective is to find a common approach to all toolkit use flags that's intuitive for the users [21:41:02] and we get together informally over the next weeks and send our material to the other concil members [21:41:13] blueness_: sure, but we can break that down a bit, so that we can then weigh options against how they address the various objectives/requirements. [21:41:27] So, avoidance of REQUIRED_USE or ebuild complexity might be an objective. [21:41:33] dilfridge: I think that sounds like a good idea indeed, and likely input from some other teams that have relevant discussions on this [21:41:44] rich0: okay i can see that as a goal too [21:41:56] sure, and once this is a bit more advanced we can send our material to the lists again [21:42:07] Not all objectives need be equally important. You an basically do a QFD if you really want to go nuts with it. [21:42:14] just that I'd be really happy if relevant maintainers chime in (gnome, qa) [21:42:26] ok [21:42:33] dilfridge: agree. We'll push them for opinions when we have a bit more. [21:42:37] anything else on this topic that needs to be discussed today? [21:42:43] yes [21:42:46] I'm fine with moving on. [21:42:46] (emphasis on *needs*) [21:42:54] I've always thought the goal from the qa perspective was tree-wide consistency. [21:43:06] I quickly like to bring up the /project team lead thing [21:43:14] ok [21:43:17] WilliamH: yeah we pretty much agree on thta [21:43:18] agenda topic 2 [21:43:30] projects without a lead [21:43:33] or lead elections [21:43:35] The GLEP defines that yearly a lead election and meeting needs to happen [21:43:37] jlec: go ahead [21:44:01] Do we wnat to enforce this or is it just enough that projects function? [21:44:14] here's my take [21:44:16] what if no voting happens [21:44:25] the GLEP doesnt say how the election should take place [21:44:26] Can simply one dev take the lead? [21:44:43] personally, I'm content to ignore it except when it is a problem, then point to it and call for elections [21:44:48] so in principle if team has 3 members and they agree on irc, then they can have a lead [21:44:49] as I read GLEP 39, a team lead isn't even mandatory [21:44:59] "It *may* have one or many leads." [21:45:06] By all means track the lead and last election date on the project pages as a part of the wiki template [21:45:12] when ppc/ppc64 was "dead" i just "threatened" to take the lead and people came out of the woodwork saying i can't do that, and that revived the projct :) [21:45:16] "or" vs "xor" [21:45:27] blueness_: and that is a very effective way to deal with issues when they come up [21:45:52] Many problems can be solved via WP:BOLD [21:46:05] "It may have one or many leads, and the leads are selected by the members of the project. This selection must occur at least once every 12 months, and may occur at any time." [21:46:18] this is kinda silly wording [21:46:29] it may have a lead, but the selection must occur [21:46:34] dilfridge: are you quoting glep39? [21:46:37] yes [21:46:44] dilfridge: honestly, a lot of GLEP 39 is silly if you ask me - obviously the result of a lot of compromise, and perhaps a bit of wishful thinking :) [21:46:49] dilfridge: it must occur if the project has a lead [21:46:51] dilfridge: I read it as >=1 leads required [21:46:54] -*- rich0 won't mention slacker marks [21:46:57] the may referring to 1 or multiple [21:46:59] let's just ask the leads to put the date up via an email to the gentoo-dev@ list [21:47:00] So we are supporting active projects independent of a lead or how the lead was set up. [21:47:14] ulm: that assumption is about as free as the assumption that >=1 lead is required [21:47:16] important is that they just work [21:47:17] that'll remind them and we can also track project leads that way [21:47:34] dilfridge: yeah, wording could be clearer :) [21:47:45] Groups of people can work effectively without having a lead. However, if a project wants to throw its weight around I think having somebody accountable for the project is important. [21:47:56] but I'm also in the, if there isn't any issue, is there something for us to do .. [21:47:57] I would strongly prefer if any project had a nominal lead. Just for having a single point of contact. [21:48:05] ie, project just taking care of a dozen ebuilds that are self-contained, not having a lead isn't a big deal [21:48:32] dilfridge: i agree, webapp was in that situation [21:48:40] I dont care how the election takes place, and how the annual confirmation takes place. [21:48:42] On the other hand, if a project wants to control how others use some global USE flag and there is controversy, the lead really helps [21:48:49] some user had an issue and there was no point of contact [21:49:04] Don't get me wrong, I think we should recommend strongly that leads get elected [21:49:17] rich0++ [21:49:20] I just don't know if we have a good "or else" for when they don't. [21:49:25] rich0: ++ [21:49:28] e.g., kde team: "!herd kde\n does anyone else want to take the jump seat this year?\n no? \n ok then it's me again..." [21:49:48] dilfridge: there's WP:BOLD again [21:50:12] When people have asked me about advice for disputes within teams I've usually recommended that they do exactly that. [21:50:35] They can call for a team lead election. Maybe the person they like the most doesn't get elected, but now somebody is empowered to deal with their concern, and has some duty to do so. [21:50:51] It provides some kind of resolution. [21:51:05] alright, so we are agreeing that we strongly suggest teams to have leads, but as long as they work it is alright. [21:51:15] exactly [21:51:21] well, several of the teams I'm on don't have a lead and work well enough without such bureaucracy [21:51:25] now the next question is [21:51:37] jlec: essentially. I don't think it is productive to disband teams that don't elect a lead, remove them from metadata, revoke their aliases, etc [21:51:43] should we encourage teams to have a lead, and if so, how strongly? [21:51:58] dilfridge: I think we should encourage it for sure, even as a point of contact [21:52:02] here's what i suggest [21:52:10] send an email to gentoo-dev@ [21:52:11] Emphasize it on the project page, track the last election date, etc. [21:52:12] I'd leave it to the teams [21:52:19] remind people of the workding of glep 39 [21:52:23] because we cannot enforce it anyway [21:52:25] encourage them to follow it [21:52:26] dilfridge: just as strongly as encourage simply devs to take it if there is no vote. [21:52:34] Maybe even nag people periodically about their last election date if it is more than 14 months ago? [21:52:36] and track the date of elections on the project pages [21:52:39] And send a reminder at 11 months? [21:52:43] ok [21:52:52] I hope you all realize this is a lot of work. [21:52:59] -*- WilliamH is with ulm [21:53:08] dilfridge: and that is my concern [21:53:13] I would leave it to the teams as well [21:53:22] the tracking on project pages isn't too much work - the teams should update their own [21:53:27] Maybe we should deputize some volunteer "team lead election reminder"? [21:53:33] The trying to centralize all that and nag begs automation [21:53:48] I like the date of last election in wiki template idea [21:54:05] -*- WilliamH isn't really for nagging devs either [21:54:23] we can pre-seed it with today's date, and at latest in a year it's >1y in the past [21:54:26] I'd say that step one is at least tracking it on the wiki, consistently [21:54:35] That is a pre-condition for any kind of nagging anyway [21:54:53] dilfridge: I'd favor not pre-setting anything, but have the projects update it themselves, that might force action as well [21:54:57] s/force/encourage/ [21:55:00] I could see the counter-argument that team foo says that they work well without a lead and are a model of good citizenship, so why are we bugging them, etc. [21:55:22] -*- WilliamH agrees with rich0 on that [21:55:26] K_F: agree. I think that project teams should try to give at least some care to their wiki pages [21:55:37] heck, we have issues with devs who don't bother with a wiki account [21:55:57] their project page can be a place to recruit, document, etc. The lead and last election date are just a part of that. [21:56:09] yup [21:56:21] Let's drop that forcing and nagging thing [21:56:32] just for the record, a lot of project pages were auto-migrated by maffblaster and me to the wiki. [21:56:36] jlec: I'm fine with that for now. Keep it positive [21:56:43] Let's simply encourage team to to meetings and selections [21:57:03] dilfridge: yeah, it will be interesting to see how many get touched at all, but that is a good sign of team activity [21:57:26] ok [21:57:42] so we have two things, [21:58:13] 1) enhance the project page templates so they show last lead election date (that's something we need to talk to a3li about) [21:59:01] 2) write an e-mail to g-project about "please consider electing a lead and confirming her/him regularly", any volunteers? [21:59:21] i can send the email [21:59:24] ++ [21:59:34] I can talk with a3li on the template [21:59:38] ++ [21:59:41] i'll make it positive and mention both points [21:59:43] great. I think those to points will be sufficient. [22:00:13] wow - we actually got through it all in an hour... [22:00:17] :) [22:00:20] (fyi, I do need to drop soon) [22:00:22] :) [22:00:23] yes and that's good [22:00:33] okay so i'm sending this email? [22:00:34] 3. Bugs with council involvment [22:00:36] rich0: not having an agenda helps :p [22:00:43] blueness_: sure [22:00:46] k [22:01:35] Bug 503382 [22:01:38] dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council [22:01:46] ok we can go on to the open floor [22:01:52] 4. Open floor [22:01:56] anyone? [22:02:04] I had my topic already. [22:02:54] ... [22:03:06] re topic 3. open bugs, I've started working on the 20131210 summary [22:03:13] ++ [22:03:28] will be finished next time, hopefully [22:03:34] very good [22:03:43] great [22:03:54] so seems like noone has anything to bring up [22:04:06] which means we can Close This Meeting. (bang) :)