Re: Mass issue: /usr/bin/env dependency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 March 2017 at 14:48, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote:
>
> On 30 March 2017 at 17:00, Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
>>
>> 1) They are going to have 'non-upstream' patches for all their
>> software.. which is just one more thing to keep up with every update.
>>
>> 2) Most of this software is not stuff they care about. It is branches
>> on a tree for the only reason they packaged it up in the first place.
>> So it is busy work from what they want.
>>
>> 3) This isn't the only rodeo they are putting this package in. So this
>> patch set looks like a special snowflake patch they have to keep up
>> with.
>
>
> Majority (+95%) of the patches related to build, install and test suite
> framework used by project is never changing.
> /usr/bin/env changes are such changes because I've been able to observer
> within +3 years across few thousands packages.
> Some of those changes will be used as long as distribution will be actively
> maintained because it is really hard sometimes to maintain such build,
> install and test suite framework fulfilling all OSeses needs.
> Sometimes it is not about those that some source maintainers are kind of bab
> people.
> Sometimes some people maintaining some publically available code are earning
> money from maining such projects by offering paid support for such software.
> In such cases it is nothing bad that such people do not care abut people
> which are not giving then money using such software.
>
> As those changes are trivial maintaining them takes really small fraction of
> whole time necessary to upgrade package spec file between versions.
> My personal observation says me that within last decade more than +60% of
> such changes never been updated.
>
>
> Sorry to say this but you are guessing and guessing you may have such
> impression that above may be truth.
> Reality is different.
>
> I'm fully aware that proposing such widely spreading change I'm entering on
> some conflict/battle ground.
> I know that all long and/or complicated conflicts are possible to finish
> using only using two methods: by giving or taking away hope.
> Stephen you chose to discourage me .. noticed ;-P
> You must know something about me that I'm really hard nut and as long as you
> will be not giving me stricte technical/engineering arguments please expect
> that such argumentation will be crushed only on technical background using
> my exp, knowledge and/or thing which I've already done .. so I'm not using
> guessing like you :)
> Please stop using guessing :)

This goes both ways.. as it is clear you are guessing my intentions
versus asking me.

My post had nothing to do with discouraging you.  My post was to
answer what I thought was Matthew's question  and consolidate the
various arguments people have come into the conversation into one
place. That way instead of 40 emails going back and forth over various
aspects they could be affirmed that these are the points one side has,
and the other side could clarify or clean up the response.

At this point, I am done here.

Nie mój cyrk, nie moje małpy

>
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>



-- 
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux