Gentoo Archives: gentoo-project

From: hasufell <hasufell@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] Agenda for Gentoo Council meeting on 2014-02-25
Date: Tue, 25 Feb 2014 17:09:32
Message-Id: 530CCE42.1080208@gentoo.org
In Reply to: [gentoo-project] Re: [gentoo-dev-announce] Agenda for Gentoo Council meeting on 2014-02-25 by Mart Raudsepp
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA512
3
4 Mart Raudsepp:
5 > On N, 2014-02-20 at 22:00 -0600, Donnie Berkholz wrote:
6 >> gtk USE flags =============
7 >>
8 >> (20 minutes)
9 >>
10 >> chithanh has asked whether QA can make decisions about USE flag
11 >> naming and usage. I interpret that to mean whether QA has
12 >> authority over tree policy.
13 >>
14 >> Vote: Confirm whether QA has authority over tree policy,
15 >> including USE flag naming and usage.
16 >>
17 >> References: -
18 >> http://article.gmane.org/gmane.linux.gentoo.devel/90291 -
19 >> http://article.gmane.org/gmane.linux.gentoo.project/3321 -
20 >> https://wiki.gentoo.org/wiki/GLEP:48
21 >>
22 >>
23 >> ulm requested that the council examine QA's decision.
24 >>
25 >> Vote: Do we affirm QA's decision?
26 >>
27 >> If not:
28 >>
29 >> Vote: What should the USE flag usage be?
30 >>
31 >> - 'gtk' only (maintainer chooses optimal version) - 'gtk2',
32 >> 'gtk3' etc but without 'gtk' - subpoint: 'gtk' == 'gtk2' for ease
33 >> of porting - 'gtk' is a USE_EXPAND like python versions - 'gtk'
34 >> is mandatory for *any* version, gtk2/gtk3 pick which
35 >>
36 >>
37 >> References: -
38 >> http://article.gmane.org/gmane.linux.gentoo.project/3319 -
39 >> http://article.gmane.org/gmane.linux.gentoo.devel/90291 - (2005)
40 >> http://marc.info/?l=gentoo-dev&m=111212920310822&w=2
41 >
42 > As the Gnome team lead, which maintains gtk+, I hereby request that
43 > any decision point concerning the gtk USE flag be removed from the
44 > agenda of shortly upcoming next council meeting. This implies the
45 > suggestion to suspend QA decision on this matter for the time being
46 > (irregardless of tree policy authority of QA team - such authority
47 > could be fine, given due process), and allow a proper process to
48 > take place before maintainers are asked to completely swap around
49 > their approach, only to perhaps end up with something completely
50 > different a month later.
51 >
52 > We, at the Gnome team, are dissatisfied with the way QA team
53 > discussed this point without consulting the Gnome team. Calling me
54 > into a meeting, just because I happened to be around for a few
55 > words, unprepared, is not consulting, and proclaiming a policy that
56 > is against current Gnome policy with no explanation nor logs of
57 > relevant discussion and technical demonstration just demonstrates a
58 > complete lack of formal thinking. This all started with a friendly
59 > approaching on changing our internal policy to be tree-wide, and
60 > all of a sudden a couple weeks later we have the complete opposite
61 > of the status quo of 10 years being declared policy.
62 >
63 > We acknowledge that our policy may not have been perfect but we
64 > need time to analyze claims brought up by/to the QA team to
65 > construct a proper proposal for a better policy that would satisfy
66 > everyone; hopefully in co-operation with a QA team.
67 >
68 > My suggestion is that someone from the Council or the QA team
69 > takes leadership in this issue and revitalizes technical
70 > discussions that happened in the mailing lists again via actually
71 > summarizing the points mentioned and concretely forming a good
72 > thesis of one or another approach is better than the other.
73 >
74 > Additionally it appears that we all in Gentoo need to think through
75 > and understand what exactly USE flags are, for what they are used
76 > and so on. The same oddly appears to slightly be the case for SLOTs
77 > and when to use which (SLOT or USE). Are USE flags just for
78 > expressing external dependencies from configure switches, or are
79 > they for expressing features (e.g, USE=gui).
80 >
81 >
82
83 I agree with a lot of points you mentioned.
84
85 But I disagree with the general request. This discussion did not just
86 start now. The gnome team had quite enough time to make things clear
87 (last discussion I started about this was in 2012), yet they did not,
88 but only said this is a "recommendation". That is like saying "QA
89 maybe, or not".
90
91 The first response from QA when I contacted them recently about this
92 another time was "bringt it up to the council, this is probably not
93 even a QA issue". Then they started throwing out some policy as well.
94
95 I'm not satisfied with any of this and I think we need the council to
96 end this. It has already wasted enough attention. It's not such a big
97 deal, really. The cards are all on the table and we all voted the
98 council, because we believe they are knowledgeable enough to make
99 decisions.
100 -----BEGIN PGP SIGNATURE-----
101
102 iQEcBAEBCgAGBQJTDM5CAAoJEFpvPKfnPDWzHPoH/iAZP5KmfIrLdbPHdmS4ylci
103 5YhYjmT2rZpD8zaNV1/ufSiHTsjoShIoGaPS/yw4Ed8Z2wzp0uNwNbGoy6yRySPH
104 o4MPm1zN1wyiaAG4l7dYklNt0ukIbvuIvq++2wn5A49DmMtMLXDD3zYxWTEq+qHw
105 M855wLtRC3BwALvyDK5GBIL7p1T5I30PVgXyw4/ioWCsb+l1eNOMqyQXiC3SqOfv
106 cgAB4ZqZsXBO755eihYqBFru1TT0u/IfOL6vFGRjVGV+W8uWiWoQVXmX+aCkm0NB
107 MPFc1B31XJGTW8Eu4hPRqTDSPMiL8TTNIKqGi2CvxDI8fbjlD1KBBQjTA+mFZtg=
108 =kbBA
109 -----END PGP SIGNATURE-----