I read yet another thread about Fedora randomly changing the way UNIX has done things forever (the specific thread was on /dev/shm mount options) and it reminded me that I’ve been saying for a while that Fedora urgently needs an architect. FESCo should appoint a person as their technical representative who speaks for overall system architecture concerns. The person in this role should actively seek out compatibility or integration problems but should also be a “go to” person for concerns that arise in the interests of distribution cohesion. Sure, they should be accountable, etc. but the idea that everything should be filed in some ticket and wait a week for FESCo to debate it is both the reason these things don’t get filed (because you can’t file every tiny annoyance) and also the reason why we have these long mailing list threads in the interim.
Here are some of the things an actual architect could do:
- Embody the overall engineering effort. Help determine overall distribution vision, help set direction, and make recommendations to the various stakeholders about what is required and what is not in order to meet the goals Fedora sets forth. This includes rationalizing the impact of certain possible technical decisions, and recommending against others.
- Help handle initial discussion of a new feature, work out the integration planning, liase with stakeholders (figure out who they are and actively seek them out if necessary)
- Monitor the distribution mailing lists for technical issues and be able to have a non-partisan recommendation in the case that there isn’t a mutually agreed upon answer. For really contentious stuff, others would handle it anyway so they can pass it on. But for stuff like system defaults, they can help resolve many problems that arise quickly.
- etc.
I know that an architect isn’t going to happen, but this is my personal opinion nonetheless. I am certain that were there actually one person in that role we’d see a marked improvement in overall cohesion and distribution quality well within 2 releases.
Jon.
How does this work when the development is happening “upstream” as a joint effort involving many other distributions? What does a Fedora Architect get to do here?
And really, hasn’t Bill Nottingham been playing this role to some extent for years?
I have a better idea
– create a huge collection of *detailed* use-cases, ideally with regression tests. The distro should be defined by such use-cases and verified before each release.
Jesse is right, we have no clue about upstreams changes — if you have tests for use-cases than you can verify that upstream development matches with our (downstream) goals.
Honestly, I’m desperately seeking for this kind of role in Fedora as well. Fedora recently does things, that are against old Unix rules and of course, rules are here to break them, but some of the changes should have been reviewed from a broader perspective and verified with affected components. I thought that FESCo or board should stand up in such cases and drop feature that are against these rules, but that’s not really happening
Take a look at other large projects with multiple upstreams that *do* handle this. A random example might be the Yocto project, which has the architect role I am suggesting, but there are many other projects. Just because there are upstreams to work with doesn’t mean you can’t have someone who helps figure out how it all goes together, gets involved with those upstreams to ensure the software will have the features relevant to Fedora, and works with packagers to ensure that the integration of those upstreams is appropriate later on.
Conversely, Fedora should not be held hostage to the whims of various disconnected upstream projects. Instead, it should help steer those other projects as a major user, especially in the case that the upstream exists primarily as a result of Fedora folks to begin with.
[...] jcm's blog World Organi[sz]ation Of Broken Dreams « [opinion] Fedora needs an architect [...]