summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'decisions/summary-20071213.tex')
-rw-r--r--decisions/summary-20071213.tex115
1 files changed, 53 insertions, 62 deletions
diff --git a/decisions/summary-20071213.tex b/decisions/summary-20071213.tex
index 9853688..6472b32 100644
--- a/decisions/summary-20071213.tex
+++ b/decisions/summary-20071213.tex
@@ -1,98 +1,89 @@
\summary{2007}{12}{13}
+Agenda call: \agoref{gentoo-dev}{ba2cdfa0060c1a2b7583e19185564855}
-\agendaitem{New USE documentation}
-\index{USE}\index{global changes}
-Reference: http://archives.gentoo.org/gentoo-dev/msg_149120.xml (dead link)
+\agendaitem{New USE documentation}
+\index{USE}\index{global changes}\index{metadata.xml}
-Considering the precedent set by how this was implemented,
-what should we do? Should we leave it or revert it? Should we require a GLEP?
+Reference: http://archives.gentoo.org/gentoo-dev/msg_149120.xml (dead
+link)\footnote{This is likely the
+\agoref{gentoo-dev}{dcc6227eceaa2a4999e6a2a256dcddbc}.}
-Other options:
-\begin{itemize}
-\item Discuss improvements on -dev, make changes, document them.
- In other words, normal development process
-\item Leave as is
-\item Require future global changes to be sent to -dev in advance,
- or they will be reverted.
-\end{itemize}
+Considering the precedent set by how the documentation of use flags in
+metadata.xml was implemented, what should we do? Should we leave it in place or
+revert it? Should we require a GLEP?
-Result of the discussion:
+The result of the discussion was:
\begin{enumerate}
- \item
- We're leaving it, and considering further changes
- \item
- It should have been posted to -dev before committing for discussion
+\item
+We're leaving this improvement in place, and are considering further changes.
+\item
+It should have been posted to the gentoo-dev mailing list before committing
+for discussion.
\end{enumerate}
-General process for global changes:
+The general process for global changes shall be:\footnote{This algorithm isn't
+really spelled out that clearly in the log. It's kinda common sense though.}
\begin{itemize}
- \item
- 1. Post to -dev for discussion
- \item
- 2a. Consensus for implementing your idea as-is. No GLEP, no council.
+\item 1. Post to gentoo-dev for discussion
+\item 2a. Consensus for implementing your idea as-is. No GLEP, no council.
BREAK.
- \item
- 2b. Consensus for a GLEP for your idea, maybe disagreement over the idea.
- Write GLEP. Discuss on -dev. Submit GLEP to council.
- \item
- 2c. Disagreement, but some support. No consensus for a GLEP. Respond to the
- council agenda mail with a post containing a summary of your idea as
- well as patches for code and documentation.
- \item
- 2d. No support. Refine your idea, or think of a new one. GOTO 1.
- \item
- 3. Council votes on the idea.
+\item 2b. Consensus for a GLEP for your idea, maybe disagreement over the idea.
+Write a GLEP. Discuss it on gentoo-dev. Submit the GLEP to the council.
+\item 2c. Disagreement, but some support. No consensus for a GLEP. Respond to
+the council agenda mail with a post containing a summary of your idea as well as
+patches for code and documentation.
+\item 2d. No support. Refine your idea, or think of a new one. GOTO 1.
+\item 3. The Council votes on the idea.
\end{itemize}
-Any future global changes that aren't discussed on -dev in advance may
-be reverted by the council if at least two council members vote to revert
-the changes. Those changes must be discussed on -dev and approved by the
-council before recommitting. If they're recommitted without council
-approval, the developer in question gets kicked out.
-
+Any future global changes that aren't discussed on -dev in advance may be
+reverted by the council if at least two council members vote to revert the
+changes. Those changes must be discussed on -dev and approved by the council
+before recommitting. If they are recommitted without council approval, the
+developer in question gets kicked out.
\agendaitem{Code of Conduct enforcement}
\index{Code of Conduct}\index{mailing list!gentoo-dev}
-\index{irc!channel!\#gentoo-dev}
+\index{irc!channel!\#gentoo-dev}\index{project!userrel}\index{project!devrel}
References:
\begin{itemize}
\item
- http://thread.gmane.org/gmane.linux.gentoo.council/82 (broken link)
+ \agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979}
\item
- \url{http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt}
+ November 2007 council meeting summary
\end{itemize}
-
-Christy Fullam (musikc) made some valuable suggestions:
-
+\dev{musikc} made some valuable suggestions:
\begin{itemize}
-\item The proposal should be restricted to only apply to \#gentoo-dev and the
- gentoo-dev list. Most other locations already have moderators of some
- sort, and the council can work with them directly if there are CoC
- problems. This idea went over really well.
-\item Moderation should be capped at 2 days, and then will be handed off to
- devrel/userrel. No council approval involved.
+\item
+The proposal should be restricted to only apply to \#gentoo-dev and the
+gentoo-dev list. Most other locations already have moderators of some sort, and
+the council can work with them directly if there are CoC problems. This idea
+went over really well.
+\item
+Moderation should be capped at 2 days, and then will be handed off to devrel /
+userrel. No council approval involved.
\end{itemize}
-Mike Doty (kingtaco) suggested that we look for a way to prevent the
-snowball effect on IRC: what if a modded person is voiced/opped by an
-unmodded person, and a chain of this goes?
+\dev{kingtaco} suggested that we look for a way to prevent the snowball effect
+on IRC: what if a modded person is voiced/opped by an unmodded person, and a
+chain of this goes?
-Donnie Berkholz (dberkholz) will incorporate these changes into the
-proposal and post an update to the -council list.
+\dev{dberkholz} will incorporate these changes into the proposal and post an
+update to the -council list.
\agendaitem{Open floor}
\index{PMS}\index{PMS!authoritative repo}
-Wulf Krueger (philantrop) asked which PMS repo was authoritative. The
+Wulf Kr├╝ger (philantrop) asked which PMS repo was authoritative. The
external one had been getting changes, and the "official" gentoo.org one
-had not. Mike Doty reported that they're working on allowing non-Gentoo
-developers to contribute to the repository, which should resolve the
-technical problems. Wulf responded that some people didn't want to
-commit to a Gentoo-hosted repository.
+had not. \dev{kingtaco} reported that they're working on allowing non-Gentoo
+developers to contribute to the repository, which should resolve the technical
+problems. Wulf responded that some people didn't want to commit to a
+Gentoo-hosted repository. Some discussion ensued.