Upstream is dead
lazka
Anyone interested in a temporary fork or something?
I know that QL is kind of "finished".. and I understand that
motivation is
missing, but the current situation isn't that good...
Eirik Haatveit
to not refresh songs db on startup), and gapless playback has become
possible thanks to the efforts of srobertson, but what else is there?
Steven Robertson
Is Quod Libet truly dead, or does it just have a very long development
cycle? Joe Wreschnig / piman, the maintainer of QL, sounded like he
intended to eventually sort through the backlog of bugs in a chat on
IRC, and Michael Urman continues to maintain Mutagen. I'm not in favor
of trying to force a fork - it's a pretty rude maneuver. If piman
agrees that QL is dead, that's a different matter.
I _am_ in favor of using a DVCS service like BitBucket or GitHub to
create a semi-official community *branch*, but I'll wait until piman
responds (or doesn't) before trying to plan that out.
Steven
lazka
> Maybe some more patches should be accepted into SVN (like the option
> to not refresh songs db on startup), and gapless playback has become
> possible thanks to the efforts of srobertson, but what else is there?
The current situation is that they come up with a patch.. it doesn't
get upstream.
Nobody is there to tell them why it isn't and what change is needed to
get it there.
And if for example look at distro bugtrackers (like launchpad), the
bugreports there are mostly fixed by available patches but still
ubuntu ships the buggy 2.0 tarball.
A clear roadmap would be nice too.
Fergus Bremner
is - to name just one example - the only player that can correctly
organise and display classical music collections.
I second Eirik's suggestion and wonder what it would take to
re-animate this uniquely marvellous player.
-fergus
Joe Wreschnig
If anyone is interested in forking the project, feel free. I would
request that you change the name, to avoid confusion.
Steven Robertson
>
> If anyone is interested in forking the project, feel free. I would
> request that you change the name, to avoid confusion.
Well, then.
Here's what I propose:
I've created a branch[1] on BitBucket based on SVN trunk, temporarily
named 'quodlibet-testing'. If Joe is okay with it, we'll continue to
use QL's existing infrastructure (issue tracker, mailing list, wiki)
while preparing a first release. Once we've gathered enough fixes and
enhancements to warrant a release, we'll go through with the name
change as a last step.
[1] http://bitbucket.org/srobertson/quodlibet-testing/
I chose BitBucket because it is the most commonly used hosting site
for Mercurial repositories, and I chose Mercurial because the MQ
extension, bundled with all current versions, provides tools which
will ease the workflow of adding and reviewing community-contributed
patches. Naturally, Mercurial is a DVCS, and the project maintainers
will respond to pull requests if a change is large enough to warrant
its own branch, but submitting individual patches attached to issues
is expected to remain the preferred way to get code in.
I'd like to avoid merging any major API or behavioral changes until
after the first release of the new project in order to preserve
compatibility with current SVN. I'd still like to avoid a fork if
possible, and this leaves the option of merging back into upstream
until the release procedures start.
I'm essentially electing myself as maintainer of the branch for now,
but if the branch does become a true fork I will actively recruit
contributors to become maintainers with equal admin rights in order to
ensure that the fork never falls over if one person gets too busy.
Let's make our favorite music player even better.
Steven
Fergus Bremner
Looking forward to moving ahead - huge potential.
With that in mind, should we not set up a wiki/forum? Somewhere at
least to map new directions.
-fergus
Fergus Bremner
-F
NickB
>
> I chose BitBucket because it is the most commonly used hosting site
> for Mercurial repositories, and I chose Mercurial because the MQ
> extension, bundled with all current versions, provides tools which
> will ease the workflow of adding and reviewing community-contributed
> patches.
so am interested to get to use it). MQ extension sounds useful here
too..
> Let's make our favorite music player even better.
Nick
Christine
I'm one of the Debian maintainers of Quod Libet, and I'd like to put
some time into lowering the bug count for Quod Libet and its plugins
in Debian. This involves sorting through a few patches, especially on
the plugins side of things. Is the right place to send patches the
community / testing branch mentioned here, or the official repo? I've
committed Debian plugin patches to the official quodlibet repo before,
but I'm a bit confused as to what Joe means by the community being
welcome to fork. Are contributors who are members of the quodlibet
project on the official Google Code site not welcome to contribute? Or
is it that Joe won't add new members and doesn't have time to review
patches right now?
later,
Christine
Steven Robertson
Joe has said on IRC that he's not interested in giving commit access
to other members, and has been too busy to review patches. I'd prefer
to avoid a fork and rename, if possible, so for now patches should go
to the Google Code bug tracker. I'll pick up those patches and include
them in my branch. Before a fork comes to pass, I'll contact you and
other packagers of QL so that we can create a smooth transition.
HTH,
Steven
Steven Robertson
Joe Wreschnig has agreed to allow the community to continue
maintaining Quod Libet, rather than requiring a fork. A few details:
* The Google Code project will remain the home of Quod Libet
development. I'll set up a Mercurial repository there soon with a full
SVN import of the original history. Please note that this will be a
different repository than the one at quodlibet-testing, and changes
will be merged in manually.
* Mutagen has become a separate project, and will be maintained by Joe
Wreschnig and Michael Urman. http://code.google.com/p/mutagen/
* A 2.0.1 release will happen shortly, containing only fixes and minor
enhancements from 2.0.
If you would like to become a project member, granting wiki and issue
tracker access, let me know.
Thanks,
Steven
P.S. I may change my visible Google Code account name to
ste...@strobe.cc. The old address will continue to work.
A. Christine Spang
>
> Hey all,
>
> Joe Wreschnig has agreed to allow the community to continue
> maintaining Quod Libet, rather than requiring a fork. A few details:
Rock on dude. I've been wanting to help out with bugs since I have
commit access to the old svn repository, but really didn't want to be
the only one pushing stuff back to the main repo, especially as it
seemed like most actual progress was happening in quodlibet-testing.
What can we (others) do to best help out from now on?
cheers,
Christine
Steven Robertson
> What can we (others) do to best help out from now on?
I think we should focus on getting a bugfix release out the door. We
should then set up a release schedule, make a feature plan for 2.1,
and implement it.
While that happens, we should also consider the organization of the
project. I'm fine with the model from quodlibet-testing, where I
commit small fixes directly, and large code changes (both by myself
and other community members) are discussed on the issue tracker before
commit; I would also be entirely open to a more formal process, where
multiple maintainers have commit access and all changes would be
subject to a code review before commit, or really any other reasonable
suggestion.
On Mon, Jun 15, 2009 at 2:09 PM, Nick B<ni...@propertwisted.com> wrote:
> I guess that's good news then. Though what becomes of the bitbucket site?
> I'm a little worried that with so many branches, repositories and so on...
The goal for the BB site was to help reinvigorate QL development. It's
largely served that purpose. Local-only issues on BB will be migrated
to GC's issue tracker, and then after a while the BB site will be shut
down.
Thanks for your help!
Steven
Tobias
I find this outcome really thrilling. QL has languished for too long.
Props to you for picking up the baton and to Joe for handing it over.
Please wield it wisely so that QL will retain its unique strengths.
Too many players on free desktops delve into featureitis but neglect
the basics. But since I’ve seen how reliable the gapless playback
patch has turned out I’m hopeful for a great future.
*Toast*
--Tobias
On Jun 15, 7:29 pm, Steven Robertson <r...@parseit.org> wrote:
> Hey all,
>
> Joe Wreschnig has agreed to allow the community to continue
> maintaining Quod Libet, rather than requiring a fork. A few details:
>
> * The Google Code project will remain the home of Quod Libet
> development. I'll set up a Mercurial repository there soon with a full
> SVN import of the original history. Please note that this will be a
> different repository than the one at quodlibet-testing, and changes
> will be merged in manually.
>
> * Mutagen has become a separate project, and will be maintained by Joe