Underlying DE for the Workstation product, Desktop -vs- Workstation

[drago01]

On Mon, Feb 3, 2014 at 3:52 PM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
>
> On 02/03/2014 02:32 PM, drago01 wrote:
>>
>> On Mon, Feb 3, 2014 at 3:11 PM, "Jóhann B. Guðmundsson"
>> <johannbg at gmail.com> wrote:
>>>
>>> On 02/03/2014 02:08 PM, Josh Boyer wrote:
>>>>
>>>> I think that's a fair observation, but I would urge the WG to set
>>>> aside marketing for a minute and focus on what they feel is the best
>>>> positioned DE from a technical and resource perspective to build the
>>>> product from.
>>>
>>>
>>> When you speak of resource perspective are you referring to downstream
>>> resources  or upstream resources because the former does not matter just
>>> the
>>> latter...
>>
>> Both matter.
>
>
> I disagree and require further explanation from you since I question the
> current thought of upstream role in downstream distributions after exploring
> the communities surrounding both to better understand the eco system of
> thoughts and the effects of those thoughts that residing in both of them.

Simply because of expertise you want to have people that know how the
stuff works including the code to some extent. Just shifting
everything to upstream that might have different release schedules and
priorities makes no sense and does not work. Having upstream
developers "in house" also allows you to influence upstream directions
to some extend and better deal with bugs encounter.

Also to handle cases like "bug xxx is a blocker bug we have y days
left to fix it" ... upstream might not care much about your schedule
but having someone from upstream being part of the community (= he/she
has interests in fixing it in time) definitely helps.

> In other much simpler words upstream maintainers are distracted from what
> they do best which is working on their code by maintaining their component
> in downstream distribution and that distraction is not helpful to end user,
> not helpful for those us in QA and does not expand those maintainers as
> individuals.

(This is a different topic but as I stated elsewhere we should focus
more on code and less on packing because the latter can be automated
in many cases while the former requires man power.
Letting "robots" do the packing work (for instance the "mclazy" script
used for gnome-updates) frees time and resources for more useful stuff
like adding features, fixing bugs etc.)

So to go back to your statement having a dead upstream is bad, having
a dead downstream is bad. Having a low on resources upstream is bad.
Having a low on resources downstream is bad. Having an active upstream
where you have some influence (and that means you contribute enough
and not just demand stuff) with a working downstream is what you
should aim for if you want to create a successful product.