Hi all, here is the summary from last week's council meeting. The complete log can be found at http://www.gentoo.org/proj/en/council/
Thanks, Markus
Roll call
---------
(here, proxy [by whom] or slacker?)
amne here
betelgeuse here
dberkholz proxy [musikc]
flameeyes here
lu_zero here
vapier here
jokey here
Agenda
------
GLEP 54: scm package version suffix
http://www.gentoo.org/proj/en/glep/glep-0054.html
GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
http://www.gentoo.org/proj/en/glep/glep-0055.html
Code of Conduct enforcement
http://thread.gmane.org/gmane.linux.gentoo.council/82
http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt
- What needs to happen for us to make a decision?
Last week, we agreed to just add moderators to #gentoo-dev and the
gentoo-dev list. Other places with their own moderation should enforce
the
CoC themselves. We also agreed that moderation must be handed over to
devrel
or userrel after 2 days.
Ferris asked some questions:
1) Do we have an implementation schedule? ;
2) Have we identified some warm bodies for it?;
3) Most devrel requests seem really to relate to CoC
violations. Would
you like us to bounce those to the CoC people, process them
using CoC
rules, or keep doing what we are doing now (generally, close
them with a
note explaining why or mediate them)? (I'm talking about the
"He's
being rude/sarcastic/disrespectful" sorts of things which
really need to
be processed immediately and merit a warning or brief
suspension if
anything.)
Slacker arches
See Caleb's post on -dev and subsequent thread
Calebs post:
http://article.gmane.org/gmane.linux.gentoo.devel/53933
Kumba's comment on mips status:
http://article.gmane.org/gmane.linux.gentoo.devel/54168
Rich0's proposal:
http://article.gmane.org/gmane.linux.gentoo.devel/54103
Document of being an active developer
Araujo raised that he needs some kind of written document of being an
active developer. Argument being that mentioning in CV in his
environment is only accepted if there is some kind of proof.
Our trustee grant deferred it back to council+infra as Foundation only
handles IP, but suggested it could be some kind of generated document.
=======================================================================
GLEP 54 : Postponed to -dev ML
-------
Comment from portage maintainer:
- no statement about compatibility/implementation plans
- more subjective:
- while a distinction between CPV and atom may not be technically
required, I might be useful to have
- (minor) if the version part is optionl there could be some
complications
So is this something we'd like to have?
Other ideas that came up during discussion:
- -scm or _scm ?
- handling as (-|_pre)9999) versions per definition
- implement as dynamic package sets
Related bugs:
- bug #9202 - Better support for CVS Ebuilds...
Pushed back to -dev ML as there are too many unresolved questions at
the moment. peper is given the task to repost it and expand on
usefulness / use cases as well as compatibility issues.
GLEP 55 : Postponed to -dev ML
-------
- Agreement on eapi subdirectories are not feasible
Ideas during discussion:
- moving from EAPI= to eapi function and using repository bashrc for
compatibility
Pushed back to -dev ML as there are too many unresolved questions at
the moment.
Slacker arches
--------------
vapier will work on rich0's suggestion and repost it for discussion on
-dev ML
Code of Conduct enforcement
---------------------------
Council members agreed on the direction, dberkholz will provide
additional details on -council ML
Document of being an active developer
-------------------------------------
Suggested options:
- Log in to dev.g.o and automatically generate there signed by
infra-maintained key, put userinfo.xml website in the doc as
reference.
dberkholz and araujo will look into a scribus based template.
devrel will have to generate a signing key for these purposes.
signature.asc
Description: OpenPGP digital signature
