[gentoo-dev] Council meeting summary for 8 May 2008

[gentoo-dev] Council meeting summary for 8 May 2008

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

Hi all,

Here is the summary from today's council meeting. The complete log will
show up at http://www.gentoo.org/proj/en/council/ shortly.

Thanks,
Donnie

[-- Attachment #2: 20080508-summary.txt --]
[-- Type: text/plain, Size: 7116 bytes --]

Quick summary
=============

Active-developer document: We reviewed it and made some suggestions for 
improving both the document and the online developer list (adding 
dates).

ChangeLog entries: Always required. If you aren't making them now, fix 
your script to call echangelog.

Ignored arch-team bugs: What's the workflow for undermanned arch teams? 
Can we improve it?

8-digit versions: Ask package maintainers with extremely long PVs 
whether they were needed and test the impact of extending 
versionator.eclass. Make decision once this data is available.

Enforced retirement: After 2.5 hours on the previous topics, people had 
to go to sleep and jokey's computer broke. Instead of waiting till the 
next regular meeting, because of its urgency, we scheduled a special 
session next week at the same time. The appeals will *not* be decided 
then -- it's about figuring out the validity and the process.

New meeting process: 105 minutes were closed and 57 were open. It might 
save some time if we always moderated, but it won't cut it in half. 
Should we keep doing this, or modify it a little to have a moderated 
#-council and open backchannel?


Roll call
=========

(here, proxy [by whom] or slacker?)

amne        slacker [30 minutes late]
betelgeuse  here
dberkholz   here
flameeyes   here
lu_zero	    here
vapier      proxy [solar]
jokey       here

We gave amne 15 minutes to show up before getting a slacker mark.


New process
===========

The last few meetings have dragged out for hours unnecessarily. This 
time, we tried moderating the channel during discussion of each topic, 
then temporarily opening the floor for that topic before a vote so 
anyone could contribute. Here's the time breakdown:

	2000-2030: closed, 30 min
	2030-2046: open, 16 min
	2046-2056: closed, 10 min
	2056-2114: open, 18 min
	2114-2146: closed, 32 min
	2146-2209: open, 23 min
	2209-2242: closed, 33 min
	2242-    : open floor

Total before open floor: 105 minutes closed, 57 minutes open.

Optimistically, we could have saved an hour if the channel was moderated 
throughout the meeting. That's unlikely to be the case in reality, 
because we'd be redirecting people's comments from queries into the 
channel.

Should we keep it moderated until the final open floor? Should we have 
an open "backchannel"?


Updates to last month's topics
==============================

	http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt

	Document of being an active developer
	-------------------------------------
	Last month:
		No updates
	Updates:
		araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. 
		He'd like to ask for approval of this design and discuss the 
		script, in particular its infrastructure requirements.

		Suggestions on certificate content:
			-Add title to the top: "Developer Certification"
			-Add devrel contact info (general devrel email address)
			-Add link to devrel userinfo page
			-Add start and end dates to devrel retired developers page
			-Add a sentence saying e.g. "This certifies that XXX was a 
			 Gentoo developer from START_DATE to TODAY_DATE." The point 
			 is to avoid implying that the developer is certified 
			 forever, or will be a developer in the future.

		The information should be gotten from LDAP, for example using 
		python-ldap. Could base this script on devrel's slacker script.

		It's unsure how signatures are going to happen, but one option 
		is to keep a GPG-encrypted image of a signature and decrypt it 
		on-demand for certificate creation. This should be discussed 
		with the person doing the signing.


	Slacker arches
	--------------
	4 months ago:
		vapier will work on rich0's suggestion and repost it for 
		discussion on -dev ML
	2 months ago:
		vapier said he was going to work on it that weekend.
	Last month:
		No updates
	Updates:


New topics
==========

	When are ChangeLog entries required?
	------------------------------------
	This question mainly relates to arch stabilizations.

	The consensus was that ChangeLog entries even for arch 
	stabilizations provide valuable information that is unique without 
	network access and more accessible than CVS logs even with network 
	access.

	Some people were curious what proportion of space ChangeLogs take in 
	the tree, but most people didn't think that was relevant.

	welp suggested making a changelog message part of repoman commit.

	It would be helpful for the QA team to help with checking for and 
	enforcing ChangeLog messages. If that doesn't help matters, the 
	council may have to take action.


	Can the council help fewer bugs get ignored by arm/sh/s390 teams?
	-----------------------------------------------------------------
	The work happens, but Mart says it's not communicated to anyone and 
	has no relationship to whether bugs are open.

	We need to understand the workflow of undermanned arch teams and see 
	whether there's anything we can help improve.

	Possibly improving recuitment -- add a good, motivating 
	staffing-needs entry.


	PMS: Are versions allowed to have more than 8 digits?
	-----------------------------------------------------
	http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
	https://bugs.gentoo.org/show_bug.cgi?id=188449

	What do various PMs/tools support? Portage, Pkgcore, Paludis all 
	handle >8. portage-utils does not but could be fixed to use longs 
	instead of ints, with some loss of performance (magnitude unclear).

	versionator.eclass also needs fixing for >8 digits.

	Apparently [ ]-style tests break with large numbers, but [[ ]] 
	works. Have to be careful which tests are getting used anywhere 
	large versions are compared.

	The council generally favored allowing versions to have <=18 digits. 
	This allows them to fit into 64 bits (18 signed digits or 19 
	unsigned) and gives them an upper bound, which some implementations 
	of version parsing could find useful.

	We voted to do more research and testing, specifically to ask the 
	package maintainers with extremely long PVs whether they were needed 
	and to test the impact of extending versionator.eclass. The involved 
	packages:

		sys-process/fuser-bsd
		sys-apps/net-tools
		sys-apps/gradm
		net-im/ntame
		media-video/captury
		media-libs/libcaptury
		media-libs/capseo
		sys-block/btrace
		www-apache/mod_depends
		net-wireless/rt2500
		sys-fs/unionfs


	Enforced retirement
	-------------------

	The meeting had already gone 2.5 hours and we were short multiple 
	council members because of the late hour in their timezone, or 
	broken hardware in the case of jokey. Because of the urgency of 
	getting this resolved, we decided it couldn't wait for next month's 
	meeting and scheduled a special session for next week at the same 
	time.


	Open floor
	----------

	Some people thought that we were going to make a final decision on 
	the above appeals today, because the agenda was insufficiently clear 
	on that. That was not the case. What we intended to do was explain 
	why we can take the appeal and then figure out the process for it
	because we haven't done any appeals before.

[gentoo-dev] Lenght of version components [was: Council meeting summary for 8 May 2008]

[Ulrich Mueller]

>>>>> On Thu, 8 May 2008, Donnie Berkholz wrote:

>	PMS: Are versions allowed to have more than 8 digits?
>	-----------------------------------------------------

> 	specifically to ask the package maintainers with extremely
>	long PVs whether they were needed and to test the impact of
>	extending versionator.eclass. The involved packages:

>		sys-process/fuser-bsd
>		sys-apps/net-tools
>		sys-apps/gradm
>		net-im/ntame
>		media-video/captury
>		media-libs/libcaptury
>		media-libs/capseo
>		sys-block/btrace
>		www-apache/mod_depends
>		net-wireless/rt2500
>		sys-fs/unionfs

You may add app-emacs/limit and app-emacs/mu-cite to this list.
Currently we limit ourselves to 8 digits for them, but both upstream
tarballs are named in the infamous YYYYMMDDHHMM format.

Ulrich
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Council meeting summary for 8 May 2008

[Duncan]

Donnie Berkholz <dberkholz@gentoo.org> posted 20080508233328.GA8896@comet,
excerpted below, on  Thu, 08 May 2008 16:33:28 -0700:

> Here is the summary from today's council meeting. The complete log will
> show up at http://www.gentoo.org/proj/en/council/ shortly.

FWIW, the log entry at the URL above is still yielding a 404.  <poke>  
Yes, I know "shortly" is relative, but in the absolute, it /has/ been a 
day and a half.  =8^/

Meanwhile, I'd like to take the opportunity while I have it to thank the 
council members.  Multiple hour meetings each month, you guys are 
certainly taking your responsibilities seriously, and there's another one 
this month due to unfinished business after the 2 and a half that you 
met.  Apart from the time, some of the decisions are anything but easy.  
It's not something everyone's cut out for, definitely.  I expect I'm 
talking for many when I say thanks, and that I'm glad someone's willing 
to make the sacrifice and take the emotional and stress toll it extracts 
to step up and make those decisions, even if I don't personally agree 
with the decisions made at times.

Actually, that's why I like the logs.  It surprises me how often after 
reading the logs I find I agree where I didn't before, and where I don't, 
I at least understand why...  Thus my frustration at not being able to 
peruse the latest one as yet. <yeah, I guess that's another poke> =8^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Council meeting summary for 8 May 2008

[Donnie Berkholz]

On 10:54 Sat 10 May     , Duncan wrote:
> Donnie Berkholz <dberkholz@gentoo.org> posted 20080508233328.GA8896@comet,
> excerpted below, on  Thu, 08 May 2008 16:33:28 -0700:
> 
> > Here is the summary from today's council meeting. The complete log will
> > show up at http://www.gentoo.org/proj/en/council/ shortly.
> 
> FWIW, the log entry at the URL above is still yielding a 404.  <poke>  
> Yes, I know "shortly" is relative, but in the absolute, it /has/ been a 
> day and a half.  =8^/

Thanks for the report.

donnie@comet $ cci "Rename log to correct name (.txt instead of .log). Reported by Duncan."

Gentoo XML-QA-checker called.  In case of troubles, contact neysx@gentoo.org

/var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080508.log,v  <--  20080508.log
new revision: delete; previous revision: 1.1
/var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080508.txt,v  <--  20080508.txt
initial revision: 1.1
Mailing the commit message...


Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Council meeting summary for 8 May 2008

[Duncan]

Donnie Berkholz <dberkholz@gentoo.org> posted
20080510194238.GA3226@comet.had1.or.comcast.net, excerpted below, on  Sat,
10 May 2008 12:42:38 -0700:

> donnie@comet $ cci "Rename log to correct name (.txt instead of .log).
> Reported by Duncan."

Thanks. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Special meeting [WAS: Council meeting summary for 8 May 2008]

[Donnie Berkholz]

On 16:33 Thu 08 May     , Donnie Berkholz wrote:
> Enforced retirement: After 2.5 hours on the previous topics, people had 
> to go to sleep and jokey's computer broke. Instead of waiting till the 
> next regular meeting, because of its urgency, we scheduled a special 
> session next week at the same time. The appeals will *not* be decided 
> then -- it's about figuring out the validity and the process.

Only 2 council members showed up: amne and me. There's some discussion 
over whether GLEP 39 requires that we reelect a new council because of 
this, and what to do now. It's happening over on the gentoo-project 
mailing list. Subscribe there to join in by sending an email to 
gentoo-project+subscribe@gentoo.org.

Feel free to catch up on the discussion so far, which started at 
http://archives.gentoo.org/gentoo-project/msg_0b435377d3b7a23a0729f23a17701c1f.xml

Please head over to the gentoo-project list if you have something to 
say, instead of responding to this email. This kind of topic is exactly 
why we split it off from -dev.

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list