[vlc-devel] Open Source Media Player Collaboration.

[compn]

On Mon, 30 Jun 2008 11:52:14 +0200, Just an Illusion wrote:
>Hello, I am not agree with the Rémi conclusion.
>
>Technically this is possible, but that require many constraints on 
>developers way of work.
>E.g : all the code architecture must be fully specify to quickly have a 
>program features overview.
>With this overview, it is possible to identify which part of code (aka 
>module) is mainly limited to codec and demux features.
>And developers can easily identify which part of code they need modify 
>(with which limitation).

i just assumed that codecs and demuxers were different files in the various projects. that each file's commits could be sent to a different list, like mplayer-docs for documentation changes.

>
>If this part of code is well identify, and if developers follow the 
>application code architecture, then it is possible to flag that module 
>as 'codec' or 'demuxer' features and demand the send any commits to a 
>'sub-mailing list' as [vlc-devel], [vlc-doc], [streaming],... which are 
>'sub-mailing list' of [vlc] (the full project).
>
>The last requirement, but not the least :
>If we want than any improvement can be shared with others projects, then 
>any code modifications must be documented (not approved or accepted but 
>really documented) and not only thru code reading interpretation (this 
>is time consuming, error prone and perhaps not adapted to the new target 
>: code coding rules, code architecture,...), typical useful information 
>for code sharing can be :
>- Which modify feature ? e.g. : h.264 protocol, Mpeg 1-4 reading and 
>broadcasting,...
>- Why modify feature ? e.g. : bug reference, feature bad implementation 
>description, specification reference (with short interpretation, if 
>any), current alternatives if any
>- How modify feature ? e.g. : which part of code, way of 
>implementation/coding, which coding rules, performance feature analysis, 
>known limitations. In old days that was the 'functional code analysis', 
>and that can be useful for [vlc-doc] sub-mailing list.
>- How testing feature ? e.g. : user case for bug, user case used to 
>check/test modifications. That is very useful in case of bug to help in 
>quick bug origin detection (and non regression testing improvement)

yes, this would be the ideal way to do it. but i wasnt hoping to change
all projects to unify the commit messages or anything. it would be too
much work. 

maybe it is too unrealistic. perhapse just sharing the user samples between
projects will achieve the same goal.

-compn