Re: cmus-ng? Friendly cmus takeover? (was: [PATCH] Fix possible double free inside http_free_uri)

[Jason W. <ja...@ja...>]

A friendly takover would be lovely. Guess I assumed that wasn't
possible, but I think it's worth a try. Also I suspect there's
something more we could to to try to find Timo, or at least what
happened to him.

Thanks Frank for your reply, I think I agree with everything you said.
I put up your subset of Timo's TODO list on the on the github wiki
attached to cmus-unofficial so we can find it easily, and make
updates.


On Fri, May 29, 2009 at 5:22 AM, Frank Terbeck <ft...@be...> wrote:
> Jason Woofenden <ja...@ja...>:
>> Frank Terbeck <ft...@be...> wrote:
>> > Jason Woofenden <jas...@he...>:
>> > [...]
>> >> Speaking of hopes... I'd love it if someone would fix the "i" key when
>> >> the current song was pulled from the queue.
>> >
>> > If I understand you correctly, that has been discussed before.
>> >
>> > And I always thought it was quite a nifty feature, that you could tell
>> > where the playback would continue when the queue has run out of
>> > entries... IIRC, Timo agreed.
>>
>> Huh... I missed that discussion, but saw something on Timo's todo list
>> about fixing the 'i' key.
>
> Yeah, that's where it got discussed, too:
>
> [snip]
> } > > Fix the "currently playing file not highlighted" bug when using queue
> } > > - must store the view the track came from
> } >
> } > Is this really a bug?
> } > I always found it was a feature, that I could play a queue and switch
> } > back to the library, to see where cmus would continue playback once
> } > the queue is empty.
> }
> } Just to make clear: I didn't mean we should change position of the
> } library view (for example) every time we take track from queue.
> }
> } If _last_ track from queue has been played and the track came from the
> } view we are playing from (according to play_library and play_sorted)
> } then we should play the track after the queued track. Otherwise use the
> } old logic.
> }
> } In practice this would mean that if you play from library and shuffle is
> } off and you queue first track of a album then playing continues from
> } second track of the album. This would be very useful for me at least.
> [snap]
>
>> > If someone changes this, make it optional - pretty please.
>>
>> I'd suggest making the i key go to the currently playing song, and add
>> another key that goes to the song that'll play after the queue. Maybe
>> shift-i.
>
> 'shift-i' aka. 'I' is taken.
> New features should get a new binding. 'T' for example, which servers
> as a mnemonic for Track, too - and it's not taken by default, AFAIK.
>
> [...]
>> > b) hosting/website/bugtracker/mailinglists/$other_work:
>> >    Are people actually willing to put enough work into this to make
>> >    such major changes worthwhile? Are there people out there to work
>> >    with the code to become familiar enough with to eventually fix
>> >    longstanding shortcomings in cmus? (Timo's TODO list comes to
>> >    mind.)
>>
>> Good point, we don't want to create systems that create work in
>> maintaining them, or that are oversized for our project. Now that you
>> mention it, a bugtracker seems like overkill. A contact form would
>> probably be much better. I can make a php one in 60 seconds.
>
> A form that sends bug reports to the mailing list would probably be a
> good idea, yes.
>
> [...]
>> I don't think cmus needs loads more features. It already has features
>> that many complex graphical players like iTunes lack, like a queue,
>> and replaygain support for vorbis files (that's the feature I was
>> looking for when I tried cmus).
>
> Yes, it really doesn't need many more features.
> But important bits like this from Timo's TODO are vital to be tackled
> one day:
>
> [snip]
> } Reduce locking mess
> } - make most of the code look like single threaded program by locking
> }   editable_mutex in main thread and worker when needed
> } - rename editable_mutex to main_mutex
> } - worker should buffer a few track_infos, lock the mutex and add all
> }   buffered tracks at once
> } [...]
> } Better format strings
> } - conditionals
> } - deprecate altformat_*
> }
> } Better command line parser (lots of work, breaks compatibility)
> } - shell compatible escaping
> } - allows binding multiple commands to one key
> } [...]
> } Much simplified player core
> } - producer/consumer split was stupid idea
> } - single threaded code would work better with simple buffer instead of
> }   array of smaller buffers
> } - communicate with main thread using pipe or unnamed socket (insane?)
> } * no shared data => no mutexes
> } * single select() in player thread instead of pthread conditional
> }   with timeout _and_ select() => no wake-ups!
> } * setting player options (especially plugin options) would be hard
> [snap]
>
>
>> I just want to have some kind of presence on the web that says "Hey,
>> welcome, we're the cmus-ng team. Here's the latest source code, here's
>> where you ask questions, send comments, patches, etc.". Could be just
>> one page with links to the mailing list, repo, and maybe a wiki and/or
>> contact form.
>>
>> I could slap together such a page an hour next week if we agree on:
>>
>> 1) It's a good idea
>>
>> 2) a new name. (cmus-ng sound good to everybody?)
>>
>> 3) our web address (cmus-ng.bamph.org?)
>
> Well, I was about to say I'm in favour of this, but when I take this
> reply into account:
>
> "a.l.e" <ale...@xo...>:
>> [...]
>> also, the archive on this list is long enough: i would try to contact
>> the people at sourceforge and ask them to give the access of this list
>> and the other ressources to the current maintainers.
>>
>> they own the archives, so they can check that this is a friendly take
>> over of an abandoned project.
>
> Really good point.
> A "friendly takeover" would probably be the best solution. That would
> also take care of the point of "market penetration" with respect to
> availability in mainstream OS distributions.
>
>> trying to get physically in contact with timo may also be a good idea...
>
> Well, unless someone knows Timo personally, that would be kind of
> hard; because there's more than one "Timo Hirvonen" in Finland. :)
>
>
> So, Jason, before you put energy into 'cmus-ng', would you see about
> asking sf.net to take over cmus for good?
>
> Also, sf.net has git repositories nowadays, so we'd only need some
> webspace to host the cmus.sf.net redirection. Mailinglist, VCS and
> even Bugtracker would have been taken care of. (That being said, I
> don't know - maybe sf.net even offers a limited amount of webspace,
> which could be enough for a small website such as the cmus page.)
>
> If you look at it, there are even entries in the sf.net bug tracker.
> But nobody ever bothered to take care of them, so a tracker manager
> would be a position the project could use. Someone who mediates
> between the website and the mailing list.
>
> Regards, Frank - who is strongly in favour of a take over, if that's
>                 humanly possible...
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> cmus-devel mailing list
> cmu...@li...
> https://lists.sourceforge.net/lists/listinfo/cmus-devel
>
>