Hi! On 23.01.2014 19:26, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
