Hi Otavio, 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.
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. 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. 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. Best regards, - Marc-Andre On Tue, Oct 22, 2013 at 11:51 AM, Otavio Salvador <ota...@ossystems.com.br>wrote: > Hello Bernhard, > > First I'd like to make clear it is not a criticism per si, but a > constructive critic. > > On Tue, Oct 22, 2013 at 1:37 PM, Bernhard Miklautz > <bmikla...@thinstuff.at> wrote: > > as Marc-Andre already said we are short on time and man power. > > Since the last release a lot of new features and clients where added, > > the code base and functionality is growing. > > > > One really big and hard problem we face is the complexity of RDP. It > > ain't an easy job to test all features. Think about it - we support a > > couple of architectures and operating systems on the client side > > (windows, linux, mac, i386, amd64) and there are a lot of different > > windows version to test. To setup, prepare and keep a proper test > > environment running is also a big, time consuming, task. > > I fully agree; so it seems it is the time to stop accepting new > features and clean up the current ones. If we keep adding more and > more code on top of it, it makes it harder and harder to stabilize. > > > On Tue, Oct 22, 2013 at 09:54:26AM -0200, Otavio Salvador wrote: > >> Personally I've been having a lot of issues with FreeRDP with features > >> not working file (serial redirection, smart card redirection and so > >> on) which worked fine in 0.9 (yes, the GPL released one) and this has > >> been a blocking issue for me. > > I personally haven't used 0.9 (jumped the train later on ;) so I don't > > know how good things where with 0.9. Are there any specifc issues you > > are refering too? > > > > For smart card there is ongoing work: > > > > https://github.com/akallabeth/FreeRDP.git branch smartcard_context_fix > > > > It contains a lot of fixes and improvements (that will also go into 1.1 > > once merged). Serial should work - at least the tests I do work. > > In my point of view, this should be a priority as this is a constant > source of problems and the better we have it, more users we'll get. > > >> What are the plans regarding 1.1? 1.2? > >> > >> I'd prefer a less feature-rich release but a more reliable one than > >> that many non-finished "next big thing but never done" releases. > > Totally agree with you, better a reliable and working release then half > working > > things or nothing at all. Thats why we recently created stable-1.1 it's > aimed to be the > > next stable release. We are trying to keep to keep the API stable and > > only merge back bug fixes and performance enhancements from master and > > fix issues. > > > > For 1.1 the plan is to get it out as soon as we can ;). We don't have > > an fixed schedule - basically we will release when we've > > managed to resolve all open issues assigned to 1.1 (currently 136) and > > try to do betas on a regular base. > > Once again; I'd freeze master and be strict about accepting new code. > FreeRDP is quite active but the flux of code is adding more and more > features. It is not doing it right as it brings a lot of regressions. > > When I were more active to FreeRDP I once proposed we use branches for > stabilization of work and merge them on master just after it has no > known issues. It never happened... > > > Since we haven't released for a while most distributions contain an > > rather old version of FreeRDP which makes it also hard for people to > > user newer versions and help us test - they would need to build it > > themselves. Therefore we are currently also work nightly package builds > > for the most widespread distributions. Also have a look on > > https://ci.freerdp.com (if you haven't seen it already). > > Yes and people will be more and more afraid of update; it won't be an > upgrade but a different product and radically change its use. This is > the optimal way of making Free Software in my opinion. > > As well covered by Eric S. Raymond, in his Cathedral and the Bazaar > book: Release early. Release often. And listen to your customers. > > > If someone wants to help: > > > > * Do Test and file issues ( > https://github.com/FreeRDP/FreeRDP/wiki/BugReporting) > > * Fix issues (https://github.com/FreeRDP/FreeRDP/issues) > > * Help us with documentation > > * Support us with test environments we can test against > > * Help us to improve our tests and testing infrastructure > > > > So a lot of good things are going on... and I'm personally not really > > concerned about the future of FreeRDP - If we stay a small "army" things > > take longer but will happen at some point. > > My fear is that 'some point' may be too late... > > Regards, > > -- > 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 > ------------------------------------------------------------------------------ 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
