Gentoo Archives: gentoo-dev

From: Fabian Groffen <grobian@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Changing policy about -Werror
Date: Fri, 14 Sep 2018 22:45:42
Message-Id: 20180914224526.GI26329@gentoo.org
In Reply to: Re: [gentoo-dev] Changing policy about -Werror by Alon Bar-Lev
1 I think you misunderstood what I wrote, or I wasn't clear enough.
2 Richard summed up my intention nicely in his response.
3
4 Fabian
5
6 On 15-09-2018 00:46:24 +0300, Alon Bar-Lev wrote:
7 > On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen <grobian@g.o> wrote:
8 > >
9 > > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
10 > > > >
11 > > > > Perhaps, if one persists on going this route, only do this for platforms
12 > > > > that upstream supports, such that arches which will suffer from this
13 > > > > (typically ppc, sparc, ...) don't have to be blocked by this.
14 > > >
15 > > > Exactly in these cases the -Werror is useful as if upstream expects no
16 > > > warnings then any warning should block installation and trigger bug
17 > > > report. In Gentoo in many cases we use packages on platform has no
18 > > > access to, our feedback to upstream is valuable. A great example is
19 > > > gnutls in which we collectively (maintainer, unstable users,
20 > > > architecture teams, stable users) found issues on architectures that
21 > > > almost nobody other than Gentoo has access to.
22 > > >
23 > >
24 > > I don't believe Gentoo users are (supposed to be) an extension of
25 > > upstreams.
26 >
27 > This is exactly what I think that is special about Gentoo, and the
28 > reason I use Gentoo. Unlike other distribution Gentoo is the closest
29 > thing of using upstream. A maintainer in Gentoo who is not see himself
30 > part of the upstream packages he maintains has far less impact than a
31 > maintainer who does see himself as part of upstream or is upstream.
32 >
33 > Per your statement, we should not allow any architecture or setup that
34 > upstream, such as exact versioning, architecture or toolchain.
35 >
36 > > If upstreams insist on that, they should make their software
37 > > non-free, adding a non-modification clause or something. In any case,
38 > > it is not Gentoo's job IMHO.
39 >
40 > Then we cannot re-distribute or patch, how is it related to the
41 > discussion? We are talking about open source projects and I know it is
42 > cliche... the "greater good" and helping the "free open source
43 > movement" a a viable alternative. I thought this is what unite us
44 > here.
45 >
46 > > In the end it is Gentoo who needs to care
47 > > for its users. I prefer we do that by giving them an option to become
48 > > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo
49 > > disables by default.
50 >
51 > Do you think someone do not care about the users? Do you actually
52 > think upstream does not care about users? I do not understand this
53 > statement. If downstream maintainer believes that upstream is friendly
54 > for the Gentoo overhead (which is higher than binary distributions) or
55 > create the relationship in which Gentoo is 1st citizen at upstream,
56 > why do you think users cannot use vanilla upstream?
57 >
58 > > As maintainer and/or enthusiastic user, like you wrote for gnutls, I
59 > > would be more than happy to provide build logs/errors for all the arches
60 > > I have access to. So like I wrote before, I think we should consider
61 > > case-by-case basis to make it easy to do so.
62 >
63 > This entire discussion is to allow case-by-case and not black and
64 > white approach recently enforced.
65 >
66 > Regards,
67 > Alon
68 >
69
70 --
71 Fabian Groffen
72 Gentoo on a different level

Attachments

File name MIME type
signature.asc application/pgp-signature