\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 , :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-feringb-requireduse} Source: \url{ https://web.archive.org/web/20100812050720/http://dev.gentoo.org/~ferringb/requi red-use.html} \index{developer!feringb} \vspace*{1cm} {\small \begin{verbatim} GLEP: 61 Title: REQUIRED_USE USE state constraints Version: 1.1 Author: Brian Harring 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} }