summaryrefslogtreecommitdiff
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
\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}}