Gentoo Archives: gentoo-dev

From: Peter Stuge <peter@×××××.se>
To: gentoo-dev@l.g.o
Subject: Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Date: Mon, 11 Feb 2013 16:22:23
Message-Id: 20130211162216.10939.qmail@stuge.se
In Reply to: Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild) by Alexis Ballier
1 Alexis,
2
3 Alexis Ballier wrote:
4 > All of this because ~10 people cannot work together, well, really,
5 > thank you :)
6
7 Do you have experience from being in a similar situation? You are
8 being quite judgemental.
9
10 There are absolutely situations where people so different that
11 cooperation simply can't work. It's pretty lame, but unless you
12 yourself participate at least on the same level as everyone else
13 (on both sides) you really don't get much of a say.
14
15 It's easy to tell people to "stop fighting, just get along" - but
16 I believ that intentional fighting is quite rare. It's more likely
17 about trying to make one's point.
18
19 That requires communication, but communication is not always
20 possible. (I don't mean transmissions back and forth, I mean
21 desire to understand the transmissions.)
22
23 For a long time I idealized open source as being an ideal community,
24 where communication always worked because everyone wanted it to. But
25 that's unfortunately not at all the case.
26
27
28 > Can you point out any important problem?
29
30 I suppose the problem is that "it is not done yet" like Greg
31 sometimes says about things that are being worked on in the kernel.
32
33 Of course when a work-in-progress is published and someone
34 desperately wants to use it they will try to use it as soon as
35 possible, and if they are unhelpful they will complain and/or run
36 off in their own direction without receiving anyone's communication.
37
38 If this has happened to you, you will know that such events teach you
39 never to do any work in the open, ie. only publish code when you
40 think that it is completely done. On the other hand you may still
41 want to have feedback during your work. A perfect conflict of
42 interest, which is quite annoying and distracting.
43
44
45 > how open source work
46
47 And how it sometimes doesn't work at all. I mean: It is not useful.
48
49 In an ideal world people would work more together. Sometimes that
50 simply isn't possible.
51
52
53 > > I have no opinion, I stayed out of the discussion and decision about
54 > > that before because I know I have a bias. I let other people decide.
55 >
56 > Note: If pro-libav people would be doing the work of fixing the tree
57 > and ensuring *everything* works with libav I would not mind at all
58 > what the default is.
59
60 I think this is completely fair! Thanks for that.
61
62
63 > I consider FFmpeg superior, but can understand there are different
64 > opinions, however, if this is to lower the tree quality
65
66 Quality is not a very helpful metric, because it means completely
67 different things for different people. Some people value code
68 readability, maintainability, and correctness very high, other people
69 value having a new idea halfway implemented and released even if it
70 only kindasorta works and is not at all reliable and not on par with
71 previous parts of the code.
72
73 I see a tendency in myself and in others to not care about what
74 happens on the inside when thinking merely as a user. I see many many
75 people complain about the insides when they are not happy with how it
76 performs. I very rarely see people actually dig in to help fix up the
77 insides. The same pattern exists in pretty much all projects that I
78 know of, and it is quite natural - there are more users than
79 developers.
80
81
82 > then it is obvious libav shouldn't be the default.
83
84 It may be obvious to you, but please remember that others may (are
85 likely to!) have a different metric.
86
87
88 > libav should realize they are the actual fork (this is now pretty
89 > clear since the takeover failed and ffmpeg didn't collapse...) and
90 > also rename their libraries so that the internal libav/ffmpeg
91 > fights would not affect their users anymore and projects could use
92 > what they think best...
93
94 Unless libav considers the API too broken to still be functional I
95 don't see the point of differentiation. A little bit of competition
96 can be good overall even though it is more stressful for both sides.
97 The most important thing is what I asked for already -
98
99 That users inform themselves, and make informed decisions.
100
101
102 Anything else is really just an excuse not to have to form, voice,
103 and defend an opinion - take a stand - which IMO is just as lame as
104 ~10 people who cannot work together.
105
106
107 //Peter

Replies