Re: [Musicpd-dev-team] Regarding Windows builds of MPD

[Denis Krjuchkov]

14.12.2013 0:10, Max Kellermann пишет:

 I'm all for fixing bugs in the stable branch, but if your idea of (2)
 is to backport the master code, then this is not my idea of a stable
 branch, and we're better off with (1).

 However my preference would be (3): fix only the regressions that made
 0.18 unusable.


Hi Max,

I fully agree with your approach to stability, however situation is 
somewhat disastrous.

Source of the problem is custom event sources (which are used everywhere 
in 0.18.x unlike for example 0.17.x). GLib expects event handle in 
GPollFD rather than socket descriptor. All hacks for constructing (and 
updating) correct GPollFD are already implemented in standard GLib event 
sources (i.e. standard IO channels). I've spent some time trying to 
understand what they do, but didn't succeed :-)

I think implementing correct fix for 0.18.x by either copying internals 
of standard IO channels or changing MPD to use standard IO channels is 
unlikely to be considered stable anyway. Also I doubt that GLib 
implementation is correct in all sutuations. IMO it's just too tricky to 
do it well.

It seems that case (1) looks like the best solution.

-- 
Denis

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team

Re: [Musicpd-dev-team] Regarding Windows builds of MPD

[Denis Krjuchkov]

14.12.2013 0:24, Sean McNamara пишет:
 Hi,


Hi Sean,


 1. For now, you make a tested build based on git master, which you
 have personally evaluated and find that it is mostly correct, except for
 any platform-independent bugs that are already known but not yet fixed.
 This basically constitutes downloading the latest commit from git master
 and trying out several features of the windows build; if it works,
 great, you can ship it once it meets your own personal criteria of what
 constitutes a good enough build. This would be the one and only Windows
 build until the next stable release of mpd, unless of course, some user
 decides on their own to build the code separately, which is their
 prerogative.

That's practically how I've done it for 0.17.x. I've tested manually 
various audio file formats, various output plugins, etc.


 2. Going forward, once the next stable mpd release is made based on git
 master, you would only need to provide updated builds for Windows when a
 stable release of the mpd source is officially released.

 This wouldn't involve any backporting, and seems like it'd be fairly
 minimal work on your part (relative to all the code changes you've made
 lately; thanks for that!).

Again that's how it was done for 0.17.x. I'm willing to return to this 
practice when 0.19.x becames stable. Anyway my build scripts support 
three build sources: latest stable tarball, latest stable git and 
development git. I need this to do development of MPD itself because 
large part of building MPD for Windows is building lots of libraries 
that are not always buildable out of the box. So generally creating new 
stable branch of MPD requires almost no work at my side.

-- 
Denis

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team