**** BEGIN LOGGING AT Mon 2009 *Now talking on ##gentoo-meetings *wolfe.freenode.net sets mode: +ns *You've invited EvaSDK to ##gentoo-meetings (wolfe.freenode.net) *You've invited remi` to ##gentoo-meetings (wolfe.freenode.net) *You've invited mraudsepp to ##gentoo-meetings (wolfe.freenode.net) *mraudsepp (n=leio@gentoo/developer/leio) has joined ##gentoo-meetings wheee *EvaSDK (n=eva@gentoo/developer/evasdk) has joined ##gentoo-meetings *gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has joined ##gentoo-meetings *gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has left ##gentoo-meetings: "Sto andando via" Where's remi` *leio (n=leio@gentoo/developer/leio) has joined ##gentoo-meetings He'll miss the discussion logs *gionnico (n=gionnico@host110-127-dynamic.46-79-r.retail.telecomitalia.it) has joined ##gentoo-meetings *DrEeevil (i=dreeevil@gentoo/developer/bonsaikitten) has joined ##gentoo-meetings http://is.gd/12uS5 ^ GNOME bugs *tanderson (n=gentoofa@gentoo/developer/gentoofan23) has joined ##gentoo-meetings tanderson, somewhat related: can we get #gentoo-meetings reinstated? It's unusable weren't we at 250 bugs? This filters keywording? What do you mean reinstated? nirbheek: what's that query ? I have 249 in my book :) EvaSDK, oh :p #gentoo-meetings has a keyword EvaSDK, it doesn't include gnome-office and gnome-mm http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=nowords&keywords=REQUEST%2C+STABLEREQ%2C+KEYWORDREQ&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker&bug_severity=critical&bug_severity=majo channel password basically and that's just for "important" stuff my search doesn't include it either mraudsepp: it does? I joined it no problem I get 268 bugs and that's _without_ CC=gnome that you have I used gnome@gentoo.org paste paste what? ;d http://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=gnome I exclude P4, ebuild request, QA and some low prio stuff like that, it's in another request mraudsepp: fail :D *Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings n819 ftw! 810 even EvaSDK: call remi ;d EvaSDK, yeah, even arun is here now :p So, what's the definitive bugzie search for gnome bugs? I don't understand what your search is. I have 268 assignee=gnome and 102 CC=gnome bugs assigned to gnome@ and fdo@ ? makes sense for those I have separate searches, but that makes even more http://is.gd/12uS5 ^^ has like 150ish results only I did : assigned to, cced, reporter: gnome@gentoo.org Then I did : assigned to, cced, reporter: gnome.*@gentoo.org (regexp) That gave me 456 421, sorry yeah, sure, but what's that tinyurl about http://is.gd/12veZ the one you gave before... That one has reporter, assignee, cc: gnome@gentoo.org well, something is wrong Can we have all this in a single page? assignee: gnome@gentoo.org is already 268 EvaSDK, you're our top bug wrangler, how do you manage this stuff? nirbheek: time just pick a bug and solve it ;d EvaSDK, I meant, which bookmarks/saved searches :p oh yeah, I have a few saved searches generally gnome assigned + gnome CCed *remi` (n=remi@gentoo/developer/remi) has joined ##gentoo-meetings then by level of interest, normal prio, inclusion, P4 ebuild request, QA, P5 low prio/long term stuff mostly does it make sense for us to use the priorities to well, prioritise? yes it does and using keywords as well Totally, let's decide that, and I'll compile it into a webpage I feel inclusion keyword is really important for team work Yes, I agree but not to be used lightly And doesn't mean "CommitBlindly" nirbheek: http://www.gentoo.org/proj/en/desktop/gnome/gnome-policy.xml how about using those priorities ? => http://www.gentoo.org/proj/en/desktop/x/x11/maintaining.xml#doc_chap3 it should be ok to commit something that is marked for inclusion but it doesn't exclude testing seems like a good starting point, like patching that maybe or maybe renaming. gnome-policy.xml has our historical priorities meaning documentation mraudsepp, actually, we can link that webpage to the appriopriate pages *searches remi`, we should probably merge the x11 and gnome ones I guess all that still makes perfect sense for us now too remi`: nice stuff I'm pretty sure Donnie wrote that :) our priorities explanation seems better in gnome-policy more developed at least the "queries" part is nice, we should copy it and make real links out of it remi`++ that would help us and others out So we all agree both pages are awesome, and need love because right now, it's really hard to dive in nirbheek: you'll do the minutes? remi`, yes I believe we just need a concentrated bug triaging and fixing when we aren't dealing with getting the newest GNOME in reduce the count, keep it down, no overview loss happening with 50 open bugs mraudsepp, let's finish talking about how to organise our bugs first mraudsepp: sure but we're not there yet Then we can talk about how to handle the bugs themselves Right, "levels" of bugs there would be nothing to organize when time is spent on fixing bugs instead of organizing them, imho we should probably write something about closing bugs with TEST-REQUEST or NEEDINFO status more often to encourage people providing feedback mraudsepp, sure, we'll do that too, but now we need to cut the bug list down, so we need to organise them, so let's do that ;p that implies that when enough information is provided we can come up with either a solution on our side or pushing this stuff upstream organizing them doesn't cut the bug list down preferrably the user would do it at this point and we CC there EvaSDK, we'll need something similar to how gnome bugzie does for that to be usable it merely hides bugs from view, the bugs still exist :( nirbheek: that is ? mraudsepp: it might exist mraudsepp: there's no hiding, it's just organizing If we can find a lightweight organisation system, might be worth it EvaSDK, when the reporter comments on a NEEDINFO bug, the bug asks if the comment gives the information asked, and then reopens it automatically if we can't reproduce it, what point is there is keeping it nagging at you ? when you are looking at stuff you can fix I mean ok, go on. I'm just continuing to always look at the full list and sort it by the column I find appropriate at the time. nirbheek: we do have that or I dreamed it ? EvaSDK: you dreamt EvaSDK, gentoo doesn't, gnome bugzie has it (they have a lot of mods) Anyway, getting back to the original convo All those "levels" of bugs may I digress for just a moments : Okay, go on about the GNOME bugzie component, do we all agree to get rid of it? *EvaSDK has changed the topic to: gnome meeting-ish yes or ask infra to make "ebuilds" or "apps" the default? or at least change it's default assignee yes, that too I like GNOME component because it saves me from typing gnome into the assignee box :) GNOME component helps power users who don't have bugzie powah, but wastes our time right, that's about the only advantage of it ;) well, we merely component our little share to bug wrangling err well, we merely contribute our little share to bug wrangling *remi` does random bugwrangling from time to time mraudsepp, except the set of "we" is EvaSDK :p EvaSDK does a whole lot Anyone remember what happened to the autoassign idea? supposedly not once there's that organization. Basic organization means easy finding what hasn't been organized yet Ford_Prefect, lack of manpowah -- you're an infra dude, get to it! and that little list is easy to reassign _actually_ this is a question we should as our power users *ask mrpouet, plaes, etc can they cc usÅ s/Å/? Yeah, they can So I suppose that solves the problem of getting that to our attention So, general consensus: Remove GNOME component, and power users etc can CC us Aye? power users can directly assign at least that's how I remember it EvaSDK, I didn't have powah when I was a power user :) I find infra making it more clear to users that they shouldn't assign a component if they aren't sure more clear there's no point in components at all otherwise it's written in clear red text right ? *Ford_Prefect wonders how many people who are not power users get the component right how clearer could it be Ford_Prefect, I would say none since most are useless :p We really want to minimise wrangler work, if possible. maybe it should be "GNOME team maintained", not "GNOME" or something ;d If the number who get it right is small, aye from me mraudsepp, too long :p Ford_Prefect, I meant, most components are useless There's too much noise in all that well the real solution would be to implement auto-assign and get rid of that component stuff altogether EvaSDK++ So, Ford_Prefect, do you volunteer to get that done? I would actually take a different approach but I don't see that happening from infra anytime soon mraudsepp, good, let's stick to the reasonably possible :p I'll talk to Robin about what remains Kewl, so this is done -- after Ford_Prefect talks to Robin, we'll see what to do about the COMPONENT field which would be to have a separate field for the specific package the bug (of type "ebuild") is about with some AJAX to get a category/PN pair quickly. Easy to make component and assignment matches from there mraudsepp, DREAM ON :p mraudsepp, blog about it Next: bugzie template search page for prioritized bugs Keyword bugs, separate Tracker bugs, separate crashers should be Major nirbheek: ACK, let's create a small "maintenance" page in the gnome doc space remi`, that will take time to do, so for now I'll just make a small html page in my devspace I can guidexmlify Excellent, so let's get the bugzie search links out now https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=gnome%40gentoo.org&emailtype2=substring&email2=&bugidtype=include&bug_id =&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0= that's my base URL remi`, dude, that's long fail can we shorten it? as for saved searches, maybe a greasemonkey script with the saved searches is better remi`, is.gd nirbheek: ???? assuming we all use browsers that can have such scripts ;d epiphany remi`, paste the http://is.gd URL mraudsepp, dude, one step at a time :p mraudsepp, let's get the URLs first ;p works the same for basic stuff nirbheek: I have _no_ idea what you're talking about I don't care for the urls, they are unreadable. Talk about search criteria mraudsepp: right, look at the x11 page I posted earlier remi`, you mean shorten the URL by removing redundant entries? I meant use a url shortner like tinyurl :p nirbheek: !good and I think it's better to talk about it with a concrete proposal, we all have day-jobs going on too remi`, just for communicating with us, so we can click on them except for nirbheek ;d *stab* *Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has quit: Read error: 104 (Connection reset by peer) mraudsepp: agreed nirbheek: you do it? remi`, I'll compile the webpages great Just give me some criteria for searches Fine, I'll get a proposed criteria for the next meeting with a sample set of links Next up: How Much Does YOUR eclass sucks? -s too much ? http://bugs.gentoo.org/show_bug.cgi?id=262491 I have no idea where we should stand on bug #256379 http://bugs.gentoo.org/show_bug.cgi?id=262490 I think you need to start with writing down the relevant properties first (P1 means that, P2 means that, what relevant keywords are there, if and what severity choices mean, etc) and then think about search criteria amongst those Are the eclass fixes high-priority? I don't think so. What about our inconsistent USE=doc meaning? gtk-doc results in rebuilding of docs I think some of this stuff should really be done in a not too distant feature, it's just annoying to get open bugs for doc stuff for example And we unconditionally install api docs anyway what open bugs? yes, we should do that always. about USE=doc, dang had started doing some stuff on it mraudsepp, see those blocking the tracker bug "stupid USE=doc management in gnome2.eclass" mraudsepp, you want it, I don't Most don't he'd compared to identical chroots, one with USE=doc, the other with USE=-doc and I don't think he saw any differences between the two *Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings remi`, exactly, our USE=doc just rebuilds the documentation! Yay, real keyboard. Ford_Prefect, congrats nirbheek: All those depend bugs are INVALID as far as I'm concerned for USE="gtk-doc" or doc, whatever, we should probably do "introspection" of the package if possible (shame he's not around to tell us what he found) like eautomake does to some extent I think the real solution is to find out the deal with cross-linking remi`: that's probably due to enhancements done since 1.10 get gtkdoc-rebase installed always, I think it should be light and not depend on all that stylesheets stuff and just don't need any USE=doc at all, as rebuilding is not necessary at all then, due to no benefits is there a need for API docs if you're not a dev anyway ? EvaSDK, Yes. Which is why KDE folks got a new USE-flag called api-docs I mean it's nothing like man pages that tell you how a command works DrEeevil, right? api-docs sounds fine well, something global for api specific stuff might work. need to investigate that, should be a global thing then nirbheek: no idea we should decide on wether building gtk-doc or not is relevant at all these days My standing understanding of USE=doc convention is since gtkdoc-rebase is executed always if installed +1 on USE=api-docs a) If documentation means no extra big downloads or build times, unconditionally always install it without USE flag b) If it means extra build time or non-trivial downloads, USE=doc currently it means extra installed weight mraudsepp, it's purely about it being useless to 90% of the users that might be complete shit for some users or we should actually support what USE=doc originally stands for : doc - Adds extra documentation (API, Javadoc, etc) meaning that USE=-doc does _not_ install API doc Which is the same as "api-docs" that would mean getting rid of it in most cases remi`, the 'etc' is very very vague :/ except that global description has been out of reality for years ;d nirbheek, I don't think it's that vague mraudsepp: the local descriptions pretty much say the same thing But I agree with remi` here for me USE=doc is more like "download an extra HTML documentation pack and install it" $ du -sh /usr/share/gtk-doc/ 125M /usr/share/gtk-doc/ IMHO, USE=-doc should _not_ install documentation other than README and/or man pages on my home system it's not that big, but not that small as well could help with livecd stuff remi`++ it not already excluded so, find out what the deal is with crosslinking these days and we go from there EvaSDK: that could very well make gnome fit on the gentoo livecd if ever comes back to life So, we have three types of docs: remi`: note that we should be able to just generate it by ourselves 1) Yelp user-documentation, manpages, etc 2) API documentation (pre-built, just install) 2) API documentation (rebuild, uses gtk-doc) mraudsepp: that's what I told dang the other day, and apparently he didn't notice cross-linking to better any better or worse with USE=doc last time I heard he hadn't looked at the right thing yet probably :) Okay, since we don't know the diff b/w rebuilding and pre-built yet, let's atleast split out into user and API docs but his method was right though identical chroots, turn on USE=doc, diff My goodness ;p Talk about brute force :D So, we all agree we need to rename to three types of docs? doc, api-doc, rebuild-api-doc ? (maybe not the third one :p) And maybe rebuild-doc too no So, atleast doc and api-doc? There's no use for doc then Yelp user documentation? remi`: that's the wrong thing to do though *Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has quit: Read error: 104 (Connection reset by peer) *remi` thinks USE=doc should control user docs too yelp user docs get always installed we aren't making that optional since the real check would be to make sure gtk-doc was never installed in the USE="-doc" chroot yeah, mraudsepp++ on this one for the record, /usr/share/gtk-doc contributes 16MB to livecd likely a bit less That's huge for the live cd Not for the live dvd, but huge for live cd test case: mksquashfs /usr/share/gtk-doc gtk-doc.squashfs *Ford_Prefect (n=ford_pre@gentoo/developer/ford-prefect) has joined ##gentoo-meetings nirbheek, why would we not install user documentation? Ford_Prefect, maybe the user doesn't want it around here's a corollary question : do _our_ users read yelp docs? remi`: that's not the point I personally _have_ to read klondike yelp docs for 99% of the extra games we're not ubuntu or fedora, do our users _need_ that doc? (it's a real question) user documentation available through yelp is as important as man pages But for the rest, I don't even know if they exist EvaSDK: I think it's important, we're talking about user features here EvaSDK, yes, and man pages are often optional nirbheek: not in gentoo at least not when they do not require huge amount of deps FEATURES=noman is there right but if we were to strip user docs, for that to be meaningful, we'd have to strip it from package compilation as well since it takes a bloody amount of time as well That should be a simple sed of the Makefile to remove the subdir well depends on the package but really I'm not thrilled by removing that I really wonder if it's worth the effort whereas gtk-doc is a pain *Ford_Prefect needs to grab dinner before he passes out. Bbiab, will reply off-list if meeting ends by then. So what we all agree upon is this: gtk-doc is a pain, and USE=doc does not mean api-docs for most people Ford_Prefect, aight, I'll be posting minutes Last comment - I'm in favour of renaming doc to api-doc to make the meaning very clear So step 1) USE=doc where it installs api docs should be renamed to api-docs nirbheek: hum I'd rather put it this way, rebuilding gtk-doc looks useless nowadays, it's api-docs but people don't necesseraly realize this Or dev-docs or something like that, so it's not library specific EvaSDK, yeah So fix to not rebuild, rather to control installation Then, rename to api-doc well, if we want to keep user docs, we might as well keep USE=doc for gtk-doc installation yeah or we have a consensus on USE=api-doc ? That's what KDE is using iirc can't find it I would argue that such use flag would probably be best discussed on -dev remi`, it was in their last meeting minutes but not sure this would end well EvaSDK, Yes. I say KDE herd wants it done, if we do it too, then the discussion on -dev will be shorter If we get kde/gnome/x11 on the same boat anyway... Exactly x11 installs no doc anyway ;) only man pages Then it should :p nirbheek: there are _no_ x docs, that's the beauty of x or its uglyness depends on how you see things EvaSDK: in X, beauty and ugliness are identical 1:1 relation ? They just redefined ugliness as beauty moving on, guys :) next point ? Static Libraries What's our position on --disable-static ? disable and provide a use-flag if necessary Do we want USE=static-libs ? only when appropriate glib, C++ bindings but in most case there is no need nor it is even tested Low-level, like libsoup? ACK on mraudsepp's list no NAK for libsoup C++ and stuff that wants to use the library but lives in / (as opposed to /usr) it's not critical So, things lower than libsoup, libgweather? :p glib ships it unconditionally though, and that's fine. I mean, it's not difficult to put static-libs in the eclass... nirbheek: USE flag pollution we don't need the static libs ever yeah like remi said they don't work Aight .la files? they're not tested would be more correct they are a source of undetected security vulnerabilities on users systems nirbheek: FTR, _anything_ above gtk will _fail_ with static linking ho ? remi`, oh, hum so let's disable since gtk uses dynamic loading => fail just disable until reasonable wanted otherwise, at which point we discuss council is fine with that ;d hehehe Good, so if someone asks, then we see