Hi,
On Thu, Oct 24, 2013 at 09:24:56AM +0000, Javid Nia / Mod2 Inc. wrote: > As a user of freerdp project and a fellow software developer I want to thank > the code writers behind freerdp. We all know it takes a serious amount of > time to write quality software. Rome was not built in one day. Thank you :). I just want to add a thanks on my side for all the people that got FreeRDP started and already put so much effort in it. It's funny I always tried to escape the MS world somehow but RDP kept following me and I really do like FreeRDP :). On Wed, Oct 23, 2013 at 05:59:36PM -0400, Marc-André Moreau wrote: > I will make myself available for a conference call to answer all of the > questions community members might have. Just contact me and we should be > able to schedule something as soon as possible. count me in. I also really do like Brians idea about having a conference call or something similar to discuss this. A lot of the problems that were addressed, thinking of stability, API changes and release management are absolutely true and it's about time that they get solved. Therefore I think instead of spending our time on blaming, flaming and talking about what went wrong we should get our heads together, bring this discussion back to a professional level and try to address and solve the currently open problems concerning FreeRDP. And most important of all make sure these don't happen again in the future. What do you think? To get started, here are the, hopefully constructive, things I have personally pulled out of the recent mails. Please feel free to add more or correct them. Main problem: '''current development model is not really optimal''' Ideas: 1) stable, not changing API * stable-x.y branches can be used for that ** should only get fixes, stability and performance improvements ** no new features ** no API changes ** have defined rules what is accepted and what isn't While developing it always will happen that an APIs change. To reflect that we should do better version numbering like other oss projects do. https://github.com/FreeRDP/FreeRDP/wiki/Release-Guide#versioning It would also make sense that big changes are discussed on the mailing list up front or that these kind of pull requests are at least reviewed and checked by two other developers. master would stay the bleeding edge where all of the new stuff goes in. 2) Stability of "subsystems" Development should also be more focused on the stability of single subsystems. When fixing bugs it is sometimes rather hard if you work on a "subsystem" (like channels, smartcard, serial, cache) because they are often really complex, and it takes time to get into them (especially the first time). I often find myself fixing a bug and not being 100% sure if this is really brings the desired result for all cases since I don't use the "subsystem" often or do not have the right use case for it. To solve/improve this I'd suggest that we choose a responsible person for a subsystem, similar like the linux kernel does with maintainers. The responsible person should have a good overview and know how it works and is used and also has some test setup in place. This might also improve communication and bug fixing since one knows who to ask and talk to. We should also adapt this approach for the stable branches and have one person responsible to take care. The subsystems/responsibilities could look like the following: * stable-1.0 * stable-1.1 * core * channels ** smart card ** serial ** sound ** clipboard ** drive ** tsmf ** usb ** printer ** parallel * clients ** x11 ** ios ** android ** mac ** windows * documentation * build system 3) Licensing Put together a clear and understandable licensing policy that explains why it is like it is and also what is possible and what is not. 4) Testing and QA This is probably the most important and most complex chunk. For hardware related functionality automated testing or unit tests are really time comsuming and sometimes almost impossible todo. Here we should really define (manual) test procedures that need to be done before we consider stable and working. This already got started: https://github.com/awakecoding/FreeRDP-Manuals/blob/master/Testing/FreeRDP-Testing-Manual.markdown Still really basic and limited. I've also some check list around that we do before releasing aFreeRDP or iFreeRDP which I would add. For the testing we also need proper use cases and test environments from people that use one feature. @Otavio if I'm not mistaken you do use serial a lot could you provide some information how one can properly test it's functionality or do you even have some test list in place? With all of this keep in mind that it's an open source project and therefore dependant on the community and volunteers. I'd really like to get your feedback and help on the above ideas that we can improve and implement them together. Thank you, Bernhard ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
