[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-buildservice
Subject:    Re: [opensuse-buildservice] Popular branches, moving them to "official" repos
From:       Greg Freemyer <greg.freemyer () gmail ! com>
Date:       2015-06-17 20:28:52
Message-ID: CAGpXXZ+kt1o9Bu1jtp_nHdsKRKrcE-y3ZxoC7Sy9mD9gau0xOw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jun 17, 2015 at 4:21 PM, Brian K. White <brian@aljex.com> wrote:
> On 6/10/2015 10:59 PM, greg.freemyer@gmail.com wrote:
>>
>>
>>
>> On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi
>> <baiduzhyi.devel@gmail.com> wrote:
>>>
>>> On Monday 08 June 2015 16:02:47 Greg Freemyer wrote:
>>>>
>>>> On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi
>>>>
>>>> <baiduzhyi.devel@gmail.com> wrote:
>>>>>
>>>>> Right. So either you haven't read my email, or you haven't checked
>>>
>>> the
>>>>>
>>>>> spec
>>>>> file for mc in factory. It has '--disable-vfs-fish' configure flag
>>>>> specifically set.
>>>>>
>>>>> Yet when you search through the OBS, there are 11 branches (or
>>>
>>> rather
>>>>>
>>>>> rebuilds) of mc, 7 of them have fish enabled as the main change
>>>
>>> over the
>>>>>
>>>>> factory version.
>>>>
>>>>
>>>> Looking at the mc changelog in the devel project it says fish was
>>>> disabled due to a data loss bug:
>>>>
>>>>
>>>
>>> https://build.opensuse.org/package/view_file/openSUSE:Factory/mc/mc.changes?
>>>>
>>>> expand=1
>>>>
>>>> https://bugzilla.novell.com/show_bug.cgi?id=856501
>>>> http://www.midnight-commander.org/ticket/3128
>>>>
>>>> In that case what are you asking for?
>>>>
>>>> A new repo called "I know there's a data corruption bug, but I want
>>>> the feature anyway".  (I'm sure there is a better name but you get
>>>
>>> the
>>>>
>>>> idea.)
>>>>
>>>> If so, there is clearly at least some demand.  I'd say make the
>>>> proposal and see if it flies.  Personally I avoid software with known
>>>> data corruption bugs if at all possible.
>>>
>>>
>>> mc is just a good example, but I mean the case in general. How many
>>> forks of
>>> other packages with minor tuning are there? Searching for some specific
>>>
>>> version of package is not very helpful, browsing through revision
>>> history of
>>> every one of those "home:/" packages is very time consuming, so it is
>>> usually
>>> faster to branch and change yourself.
>>
>>
>> Stas,
>>
>> I clearly work with the official development versions.  If I find they
>> don't build the way I want I branch, change, submit.  In general the SR is
>> accepted.
>>
>> Thus I looked at mc to see what change was not being submitted back to the
>> development project a disabled feature that can cause data loss when enabled
>> made sense to me.
>>
>> What kind of build tweaks are living in home directories?  Why aren't they
>> being SR'ed back to the devel project?
>>
>> To me anything that encourages a divergence between devel packages and
>> home packages is going in the wrong direction.
>>
>> Greg
>>
>
> That is an unanswerable, infinite, open-ended question.
>
> There are countless configuration choices, personal preferences, compromises
> for practicality/maintainability, policy based choices like
> including/excluding support for some optional non-oss feature, things like
> agreeing/disagreeing with suse's choice of added patches, etc etc
>
>
> For instance, I don't happen to like that suse hacked in SLP support into
> rsync daemon. I especially don't like that this included new config file
> directives that aren't in the manual or upstream or other rsyncs on other
> platforms. I especially especially don't like that this broke my ability to
> publish a single config file to a range of hosts that all ran otherwise
> perfectly compatible versions of rsync, even though some were freebsd, sco
> open server, even one solaris, and some were linux but not suse, and some
> were suse. My well working system broke when the config file either failed
> to contain an required directive, or contained an unrecognized directive. I
> no longer remember which direction caused some of the daemons to fail to
> start, since I dealt with it a long time ago by branching and building my
> own rsync, and keeping it updated over time, without those SLP patches.
>
> It's a valid thing for me the enterprise-wide architect to decide that I
> want for my own reasons, and yet it's not something that suse wants or even
> necessarily should want to ever accept as a SR from me. It's perfectly fine
> for suse to want that service location feature. It's not a bug to be fixed.
> It's also perfectly fine for me not to want it, and for it to be considered
> a bug to be fixed FOR ME.
>
> That's just one example. The potential similar ones are literally countless.

Brian,

That makes sense, but it is the "infinite" set of possibilities that
concerns me.

Stas asked to have a way to manage these types of packages outside of
home projects.

If they are important enough (KDE unstable) then a OBS repository in
the main namespace makes sense.

One called "Projects with random tweaks we like" doesn't.  At least not to me.

Greg
-- 
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

[prev in list] [next in list] [prev in thread] [next in thread]