On Mon, Dec 16, 2013 at 1:17 PM, Christoph Wickert
Am Dienstag, den 10.12.2013, 20:51 +0000 schrieb "Jóhann B.
> On 12/10/2013 07:59 PM, Christoph Wickert wrote:
> > And last but not least we need manpower for it's development and
> > maintenance. And this is where no other desktop can beat GNOME.
> Step right back how the community is working and reread the statement
> you just made...
> Gnome developers within the project as well as many other upstream
> maintainers we have handle their development upstream and Gnome
> developers within our project as well as many other upstream developers
> we have prefer getting their reports filed upstream so what kind of
> downstream development are you seeing here that would be specific for
> Fedora only and to the workstation product that specifically requires
> their full time present here within the project and which application
> developers have agreed to devote their free time developing those that
> applications ?
I never said I want any distro-specific downstream development, but
Fedora's mission is to lead, not to follow. We not only consume
development, we drive it. Whatever becomes our workstation product, we
want it to set new standards - not only for us but for the overall Linux
ecosystem. It would be a shame if all our efforts are limited to Fedora
or if we focus on simply integrating upstream bits into Fedora nicely.
Therefor we need manpower - that's all I said.
> When you make this statement "last but not least we need manpower for
> it's development and maintenance." with the exception of the kernel as
> far as I know the general rule of thumb for developers within the
> project is to fix in upstream first then backport fix downstream so what
> exactly is the benefit of your statement?
No matter how well we collaborate with upstream, we may find ourselves
in situations where we need a fix ASAP and cannot wait for upstream.
When we are to release the workstation product, and find it has a bug or
does not work well with something else in Fedora, we need a fix and
cannot wait until upstream has time for us. of course we can - and
should still upstream it later.
It's funny you take the kernel as example. Just look how many changes we
have in there that are not yet upstreamed. It's not like we submit all
our patches, wait for the next merge window and then ship a vanilla
kernel for our stable releases, so this is actually a good example of
what I was trying to say.
Not to stray too far here, but the kernel policy is already "upstream
first, then backport" for the vast majority of things. There are a
few exceptions, but those tend to be rather trivial patches to shut up
warnings or change defaults. We're also working on reducing those as
well. The glaring exception is secure boot support, and that has a
rather long and complicated history. It's also not something I'd care
So please refrain from holding up the kernel as some kind of special
example of anything.