diff options
Diffstat (limited to 'decisions/summary-20080508.tex')
| -rw-r--r-- | decisions/summary-20080508.tex | 211 |
1 files changed, 94 insertions, 117 deletions
diff --git a/decisions/summary-20080508.tex b/decisions/summary-20080508.tex index cee6619..72aac79 100644 --- a/decisions/summary-20080508.tex +++ b/decisions/summary-20080508.tex @@ -1,31 +1,34 @@ \summary{2008}{5}{8} +Agenda call: \agoref{gentoo-dev}{bd9a171d7303bf1299a4c307f7b6ddcf} + \agendaitem{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: - -\begin{verbatim} - 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 -\end{verbatim} +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: +\begin{center} + \begin{tabular}{c|c|c|c} + start & end & mode & duration \\ \hline + 20:00 & 20:30 & closed & 30min \\ + 20:30 & 20:46 & open & 16min \\ + 20:46 & 20:56 & closed & 10min \\ + 20:56 & 21:14 & open & 18min \\ + 21:14 & 21:46 & closed & 32min \\ + 21:46 & 22:09 & open & 23min \\ + 22:09 & 22:42 & closed & 33min \\ + 22:42 & & \multicolumn{2}{c}{open floor} + \end{tabular} +\end{center} 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. +throughout the meeting. That's unlikely to be the case in reality, because we +would 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"? @@ -34,48 +37,34 @@ an open "backchannel"? \agendaitem{Document of being an active developer} \index{developer certificate} +\dev{araujo} made http://dev.gentoo.org/$\sim$araujo/gcert1.pdf in Scribus. +He'd like to ask for approval of this design and discuss the script, in +particular its infrastructure requirements. -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: +Suggestions on the certificate content were: \begin{itemize} -\item Add title to the top: "Developer Certification" +\item Add a title to the top: "Developer Certification" \item Add devrel contact info (general devrel email address) -\item Add link to devrel userinfo page -\item Add start and end dates to devrel retired developers -page -\item 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. +\item Add a link to the devrel userinfo web page +\item Add start and end dates on the devrel retired developers web page +\item 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 thatthe developer is certified forever, or will +be a developer in the future. This information should be gotten from LDAP, for +example using python-ldap. One could base this script on devrel's slacker +script. \end{itemize} -\agendaitem{Slacker arches} -\index{arches!slacking} - -4 months ago: vapier will work on rich0's suggestion and repost it for -discussion on -dev ML +It is 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. -2 months ago: vapier said he was going to work on it that weekend. -Last month: No updates +\agendaitem{Slacker arches} +\index{arches!slacking} -Updates: --- +There were no updates on this topic. \agendaitem{When are ChangeLog entries required?} @@ -83,35 +72,29 @@ Updates: --- 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. +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. So, ChangeLog entries are always +required. If you aren't making them now, fix your script to call echangelog. -So, Always required. If you aren't making them now, fix -your script to call echangelog. +Some people were curious what proportion of space ChangeLogs take in the tree, +but most people didn't think that was relevant. -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. +\dev{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. \agendaitem{Can the council help fewer bugs get ignored by arm/sh/s390 teams?} \index{arch!arm}\index{arch!sh}\index{arch!s390} -The work happens, but Mart says it's not communicated to anyone and - has no relationship to whether bugs are open. +The work happens, but \dev{leio} says it is 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. -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. +Possibly improving recuitment -- we should add a good, motivating +staffing-needs entry. \agendaitem{PMS: Are versions allowed to have more than 8 digits?} @@ -124,57 +107,51 @@ References: \bug{188449} \end{itemize} -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: - -\begin{verbatim} - 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 -\end{verbatim} +What do various package managers / tools support? \package{sys-apps/portage}, +\package{sys-apps/pkgcore}, and \package{sys-apps/paludis} all handle more +than 8 digits. \package{app-portage/portage-utils} does not but could be fixed +to use longs instead of ints, with some loss of performance (magnitude unclear). +versionator.eclass \index{eclass!versionator} also needs fixing for >8 digits. +Apparently [ ]-style tests break with large numbers, but [[ ]] works. We 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 are: + +\begin{itemize} +\item \package{sys-process/fuser-bsd} +\item \package{sys-apps/net-tools} +\item \package{sys-apps/gradm} +\item \package{net-im/ntame} +\item \package{media-video/captury} +\item \package{media-libs/libcaptury} +\item \package{media-libs/capseo} +\item \package{sys-block/btrace} +\item \package{www-apache/mod_depends} +\item \package{net-wireless/rt2500} +\item \package{sys-fs/unionfs} +\end{itemize} \agendaitem{Enforced retirement} \index{retirement!enforced}\index{project!devrel} -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. +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 \dev{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. \agendaitem{Open floor} \index{retirement!appeal} - 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. +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. |