Mailinglist Archive: opensuse-buildservice (95 mails)

< Previous Next >
Re: [opensuse-buildservice] Popular branches, moving them to "official" repos
On 6/10/2015 10:59 PM, greg.freemyer@xxxxxxxxx wrote:

On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi
<baiduzhyi.devel@xxxxxxxxx> 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@xxxxxxxxx> wrote:
Right. So either you haven't read my email, or you haven't checked
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
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:

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

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
faster to branch and change yourself.


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.


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.


To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups