
\chapter{Code of Conduct}


\section{``Code of Conduct'', Mar. 2007}
Source: 
\url{
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/ 
coc.xml?revision=1.2&view=markup}

\vspace*{1cm}

\begin{quote}
This document describes Gentoo's Code of Conduct for public communication fora,
as well as the action taken should it be broken.
\end{quote}

\subsection{Draft disclaimer}
This document is an ongoing work, subject to growth and revision as Gentoo 
grows and changes.

\subsection{Scope}

\paragraph{Joining and participation agreement}

Gentoo prides itself on being a community driven distribution that acts with 
the  best interest of the community at heart. Rules and regulations that keep us 
all  moving in a forward direction are a reality for a community of this size. 

This document describes Gentoo's Code of Conduct for public communication 
mediums,  who shall enforce said Code of Conduct, the action taken should the 
Code of  Conduct be broken, as well as the method for appeals. Questions about 
this document and its contents can be directed to the council at 
council@gentoo.org.

By joining and/or participating in the Gentoo community, you are stating that
you accept and agree to adhere to the rules listed below, even if you do not
explicitly state so.

\subsection{Behaviour and Consequences}

\paragraph{Acceptable behaviour}

Things that should be seen:
\begin{itemize}
 \item 
{\bf Be courteous.} Though respect is earned, it must start somewhere.      
    Respect someones right for their own opinion and acknowledge that they do    
   deserve a measure of politeness in your response.
\item
{\bf Give accurate information in the spirit of being helpful.}
\item
{\bf Respectfully disagree with or challenge other members.} The
    operative word here is respectfully.
\item
{\bf Using the correct forum for your post.} Bug reports and idle 
chatter
    do not belong on the gentoo-dev mailing list; discussion about a
    wide-ranging change to the tree probably does not belong on Bugzilla.
    Different fora will also have different standards of behaviour -- a joke
    that is perfectly acceptable on IRC will be taken differently when made on a
    mailing list.
\item
{\bf Admit the possibility of fault and respect different point of views.}
    Noone is perfect -- you will get things wrong occasionally. Don't be afraid
    to admit this. Similarly, while something may seem perfectly obvious to you,
    others may see it differently. 
\item
{\bf If you screw up, take responsibility for your actions.}
\end{itemize}

\paragraph{Unacceptable behaviour}

Gentoo developers have come together with a common purpose, to further the  
project. Conflicts will undoubtedly arise, and though you are encouraged to work 
through issues on your own, assistance is available as requested and as needed.

Deciding to suspend or ban someone isn't a decision to be taken lightly, but
sometimes it has to happen. Below is a list of things that could result in  
disciplinary action.

\begin{itemize}
 \item 
 {\bf Flaming and trolling.} What is trolling? You are deemed to be trolling 
      if you make comments intended to provoke an angry response from others. 
What      is flaming? Flaming is the act of sending or posting messages that are 
           deliberately hostile and insulting.
\item 
{\bf Posting/participating only to incite drama or negativity}
rather than
    to tactfully share information.
\item
{\bf Being judgmental, mean-spirited or insulting.} It is possible to
    respectfully challenge someone in a way that empowers without being          
     judgemental.
\item
{\bf Constantly purveying misinformation} despite repeated warnings.
\end{itemize}

\paragraph{Consequences}

Disciplinary action will be up to the descretion of the proctors. What is a  
proctor? A proctor is an official charged with the duty of maintaining good  
order. If discplinary measures are taken and the affected person wishes to  
appeal, appeals should be addressed to the Gentoo Council via email at 
council@gentoo.org. To prevent conflicts of interest, Council members may not 
perform the duties of a proctor.

If you perceive a breach of the Code of Conduct guidelines, let the proctors  
know. Though they will also be watching many of the public mediums for any  
problems, they can not be expected to catch everything.

The proctors will attempt to resolve the problem by talking to involved 
parties,  potentially issuing warnings if appropriate. If the problem repeats 
itself,  there are various options open to the proctors, including temporary or 
permanent  suspension of a person's ability to post to mailing lists, removal of 
Bugzilla  access, or in more severe cases suspension of developer privileges. 
Any action  of this sort will require consensus from at least three proctors.

\subsection{Summary}

If you are unsure whether or not something is OK to post/comment/etc,
assume it isn't, and reconsider whether you need to post it. Remember that posts
made to mailing lists are archived for perpetuity, and read by far more people
than will be actively involved in any one thread. A comment made in anger can
have far-reaching consequences that you might not have thought about at the 
time.

Remember, the moment you participate in a public discussion on Gentoo medium,
you have made yourself a representative of the Gentoo community. We hope that
you will not take this responsibility lightly, and will prove to be a positive
force in it.



\section{``CoC enforcement proposal'', by Donnie Berkholz, Nov. 2007}
\label{2007-11-dberkholz-coc}
Source: \agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979}
\index{Code of Conduct!enforcement}\index{project!proctors}
\index{developer!dberkholz}
\vspace*{1cm}


Consider this entire document a draft open to council discussion. I 
appreciate the people on the gentoo-project list who contributed to the 
discussion.

\paragraph{The problem}

My basic philosophy is: compliment in public, criticize in private. One 
of the problems with the proctors last time around was that their 
actions became too public, embarrassing the parties involved. Another 
problem with the proctors was that real action was not taken soon 
enough, and too long was spent talking. Real action in this context 
means that someone is temporarily blocked from posting to the relevant 
forum (mailing lists, IRC, forums), rather than sitting around talking. 
A third problem with the proctors was the difference in interpretation 
of the CoC within the group and with the council. It's particularly 
important to discriminate technical discussions from personal attacks 
and misconduct.

\paragraph{The conceptual solution}

A primary focus of CoC enforcement is deterrence from continued 
violation, so permanent action is unnecessary. Thus, what seems 
necessary is a way to take rapid, private, temporary action.

By making initial actions temporary (e.g., 6-12 hours in most cases), 
they can be taken rapidly with little negative consequence in the case 
of a mistake. The goal is to provide developers with a cooling-off 
period but allow them to rejoin the discussion with little loss. Since 
the actions are always private, the only reason other developers will 
learn about them is that either the affected developer or whoever took 
the action (the actor) leaked it. Leaks by the actor will be taken 
seriously as a CoC violation in their own right.

The basic idea behind the time frame is that the longer the action, the 
fewer people who can choose to take it. Perhaps only one or two people 
besides the council could decide to take any action longer than 12 
hours, which would severely impede a developer's ability to participate 
in a discussion.

Whoever's taking action also needs to have a similar interpretation of 
the CoC as the council, which is the problem that came up with the 
proctors. To ensure this, the council will need some kind of role in 
deciding who could take action. But we don't want to fall into the trap 
of writing down every little rule and every possible infraction; that 
just makes it easy to find loopholes.

\paragraph{The implementation}

One way to enable Gentoo to enforce the CoC with these ideas in mind is 
to create a highly selective team with only short-term abilities and a 
strong lead to ensure the team's actions fit the council's CoC 
interpretation. Adhering to the principles mentioned above is what 
discriminates between this group and the former proctors.

All this team's actions must be approved by the lead within a short time 
period or must be reverted. It's expected that many actions will range 
from 6-12 hours, so 12 hours seems like a reasonable time to require 
lead approval. Whenever the lead is unavailable, approval falls to the 
council. (Remember, two council members together can make decisions.)

The lead of this team must gain council approval for any action lasting 
3 or more days. To ensure that this process remains temporary, in no 
case can any action last longer than 7 days. These actions must also be 
forwarded on to devrel or userrel, depending on who's involved, and they 
will consider longer-term suspension or termination.

There is no conflict of interest between the council and this team's 
members, because the council is considered to have the best interests of 
Gentoo in mind. Developers can be members of both groups. The council 
must approve all members of this team, and it must reassess them 
annually to ensure they still interpret the CoC in the same way. 
Furthermore, the team's lead will be appointed by the council to further 
ensure a cohesive CoC interpretation.

It is expected that membership on this team will be highly selective and 
not all who wish to join will make the cut. The team will be limited to 
3 people for a probationary period so we don't get dumped in the deep 
end right away, and it will never have more than 5 people. Once 
appointed by the council, the team lead will choose applicants for the 
rest of the team to forward on for council approval.



\chapter{Stabilization}


\chapter{PMS, EAPIs, GLEPs, and similar}

\section{Live Ebuild as template proposal}
\label{2000-02-luzero-live}
Source: \url{http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst}, file is dated 
11 March 2009
\index{GLEP!54}
\index{developer!lu_zero}
\vspace*{1cm}

{\small \begin{verbatim}
:GLEP: XXX
:Title: Live Ebuild as Template
:Version: $Revision: $
:Last-Modified: $Date: $
:Author: Luca Barbato <lu_zero@gentoo.org>,
:Status: Draft
:Type: Standards Track
:Content-Type: text/x-rst
:Created: 12 Jun 2008

Credits
=======

Thanks to Gianni Ceccarelli for the early feedback and markup help, Zack Medico
for pointing some issues and suggesting solutions (and pushing me to complete
it), Thomas Anderson for the help.

Abstract
========

This glep provides a mechanism to allow traceable installation from
live source repositories (e.g. ``svn``, ``bzr``, ``git``) using
ebuilds.

Motivation
==========

Sometimes upstream may not provide releases often enough to satisfy certain
needs, either because there isn't a release schedule or the scheduled release
is too far to address certain issues or provide certain features in a timely
manner.

In order to provide such fixes or features the main solutions had been either
backport them in form of patches or provide snapshots from the development
tree if the number of changes is too high.

Sometimes is needed to update the snapshots often enough that would be simpler
directly using the live sources.

Current situation (``-9999 ebuilds``)
-----------------------------------

Right now the are some eclasses that on unpack phase fetch the sources from 
the upstream server, prepare them and then the usual ebuild process follows.

In order to make an ebuild using those eclasses be valued as the highest
possible, the simplest solution had been give it a version "high enough",
commonly ``9999``.
That makes simple track a single live branch per package.

The same reasoning could be done with any version component in order to try
to track different branches:
- to track what will be the next ``1.5`` version, a version like ``1.4.9999``
  or 1.5_pre9999 could be used.
- to track all the improvements happening on the 1.5 branch somebody could use
  a version like 1.5_p9999 or 1.5.9999 again.

9999 is just an arbitrary big number.

Shortcomings
------------

There are many obvious and non obvious shortcomings in this situations:
- you have to hand produce "high enough" version values and be sure they do
  not clash (e.g. 2.3_pre9999 live ebuild being shadowed by 2.3_pre20050201
  snapshot).
- you cannot track what did you install since you don't have a precise
  information about it, emerge logs will just provide you the build date.
- you cannot do exact reemerges and that may break revdep-rebuild
- the package manager isn't aware of the "liveness" condition.
- in order to refresh/update the installed package automatically you need
  either to rely on script or on sets hand produced or heuristically defined
  (e.g "all ebuilds that inherit eclass svn go in svn set").
- since you fetch on unpack phase you cannot use emerge --fetch consistently.


This document aims to address the above shortcomings.

Use Cases
=========

Those are the following use case considered::

  * track the tip of the main branch
  * track specific version branches
  * track multiple topic branches
  * 


Backwards Compatibility
=======================

This is an expansion to [GLEP54]_.


Live Template
=============

Structure
---------

Any numeric version component could be substituted with the keyword ``live``.
The keyword must be present at most one time::

  ``cat/pkg-live``
  ``cat/pkg-1.live``
  ``cat/pkg-1.2.live``
  ``cat/pkg-1.2.3_prelive``
  ``cat/pkg-1.2.2_plive``

It's advised not to chain suffixes beside ``-r`` after the live keyword
even if is possible (e.g. ``cat/pkg-1.2.live_pre``)

Resolution and Version Comparison
---------------------------------

At resolution the live keyword is substituted with a timestamp in the form of
iso date (``YYYYMMDDhhmm``) and the version comparison follows the normal
version comparison rules.

Generation
----------

[Details about generating a normal ebuild out of template]

Informations shown on pretend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The live template is always resolved to a snapshot value, portage should mark
both template and rendered templates to notify the user.

live template yet to be rendered could get a specific letter "L" in order to
mark it or it could be shown as is.
Rendered templates will shown with the version with ``live`` replaced with the
iso date and the informations about the branch and revision name will be shown 
on verbose in a fashion similar to what is used for useflags.

Additional Phase
~~~~~~~~~~~~~~~~

[Reference about ``src_fetch`` bugXXXX_]

Revision information embedding
------------------------------

In order to properly allow re-emerge, it's required that additional informations 
will be stored and exposed to portage.

Eclass Support
~~~~~~~~~~~~~~

Live templates will use a standardized form of eclass interface to expose the
revision information to the ebuild and the package manager.

Every ebuild will expose the following variables:

``LIVE_URI``
``LIVE_BRANCH``
``LIVE_REVISION``


References
==========

.. [GLEP54] scm package version suffix
    (http://glep.gentoo.org/glep-0054.html)
.. [bugXXXX] src_fetch rfe (http://bugs.gentoo.org/XXXX)



Copyright
=========

This document has been placed in the public domain.

\end{verbatim}}


\section{REQUIRED_USE USE state constraints}
\label{2010-05-ferringb-requireduse}

Source: 
\url{
https://web.archive.org/web/20100812050720/http://dev.gentoo.org/~ferringb/requi 
red-use.html}
\index{developer!ferringb}

\vspace*{1cm}

{\small
\begin{verbatim}
GLEP:	61
Title:	REQUIRED_USE USE state constraints
Version:	1.1
Author:	Brian Harring <ferringb at gentoo.org>
Last-Modified:	2010/04/10 17:03:27
Status:	Draft
Type:	Standards Track
Content-Type:	text/x-rst
Created:	10-April-2010
Post-History:	10-April-2010

Abstract
========

This GLEP proposes the addition of a new metadata key to specify what USE flag 
combinations are disallowed for a specific pkg.

Motivation
==========

It's a semi common occurence that an ebuild may need to state that they disallow 
USE flags in specific combinations- either mysql or sqlite for example, but not 
both.

Existing solutions rely on checking the the USE configuration in pkg_setup which 
is non-optimal due to pkg_setup being ran potentially hours after the initial 
emerge -p invocation.

Current versions of EAPI4 support a phase hook pkg_pretend that is intended to 
move pre-build checks to just after resolution. It has been proposed that 
pkg_pretend should continue the tradition of adhoc shell code validating the USE 
state- this too is non optimal for the following reasons-

1. The only way to find out if the USE state is disallowed is to run the code
2. The common implementation of this can result in an iterative process where 
the user hits a USE constraint, fixs it, reruns the emerge invocation only to 
find that there is another constraint still violated for the ebuild, thus 
requiring them to fix it, rerun emerge, etc.
3. For a package manager to classify the error, the only option it has is to 
try and parse adhoc output written by an ebuild dev. This effectively disallows 
package manager options for providing a more informative error message. A simple 
example would be if the package manager wanted to integrate in the flag 
descriptions from use.desc/use.local.desc; this would be effectively impossible.
4. Fundamentally these constraints are data, yet they're being encoded as 
executable code- this effectively blocks the possibility of doing a wide variety 
of QA/tree scans. For example it blocks the possibility of sanely scanning for 
USE flag induced hard dependency cycles, because the tools in question cannot 
get that info out of adhoc shell code.
5. More importantly if the manager cannot know what the allowed USE states are 
for the ebuild in question, this eliminates the possibility of ever sanely 
breaking dependency cycles caused by USE flags.

Just as .sh scripts are considered a poor archival form due to their opaqueness, 
pkg_setup and pkg_pretend aren't a proper solution for this. pkg_pretend in 
particular makes the situation slightly worse due to ebuild devs being expected 
to convert their ebuilds to the pkg_pretend form when using EAPI4. In doing so 
they'll have to do work w/out the gains REQUIRED_USE provides and have to repeat 
the same conversion work when REQUIRED_USE lands in a later EAPI.

It's due to this and a few lesser reasons that EAPI4 is strongly recommended as 
the target for this functionality.

Specification
=============

Essentially REQUIRED_USE is proposed to be an analogue of DEPENDS style syntax- 
a list of assertions that must be met for this USE configuration to be valid for 
this ebuild. For example, to state "if build is set, python must be unset":

REQUIRED_USE="build? ( !python )"

To state "either mysql or sqlite must be set, but not both":

REQUIRED_USE="mysql? ( !sqlite ) !mysql? ( sqlite )"

Note that the mysql/sqlite relationship is that of an Exclusive OR (XOR). While 
an XOR can be formed from existing syntax, it's suggested that a specific 
operator be added for this case using ^^. Reformatting the "mysql or sqlite, but 
not both" with XOR results in:

REQUIRED_USE="^^ ( mysql sqlite )"

Like any block operator, this can be combined with other constraints. For 
example if the user has flipped on the client flag, one gui must be choosen:

REQUIRED_USE="client? ( ^^ ( gtk qt motif ) )"

If the pkg is implemented sanely and requires at least one gui, but can support 
multiple it would be:

REQUIRED_USE="client? ( || ( gtk qt motif ) )"

Because ARCH is integrated into the USE space, this also allows for specifying 
corner cases like "at least one gui must be specified, but on mips only one gui 
can be specified":

REQUIRED_USE="client? ( !mips? ( || (  gtk qt motif ) ) mips? ( ^^ ( gtk qt 
motif ) ) )"

Please note that the AND operator is of course supported- if to enable client 
you must choose at least one gui and enable the python bindings the syntax would 
be:

REQUIRED_USE="client? ( python || ( gtk qt motif x11 ) )"

Finally, please note that this new metadata key can be set by eclasses, and the 
inherit implementation should protect the eclass set value just the same as how 
eclass defined DEPEND is protected.
Implementation

Implementing this for EAPI4, currently 'few' (Sebastion Luther) has a working 
git branch available at [portage-implementation] implementing this 
functionality.

For getting this implemented in pkgcore, the author of the glep will handle it. 
As for paludis, presumably they can manage it due to MYOPTIONS existing in 
exheres already.

Backwards Compatibility
=======================

EAPI already makes this a non issue for backwards compatibility. Additionally 
the rsync metadata caches (enumerated flat file format) is designed for key 
expansion so there is no issue there either.

References
==========

Original ML proposal: 
http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml
[portage-implementation]	
http://github.com/few/fews-portage-branch/tree/REQUIRED_USE

Thanks to
=========

David Leverton, Brian Dolbec, and Jorge Manuel Vicetto for proofreading this and 
correcting the innumerable typos, run on sentences and general abuse of english 
the GLEP author is known for.

Additionally, many thanks to Sebastion Luther ('few') for stepping up and 
writing the portage patch on short notice.

Copyright
=========

This document has been placed in the public domain.
\end{verbatim}
}

