On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi 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?... 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. Greg -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi wrote:

...

On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi

wrote:

...

Right. So either you haven't read my email, or you haven't checked

On Monday 08 June 2015 16:02:47 Greg Freemyer wrote: 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:

...

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

https://build.opensuse.org/package/view_file/openSUSE:Factory/mc/mc.changes? 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org

On Wed, Jun 17, 2015 at 4:21 PM, Brian K. White wrote:

On 6/10/2015 10:59 PM, greg.freemyer@gmail.com wrote:

...

On June 10, 2015 5:59:35 AM EDT, Stanislav Baiduzhyi wrote:

...

On Monday 08 June 2015 16:02:47 Greg Freemyer wrote:

...

On Mon, Jun 8, 2015 at 9:02 AM, Stanislav Baiduzhyi

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