On Tue, Oct 22, 2013 at 2:34 PM, Marc-André Moreau <marcandre.mor...@gmail.com> wrote: > I understand that this is constructive criticism, the issue is mostly with > the fact that one cannot realistically do what you suggest. Freezing master > is not an option, which is why we've made a stabilization branch: the code > there is simply stabilized over time with no breaking changes, while master > can remain what it's always been. As for listening to my customers, it's > pretty much what I've been doing for the last 5 years: people pay for > features and nobody wants to pay for tests, bug fixes which aren't blockers > to them, and general work which helps others but not them. In the end of the > day, what most people truly want is code that works for them and will remain > stable over time, they don't have the time to work in areas which doesn't > directly benefit to them unless they are highly passionate about it and can > spend some of their free time doing extra work for fun. Let's just say I > have done a VERY large amount of unpaid work on this project over the years > and cannot afford to do as much as I used to be. It's funny how certain > features simply don't fix or complete themselves when I'm not working on > them. Wishful thinking consistently fails me for some reason.
Well this is how most Free Software projects work. In this case you might start pushing your customers to pay for your time to stabilize the new code for merging, as part of the project. > However, what you are getting is mostly an emotional reaction: if we *had* > the time to do more things right, then of course we would have frequent > stable releases, more documentation, more API stability, more support, more > whatever you want. The problem is that there is only 24 hours in a day and > all that would be required in unpaid work is enough for a couple full time > employees. You can definitely ask that we do all of this and then say later > you've warned us we should have done it, it doesn't change the fact that we > simply don't have enough resources to do it and still have features to > implement because our customers and community members need them for their > specific projects. We've resisted most of RDP8 doing a lot of stabilization > work and optimization, and now we've got some catching up to do. With the > new Microsoft RDP clients released, we have no choice but to move on to at > least starting portions of RDP8 and even RDP8.1 in master. This is pretty > much why we could never freeze master, because there are too many people who > actually need to be working on the bleeding edge of FreeRDP. It's not a > matter of choice, it's a matter of keeping up with the competition. If they > have it, then we've got to have it as well, and do it even better. We're not keeping up with competition. In competition SmartCard redirection work; Serial work, Parallel Work. > Getting people to understand that open source doesn't mean there's a whole > team of unpaid employees at your disposal takes time, but as silly as it > sounds, it's still true. As an example, a lot of the complaints you're > having now, I've had them from developers at HP. Getting the stable-1.1 > branch in place worked very well and they're using it and often contributing > bug fixes. I can say I am quite satisfied now how we operate with them. > Maybe you should follow their example and start using the stable-1.1 branch > as well. If there are specific blocking issues that prevent you from > upgrading and nobody is working on fixing them, then please allocate some > resources on them. At least you have the assurance that the stable-1.1 is > not a moving target, it's a stabilizing target. No; I am getting out of RDP business. I allocated a lot of resources for FreeRDP in past and this didn't pay itself so it is a no-go for now at this moment. > So, to summarize: the stable-1.1 is what you're looking for. For blocking > issues you might have that nobody is working on, we're not free employees, > which means you can either wait forever until somebody takes the time to fix > it for free or you can allocate resources to fix it. We will gladly merge > your bug fixes, but we just don't have time to do free support 24/7 (and > even if we had, there are too many issues to cover). The master branch is > often used by people who need the bleeding edge of FreeRDP and can afford > some occasional instability that is often fixed within a few days. I guess > you could compare master to debian sid and the stable branch to the current > debian stable release. You need debian stable, a lot of people need debian > sid, and you can't tell people who need debian sid that they need debian > stable just like they can't tell you you need debian sid. Marc-Andre, seriously ... stop to justify things and claim there're no way of doing it better. It always have better ways of doing things, it is just a matter of finding it. I started this discussion to find better ways, not excuses. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ------------------------------------------------------------------------------ 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
