public inbox for gentoo-dev-announce@lists.gentoo.org
 help / color / mirror / Atom feed
From: Markus Ullmann <jokey@gentoo.org>
To: gentoo-council@lists.gentoo.org
Cc: gentoo-dev@lists.gentoo.org, gentoo-dev-announce@lists.gentoo.org
Subject: [gentoo-dev-announce] Council meeting summary 20080110
Date: Mon, 14 Jan 2008 13:34:08 +0100	[thread overview]
Message-ID: <478B56C0.2070003@gentoo.org> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 158 bytes --]

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

[-- Attachment #1.2: 20080110-summary.txt --]
[-- Type: text/plain, Size: 4122 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

                 reply	other threads:[~2008-01-14 12:38 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478B56C0.2070003@gentoo.org \
    --to=jokey@gentoo.org \
    --cc=gentoo-council@lists.gentoo.org \
    --cc=gentoo-dev-announce@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox