21:01 <@Koon> man it's hot 21:01 <@Koon> 19:00 UTC 21:01 < genstef> hi :) 21:01 < genstef> so let us start 21:02 <@vapier> who are you 21:02 < genstef> nobody 21:02 <@vapier> agriffis is at OSL but i dont know if he picked a proxy 21:02 <@vapier> we going to do GLEP42 first ? be a quickie 21:03 <@Koon> seemant's missing 21:04 <@Koon> In today's agenda : 21:04 <@Koon> - GLEP 42 21:04 <@Koon> - Sunrise project status 21:04 <@Koon> anything else ? 21:04 <@az> noting mailed to -council that i know of 21:04 <@solar> that is the only thing on the plate that I'm aware of 21:05 <+genstef> bugzilla being slow and we need a proxy or cache for when it is down - but jakobs request was not accepted afaik 21:05 <@solar> ok so 42 http://www.gentoo.org/proj/en/glep/glep-0042.html 21:05 <@Koon> vapier: you asked for portage guys to come to the meeting but... 21:06 <@vapier> they all seem AFK 21:06 <@vapier> maybe i need to send a heads up e-mail from now on the nite before 21:07 <@vapier> ah one is alive after all 21:07 <@vapier> /mode # +v zmedico 21:07 <@vapier> aldksjfa stupid mirc 21:07 <@Koon> you mean that, right 21:07 <@az> is there anything anybody want to discuss about it ? that, glsa's and info logging have been on the needed list for a long time now 21:07 <@vapier> zmedico: so we were doing GLEP 42 21:08 <+zmedico> alrighty 21:08 <@vapier> zmedico: from what i gather on the list from the portage members, it's all doable/done ? 21:08 <@Koon> we really need a way to pass vital upgrade information to our users 21:08 <@Koon> so I'll take whatever comes that achives that goal 21:08 <+zmedico> vapier: yeah, it'd not all done, but it's certainly doable. 21:09 <@vapier> so no real qualms with the latest version ? 21:09 <+zmedico> seems good to me 21:11 <@solar> most of it can already be accomplished via the post sync hooks easy enough. 21:12 <@solar> the parts where before you merge a package I dont' see happening 21:12 <@solar> as it dives deep into the resolver. 21:13 <@solar> I also would rather see such data going to stderr only. 21:14 <@solar> as portage/emerge in stable lacks the ability to share it's resolver data right now and many people make use of the --pretend options to parse emerge output. Sending news to stdout would break that 21:14 <+zmedico> I missed the part about news prior to install. I thought it was just post sync. 21:14 <@Koon> Checks for new news messages should be displayed: 21:14 <@Koon> * After an emerge sync 21:14 <@Koon> * After an emerge --pretend 21:14 <@Koon> * Before an emerge (which may also include a red warning message) 21:15 <@solar> please read it carefully. sbp and ciaranm both use gleps as to smuggle in additional goals they have 21:15 <@Koon> solar: is taht what you're talking about ? 21:15 <@solar> like repo-ids 21:15 <@solar> Koon: yes 21:17 <@Koon> solar: what would be the problem of pre-emerge notfication of new messages ? 21:17 <@Koon> no current hook for it ? 21:18 <+zmedico> no current hook, but we can add it. 21:19 <@az> cant that be put on hold or something ? or cant portage just after it did the order, just loop over them ? Dont see why there really need to be a hook as such 21:20 <@Koon> If I read the GLEp correctly, notification of new messages occur even if the packages are not those you are currently emerging (but are installed) ? 21:21 <@Koon> meaning "emerge xchat" would warn about the existance of messages about MySQl migration 21:22 <+zmedico> I don't think so. all unread would be displayed at sync, and the pertinent ones would be displayed for install commands. 21:23 <@Koon> That would be better, but that is not mandated in the GLEP 21:23 <@Koon> or I missed it 21:24 <+zmedico> you're right 21:24 <+zmedico> I guess it just shows all unread new items 21:24 <@Koon> yes, and in the same way "after an emerge sync" and "before an emerge package" 21:24 <+zmedico> makes sense. just mark them read and then you won't be bothered again. 21:25 <@Koon> that simplifies it, no need to dive in the resolver 21:25 <+zmedico> yeah, no need for emerge to feed a package list to the news scanner. 21:25 <@Koon> the same is_there_news() routine is called in every case 21:25 * zmedico nods 21:26 <@Koon> solar: does that answer your concern ? 21:27 <@Koon> am I splitted/alone ? 21:27 <@solar> well. I dislike most of it. So I'll go ahead and say if we are voting I'd reject it 21:28 <@Koon> what are your (main) issues against it ? 21:28 <@solar> we are a bit shy and spb nor ciaranm are here so I don't think we should vote 21:28 <+zmedico> well, if we and a hook for install commands, portage doesn't have to know anything about the news stuff. it can just be hooked in. 21:28 <+zmedico> s/and/add/ 21:28 <+zmedico> az: that's where hooks are useful 21:28 <@Koon> solar: you're against the principle of sending upgrade info to the end user ? Or against the implementation details ? 21:29 <@Koon> vapier/SwiFT/az: what so you think of it ? 21:30 <@SwifT> I think the goal is noble and worth implementing 21:30 <@SwifT> can't care less about spb/ciaranm 21:30 <@az> well, the idea in itself is fine, if there is issues about implementation that others with more knowledge on portage disagrees with, i guess it should be seen to first 21:30 <@solar> I don't care for the implementation details. I don't really want eselect forced upon me. the end goal is desireable yes 21:30 <@SwifT> I also feel that there is enough support for it 21:31 <@solar> existing portage provide the majority of whats needed todo most of this today 21:31 <@SwifT> and in the end, if it doesn't work out, no sweat :) 21:31 <@Koon> eselect is presented as a default/possible news reader 21:31 <@Koon> not the only option 21:31 <@vapier> eselect is an option 21:31 <@Koon> also it's quite easy to ignore the whole system 21:31 <@vapier> it's also going to happen regardless ... an outstanding issue is all the -config scripts we have 21:32 <@vapier> that was the point of eselect 21:32 <@SwifT> the rsync_exclude option? well, it might be more userfriendly to use a FEATURE, but that might be just my own feeling 21:32 <@SwifT> and it's a detail 21:32 <@Koon> FEATURE=ignore_news ? 21:32 <@solar> excluding is easy enough. 21:33 <@Koon> Should we vote ? 21:33 <@SwifT> FEATURE="shownews" (I don't like negative entities) 21:33 <@SwifT> :) 21:34 <@solar> well from the looks of it portage/emerge would only display the number of unread items 21:35 <@SwifT> also true 21:35 <@Koon> it's more a change in development/pr methods than a technical one 21:35 <@solar> not the news itself so as long as it's a 1 liner it should be ok. Again this can already be done via post sync actions. 21:36 <@SwifT> disregard my comment then, those few lines don't make much difference as we do that for the config stuff already 21:36 <@Koon> maintainers should change their habits and prepare news messages for their non-trivial upgrades 21:37 <@Koon> where they used to rely only on postinstall messages in the past 21:37 <@solar> maintainers will also have to go edit these news items for every pkg move 21:38 <@vapier> are you posting a complaint or pointing out the obvious ? ;) 21:38 <@Koon> it's too hot to think 21:39 <@SwifT> messages need to be posted on -dev some time in advance; there should be sufficient support from devs and users to craft the message 21:40 <@Koon> Ready to vote ? 21:40 <@SwifT> aye here 21:41 <@az> yeah 21:41 <@vapier> +1 21:42 <@Koon> I vote yes, this is long due 21:43 <@az> +1 21:43 <@az> that and the elog stuff should hopefully get the needed messages through once they are in use 21:45 <@Koon> solar? 21:45 <@vapier> SwifT ? 21:46 <@SwifT> I said "aye here" 21:46 <@az> could throw it back with yes if foo bar is resolved if there is issues, and for the eselect issue - just look at etc-config, dispatch-conf and now blubb's new thing 21:47 <@Koon> That means 4 yes, probably adopted then 21:48 <@Koon> Now the Sunrise status discussion 21:48 <@solar> I'd rather not vote on it till a proof of concept exists for the portage ends of things. The way they are planning it seems somewhat ulgy with all the portageq calls. And as stated several times most of the functionality already exists 21:48 <@vapier> eselect is a reference implementation 21:48 <@vapier> not required 21:48 <@solar> that is not for portage 21:48 <@Koon> Thats a catch-22, there needs to be an OK on the GLEp before anything is developed 21:48 <@solar> that is for that other pkg mgr. 21:49 <@az> what i meant, its not like it will be locked down 21:49 <@Koon> yes, we can still cut its balls if it bevomes nasty 21:49 <@Koon> well, probably those who come after us 21:50 <@az> solar: which one of the many otheres these days ? *grin* 21:50 <@Koon> The Mythical 2007 Council 21:50 <@solar> who is going to code it anyway? I'm not totally in favor of approving something then the work is dumped on others. 21:50 <@Koon> we approve the idea of it 21:51 <@Koon> solar: then you don't agree on the counil/glep thing 21:51 <@Koon> council 21:51 <@Koon> because "approving things and then hoping someone will do it" is what we do 21:52 <@Koon> this GLEP having a particularity : it's not written by the ones that will have to do the work 21:52 <@Koon> letting some room for the implementer to do it a little differently 21:52 <@Koon> OK, only 10 minutes left, so let's consider it approved with 4 yes and go to sunrise discussion 21:53 <@Koon> vapier: you voted yes, right 21:53 <@solar> I'll vote yes on the basic idea. just not that implementation 21:53 <+genstef> ok, we have worked with the mailing list on hashing the details out and improving the implementation 21:54 <+genstef> but apparently interest has ceased since brix got the overlay closed down 21:54 <@Koon> it should revivce when we open it back 21:54 <@Koon> revive 21:54 <@vapier> Koon: +1 21:55 <+genstef> Koon: yeah, exactly what I am thinking 21:56 <@Koon> Have all the reasonable objections been addressed ? 21:56 <@Koon> because you'll never satisfy those who want it dead anyway 21:56 <+genstef> I hope so. If you can point something more out to me I would love to hear it 21:56 <@az> last bitching there have been, have stopped when vapier asked to point out the issues 21:56 <@az> if i remember 21:56 <@Koon> az: I didn't follow very closely but I remember that too 21:57 <@Koon> Frankly I don't like too much when people wanting to kill other's innovations do not even stand by to point out reasonable objections 21:57 <@vapier> so i know wolf and brix had issues, who were some of the other people originally ? or do i need to flip through some threads again ? 21:58 <+genstef> vapier: foser probably 21:58 <+genstef> others had the general objection of unreviewed code which has been adressed by making that part read-only 21:59 <@solar> genstef: in short.. the new sunrise will provide a place to host maintainer-wanted ebuilds which will be proxied by you and what ever team you put together? the repo itself will be anonymous. 21:59 <+genstef> one repo for users to commit 21:59 <@vapier> the team including many user contributions 21:59 <@Koon> sounds like what some others do without giving it a fancy name 22:00 <+genstef> one repo for developers to move the ebuilds to 22:00 <+genstef> the user-commit thing is read only 22:00 <@solar> so your goal is to open cvs +w up to the world? 22:00 <@solar> cvs/svn/vcs.. 22:00 <@Koon> vss? 22:01 <+genstef> solar: no 22:01 <@solar> version control system. (what ever one is picked in the end.) 22:01 <+genstef> solar: users get accounts on request 22:01 <@SwifT> i like the sunrise/ vs reviewed/ qa :) 22:01 <@Koon> I am all for opening Gentoo more to the community, so I support the idea 22:01 <+genstef> SwifT: yeah exactly :) 22:02 <+genstef> and sunrise cannot be checked out anonyous 22:02 <@solar> what criteria will there be to have a user approved? 22:02 <@Koon> quality of contrib I suppose 22:02 <+genstef> solar: ebuild-quiz 22:02 <+genstef> solar: users can only commit to sunrise/, only developers to reviewed/ 22:03 <@SwifT> solar: ebuilds by non-devs are still staged before they are available for public usage 22:03 <@solar> who will be reviewing those? recruiters? other? 22:03 <@Koon> call them wanabees rather than "users" or "world" 22:03 <+genstef> solar: sunrise developers 22:03 <+genstef> solar: people in the project 22:03 <+genstef> solar: but there is not much advantage of taking the ebuild quiz 22:04 <+genstef> just skipping the pre-commit review 22:04 <+genstef> of course users are still users even with the quiz and do not get more permissions 22:04 <@Koon> genstef: I think solar's concern is more about security, giving a +w access to somewhere into Gentoo's infra to someone less controlled 22:05 <@Koon> not about end-user risk of using a bad ebuild contributed through the system 22:05 <@solar> Koon: how can you tell :) 22:05 <+genstef> well the write access is only for unreviewed stuff, so they can do no harm 22:05 <@Koon> I read your mind, don't move too much 22:05 <+genstef> like write access to bugzilla attachments 22:05 <@SwifT> genstef: it's more about the security considerations than the contribution sensibility 22:06 <@Koon> genstef: the "harm" is more a new attack vector on Gentoo(s infra that we must care for, than potential harm done to users 22:07 <@Koon> but I say it's the price to pay for a dev community 22:07 <@solar> genstef: for sunrise. I'd prefer that any cia hooks that you might put in place do not show up under the 'gentoo' name as it would skew real cia stats.. gentoo-sunrise other would be fine. 22:08 <+genstef> solar: ok 22:08 * solar has no objections and would encourage anon to be opened up 22:08 <@Koon> OK. I vote for stopping the suspension of the Sunrise project 22:08 <@solar> anon-read-only that is to all of it. 22:08 <@Koon> as all reasonable objections have been addressed 22:09 <+genstef> solar: it is http accessible, just not for checkout 22:09 <@solar> right. http:// is useless and webdav is not allowed on infra servers. 22:09 <@solar> so checking out would be somewhat of a pita. granted anon is what others object to. 22:10 <@Koon> and kudos to the project Sunrise developers for having addressed those concerns so gracefully 22:10 <@Koon> without falling into the traps that were set up for them to fall in 22:10 <@SwifT> the sunrisefaq is a nice document to read 22:10 * solar has to split for a few mins. 22:10 <@Koon> vapier? az? 22:11 <@SwifT> i'm o 22:11 <@SwifT> kay for it 22:11 <@az> fine with me 22:13 <@Koon> seemant was for the suspension and is not with us today 22:14 <+genstef> he has sent no proxy either, has he maybe forgotten the meeting? Or does he not care? I have talked long with him after the last meeting 22:15 <@az> might have forgotten or busy 22:15 <@az> havent seen him today 22:15 <@Koon> vapier? 22:16 <@Koon> I'll have to let you all finish without me... so for the record I'm for stopping the suspension 22:17 <@az> same here 22:19 <@vapier> sorry, had phone call 22:20 <@vapier> i'm for the project and i'm for hunting down the people who had outstanding concerns 22:20 <@Koon> to kill them or ask them a few questions ? 22:21 <@Koon> I'm pretty sure once the project is un-suspended they will show up 22:21 <@SwifT> =) 22:22 <@Koon> OK then 22:22 <@Koon> I'll let you finish from here, see you all next month for our last meeting 22:24 <@SwifT> I'm off as well now 22:24 <@SwifT> laptop's too heated :) 22:24 <+genstef> bye SwifT 22:26 <@solar> meeting over then.