blob: 7d59d704b1fefa5cb8a7a9d9d1ec99c69cf0468b (
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
|
\summary{2017}{7}{16}
Agenda call:
Agenda announcement:
\agendaitem{Constituting the new council}
The Council decided on holding meetings every 2nd Sunday of each month at
1800 UTC.
The last council's workflow of sending a call for agenda items two weeks in
advance, and sending the final sending agenda one week in advance was adopted,
including having the meeting focused, i.e., to have major discussions on
-project ML prior to the meeting.
The chairs were selected for the council meetings of the coming period.
\agendaitem{Discussion about the current situation of the stable tree}
The following summary was sent in a separate \agoref{gentoo-dev}{0aba06faccfa7c5a9648745a3639932b}
as a result of the discussions during this meeting:
\begin{quote}\small
\begin{verbatim}
I see the problem of lagging stable and unstable trees as:
1. lack of automation
2. lack of manpower
The PROPOSAL to solve the '1. automation' part is to draft
a new GLEP. If there is any interest (I assume there is!) I'll start one.
Let's call that fufure 'life of KEYWORDS'. It will cover:
- Update on GLEP-40 ("x86 stabilization can do only x86@ team")
to allow package maintainers to do ARCH=x86 stabilization.
It will be an arch-agnostic way: each arch will have minimal requirements
to setup environment suitable for stabilization and keywording:
CFLAGS to have, hardware required, whatever else is practical.
- Formalize list of stable arches as such (will be covered by
'arches.desc' GLEP)
- Formalize what is a "stable arch". In short:
- arch is marked as such in 'arches.desc'
- performs most of STABLEREQ/KEYWORDREQ or gives rationale
why progress can't be easily done before 90-days timeout
- Formalize and automate process of dropping keywords for timed out
STABLEREQ/KEYWORDREQ requests.
- Automate process of restoring dropped KEYWORDS due to bumps
adding new unkeyworded dependencies. repoman already complains
about those. What is left is to grab them in batches time to time
and handle those as if those were KEYWORDREQ.
- File more automated STABLEREQs to rely less on lazy maintainers
(I am example of lazy maintainer not siling STABLEREQs enough).
- Formalize which STABLEREQ/KEYWORDREQ can be done automatically
by arch teams (or maybe anyone else having the hardware!).
In short: anything not marked as "Runtime testing required"
on bugzilla and not having any blocker bugs.
The proposal to solve the '2. manpower' part is:
- Write more docs and make stabilisation process easier for everyone.
Important detail: the list is not in set in stone but rather a guideline
of things to cover.
Please feel free to propose other topics, questions, concerns, likes or
any other actionable feedback!
\end{verbatim}
\end{quote}
\agendaitem{Open bugs with council involvement}
\bug{618254}: The council voted on closing this bug; the motion passed with 6 yes, 0 no
and 1 abstain votes.
\agendaitem{Open floor to council members to introduce themselves}
No summary was given.
\agendaitem{Open floor}
No items were raised during the open floor
|