path: root/meeting-logs/20060720.txt

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 <target> (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.