- commit the meeting log

1 files changed, 227 insertions, 0 deletions

diff --git a/meeting-logs/20060720.txt b/meeting-logs/20060720.txt
new file mode 100644
index 0000000..e92efab
--- /dev/null
+++ b/meeting-logs/20060720.txt
@@ -0,0 +1,227 @@
+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.