Hi Arlo, Thank you for your feedback, and you are right, it can be very hard to stay in sync with the bleeding edge of FreeRDP. In this case, the stable branch of FreeRDP may be better suited for you. If you base your work on the stable branch, you won't be getting new features as as fast as they keep coming in the master branch, but at least you will be able to work on top of a non-moving target which is the core of the issue here. I totally get your point and you're not the first one to bring that up, the compromise we came up with was the stable branch and it's been working very well for HP contributions. The problem was exactly what you are describing.
As for RDP8 features, please let us know when you have code like that sitting on a branch somewhere! It's not the first time I manually integrate large contributions that are received in all sorts of states. The more closely we can work together the easier it is for us to help with the integration. For instance, the original libfreerdp-primitives contribution from HP was not in a state which could be merged without breaking portability for most non-Linux platforms. I spent a whole weekend cleaning it up, improving the cmake scripts, testing on non-Windows platforms and making sure it wouldn't break things for other people when I finally merged it in master. Oftentimes we can't expect developers to really know the side effect of their code in terms of portability, and we can't blame them, there's just so much to think about. I think the contribution that came in the worst possible state was the original TS Gateway code. It was a tarball in an email with version control history removed, so I had to proceed with making a diff of the source trees and manually integrating bits of code. I still did it, and here we are today. When we originally got the contribution for USB redirection, I originally left it in a branch because it required some extra work avoid breaking the build on many platforms. It took some time before it found its way into master, but I eventually merged it after it was modified to build properly only when enabled on platforms where it was supported and after dependencies were detected. This being said, I would more than glad to take a look at your code and help integrating it myself just like I often did in the past for major contributions :) What do you think? Best regards, - Marc-Andre On Wed, Oct 23, 2013 at 3:11 PM, Arlo Liu <arlo....@atrustcorp.com> wrote: > There are something I want to talk. > I and my company really want to push back many bug fix and new features > back to FreeRDP (like we did with USB redirection). But there is a big > issue that cause us stop to merge code to FreeRDP mainline. You guys change > API and architecture too often. > > The first time that we found that it's hard to merge code back is FreeRDP > change to use WinPR (lacks functional and unstable at that time). So we > decide to take lots of time to merge our code base to keep update with > mainline, but we found you changed API again when we finished the merge > work. And not just API, it seems you prefer to put some very experiential > or even not completed feature to mainline instead of development branch. > > After 2~3 times we try to sync our code base with mainline, we give up > finally, even we already preapred some bug fix/feature patch like serial > redirection, RD gateway...etc, which want to push back to community. > > I'm not saying that the new features is not cool (it is), but if it's an > open project which want to let many developers collaborate with it, it > might needs to consider the consistency of core API, backward compatibility > and the essential quality of commit (or, at least do not push a single > commit with so many modification). > > For example, we can't push some RDP 8.x feature like GFX, VOR back to > mainline. It's not just because that we need to spend lots of time for > porting task, the more major issue is because we found the architecture of > mainline changed a lot, and we can't not just add a new VC extension with > modify current architecture. > > > > > 2013/10/24 Marc-André Moreau <marcandre.mor...@gmail.com> > >> Hi Vic, >> >> Thank you for your support, and you do summarize well the situation. >> >> We have always been very inclusive of people's contributions and always >> will be. As for enjoying the new code without complaining and fixing >> problems which bother you, that's pretty much how this should be >> approached. I've had numerous conversations similar to this with >> developers >> from HP in the past until they figured out that the best way to approach >> this is to do exactly like Vic said: enjoy the code, fix what bothers you, >> we'll give you the space that you need and make sure to integrate it as >> much as possible. Daryl can probably tell you about that ;) You need a >> stable branch where you can develop on top of a non-moving target? I >> totally understand the need for that, and I've never been against it, >> that's why we have the stable branch. Luckily we have volunteers who spend >> time maintaining that branch to make it truly useful and frequently >> backport fixes from master to it. We found out through experience that >> using master the way it is with a separate stable branch that we can >> frequently backport fixes to is a lot easier than trying to use master as >> a >> stable branch. >> >> While all of this discussion is happening, there are people working on >> improving the state of certain features which have been discussed (serial >> and smartcard). Instead of complaining that they're not working, how about >> just working on fixing them with the others? It's funny how those >> developers actively working on fixing what is causing all of these >> complaints are not actively involved in this conversation. Maybe we should >> take their example, less complaining, more fixing and coding, that's how >> things move forward. >> >> Best regards, >> - Marc-Andre >> >> >> On Wed, Oct 23, 2013 at 10:56 AM, Vic Lee <llyzs....@gmail.com> wrote: >> >> > Hi Jay, >> > >> > I am sorry you feel that way. I still remember when you and Marc invited >> > me to leave rdesktop and join FreeRDP because rdesktop was controlled by >> > Cendio and refused any architetural changes even they were useful or >> > necessary. And Marc said FreeRDP would be much more open. This has been >> > true until now, and I believe it will be always true in the project. I >> > really don't feel it has been taken over by any group of people like >> > Cendio in any way - anybody from anywhere are still always welcome to >> > contribute, I am sure Marc agrees. >> > >> > Regarding the topic: yes lack of stable release control is an issue. >> > Often when I merged master in order to use some new feature I would also >> > have all kinds of problems, but I usually just fix them myself, and >> > enjoy the new codes instead of complaining... Marc has made the point, >> > stable release control requires a lot of manpower, and it's even more >> > difficult for such a fast-evolving technology. >> > >> > Speaking of architetural changes, sometimes you don't see benefits of >> > something when you are not using it yet. I was also skeptical about >> > WinPR, felt it was way too much effort for little value, until when I >> > moved to cross-platform development I saw the idea behind and the >> > advantages, and even start to contribute to it. >> > >> > Let's stay a healthy community and not let such differences ruin us. I >> > am sure a solution will eventually come out, and we should focus on >> > working on solutions instead of falling apart. >> > >> > Thanks, >> > >> > Vic >> > >> > On Wednesday, October 23, 2013 03:48 PM, Jay Sorg wrote: >> > > When we are talking about this, you mention Thinstuff. >> > > >> > > What do I think? >> > > >> > > I left rdesktop in Peter's control and Cendio took over. >> > > I left FreeRDP is your control and Thinstuff took over. >> > > >> > > You need to fix this! >> > > >> > > Jay >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > 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 >> > >> >> ------------------------------------------------------------------------------ >> 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 >> > > > > -- > Arlo Liu > Atrust Computer Corp. > http://www.atrustcorp.com > Tel: +886-3-3288837 ext.71 > Fax: +886-3-3288973 > 3F., No.361, Fusing 1st Rd., Gueishan Township, Taoyuan County 333, Taiwan > ------------------------------------------------------------------------------ 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
