Hi,
As a potential user (:)) of the Windows builds, I would like to propose
that:
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.
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!).
Lastly -- consider that the type of user who would run Windows AND want to
download precompiled binaries, is likely not the same type of user who
would want to run unstable software. So, once the next stable mpd release
includes your Windows fixes, I really see no value in continuing to produce
builds of git master (or any dev branch), because the people who are most
likely to consume them are the least likely to report any problems they
find, much less fix them themselves. You'll be getting bug reports and
patches from users who have the technical knowledge to grab the git master
code and build it for Windows themselves, and for those people, the
precompiled builds won't help them much at all.
-Sean
On Fri, Dec 13, 2013 at 1:08 PM, Denis Krjuchkov <de...@crazydev.net> wrote:
> Hello list,
>
> some months ago I proposed my self as a Windows binaries maintainer.
> I'm still committed to this task.
>
> However 0.18.x branch is unusable on Windows due to GLib event loop
> implementation oddities. In short: it does not work.
>
> Current MPD trunk (v0.19.x) supports native Windows event loop which
> works well from my experience.
>
> I see two principal ways of fixing things:
>
> 1) Provide binaries for ongoing master branch. Since this is a
> development branch it might be less stable, however again from my
> experience it works well.
>
> 2) Backport important changes from master to 0.18.x and keep updating it
> as 0.18.x branch evolves.
>
> I'm not yet decided, so comments and ideas are appreciated.
>
> --
> 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=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Musicpd-dev-team mailing list
> Musicpd-dev-team@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
>
------------------------------------------------------------------------------
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=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
