Fedora.next in 2014 -- Big Picture and Themes

[Thorsten Leemhuis]

Hi!

On 23.01.2014 19:26, Josh Boyer wrote:
> On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> 
> […]

Thx for your answer, just replying to some parts of it where I feel that
making additional statements bring the discussion forward.

>> What really gives me the creeps on those pages: "sub-committees of
>> FESCo, with individual governance structures". Those afaics are three
>> Product Working Groups Workgroups, two Fedora Rings Working Groups and
>> the Inter-WG for coordination. That sounds like a awful lot of
>> overhead an even more bureaucracy than we already have. And we imho
>> have way to much already (part of it is my fault!) – something I had
>> hoped Fedora.next would try to fix.
> It is more overhead to a degree.  On the other hand, the idea is to
> enable people that are interested in specific areas to go forth and
> create a Fedora deliverable that they think meets the needs of those
> areas best, without having to pass everything through FESCo.  FESCo
> just doesn't scale like that.

Sure, but I doubt that more committees are the best way to solve that.
I'm wondering if a development approach that more resembles the Linux
kernel would be better. Sure, the kernel also has people (not
committees!) that steer things and some rules (a lot not written down,
which has benefits imo). And in the end it's a lot "if you want
something crazy new realized you can do that as long as you do not break
the things others care about". More of that attitude and less
rules/committees is something I'd like to see in Fedora.

>> I these days wouldn't start contributing to Fedora, as all those rules
>> and guidelines that the wiki provides would scare me off. That's what
>> Fedora.next should fix imo, as we afaics need more contributors: I
>> more often than a few years ago find packages in Fedora that are badly
>> maintained or outdated. Contributing must be as easy as editing a
> The packaging guidelines are very daunting.  Automating as much of
> that as possible, either through spec creation tooling or package
> review tooling would help.

I think it's not only the packaging guidelines imho, it's the whole
processes around package maintenance -- for existing packagers and
newcomers.

I for example recently saw that a package I used to maintain long ago
was outdated in fedora 20. I chose to ignore it in the end, as I didn't
want to nag the current maintainers via bugzilla (yes, I should have
done that; sorry, was overly careful or lazy, but that's how people are
quite often afaics); I would have preferred to simply do a "fedpkg clone
foo; <update, build, quick test run>" and then submit it to rawhide,
without fearing somebody might yell at me(¹). IOW: like editing a
wikipedia page, even if that's in the end more work that simply filing a
bug.

(¹) Yes, I still have provenpackager rights, so I could have done that,
but that wouldn't be considered appropriate under current rules

>> wikipedia page. Further: kororaproject.org, fedorautils-installer and
>> similar project show that there are people that want to make Fedora
>> better. But they do their work outside of Fedora and RPM Fusion;
>> fixing the issues directly at the root would be better for all of us.
> Small note:  The two projects you use as an example are required to do
> what they're doing (in part) outside of Fedora for legal reasons.  I
> don't believe Fedora.next will change how US law works, so it might
> not be the best of examples.

Hmmm. Maybe it were bad examples. But I guess I didn't actually explain
the point I was trying to make properly. So here we go in different
words after a few more quotes lines:

> (And we have a Board meeting to discuss related things that are not
> legally prohibited.)
(for the archives: see
https://lists.fedoraproject.org/pipermail/advisory-board/2014-January/012433.html
for context and outcome; in short: the Fedora board voted against the
proposal to allow 3rd party repos in the App installer)

The Fedoraproject once again chose to leave non-free out of Fedora. I
appreciate that. I even think a lot of users understand why the
Fedoraproject acts like this (now and earlier, too). But: it utterly
hard to get non-free Software when running Fedora. That's what the
Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on
non-free Software, does a way better job in that area than Fedora does.
We need to catch up here and I think the Fedoraproject should drive
this, because it's important for the success of Fedora (and RHEL/CentOS)
that people can easily use it for what they want. And as the down-voted
proposal shows: There are developers within the Fedoraproject that are
willing to do the work; there are more in Korora, RPM Fusion and other
places. We just need to bring them together properly afiacs.

Obviously those developers need a place to do their work. I think RPM
Fusion is that, as it's well established and something a lot of people
all to Fedora anyway. But yes, RPM Fusion contains packages that are
problematic under US law. if this is hindering to much let's fix it –
for example by separating RPM Fusion free and non-free more or by
splitting off the later completely. I'm not involved in RPM Fusion any
more, but I'm quite sure they would be open to such a idea if the
Fedoraproject would want that.

>> That's why I got the feeing a lot of contributors are simply waiting
>> for more concrete details to emerge before deciding what to make of
>> Fedora.next; or they simply at all don't care to much what the higher
>> ups do, as getting involved on that level can cost quite a lot of time
>> and can be frustrating (that's not a complaint, that's simply how it
>> is often; wasn't much different in my days, but noticed that more when
>> I wasn't that active an more myself).
> If they are waiting, what are they waiting for?

I for one waited (and still wait) for a text that gives a brief
overview; something like a four or five para text which outlines the
consequences and how Fedora will look like in the end. Something easy to
understand; so easy that people can grasp it who are not involved in
Fedora, but know what Linux is.

Then provide some more text that then goes into the details. But keep it
short and easy to read, too. Most of us have a stressful day and the
attention span is quite short. So even the longer stuff should not take
more than 10 minutes to read (or provide something to put 12 more hours
into a day, then the text can be a bit longer ;-) ).

> [...]

Cu
knurd