19:00 UTC, so let's start w00t k Agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2937 dilfridge? yes? [21:01] why w00t? just like that :) * blueness here roll call * dilfridge here * WilliamH here here [21:02] here scarabeus? her e I've one additional bug for agenda topic 4 [21:03] bug 480408 ulm: https://bugs.gentoo.org/480408 "Autobuilds go to /experimental and to /releases only when actually tested"; Gentoo Linux, Unspecified; CONF; mattst88:council k everyone o.k. if we add it? sure sure not a prob okay, but i'm not sure why that came to the council * WilliamH thinks that should be a releng decision? [21:04] blueness: let's discuss this later ;) k topic 2, support for separate /usr partition WilliamH: your stage Here's the thing folks. The council's vote in 2012 was ambiguous. [21:05] The summary said one thing, but looking at the log, the intention was completely different. and, imo, the intention, mandating support for separate /usr without a preboot mechanism, is a maintenance nightmare. WilliamH: sorry to interrupt - but I don't think we need to figure out the past intentions so much as define the policy moving forward [21:06] As you can see from the blog posts I cited from Flameeyes, what is needed in early boot is very difficult to define these days. Going forward, I would like for us to require some kind of preboot mechanism, e.g. initramfs or the sep-usr use flag on busybox, if folks have /usr and / on separate partitions. [21:07] (let us know when your done with the presentation and can ask questions) [21:08] That also eliminates the concern about crossing the / -> /usr barrier, since /usr would always be mounted when / is. Ok, let's open for discussion. suggest that when we vote we perhaps do it progressively - policy for new pkgs, existing ones, etc. [21:09] for anyone else who wants to quickly read up on busybox[sep-usr], here's a link: http://www.gossamer-threads.com/lists/gentoo/dev/252734 rich0: there's not really a way to separate this into new vs existing... basically it's an init wrapper that mounts /usr etc then hands off to real init My feeling is that long-term we want to stop supporting separate /usr without an early-boot mechanism to mount it. How we get there I think is open for debate. rich0: as soon as one package changes, everyone will be hit. there is another aspect of this, as far as I understand it, with the current systemd installation in Gentoo, having a separate /usr without early boot mechanism is impossible [21:10] rich0: most of tthe changes will be for base-system packages. For packages that are recent like systemd or such, I think we can just stick them in /usr and not worry about them. I had tried to summarise a bit and also suggested some successive votes here: http://article.gmane.org/gmane.linux.gentoo.project/2941 rich0, i read the FHS 3.4 standards yesterday, and while there is no mention of early boot mechanism it is clear that a system must be able to boot off of just / without /usr For stuff that exists the question is when to de-support separate usr, assuming we're Ok with that general direction. rich0: that's a separate issue, sticking whole packages in /usr isn't what I'm talking about. blueness: I agree 100% that what I'm proposing is not FHS compliant. [21:11] there exist configuratons eg nfs mounts of /usr where mounting / and /usr at the same time are not possible Basically the question is whether we care. blueness: that's true... unfortunately here reality seems to have ignored FHS blueness: no it isn't. rich0, okay so what do we do about such systems? i ran an entire lab like that till recently i don't think it should be our job to expend *significant* effort reworking build systems and such to follow fhs. only if it's relatively easy via configure flags, for example blueness: remember that in the latest standards, anything in / can be symlinks. and chainsaw runs a farm of similar servers blueness: same here Re NFS - why can't an initramfs mount both root and /usr? [21:12] so i'm okay as long as we have solutions in place for such systems dberkholz: but we also shouldn't remove support where it currently exists rich0, no the / would boot first and hten nfs mount /usr ulm, agreed we should not remove support where it already exists e.g., I wouldn't remove gen_usr_ldscript from util-linux [21:13] ulm: sure. i don't see that as controversial, to follow fhs wherever reasonable there is a similar problme with pxeboots blueness: the question isn't how it worked, but how it could work. Any reason an initramfs would not be possible, or a script that runs early from inittab? ulm: the /usr merge (separate subject) is fhs compliant. WilliamH: how that? rich0, okay if we can design an initramfs which can handle that then i'm okay Let's not get into the /usr merge here though, I was just siting it as an example. blueness: I'd think that dracut would work, but I'd have to see. [21:14] WilliamH, but people are worried about a slipper slope here WilliamH: well, it's the big question for the long term dracut is a documentation mess ulm: because newer fhs says that /{bin,sbin,lib*} can be symlinks Anybody doing PXE+nfs should know what they're doing in any case. Hardly a handbook install (I run one myself, but not with separate usr) someone wrote up a really small initramfs to do this (robbat2?), last time the discussion came up. WilliamH: pointer? we really badly need some *official installation documentation* on how to set up a system with an initrd [21:15] dilfridge: no argument there The thing about initramfs is that you can use the tools, or you can roll your own quite easily. okay so my position in a nutshell: okay to early boot mechanism with / and /usr separate provide we have working initramfs's (via genkernel say) for already existing setups I think we need to distinguish between where we are going and how we get there. +1 dilfridge, we really badly need some *official installation documentation* on how to set up a system with an initrd If we're not ready to make the jump now, then we don't need to jump. However, a declaration of long-term intent will allow everybody to start migrating. rich0, yeah that might work too, so people start to work towards athat as a team [21:16] but like ulm said -> e.g., I wouldn't remove gen_usr_ldscript from util-linux rich0: this is the jump -- separate /usr with or without an initramfs... That is the most disruptive part of going forward whether we do the /usr merge or not. blueness: yup - right now everybody is playing tug of war. Better to have them focusing on offering various solutions, docs, handbooks, whatever rather than fighting over whether it will happen. rich0: from what i see about it. it would be a disaster if one day people wok up and gen_usr_ldscript were dropped from util-linux blueness: only if they were not warned. [21:17] let me make another point (or repeat it) - systemd, separate usr & no initrd etc right now does already not work WilliamH, or if they were warned and didn't ahve a solution blueness, WilliamH: I think that might be the end result, but docs/handbook/etc maybe need to evolve to get there since (with the upcoming gnome) people will be moving to systemd, that makes these questions a bit more urgent blueness: my thought about gen_usr_ldscript is to first make it so you can turn it off in make.conf for testing. [21:18] WilliamH, i still need a solution for currently supported configuratons dilfridge: good point. One thing we could state is that non-legacy-packages can be /usr-dependent right away. I think the big concern is over openrc/sysvinit/udev and so on Anybody running systemd already is past this issue. rich0, correct [21:19] rich0: right So let them just move on blueness: if we turn it off, everywhere, the solution would be to rebuild all affected packages, then before you reboot switch to an initramfs. or sep-usr busybox WilliamH, okay then we need to doc what needs to be done before the switch is thrown blueness: there would be a list out there of the packages. because today we'll have it on a use flag last time I checked, sep-usr busybox was fundamentally broken but tomorrow we'll want to drop the support as it didn't fsck /usr WilliamH: I'd set up the initramfs first before rebuilding half your system to depend on it. The whole point of an initramfs is that it is smart enough to figure out how to boot your system either way. has that changed? [21:20] rich0: yes, that's true too, you could do it either way. ulm, i haven't check about sep-user busybox, but that it would surprise me you can build busybox without /usr everying in /bin and /sbin Honestly, I'm all for choice but I don't really get the initramfs hate. I don't think it really matters though - we should document whatever practical choices exist and leave it to the user. sep-usr busybox is not fancy at all. its purpose is to just mount /usr then move on. blueness: yeah, but it mounts /usr if you want more that is when you need an initramfs. If you can install grub you can build an initramfs... [21:21] rich0: I dont like it either, but that is mainly because of missing documentation dilfridge: http://www.gentoo.org/doc/en/initramfs-guide.xml dilfridge: yup - docs are definitely weak on the initramfs front. Maybe an area to focus on. rich0, the only argument against initramfs is just a cleaner boot, which might be an issue say on embedded systems rich0: and when I started with Linux, everyone recommended to use a separate /usr , always, everywhere like this? https://wiki.gentoo.org/wiki/Early_Userspace_Mounting http://www.gentoo.org/doc/en/initramfs-guide.xml docs have been out there for a long time. [21:22] looks good trying to keep this somewhat focused, should we take any decisions today? [21:23] So how about we propose that non-legacy pacakges (ie stuff that wasn't stable a year ago) don't have to support a separate /usr without an early boot mechanism. For legacy packages our intent is to not require this support and do the transition over the next six months, with communications/docs/etc in place before we make the change. FYI, initramfs images can be embedded into a kernel image for one compact file --- this might be an issue in some pxe situations To whatever extent they already exist it is just a communications problem. rich0, it might be more than just communication though [21:24] At the very least the handbook needs pointers and such it maybe technically difficult in certain exotic boot situations blueness: "To whatever extent they already exist..." yeah rich0: the handbook recommends not mounting with separate /usr. s/mounting/partitioning/ rich0: thist implies that we express our intention to do the /usr merge? [21:25] The examples do not show doing that. *this WilliamH: might want to update this: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml ulm: not necessarily. Example there is a separate /usr That could be done in less than 6 months. (and the doc I followed umpteen years ago) [21:26] well, we should go for consistency WilliamH: Just suggest that it be sometime in the next six months - not a hard time limit. We go when we're ready. so either FHS compliance so, let's say we make a statement of intent now (no sep-usr support required in half a year), strive to consolidate the documentation on initramfs etc, revisit in 2 months to see the status or /usr merge ulm: /usr merge is fhs compliant though. WilliamH: it isn't no way ulm: they aren't mutually exclusive. ulm: wait a sec [21:27] "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." * WilliamH is getting the link ulm: I think we really need to think about doing the /usr merge, but I don't see that has having to be a dependency. Somebody has to be willing to take that on. what do you mean by merge here -> ulm: /usr merge is fhs compliant though. a sym link / -> /usr ? that would be funny blueness: moving everything from /bin /sbin /lib* to /usr [21:28] i think going for consistency wherever feasible is different from requiring 100% consistency. the former is reasonable given the current state of reality, the latter is not. the /usr merg has symlinks in / for bin, sbin, lib* that go to their counerparts in /usr ulm, that would be very bad we have to try to be faithful to this -> "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." as best we can eg suppose /usr is corrupt and needs repair [21:29] blueness: I think the issue is that upstream has basically abandoned that entirely. can we get / up and fsck from it? At least for upstream=systemd/udev rich0, which upstream? blueness: yeah, the question is exactly if we would give that up then you're screwed because you won't be able to boot anyway, unless you boot to busybox. ulm hang on I'm getting the fhs link for you to show what I was talking about. ulm, we cannot give that up That is what is driving this. ulm: http://www.linuxbase.org/betaspecs/fhs/fhs.html [21:30] root is not sufficient as it stands if you're using something like a bluetooth keyboard, and the sense is that it will only get worse blueness: that exactly is the problem, on one hand people with dated server installations swear that / needs to be self-sufficient WilliamH: yes, and that says what I've quoted earlier blueness: on the other hand recent software sets do not really follow the constrictions for that anymore dilfridge, i'm one of them and there are lots of others, it would be bad blueness: meaning things break during upgrades without you noticing [21:31] yeah i know, we need to prevent that in so far as it is possible i'm okay with the initramfs solution but not with the merge I think we need to leave the merge aside for now. I think that is really a separate issue. [21:32] rich0: yes okay merge aside, let me get this clear There is a difference between allowing dependencies in /usr, and moving everything to /usr en masse. blueness: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ suppose / is fine and /usr is need of repair, would we be albe to affect the repairs using the proposed initramfs solution? *** reavertm (~reavertm@gentoo/developer/reavertm) has joined channel #gentoo-council [21:33] blueness: you need your repair utils in the initramfs WilliamH, i've read it, and i think those guys need to seriously rethink their position blueness: greatly depends on the nature of the problem. most initramfs will do basic fsck/etc automatically blueness: good luck on that one. blueness: busybox provides some of them most will also drop you to a shell, but what is available varies and is usually very limited ulm, that work, if the initramfs takes the place of / with documentation etc etc I think docs are a sticking point here. people who run servers need to have a repair path, if that's via initramfs tools i'm oaky with that [21:34] hence I suggest we agree on intent, but allow some time for doc updates and revisit Honestly, if your /usr is really hosed the stuff in / isn't going to be sufficient. You really need a rescue CD for serious work. blueness: that would be the repair path, yes. Much of the stuff in / is going to be in an initramfs. Most initramfs allow arbitrary files to be bundled as well. rich0, i think ulm's idea of repair in intramfs is great The usr merge is a red herring that doesn't affect this vote really. that might be the point that will satisfy people [21:35] like making the initramfs the new / I dont have much experience, but I *think* having fs repair utilities and basic network stuff (e.g. dhcpcd) in an initrd shoudl be possible blueness: you can very easily make your own initramfs too. That is a little bit more advanced but that level of customization is possible. in general Might not hurt to put that in the docs too - how to repair from an initramfs, or ensure your initramfs is configured to enable it (sometimes dropping to a shell is a config item for security - it is a root shell) WilliamH, i know :) i spend my time building firmware images [21:36] rich0, yeah if we can show how all FHS concerns are met in a slightly different way, then we have a very good middle path i can agree to the intent so my understanding now is, we will support separate /usr as long as people are using a mechanism to ensure it's mounted early. current methods include initramfs or busybox[sep-usr]. [21:37] Is there anybody who has issues then with the long-term move, but before we do it we need to agree all docs/etc are in a row? so shall we do actual voting today, or go back to ML discussion? if we vote, I suggest that we do it in steps, as suggested by rich0 ulm: vote today, but in steps [21:38] who wants to vote now? ml discussion is going to be a never-ending bikeshed I think. I suggest we at least vote on something around intent we can vote to the intent and get feedback on the mechanism the community make bring up tech issues we ahve not thought of If we are going to vote on intent, what does that mean in terms of base-system and toolchain working on legasy issues... like gen_usr_ldscript... [21:39] WilliamH: I'd rather avoid micro-management ulm: ok, that's fine with me. Suggest we also vote that stuff that wasn't stable a year ago (eg systemd) can depend on /usr now. I would rather avoid micro-management as well. ok here's a suggestion for a vote: yeah me neither, because people will figure out what to do just knowing the goal [21:40] One thing I think needs to be in the statement of intent is 1 "Since that particular setup may already be subtly broken today depending on the installed software, Council strongly suggests to use an early boot mount mechanism, e.g. initramfs, if /usr is on a separate partition." [21:41] strike "strongly" dilfridge: go ahead... ulm: no s/strongly suggests to use/recommends using/ dberkholz: +1 dberkholz, yep dberkholz: ok ok strongly is overkill [21:42] ++ - in general I've learned at work that any word ending in ly probably isn't necessary. LIke the probably in my last sentece. 1a "Since that particular setup may already be subtly broken today depending on the installed software, Council recommends using an early boot mount mechanism, e.g. initramfs, if /usr is on a separate partition." seems good so far o.k., please vote on 1(a) as suggested [21:43] 1b "Since that particular setup may already be subtly broken today depending on the installed software, Council recommends using an early boot mount mechanism, e.g. initramfs, to mount /usr if /usr is on a separate partition." sorry 1b please clearer (added "to mount /usr") * WilliamH votes yes * dilfridge yes * scarabeus goes for yes * blueness yes yes * ulm yes on 1b Now there is one more thing. [21:44] WilliamH: a few more things actually That's just part 1 sure. although i'd go with "the council" vs "Council" as a proper noun If we start changing software based on that recommendation and bugs are opened wanting us to change it back... dberkholz: your vote? as I"m sure there will be... WilliamH: we haven't gotten that far dberkholz: is that yes? sure == yes [21:45] k 1b just is a recommenation to users, not green light to maintainers unanimous rich0, right thanks for that clarification dilfridge: any further suggestion for a vote? well 2a - "Over the next few months the intent is to not require maintainers to support a separate /usr without an early boot mechanism, once the Council agrees that the necessary docs/migration path is in place. [21:46] something like that would be the next question, indeed what happened to scarabeus? doesn't seem to have said anything since 19:03 UTC. why council, when the docs are in place can be checked by anyone ah :) Yes, the docs are already there. mattst88_: i voted, i just don't do much about the /usr :;-) [21:47] rich0: shouldn't we ask the inverted question? ulm: means what? i.e. maintainers are required to still support separate /usr for existing packages [21:48] * WilliamH would vote no for that. (ones that are stable for at least one year) That's getting into micro-management. 2b - Once the Council agrees the necessary docs/migration path is in place maintainers will not be required to support booting with a separate /usr without an early boot mechanism (eg initramfs). until we revisit the issue rich0, can i suggest: 2a - "The intention is to eventually not require maintainers to support a separate /usr without an early boot mechanism once the Council agress that the necessary docs/migration path is in place." What is there to revisit? WilliamH: documentation mainly I'm fine with blueness's wording as well blueness: new wording -> new number please, otherwise things get confused [21:49] dilfridge, okay sorry s/number/letter/ I don't think we'll get agreement that docs are in place now in the next 10 min 2c - "The intention is to eventually not require maintainers to support a separate /usr without an early boot mechanism once the Council agress that the necessary docs/migration path is in place." What docs can we even agree on? there are many ways to build an initramfs... unless we force a divided vote - and I'm not certain that is a great idea. In any case, we need communications/etc to users before doing anything. any further changes to 2c wording? [21:50] There were docs sited in the meeting earlier... Suggest we vote on 2c yes vote on 2c please vote on 2c then * blueness yes on 2c WilliamH: agree docs were cited, not sure they're sufficient. i would actually say that council should not need to agree on when to start migrate, we don't dicate when to put new stuff or remove old one; we can leave that to openrc/systemd guys when they are sattisfied * rich0 yes on 2c paste 2c again? 2c - "The intention is to eventually not require maintainers to support a separate /usr without an early boot mechanism once the Council agress that the necessary docs/migration path is in place." scarabeus: only suggest council reviews due to the extreme sensitivity of the issue [21:51] s/agress/agrees normally I'd agree with you on that. dberkholz: already noted * WilliamH votes yes its base system, the same applies for genkernel or kernel guys, who started to change genpatches to huge stuff * ulm abstains on 2c I would like to say something though. [21:52] * dilfridge abstains on 2c wait, I withdraw my vote * WilliamH abstains dberkholz: scarabeus: ? The problem is that is too subjective. That's why I abstain Nothing subjective about it. When the council votes, it votes. [21:53] nope from me for this, unless the docs are exactly listed (you can easily say its fine or otherwise) Intent is to end debate over direction and direct efforts to how we get there. WilliamH: it's a design decision, it will always be subjective i vote yes Which docs are we talking about though? I cound 3 yes, 1 no, 3 abstains i don't think we should overly define this actually that could be worse WilliamH: suggest we take the docs discussion to the lists/etc. *count the dracut docs, the genkernel docs, a how to roll your own doc? motion passed [21:54] WilliamH: whatever docs gives the council the warm fuzzies. :) I intend to pitch in though. WilliamH, you can always bring that up when we discuss the docs, right now its just to have the goal stated ... and 2c does that ok * WilliamH votes yes then change my vote the key docs thing will be the handbook, mainly checking to make sure http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=7 has everything we need. Suggest voting on 3a - "Packages not stable 1 year ago need not support a separate /usr without an early boot mechanism immediately." 4 yes, 1 no, 2 abstains rich0: what about package splits? [21:55] strike "immediately" like netifrc ulm: irrelivent to this netifrc doesn't care about initramfs WilliamH: just an example ;) ;-) I guess there common sense applies... if part of something was stable a year ago, it counts as stable a year ago that double negative is killing me [21:56] 3b - Packages that were not stable on Aug 1st 2013 do not need to support a separate /usr. No further council vote is needed for these packages." s/2013/2012 rich0, i'm confused with respect to the intent/issue this is addressing Packages that did not have stable versions somebody could for sure get there "this version was not stable" :D [21:57] blueness: intent is that systemd/etc which already do not support a separate /usr can stay as they are Maybe just drop that issue entirely. Clearly we're not going to migrate that stuff to / only to migrate it back. * WilliamH thinks this is getting into micromanagement. rich0: yes i would reword it but we should be wary that people interpret 2c as "it is required now" [21:58] we're over time already, I suggest we conclude the issue at this point continue next month if there's need for it ulm: I'm fine with that. ulm, i'm okay with ending now, let's just leave the two points that'll be enough ok, at least we have a nice policy statement more like 3c "Packages with any stable version on 1 Aug 2012 should support a separate /usr if feasible." * blueness puts on his fire proof vest dberkholz: nope [21:59] topic 3, locale for build logs in bugzilla yep my baby http://article.gmane.org/gmane.linux.gentoo.project/2926 actually the discussion on the list was pretty much helpful bug 478382 chithead: https://bugs.gentoo.org/478382 "Please set LC_MESSAGES=C in make.conf"; Gentoo Hosted Projects, Catalyst; CONF; chithanh:catalyst I would like to immediately propose a vote [22:00] but I have a slightly different suggestion dilfridge: ++ - suggest something dilfridge: just a comment from me https://wiki.gentoo.org/wiki/Bugzilla_HOWTO#Evaluating_emerge_Errors currently suggests LC_ALL=C [22:01] so maybe we have to take care of this, too 4: "Make a news item, then add LC_MESSAGES=C to the base profile make.defaults" (this means anyone can override in make.conf easily, and still it goes into effect everywhere now) [22:02] this seems pretty straight forward, i see no problems here [22:03] are we voting? not sure if make.defaults is the right place for it ulm: where else? bug reporting guide? * WilliamH is wondering about forcing the setting too. people ignore that [22:04] ulm: the intent is to have it someplace so that it becomes a default behavior. I think it is either a profile or make.globals or the default make.conf well it's not really forcing it, it is just setting a sane default If I got a bug with logs in a language I couldn't read I would probably just close the bug as needinfo and explain that I couldn't read the logs. the profile is the simplest option I think if people insist to have russian gcc error messages, well, ... i read german and russian so i don't have to care, but i have half half bugs; localized/english and most will ignore you for the request to compile ie libreoffice for next 16 hours again... :-) [22:05] ulm: the intent is that the default will make your logs "bugzilla capable", and you need to actively do something to get away from that Oh, and I would also be willing to propose that maintainers are free to close bugs with non-english logs at their discretion. ulm: That guide (https://gentoo.org/doc/en/bugzilla-howto.xml --> https://wiki.gentoo.org/wiki/Bugzilla_HOWTO) already lists LC_ALL=C. But we can still change the defaults rich0: that's a different item, we can talk about it afterwards [22:06] TomWij: yeah, that's why I've posted this URL above :p LC_ALL causes pain for the python guys most people don't even realize they override the locale until it is too late, so why not have some default to keep us happy if it is in make.conf, it will become default for all new installs. jer (who complained most in the past) was fine with it ok, let's vote on dilfridge's proposal then dilfridge, ulm: Ah, I see the issue now; just the messages (for build logs) makes a lot more sense. [22:07] LC_MESSAGES=C in make.defaults * dilfridge yes * rich0 yes k * WilliamH yes * ulm yes * blueness yes 6 yes [22:08] scarabeus? yes unanimous docs need to be updated, too but that's self evident, no vote required I guess [22:09] next topic topic 4, open bugs with council involvement bug 477030 https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council anyone has talked to betelgeuse? [22:10] i looked for him but i never saw him didn't see him, just assign one guy to talk with him on the bug it is not something that needs to be fixed with upmost importance scarabeus: you've just volunteered? ;) and since we're at it [22:11] fancy do i get a beer for it? :-) dilfridge: when do we get the summary for July? regarding topic #3 do note that vapier spoke out against having it in make.defaults http://archives.gentoo.org/gentoo-dev/msg_0cd6b1f0e0b0c156e51b498362ec96f2.xml 10. Customs and Border Patrol knows of any time you have been arrested. I had read that the CBP’s background check is highly exhaustive, but I got the chance to witness the extent of their scrutiny. The applicant who had his appointment before mine began the process cordially, but their conversation quickly became heated. Apparently, this gentleman had his application denied due to an arrest 40 years ago. And according to him, the scarabeus: when I see you next :) 10. Customs and Border Patrol knows of any time you have been arrested. I had read that the CBP’s background check is highly exhaustive, but I got the chance to witness the extent of their scrutiny. The applicant who had his appointment before mine began the process cordially, but their conversation quickly became heated. Apparently, this gentleman had his application denied due to an arrest 40 years ago. And according to him, the [22:12] woops, sorry! middle click gone wild. dberkholz, what are you reading! hmm chithead: the post says that he's indifferent? [22:13] i was attempting to copy the link to vapier's thing and apparently failed with my two-button mouse ulm: indifferent to having it in make.conf, against having it in make.defaults ulm: soon ah, right chithead: not sure we want to re-open. I'm on the fence about that, but make.conf doesn't impact existing users at all. that vote is closed for now [22:14] chithead, i wish he'd given a reason chithead: dberkholz: if vapier does not bother to explain why, then we can't bother to take him serious I'd be fine with actually putting it in both places, to make it easy for new users to edit, have a comment to explain why it is set and not to submit bugs that are non-english, etc. we can revisit next month if there are good arguments sure next bug 480408 ulm: https://bugs.gentoo.org/480408 "Autobuilds go to /experimental and to /releases only when actually tested"; Gentoo Linux, Unspecified; CONF; mattst88:council (I'm here if anyone has questions) [22:15] ulm, why is this on the floor? I can answer that. shoot should we discuss this today, given that we're way behind schedule? ulm, let's start jmbsvicetto: are you here? who cares about schedule... I'd be happy to have someone else engage jmbsvicetto on the bug. *** NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has quit: Quit: what, what, what, what, what, what, what, what, what, what. Only 10 Watts Neddy ? Thats not very bright!! [22:16] I've been unsuccessful it seems, and have apparently insulted him. :\ anyway, I thought this proposal was uncontroversial (it received only positive comments on gentoo-dev), but jmbsvicetto objects. i dont get whats the problem, jorge tries hard, and we could put anything automatic there too (if somebody is interested) otherwise it is pointless, hand testing is weird [22:17] and I haven't been able to understand what he disagrees with. mattst88_, i'm on the bug cc, i'm just not sure why he's taken the position he has, but i don't feel comfortable bringing it to the council before its been discussed with releng lead (who is that?) blueness: I don't think we have one. *** xmw (~michael@gentoo/developer/xmw) has joined channel #gentoo-council That is jmbsvicetto (acting lead) the releng page doesn't say that. [22:18] mattst88_, i spoke with him briefly about it, but just to thank him for his hard work, and he *does* work very hard i'd like to table this pending my having a discussion with him jmbsvicetto, ^^^^ there's obviously a social problem in addition to the technical one, and we cannot solve this without further information blueness: could we do it in public? mattst88_, are you okay with that blueness: if we do it in the bug -- yes. I would like to hear jmbsvicetto explain his position. mattst88_, i'm not against public debate [22:19] rich0: yes, we shouldn't take a decision without that just a guess, but i'm thinking it may be manual vs automated testing mattst88_: No, it doesn't, that's what I was told personally though... I've run into build issues a few times in the last year. They have been improving, and I'm sure it is hard work. Would love to see build issues addressed, but would like releng's input as far as best way to accomplish that. but I do find it odd that agaffney is still there. if we could come up with an automated test suite, that would be probably go over well maybe just the page hasn't been updated in a while? mattst88_, he may need help [22:20] testing etc we used to do manual testing, fixes, etc and it was incredibly effort-intensive so, let's refer this back to bugzilla? right. fine by me. agree [22:21] Somebody want to volunteer with the inquiry? I don't mind rich0: k dberkholz: writting that openqa thing is quest for one afternoon I have some interest in this. topic 5, open floor yeah back to bugzilla, and since i'm part of releng i'll try to nudge this foward blueness: I'm fine with you taking the lead on that. [22:22] * ulm listening for open floor topics scarabeus: does it run on gentoo? [22:23] dberkholz: i said on the bug does the council favor git migration? dberkholz: it does scarabeus, i've never used openqa is that something you can easily set up? automate etc dberkholz: i did use gentoo at work to run it (without the web interface it is lame) that is bit rougher xmw: seriously? xmw: it isn't council that is stopping that; it is infra issues. [22:24] blueness: you basically say write x write z; enter; and then at specific points you say do_screenshot() later in web interface you just create "needle" which is part of the screen you compare to if it match test passed otherwise, problem is in place ulm: so, can you repeat your position, for us to nag infra, please? not a huge fan of things that require a web interface, really. they tend to fail hard in gentoo blueness: http://openqa.opensuse.org/results/openSUSE-Factory-GNOME-Live-i686-Build0658-live [22:25] blueness: the green squared ones are the tested parts (you can test even sounds if you are nuts like opensuse :D) xmw: not sure how the council should accelerate this scarabeus, looks like serious setup though [22:26] I'm all for the git migration, and robbat2 actually stepped down from trustees to give it more attention xmw: we definitely favor it, it's more of a matter of people doing the work I intend to help with docs, and xmw if you want to help out we can try to work with you. ulm: just eliminate any doubt, aka "there isn't even a clear standpoint from/of the council". infra has to do some back-end work though - on stuff that generally isn't accessible xmw: definitely in favour, but dont really know how to help since the rest is "work inside infra stuff" [22:27] xmw, yeah totally in favor of a git migration cvs is killing me, its such a resource hog ulm: Even s/should/could/, because it still depends on people doing work and you can't really do much about that (and as pointed out robbat2 makes more time free for it); unless you put more people to the work, but then again, I doubt if the amount of people is really the problem (and it is known that adding people slows things down due to lack of knowledge and extra communication). xmw: I'm in favour of course, but as others said, statements of intention won't help much i think this has always been about resources [22:28] i don't know anyone who is against a git migration thanks for the statement. xmw: http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt "The council also urges individual developers to join the effort to move the tree to git. " it's hard to get the semi-public infra code, maybe another attempt may help. dberkholz: there we go thanks :) dberkholz, i don't see how individual developers outside of infra could help here [22:29] I see no further topics brought forward to the council Well, there are other things that can be done in terms of docs/etc. [22:30] who's chair next time? *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: 10 Sep 2010 at 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/" blueness: me again blueness: note that the frontend is not technically needed, it is just easier to write result comparison that way, but you can do it without frontend and just execute the os-autoinst in loop blueness: check the tracker, there's opportunities to help: https://bugs.gentoo.org/show_bug.cgi?id=333531 ulm, okay i have an issue the meeting is closed thank you everybody [22:31] ulm: ^^ does the /topic say 2010, or is my irc client confused? ulm: blueness wanted to say something oops thanks. affirmative on the 2010. ulm: should we re-open? *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "Next meeting: 10 Sep 2013 at 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/" ulm: thank you! [22:32] blueness: Issue for council discussion or not? next meeting 10th of september dilfridge, its okay i'll just email him *** Hawk777 (~Hawk777@ritchie.cs.ubc.ca) has left channel #gentoo-council: #gentoo-council i liked the 2k10 ulm, i'll email you an issue blueness: sorry np missed your line :( *** TomWij (~TomWij@gentoo/developer/tomwij) has left channel #gentoo-council: "WeeChat 0.4.1" [22:33] ulm, really no problem, its easier via email