On Mon, Dec 16, 2013 at 1:17 PM, Christoph Wickert christoph.wickert@gmail.com wrote:
Am Dienstag, den 10.12.2013, 20:51 +0000 schrieb "Jóhann B. Guðmundsson":
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 to repeat.
So please refrain from holding up the kernel as some kind of special example of anything.
josh