summaryrefslogtreecommitdiff log msg author committer range
blob: cc8301be82850b0d771d16d854cbba89656b4537 (plain)
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416  .highlight .hll { background-color: #ffffcc } .highlight .c { color: #888888 } /* Comment */ .highlight .err { color: #a61717; background-color: #e3d2d2 } /* Error */ .highlight .k { color: #008800; font-weight: bold } /* Keyword */ .highlight .ch { color: #888888 } /* Comment.Hashbang */ .highlight .cm { color: #888888 } /* Comment.Multiline */ .highlight .cp { color: #cc0000; font-weight: bold } /* Comment.Preproc */ .highlight .cpf { color: #888888 } /* Comment.PreprocFile */ .highlight .c1 { color: #888888 } /* Comment.Single */ .highlight .cs { color: #cc0000; font-weight: bold; background-color: #fff0f0 } /* Comment.Special */ .highlight .gd { color: #000000; background-color: #ffdddd } /* Generic.Deleted */ .highlight .ge { font-style: italic } /* Generic.Emph */ .highlight .gr { color: #aa0000 } /* Generic.Error */ .highlight .gh { color: #333333 } /* Generic.Heading */ .highlight .gi { color: #000000; background-color: #ddffdd } /* Generic.Inserted */ .highlight .go { color: #888888 } /* Generic.Output */ .highlight .gp { color: #555555 } /* Generic.Prompt */ .highlight .gs { font-weight: bold } /* Generic.Strong */ .highlight .gu { color: #666666 } /* Generic.Subheading */ .highlight .gt { color: #aa0000 } /* Generic.Traceback */ .highlight .kc { color: #008800; font-weight: bold } /* Keyword.Constant */ .highlight .kd { color: #008800; font-weight: bold } /* Keyword.Declaration */ .highlight .kn { color: #008800; font-weight: bold } /* Keyword.Namespace */ .highlight .kp { color: #008800 } /* Keyword.Pseudo */ .highlight .kr { color: #008800; font-weight: bold } /* Keyword.Reserved */ .highlight .kt { color: #888888; font-weight: bold } /* Keyword.Type */ .highlight .m { color: #0000DD; font-weight: bold } /* Literal.Number */ .highlight .s { color: #dd2200; background-color: #fff0f0 } /* Literal.String */ .highlight .na { color: #336699 } /* Name.Attribute */ .highlight .nb { color: #003388 } /* Name.Builtin */ .highlight .nc { color: #bb0066; font-weight: bold } /* Name.Class */ .highlight .no { color: #003366; font-weight: bold } /* Name.Constant */ .highlight .nd { color: #555555 } /* Name.Decorator */ .highlight .ne { color: #bb0066; font-weight: bold } /* Name.Exception */ .highlight .nf { color: #0066bb; font-weight: bold } /* Name.Function */ .highlight .nl { color: #336699; font-style: italic } /* Name.Label */ .highlight .nn { color: #bb0066; font-weight: bold } /* Name.Namespace */ .highlight .py { color: #336699; font-weight: bold } /* Name.Property */ .highlight .nt { color: #bb0066; font-weight: bold } /* Name.Tag */ .highlight .nv { color: #336699 } /* Name.Variable */ .highlight .ow { color: #008800 } /* Operator.Word */ .highlight .w { color: #bbbbbb } /* Text.Whitespace */ .highlight .mb { color: #0000DD; font-weight: bold } /* Literal.Number.Bin */ .highlight .mf { color: #0000DD; font-weight: bold } /* Literal.Number.Float */ .highlight .mh { color: #0000DD; font-weight: bold } /* Literal.Number.Hex */ .highlight .mi { color: #0000DD; font-weight: bold } /* Literal.Number.Integer */ .highlight .mo { color: #0000DD; font-weight: bold } /* Literal.Number.Oct */ .highlight .sa { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Affix */ .highlight .sb { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Backtick */ .highlight .sc { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Char */ .highlight .dl { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Delimiter */ .highlight .sd { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Doc */ .highlight .s2 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Double */ .highlight .se { color: #0044dd; background-color: #fff0f0 } /* Literal.String.Escape */ .highlight .sh { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Heredoc */ .highlight .si { color: #3333bb; background-color: #fff0f0 } /* Literal.String.Interpol */ .highlight .sx { color: #22bb22; background-color: #f0fff0 } /* Literal.String.Other */ .highlight .sr { color: #008800; background-color: #fff0ff } /* Literal.String.Regex */ .highlight .s1 { color: #dd2200; background-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */\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}}