* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20130910.txt
@ 2013-09-10 20:59 Ulrich Mueller (ulm)
0 siblings, 0 replies; only message in thread
From: Ulrich Mueller (ulm) @ 2013-09-10 20:59 UTC (permalink / raw
To: gentoo-commits
ulm 13/09/10 20:59:54
Added: 20130910.txt
Log:
Log for 20130910 meeting.
Revision Changes Path
1.1 xml/htdocs/proj/en/council/meeting-logs/20130910.txt
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20130910.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20130910.txt?rev=1.1&content-type=text/plain
Index: 20130910.txt
===================================================================
<ulm> let's start then [21:00]
*** dastergon (~dastergon@gentoo/developer/dastergon) has joined channel
#gentoo-council
<ulm> agenda is here:
http://article.gmane.org/gmane.linux.gentoo.devel.announce/1978
<ulm> roll call
<rich0> here
<Calchan> here
<blueness> here
<Calchan> proxing for dberkholz
<WilliamH> here
* scarabeus here
<scarabeus> dilfridge: pling [21:01]
<blueness> start without him? [21:02]
<ulm> let's see if I have his phone number
<ulm> I've sent a text message [21:03]
<blueness> ulm, any response? [21:04]
<ulm> no
<ulm> let's start then [21:05]
<blueness> k
<ulm> 2. Install functions, default src_install
<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2976
<ulm> it's all in that message, so I've nothing to add here
<ulm> I suggest that we discuss and vote about the two parts separately
[21:06]
<rich0> ulm: my sense from the discussion is that there is no real need to
make it retroactive. Is there somebody seeking that who I missed?
<rich0> Ie, nothing in-tree depends on the portage-specific behavior.
<ulm> first would be clarification of PMS wording for do* functions:
http://article.gmane.org/gmane.linux.gentoo.pms/764 [21:07]
<ulm> rich0: right, we'll come to this in a minute
<ulm> anyone wants to discuss the first part? [21:08]
<blueness> ulm, the clarification would say that do* without arguments die?
<ulm> blueness: exactly
<ulm> portage could keep it's current behaviour for at least a transition time
though, i.e. dodoc has only a QA warning [21:09]
<ulm> *its
* scarabeus agree with making it fatal :-)
<rich0> Your wording seems fine to me.
<blueness> i'm for it
<rich0> If nothing in-tree now depends on this behavior suggest we keep it
that way... [21:10]
<ulm> ok, then please vote for the wording in
http://article.gmane.org/gmane.linux.gentoo.pms/764
* ulm yes
<rich0> yes
<Calchan> yes [21:11]
<WilliamH> yes
*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 240
seconds
<blueness> yes
<ulm> scarabeus?
*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
#gentoo-council
* scarabeus yes
<ulm> unanimously
<ulm> second part is a bit more tricky
<ulm> http://article.gmane.org/gmane.linux.gentoo.pms/766 [21:12]
<ulm> that would change default src_install for EAPI 4 and 5 retroactively
<ulm> but AFAIK it's not used in the tree [21:13]
<ulm> so I'm indifferent
<blueness> i'm not sure we need this retroactive
<rich0> I suggest not doing any retroactive changes if there isn't a need.
<rich0> But by all means keep this undocumented behavior out of portage.
* WilliamH isn't sure about this either
<blueness> well what if someone tries this at EAPI=0. they would only get the
QA warning. then later when bumping to EAPI=5 the ebuild would
die. doesn't sound that bad to me. [21:14]
<scarabeus> if it is not used in main tree we can even do retroactive fix; but
i would leave it to ulm to decide as it is his patch [21:15]
<WilliamH> scarabeus: that sounds reasonable...
<ulm> let's just vote then [21:16]
<blueness> k
<ulm> approve wording of http://article.gmane.org/gmane.linux.gentoo.pms/766
yes/no [21:17]
<WilliamH> ulm: what is the vote?
<ulm> I abstain from the vote
<Calchan> retroactively changing an EAPI defeats the purpose of EAPIs, so I
vote no
<blueness> i vote no to retroactively changing
<ssuominen> while src_install() is being discussed, I should have suggested
looking at bug 459692 at the same time. i'm late as usual. :/
[21:18]
<willikins> https://bugs.gentoo.org/459692 "[Future EAPI] Provide a function,
like dodocs(), to process DOCS= without calling `default`";
Gentoo Hosted Projects, PMS/EAPI; CONF; ssuominen:pms-bugs
<scarabeus> ok if we have 2 and rest indiferent it is no
<ulm> ssuominen: that's agenda topic 3
<rich0> ulm: that link points to code, not a policy. If you're asking whether
or not it should be retroactive, I say no for the stated reasons.
<ssuominen> ulm: cool!
*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264
seconds [21:19]
* WilliamH votes no
<ulm> scarabeus: not sure what your vote was?
<ulm> so far I count 4 no votes, so it doesn't pass [21:20]
<scarabeus> indiferent
<ulm> thanks
<ulm> next topic [21:21]
<ulm> 3. einstalldocs() pre-approval for next EAPI
<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2978
<ulm> http://thread.gmane.org/gmane.linux.gentoo.devel/87642/focus=87803
<ulm> mgorny: are you here?
<mgorny> yes
<ulm> mgorny: can you shortly summarise it? [21:22]
<mgorny> sure
<mgorny> EAPI 4 default src_install() calls 'make install' and installs docs
<mgorny> we'd like to split the doc-install part in EAPI 6 to a separate
function [21:23]
<mgorny> it'd likely be called einstalldocs and fix most of the issues that
were pointed out
*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
<mgorny> however, since a lot of eclasses reimplement that doc-install in
different ways already
<mgorny> we'd like to also the same function to eutils.eclass for older EAPIs
[21:24]
<mgorny> (and use that consistently in all eclasses)
<mgorny> so I'd like the Council to vote on the code i presented that would go
into future EAPI 6, and into eutils.eclass
*** pacho2 (~pacho@gentoo/developer/pacho) has quit: Quit: Leaving.
<ulm> that's the code in the second link that I've posted above [21:25]
<blueness> mgorny, eutils.eclass would have intelligence to know if
eisntalldocs() is defined (ebcause of EAPI 6)?
*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
<WilliamH> mgorny: why not just make it part of src_install for EAPI>=6 and
add it to utils.eclass for older eapis?
<scarabeus> blueness: we already did it with something so yea we can do that
*** pacho2 (~pacho@gentoo/developer/pacho) has quit: Read error: Connection
reset by peer
<mgorny> blueness: we already have some backports like this, the functions are
inside 'if has $EAPI ...'
<blueness> WilliamH, i think that's what he's saying so i just wanted to be
sure [21:26]
<scarabeus> WilliamH: to clean up most of the using eclasses, otherwise you
would have to keep lots of stuff in eclasses
<mgorny> WilliamH: that's what i said :)
<scarabeus> this makes quite lot of sense so I like it
<blueness> works for me, i'm for it
<WilliamH> mgorny: Oh, I thought you said make it a separate function in eapi
6. ;-)
<mgorny> yes, there will be a separate function
<mgorny> so people could use it in eclasses without calling 'make install'
<scarabeus> only one nitpick for the code as i read it now, you should detect
the default files and warn if you put them manually to the
array/list so we avoid duplication maybe? [21:27]
<ulm> implementation looks sane, and it makes sense to add it to eutils now,
but preapprove the implementation for EAPI 6
<mgorny> scarabeus: sounds out of scope of PMS IMO
*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
<scarabeus> mgorny: yea, but for the feature implementation which you want to
put to eutils anyway... :P
<mgorny> scarabeus: sure
<scarabeus> and i said nitpick, not critical stopper [21:28]
<ulm> I'd test for [[ ${#DOCS[@]} -gt 0 ]] not for [[ ${DOCS[@]} ]] but it's
probably a matter of taste [21:29]
<ulm> so also not a stopper
<scarabeus> yea that is just taste ;-)
<ulm> so, just vote?
* blueness yes
* ulm yes [21:30]
<Calchan> yes
<rich0> yes
* WilliamH yes
* scarabeus yes
<ulm> unanimous
* scarabeus throws cookie on mgorny ;-)
<mgorny> thanks
<ulm> yw :)
<ulm> next topic
<ulm> 4. Minor architectures stabilisation policy
<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2984
<ulm> http://thread.gmane.org/gmane.linux.gentoo.devel/87741
<ulm> hwoarang: here? [21:31]
<dilfridge> /&%(/&%)/&%)(/& [21:32]
<blueness> i'm on many arch teams and imho, arch testing is a lot of work
<dilfridge> sorry
<blueness> lot of busywork
<ulm> dilfridge: hello
<Calchan> the question is very simple: why would we not do it?
<blueness> so without the manpower, its hard to say if "stable" even means
anything with that low a level of manpower
<blueness> also
<scarabeus> yea most stable on exotic archs is now "compilation tested" which
beats me... is useless [21:33]
<blueness> mips is ~arch and yet hwoarang and mattst88 and I are doing a lot
with mips
<rich0> blueness: agree - it just seems like keeping archs that can't keep up
just weighs down everybody else, and doesn't really do any service to
users of those archs.
<blueness> i spent a whole month last summer trying to get ppc and ppc64 up to
date, and it nearly killed me and yet those are in "decent" shape
<ulm> do we have statements from the respective arch teams? [21:34]
<WilliamH> I've had experiences in the past (not recent past) where arch teams
refuse to stabilize something unless users of that arch want the
newer version stable.
<ulm> or is that only ago for all of them?
<scarabeus> WilliamH: wich is also bad
<Calchan> ulm: isn't the respective arch teams just ago?
<rich0> ulm: I'm certainly interested in that - I believe I called for that in
-dev and didn't hear anything.
<dilfridge> seems I arrived when the interesting stuff started
<blueness> scarabeus, correct because then packages deps get out of sync
<dilfridge> some arch team members commented [21:35]
<dilfridge> but noone from s390 or m68k
<dilfridge> which are the most critical points
<Calchan> dilfridge: last I knew m68k was just vapier [21:36]
<dilfridge> (at least according to the metrics provided by hwoarang (I
think)?)
<scarabeus> yea it is just mike afaik
<dilfridge> well even if it is just mike, he didnt comment
<Calchan> and you're going to have a hard time interesting him in
stabilizations [21:37]
<blueness> my only concern with minor arches is embedded systems, so maybe
m68k is used in embedded
<scarabeus> blueness: still we have testing
<blueness> but its just a question of what we mean by "stable"
<scarabeus> and if there are not enough people to stable it, then...
<blueness> scarabeus, right
<scarabeus> i am all in favor of puting all of them to testing-only unless 4
people team is behind them [21:38]
<Calchan> I'm going back to my question above:
<Calchan> 19:32 < Calchan> the question is very simple: why would we not do
it?
<Calchan> any reasons?
<ssuominen> armin76 just blogged on planet.gentoo.org howto use m68k emulator
as a arch build host and about stage3's for m68k for the purpose
<blueness> Calchan, that's hard to answer because we don't know what the user
base is
<ulm> alpha and sparc are still supported by security
<dilfridge> not do what?
<ulm> at least that's what
http://www.gentoo.org/security/en/vulnerability-policy.xml says
<rich0> scarabeus: I don't care how many are in the team - just that they keep
up. If users of some arch hire a full-time dev to stabilize things,
more power to them.
<Calchan> blueness: true and not true at the same time, this kind of
stabilization work doesn't bring any value [21:39]
<scarabeus> rich0: but it must not end like ago doing everything, he will
eventually burn out...
<blueness> yes he will
<dilfridge> at some point for sure
<blueness> i'm surprised he hasn't yet
<blueness> i've also wondered if we can't automate stabilizations [21:40]
<blueness> ie create a tinderbox with a stabilization queue
<scarabeus> thats different topic
* dilfridge spent a negligible time as amd64 arch tester and felt the pain
quickly
<blueness> scarabeus, true
<dilfridge> yes but that is only good for build testing
<blueness> call the question?
<scarabeus> so should we vote to kill them and announce it and see the
opposition that it rises to revisit it?
<dilfridge> I still believe that stable testing should be more [21:41]
<rich0> in any case, I agree with scarabeus - I'm inclined to yank them all
since nobody really has committed to doing anything to keep them
going.
<Calchan> scarabeus: who's talking about "killing" them?
<ulm> so, do we vote on it?
<scarabeus> marking them testing
<dilfridge> how about, yank m68k and s390 stable and give the others warning?
<blueness> nah
<blueness> yank em all
<Calchan> scarabeus: that's the kind of wording which will indeed rais trouble
<dilfridge> blueness: it's hard to reverse [21:42]
<WilliamH> s/yank/mark testing/
<ulm> drop to testing
* scarabeus agrees
<Calchan> yes, mark them testing
* blueness yes
<WilliamH> yes
<dilfridge> mark testing = "no stable keyword"
<WilliamH> which arch's though?
<ulm> let's vote on them separately? [21:43]
<dilfridge> ?
<rich0> let's be clear on which ones.
<ssuominen> why not leave them be and just change wording/policy to not list
those arch's officially supported. the road from ~ to stable
after testing they build/work on m68k and others has been long, so
reverting that should not be taken lightly...
<blueness> s390 sh ia64 alpha m68k sparc
<dilfridge> separate votes
<ulm> yeah
<ulm> in alphabetical order ;)
<ulm> alpha: no more stable keyword? [21:44]
* scarabeus yes
* blueness yes
<dilfridge> guys please be careful, we're about to do something irreversible
* dilfridge no
<WilliamH> yes
* ulm abstains
* WilliamH withdraws...
<scarabeus> dilfridge: it is revetable quite easily; you can later on pick
them up
<rich0> yes
<WilliamH> folks, I want a way to do something as a maintainer... [21:45]
<Calchan> yes
<ssuominen> easily? not
<WilliamH> dilfridge: how is this irreversable?
<scarabeus> it is if you do scrapper for deleted ebuilds too and just parse
max subset of keywords and put them back as it compiles, and if
you want to get stable arch you have to test it, not just stamp
back what it had [21:46]
<ulm> WilliamH: it's hard to get an arch back into consistent state
<dilfridge> versions will progress after the stable keywords have been
removed, everything will have to be retested to get a functioning
deptree
<ulm> once you start dropping keywords
<ulm> dilfridge: exactly
<Calchan> btw, has anybody tried to get feedback form users on this? not just
devs?
<dilfridge> it helps if you use an arch where compiling is fast :D [21:47]
<dilfridge> Calchan: would you like to adopt the gentoostats project?
<WilliamH> AS a maintainer, I would like a policy like this:
<Calchan> dilfridge: what's your point?
<WilliamH> if I have a stable request for a new version of a package and it
has been open for 30-60 days or so and minor arch's do not respond
or have any blockers on my stablereq, [21:48]
<dilfridge> knowing how many people really use an arch... we have e.g. ppc64
keywords on whole kde and I know of one user
<WilliamH> then I want to remove the older versions.
<ulm> looks like the topic needs more discussion [21:49]
<rich0> I don't really care how many users there are - only how
well-maintained the stable keywords are.
<dilfridge> WilliamH: good point.
<ulm> as we've envisaged another meeting for this month anyway
<dilfridge> WilliamH: full agreement
<ulm> how about postponing the vote by a week?
<ssuominen> It's not just kids in basement -users, but actual production ...
<rich0> Should we vote on deferral vs immediate resolution?
*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
#gentoo-council
<blueness> dilfridge, if we can't maintain a stable set of stabilized ebuilds,
we're worse off then dropping to testing
<ulm> and discuss in the mailing lists
<blueness> let's table it
<dilfridge> well
<scarabeus> ssuominen: so they can give back some resources or do something
against it otherwise it is tough luck [21:50]
<dilfridge> ulm: it was already discussed
* WilliamH agrees with blueness
<rich0> personally I would rather not table.
<dilfridge> ulm: but that's why I suggested "giving warning" for some arches,
i.e. next month we drop if nothing changes
<Calchan> it looks lie we don't have a clear view of the actual impact of
dropping those to ~arch, so it is clearly premature to vote on this
<rich0> however, up to the majority - I suspect that nothing will happen if we
table beyond two more weeks going by
<ulm> ok [21:51]
<WilliamH> we shouldn't table for long.
<ulm> please vote: defer the decision to next meeting
<rich0> no
* blueness yes
* dilfridge no
<ulm> which likely will be in september
<scarabeus> no
* ulm yes
* WilliamH yes as long as it is this month.
<Calchan> yes to defering the vote to when we get enough informaiton to mak
ethe decision [21:52]
<WilliamH> This should not go on forever.
<ulm> I count 4 yes and 3 no
<dilfridge> Calchan: that's as good as saying "never"
<rich0> forever = infinity times two weeks. :)
<ulm> so, vote will be in next meeting
<rich0> agree
<dilfridge> which means the alpha decision is scrapped?
<blueness> k
<ulm> next topic [21:53]
<Calchan> dilfridge: no, no reply to a request for information is information
<ulm> 5. Specification of /var/db/pkg contents
<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2995
<rich0> Calchan: that is a data point we already have then.
<ulm> https://bugs.gentoo.org/show_bug.cgi?id=458866
<ulm> blueness: your topic
<blueness> thanks
<blueness> so this came up because i wrote a utility called revdep-pax
<dilfridge> Calchan: if no arch team member replies to the discussion on the
dev ml, that means it's already dead
<Calchan> rich0: I'd disagree, to me it look slike no reasonable attempt at
contacting users has been made
<Calchan> and that's users we're interested in here, not devs [21:54]
<blueness> i needs a complete linkage map (ie what exes link against what
libraries) of the whole system
<rich0> Calchan: speak for yourself, unless we're talking about users who want
to be devs. :)
<blueness> this information is constructed by portage and saved in
/var/db/pkgs in NEEDED.ELF.2
<rich0> Caring about users won't help them - only fixing keywords.
<blueness> one can re-generate that info on the fly but it is very very long
[21:55]
<blueness> there's lots of other utilities that can make use of NEEDED.ELF.2
info
<Calchan> rich0: what I'm saying is we're speculating on the impact of a
decision when we should actually research it, I'm not siding one way
or the other
<rich0> Calchan: we're off-topic
<Calchan> no
<blueness> and so we should probably expose the contents of /var/db/pkgs to
other utilities that could use package info
<dilfridge> rich0: Calchan: please continue later [21:56]
<blueness> zac's comment says it all ->
https://bugs.gentoo.org/show_bug.cgi?id=458866#c18
<dilfridge> ok
<dilfridge> we have a couple of fundamental questions here
<blueness> so we need a PMS requirement that /dev/db/pkg information be made
available to other usitilites that can use it
<dilfridge> A) we should decide whether (generically) database information of
locally installed packages is within the scope of pms [21:57]
<blueness> the motion would be something like "document and add the contents
of /var/db/pkg specified to the PMS specs for interoperability
between utilities that need portage information"
<rich0> blueness: I'd say that we need to provide NEEDED.ELF.2 info to
packages, not that we need to provide /var/db/pkg info.
<rich0> The latter is one particular implementation of a PM, not a
specification. [21:58]
<blueness> rich0, okay we can start with NEEDED.ELF.2
<blueness> that is the critical body of information
<dilfridge> because Ciaran claims this is not PMS business, and we can say yes
or no
<rich0> Seems to me that what is needed is an API.
<blueness> eg you want to ask a question like "what executables link against
this library" ... that's in NEEDED.ELF.2
<ulm> blueness: I'd rather split it: 1. should we document /var/db/pkg, and 2.
should it be in the scope of PMS
<blueness> in a rolling distro like gentoo, that info is critical [21:59]
<dilfridge> 0. should this be in pms at all?
<blueness> dilfridge, yes
<blueness> all package managers must provide this info for interoperability of
utilities
<blueness> so the question does belong in pms, you might say no, but it does
belong here
<rich0> I think that having a spec that is reasonable is fine - some kind of
API. Call it PMS or not - that is just a title.
<ulm> PMS should really be called "EAPI specification", because that's its
intent
<dilfridge> hehe [22:00]
<dilfridge> let's vote about renaming pms
<ulm> not now ;)
<dilfridge> the name is silly anyway
<blueness> ulm, regarding the split: i'm mostly interested in NEEDED.ELF.2
info [22:01]
<blueness> consider revdep-rebuild ... that takes forever because i
recalculates this mapping on the fly
<blueness> the same can be done in seconds if NEEDED.ELF.2 info is read
<blueness> emerge @preserve-libs uses it
<dilfridge> ulm: but there is no connection between EAPI and database format,
so renaming it eapi-specs does not cover what we want to add now
[22:02]
<blueness> so if we want to write other utilities outside of portage that need
the same info, we need to expose it in all package managers
<ulm> dilfridge: yes, that's exactly the point
<blueness> ulm, i would be happy with an abstraction layer to free up the db
formate
* WilliamH thinks the database format would be a completely separate document
[22:03]
<WilliamH> not pms
* scarabeus dont care about what document to put it to, but it should be
documented and expected by all package managers and thats it
<ulm> so, how about a first vote if we want the VDB documented at all?
<blueness> ulm, the way you phrase it above pulls in too much [22:04]
<ulm> and a second vote if it should be part of PMS or a separate document
(e.g. a GLEP)
<Calchan> ulm: is having the VDB documented in PMS the only possiblity?
<blueness> can i try again?
<Calchan> ah ok, sorry
<rich0> blueness: ++ agree on abstraction layer
<dilfridge> ulm: how about first a vote whether vdb information (independent
of format) should be documented?
<dilfridge> (in pms)
<ulm> dilfridge: or that
<rich0> dilfridge: not so much documented, as made available
<rich0> (in a documented manner)
<dilfridge> yep
<dilfridge> better
<rich0> Ie, direct parsing of PM files isn't the interface
<blueness> motion: all package managers should export NEEDED.ELF.2 information
for interoperability between utilities and portage
<ulm> k [22:05]
<blueness> how does that sound?
<dilfridge> blueness: like skipping ahead :)
<blueness> i'm not that worried about documenting all of vdb [22:06]
<dilfridge> ok other suggestion
<blueness> so i'd like the vote to concentrate on export NEEDED.ELF.2 info
<rich0> Coulda, woulda, shoulda. :) We can certainly suggest intended
direction, but implementation will be up to the PMs to carry out.
[22:07]
<blueness> rich0, exactly
<dilfridge> vote on "Making VDB information (independent of database format
and package manager) available is within the scope of PMS"
<blueness> i'll live with whatever makes the maintainer's life easy
<blueness> dilfridge, no that is not the issue
<blueness> as i said it pulls in too much, NEEDED.ELF.2 is the critical piece
[22:08]
<dilfridge> blueness: I know that, but let's squash possible resistance
against the inclusion into specs first
<blueness> it doesn't squash the resistance
<dilfridge> anyway
<rich0> Are the portage/whatever maintainers willing to implement some kind of
interface? I'm fine with saying that the council encourages this, but
nothing will happen unless somebody is willing to do the work.
<dilfridge> how about we vote on blueness motion?
<blueness> rich0, zac is [22:09]
<blueness> and i'm okay with an intended direction without burdoning people
<rich0> blueness: thanks - then I'm all for encouraging the creation of a
PM-neutral API for providing VDB info available to utilities.
*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 246
seconds
*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
#gentoo-council
<rich0> I think quite a bit of info is already available in APIs for both
portage and paludis - just without any standardization between them,
and I can't speak to NEEDED.ELF.2 in particular. [22:10]
<blueness> rich0, should it be all of VDB or just NEEDED.ELF.2, we can always
revisit other vdb elements
<blueness> rich0, let's stick to my motion first and then see if there are
other vdb elements that need exposure
<rich0> Suggest that we let the PM teams cooperate and expose what they can.
agree to start with that one field. [22:11]
<ulm> how about this: "the council recommends that package managers export
information NEEDED.ELF.2 information for interoperability between
utilities"
<blueness> rich0, sure
<rich0> Would love to see a well-documented PM-neutral API for this stuff.
<ulm> oops
<blueness> ulm, works for me
<ulm> "the council recommends that package managers export the NEEDED.ELF.2
information for interoperability between utilities"
<blueness> rich0, so would i but that's a lot of work!
<ulm> blueness: vote on this?
<blueness> ulm, okay i accept that as a friendly amendment let's vote
* blueness yes [22:12]
* dilfridge yes
<Calchan> can I votre "meh"?
<Calchan> s/votre/vote/
<dilfridge> (but I think it it's too soft a statement)
<ulm> well, it would be easier if there was a draft spec already [22:13]
<rich0> yes
<ulm> like a GLEP
<rich0> ulm: agree that really it needs a spec - this is more about
intent/direction
<dilfridge> ok let's finish the vote
<WilliamH> yes
<rich0> but we're not going to bikeshed a spec on irc here
* ulm yes
* scarabeus yes [22:14]
<scarabeus> rich0: but we could try!
<ulm> Calchan: "meh" is an abstention? ;)
<scarabeus> the fact nobody ever done that should not stop us :D
<rich0> scarabeus: you can try - I have someplace to leave for in 5min :)
* WilliamH doesn't think it is up to us to come up with the spec
<Calchan> ulm: take it as what you want, but meh it is
<ulm> anyway, 6 yes votes
<ulm> so it's accepted [22:15]
<blueness> the intention could be fulfilled by a glep
<blueness> yippy!
<ulm> blueness: anything else on this topic?
<blueness> ulm, no just that i like the idea of a glep here but that's beyond
us
<ulm> otherwise, it's 20:15 UTC [22:16]
<blueness> call it a meeting and continue next time?
<ulm> so I suggest that we proceed to open floor here and move the rest of
topics to another meeting
<scarabeus> ok
<rich0> agree - I have to take off in any case
<dilfridge> yes, open floor now, next week another meeting [22:17]
<ulm> everyone o.k. with next tuesday, same time?
<WilliamH> fine with me
<rich0> wfm
<blueness> works for me
*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264
seconds
<dilfridge> wfm
* blueness must feed my dog! brb
*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
#gentoo-council
*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
"Next meeting: 17 Sep 2013 at 19:00 UTC |
http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
http://www.gentoo.org/proj/en/council/"
<ulm> so, open floor [22:18]
* ulm listens
<ulm> nothing, it seems [22:19]
<ulm> so let's close the meeting here [22:20]
<ulm> thank you everybody
<scarabeus> thank you for chairing
<rich0> ulm: thanks :)
<ulm> ah
<ulm> everyone o.k. with me chairing in one week?
<dilfridge> sure
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2013-09-10 21:00 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-10 20:59 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/council/meeting-logs: 20130910.txt Ulrich Mueller (ulm)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox