On 02/03/2014 03:41 PM, drago01 wrote:
On Mon, Feb 3, 2014 at 3:52 PM, "Jóhann B. Guðmundsson"
<johannbg@xxxxxxxxx> wrote:
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.
Which is why I said the role of the upstream in downstream distribution
should be the role of an consultant which provides all that without any
negatives or distractions.
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.
Dead upstream is bad ( irrelevant if that upstream is within the
distribution itself or outside )
Upstream being low on resources is bad even worse if downstreams
distracts them ( Again irrelevant if that upstream is within the
distribution itself or outside it )
Having an active upstream is what matters ( again irrelevant if that
upstream is within the distribution itself or outside it )
Our contribution as an downstream distribution is to delivering that
feed back we receive as well as package maintaining and integrating the
component or stacks of components downstream here with us ( which makes
us not demanding anything for upstream ) is that successful beneficial
relationship.
So if an upstream maintainer is in any other role then "consultant"
within distribution(s) it becomes no longer successful beneficial
relationship for anybody it becomes a distraction for everybody.
Image how further the software center work could have gone if Richard
would not have been distracted having to integrate it and dealing with (
to put it mildly ) less then perfectly maintained component with us ( as
opposed to him be in the role of an consultant and say this is whats
happening and this is what I would like you as an downstream
distribution to do and then just continue work on upstream ) image how
not so far or not so successful systemd had become if for example Kay
and or Lennart would have been spending all their time migrating legacy
sysv initscript to native systemd units in downstream distributions.
JBG
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
