subject:"Re\: \[FreeRDP\-devel\] Stable release"

Re: [FreeRDP-devel] Stable release

2016-01-12 Thread Niklas Andersson

Thanks tons for your work Bernhard,

  Out or curiosity - are these nightly builds based on FreeRDPmaster? I 
couldn't see any tags with 2.0 on Github.

  Also, do you plan to tag a 2.0 build for inclusion in Debian?

Best regards and thanks,
Niklas

On 11/01/16 10:45, Bernhard Miklautz wrote:
> Hi,
>
> On Mon, Jan 11, 2016 at 08:56:44AM +0100, Valerio Pachera wrote:
>> 2016-01-11 8:55 GMT+01:00 Valerio Pachera :
>>> apt-get update
>>>
>>> Err http://pub.freerdp.com freerdp-nightly/main i386 Packages
>>>404  Not Found [IP: 212.232.26.215 80]
>>>
>>> The repository
>>>
>> I was writing that the repository is not working right now.
>> I tried on a debian wheezy and a jessie.
> For me the error looks like the repo wasn't added correctly to the
> sources list. Whats your exact entry?
> For wheezy this should be:
>
> deb http://pub.freerdp.com/repositories/deb/wheezy/ freerdp-nightly main
>
> You get the apt key like
> wget -O - http://pub.freerdp.com/repositories/ADD6BF6D97CE5D8D.asc | sudo 
> apt-key add -
>
> Best regards,
> Bernhard
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> FreeRDP-devel mailing list
> FreeRDP-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freerdp-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

2016-01-12 Thread Bernhard Miklautz

Hi,

On Tue, Jan 12, 2016 at 12:34:08PM +0100, Niklas Andersson wrote:
>   Out or curiosity - are these nightly builds based on FreeRDPmaster? I 
> couldn't see any tags with 2.0 on Github.
the nightly builds are based on master which is the base for 2.0.

>   Also, do you plan to tag a 2.0 build for inclusion in Debian?
At some point there will be a 2.0 tag for sure. But at the moment we are
preparing the package based on a snapshot of master.

Best regards,
Bernhard

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

2016-01-11 Thread Valerio Pachera

2015-12-18 16:50 GMT+01:00 Bernhard Miklautz 
:

> For users and for testing we do have nightly pre-builds for some time:
>
> https://github.com/FreeRDP/FreeRDP/wiki/PreBuilds
>


apt-get update

Err http://pub.freerdp.com freerdp-nightly/main i386 Packages
  404  Not Found [IP: 212.232.26.215 80]

The repository
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

2016-01-11 Thread Valerio Pachera

2016-01-11 8:55 GMT+01:00 Valerio Pachera :

>
>
> apt-get update
>
> Err http://pub.freerdp.com freerdp-nightly/main i386 Packages
>   404  Not Found [IP: 212.232.26.215 80]
>
> The repository
>

I was writing that the repository is not working right now.
I tried on a debian wheezy and a jessie.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

2016-01-11 Thread Bernhard Miklautz

Hi,

On Mon, Jan 11, 2016 at 08:56:44AM +0100, Valerio Pachera wrote:
> 2016-01-11 8:55 GMT+01:00 Valerio Pachera :
> > apt-get update
> >
> > Err http://pub.freerdp.com freerdp-nightly/main i386 Packages
> >   404  Not Found [IP: 212.232.26.215 80]
> >
> > The repository
> >
> 
> I was writing that the repository is not working right now.
> I tried on a debian wheezy and a jessie.
For me the error looks like the repo wasn't added correctly to the
sources list. Whats your exact entry?
For wheezy this should be:

deb http://pub.freerdp.com/repositories/deb/wheezy/ freerdp-nightly main 

You get the apt key like
wget -O - http://pub.freerdp.com/repositories/ADD6BF6D97CE5D8D.asc | sudo 
apt-key add -

Best regards,
Bernhard

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

2015-12-18 Thread Bernhard Miklautz

Hi,

On Fri, Dec 18, 2015 at 04:12:47PM +0100, Valerio Pachera wrote:
> Hi, I opned a bug report to point out that the last stable release is more
> than 2 years old and that many commit has been pushed since then.
> https://github.com/FreeRDP/FreeRDP/issues/3008
.. there are multiple issues open regarding a new release. We are aware
that there wasn't a release for a, let's say, *while* ;).

> Could you tell me why you dind't relase 1.2 release after so much effort.
This had multiple reasons. First of the release version number 1.2 wasn't
particularly chosen very well. In comparison to 1.1 it had rather big
changes including the API(s). This made it really hard for developers
and packagers. Secondly we split of the stable-1.1 branch but as
development was still focused on master and no one had time to do the
final finish and stabilizing it was let laying around and later it
was already quite outdated. There are some other reasons but those are the
most important.

> I saw you are also working on version 2 of freerdp but may versione 1.2 be
> released meanwhile?
As far as I can tell there won't be any release of the 1.1 or 1.2
branch. Between 1.1+ and the current 2.0 branch a lot of effort was
put into stabilizing, code hardening and clean-ups so the master branch
is, even if we didn't draft an official release (yet), really stable and
I suggest using it. For users and for testing we do have nightly pre-builds for 
some time:

https://github.com/FreeRDP/FreeRDP/wiki/PreBuilds

There isn't any fixed release date for 2.0 but we are currently working
hard on stabilizing the API and getting it "ready".

Starting with 2.0 I hope we manage to do release more frequently.

Best regards,
Bernhard

--
___
FreeRDP-devel mailing list
FreeRDP-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-25 Thread Otavio Salvador

On Thu, Oct 24, 2013 at 10:01 AM, Bernhard Miklautz
bernhard.mikla...@shacknet.at wrote:
 @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?

Yes; we can help with how to test it, in case someone is going to work on this.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-24 Thread Javid Nia / Mod2 Inc .

Hi All:

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.

Javid nia





-Original Message-
From: Marc-André Moreau [mailto:marcandre.mor...@gmail.com]
Sent: Wednesday, October 23, 2013 3:00 PM
To: brian mullan
Cc: freerdp-devel
Subject: Re: [Freerdp-devel] Stable release

Hi Brian,

This is a good idea. It is clear that many community members have come to 
perceive things in ways that shouldn't be, and we need to fix that. This 
conversation has already degenerated enough and it's not helping anyone.

I just want to assure people there is no takeover, there is no conspiracy, we 
value community contributions and continue to remain very inclusive.

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.

Best regards,
- Marc-Andre


On Wed, Oct 23, 2013 at 4:41 PM, brian mullan bmullan.m...@gmail.comwrote:

 I don't have a stake in this very passionate discussion on the alias
 but with many years in the technical world I would suggest that Email
 is absolutely the worst way to talk out issues like this.

 Typing out emails leaves out context that a voice discussion could
 easily help facilitate.

 People misinterpret text they read forget to add some important
 background point to a msg they sent etc.

 I'm suggesting perhaps it would be useful for all of this to be
 discussed on a conference call where all of you can actively talk
 about these points and come to a meeting of the minds where everyone
 comes away an agreement they are satisfied with.

 This is a development alias but I'm not sure all of this thread was
 necessarily good for all of the company's mentioned nor the various
 projects that may/may not be in conflict ??

 I've always found it better to pound these types of disagreements out
 real-time in a phone conference.

 Just a suggestion...

 Brian

 --
  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=60135991iu=/4140/ostg.c
 lktrk ___
 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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel




This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Bernhard Miklautz

Hi,

On 10/23/2013 06:26 AM, Jay Sorg wrote:
 I'm concerned / confused about the future of FreeRDP.
 It seems like there is too many restructuring / refactoring of the
 source code that add no value.
 All the documentation on
 http://www.freerdp.com/api/
 is out of date.
True. Have a look to http://pub.freerdp.com/api/ - updated and
regenerated in something like 2 hour intervals. - The link just hasn't
made it to the freerdp.com page.

Best regards,
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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Jay Sorg

I'm sorry, you missed the point.

Jay


On Wed, Oct 23, 2013 at 12:27 AM, Bernhard Miklautz
bmikla...@thinstuff.at wrote:
 Hi,

 On 10/23/2013 06:26 AM, Jay Sorg wrote:
 I'm concerned / confused about the future of FreeRDP.
 It seems like there is too many restructuring / refactoring of the
 source code that add no value.
 All the documentation on
 http://www.freerdp.com/api/
 is out of date.
 True. Have a look to http://pub.freerdp.com/api/ - updated and
 regenerated in something like 2 hour intervals. - The link just hasn't
 made it to the freerdp.com page.

 Best regards,
 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Jay Sorg

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


On Tue, Oct 22, 2013 at 10:58 PM, Marc-André Moreau
marcandre.mor...@gmail.com wrote:
 Hi Jay,

 I understand you are not in agreement with certain architectural decisions.
 However, they are not adding no value to the FreeRDP project, they are
 quite useful. WinPR has greatly enhanced the portability and reusability of
 the code.

 As for the lots of complaints and developers being discouraged by this,
 give me a break. FreeRDP is not a Linux-centric project, it's an RDP-centric
 project, and it is designed to be as portable, flexible and modular as
 possible. Also, it is not a secret that the Microsoft Remote Desktop
 Protocol (RDP) is involves a lot of the Windows API being remoted, which  is
 why the WinPR approach feels natural. You may not like it, but that's still
 how we're doing it, and we can't make everybody happy at once.

 Regarding xrdp-ng, it was only a temporary name. We've chosen to name the
 project FreeRDS for FreeRDP Remote Desktop Services, and just like
 FreeRDP, it doesn't aim at being a Linux-centric project but a full blown
 cross-platform remote desktop services implementation. As for forking the
 project, I think we both know that we work at totally different speeds and
 that what Thinstuff and I need in the short term is fairly different from
 xrdp. If I were to make the major changes I've been doing in FreeRDS in xrdp
 you'd get a heart attack, as I know you wouldn't like most of it. No hard
 feelings, we're just working on our own project that fits our needs. It's
 something you're doing as well with NeutrinoRDP, the stabilization fork
 you're using with xrdp.

 It's not a competition, and I've never meant to insult you. I just need a
 project which is fairly different from what xrdp is. When I originally got
 started, I didn't have much imagination, so I just called it xrdp-ng.
 We've finally decided to name it FreeRDS as it will have nothing to do with
 xrdp in the future as it's taking a totally different direction. You already
 hate the WinPR approach, and that's exactly what FreeRDS is using now along
 with as much of FreeRDP as possible. Is it really such a bad thing that it's
 a separate project? It's a long term investment for us, as in total it's
 somewhere between 6 months to a year of development effort to get the first
 usable release of FreeRDS with enough features to be interesting. We've got
 customers who need this, that's why we're working on it, and we want it for
 ourselves as well because of its potential.

 What do you think?

 Best regards,
 - Marc-Andre


 On Wed, Oct 23, 2013 at 12:26 AM, Jay Sorg jay.s...@gmail.com wrote:

 I would like to express my concern too over the stability of FreeRDP.
 It was much better a year ago.

 I'm concerned / confused about the future of FreeRDP.
 It seems like there is too many restructuring / refactoring of the
 source code that add no value.
 All the documentation on
 http://www.freerdp.com/api/
 is out of date.

 Lack of help is the problem, but who wants to help?
 I hear a lot of complains about the windows'ish push.
 WinPR / window command line parameters / a registry on Linux.
 Talented Linux developers are discouraged by this.

 I'd have to say, I'm discouraged too.

 Another thing, with FreeRDP is such a bad state, why is this project
 forking my project xrdp?
 Why are you duplicating all the good work done on xrdp?
 And why call it xrdp-ng?  Are you suggesting you can do a better RDP
 Linux server?
 I find it quite insulting!

 I think there are some tough management issues that need to be addressed.

 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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Bernhard Miklautz

Hi Jay,

first of I'm truthfully sorry how it went with xrdp. Even if I wasn't
directly involved I absolutely understand you and also think some not
really right choices were made.. Sorry for that.

That said,

On 10/23/2013 09:48 AM, Jay Sorg wrote:
 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.
... what do you understand by took over?

Spending time on fixing bugs?
Trying to get new features in?
Spending money on improving OSS software?
Helping out users? 

I believe in FreeRDP and spent quite some of my spare time on it -
trying to fix bugs, help people, improve infrastructure,  
and I'm really lucky that my employer, Thinstuff, also shares the believes in 
FreeRDP and
that we are allowed to do some work on FreeRDP in our paid time.
A lot of things I do would not be possible for me otherwise.

Thinstuff didn't in *any* kind take over FreeRDP. To let me put this
straight Marc-Andre is the project lead and I (like any other Thinstuff
employee) isn't favoured in any way when working on FreeRDP. We don't dictate 
any
direction, we just regular contributors doing pull request and help on
other stuff. - For me that doesn't look like taking over?

On the other side, it's not a secret that we do and did projects together with
Marc-André and his company. If we do projects the by-product is most
of the time that something that was done ends up in FreeRDP since it's a
new feature or improvement even if it's just a trivial memory leak or
fix. - Still not seeing the take over point her.

Jay, I'm really happy and thankful that you and Marc-André started
FreeRDP but if you leave the project and not happy how it turned out
it's one thing. If you are unhappy how other things went thats the
other. On both, I really do see your point and respect this
but I also feel personally offended by public accusations that are 
just not right and true.
I know all of the people at Thinstuff and they are nice and good 
girls and boys and definately not with the intention, or mindset, 
of taking over an project.

This is just my personal opinion and has nothing todo with my employer.

Best regards,
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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Otavio Salvador

Hello folks,

On Wed, Oct 23, 2013 at 7:15 AM, Bernhard Miklautz
bmikla...@thinstuff.at wrote:
 first of I'm truthfully sorry how it went with xrdp. Even if I wasn't
 directly involved I absolutely understand you and also think some not
 really right choices were made.. Sorry for that.

I think Marc-Andre and ThinStuff need to step back and listen. Stop to
tell excuses and do an analysis of state points instead to justify
'your actions' learn from the feedback.

 On 10/23/2013 09:48 AM, Jay Sorg wrote:
 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.
 ... what do you understand by took over?

 Spending time on fixing bugs?
 Trying to get new features in?
 Spending money on improving OSS software?
 Helping out users?

Jay did it a lot. I did it a lot.

I stopped when I noticed FreeRDP will never be usable for me. My
product still uses FreeRDP 0.8+GIT (before rewrite) and it works more
or less but it is stable. FreeRDP suck in this aspect.

...
 Thinstuff didn't in *any* kind take over FreeRDP. To let me put this
 straight Marc-Andre is the project lead and I (like any other Thinstuff

Marc-Andre is very skilled but not to manage a project. FreeRDP
commitment from community reduced a lot and as he realized companies
are commited to their own needs and don't expend money to fix bugs
which they don't care about.

 employee) isn't favoured in any way when working on FreeRDP. We don't dictate 
 any
 direction, we just regular contributors doing pull request and help on
 other stuff. - For me that doesn't look like taking over?

Taking over can be of many forms. I don't know all the projects done
but Marc-Andre needs to ensure not only Thinstuff needs are
accomplished or it ends being a 'featureness-compliance takeover'.

 On the other side, it's not a secret that we do and did projects together with
 Marc-André and his company. If we do projects the by-product is most
 of the time that something that was done ends up in FreeRDP since it's a
 new feature or improvement even if it's just a trivial memory leak or
 fix. - Still not seeing the take over point her.

 Jay, I'm really happy and thankful that you and Marc-André started
 FreeRDP but if you leave the project and not happy how it turned out
 it's one thing. If you are unhappy how other things went thats the
 other. On both, I really do see your point and respect this
 but I also feel personally offended by public accusations that are
 just not right and true.
 I know all of the people at Thinstuff and they are nice and good
 girls and boys and definately not with the intention, or mindset,
 of taking over an project.

 This is just my personal opinion and has nothing todo with my employer.

I participated a lot on the began of FreeRDP and it was very exciting.
Currently it is not. Too bad.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Marc-André Moreau

Hi Otavio,

I think you also need to take a step back and realize the following:

I have already acknowledged that you do bring valid points. It is not not a
good thing that certain features like serial, parallel and smartcard are
not as stable as they should be, and would definitely use a helping hand
with that. We've never been against fixing those features, we just never
got to complete fixing them. FreeRDP covers a huge amount of possible use
cases and this means that if company A,B,C want FreeRDP in a certain way
then company D,E,F want it a certain way which A,B,C doesn't understand or
care about. We're highly inclusive and try to cover everybody's use cases
as best as possible, but that doesn't mean we're offering free support to
cover all use cases. It just means we'll integrate your stuff and make
place for it such that it can be as reusable as possible without preventing
other people from using FreeRDP the way they need to.

Simply put, here's what the whole situation looks like: FreeRDP used to be
more stable for features you cared about, then they were broken in 1.0 and
a lot of new features and architectural fixes were done before completely
fixing those features. Looking at that, you're just asking that we stop
adding new features, freeze everything and spend most of our time
stabilizing what we currently have rather than go after new features.

Since what you need is the complete restoration of those features that were
broken before you can migrate to the latest code, it can be quite
frustrating to see nobody cared to fix those features over all this time.
If you're frustrated about that, then hell, imagine my frustration! There's
a LOT of stuff which nobody even cared to fix in all of this time that
would have been totally worth it. I must keep my cool with all of these
people asking me about all sorts of things and complaining all the time
about missing stuff. I've been doing an incredible amount of work on this
project so if you need something more, than you've got to stop complaining
and start doing something. I'm just sick and tired of such alleged
constructive criticism that truly isn't. The constructive part is where I
acknowledged there is a problem, the negative part is where you don't
understand that while we acknowledge there is a problem, you just don't
acknowledge that fixing the problems require time and resources which we
don't have and apparently aren't willing to provide at this time.

I work on the bleeding edge of FreeRDP just like many other developers and
it works fine for us. Others require a more stable version of it which is
why we came up with the stable branch. Finding a method of operation that
actually works in practice takes time, but the stable branch does work.
Without Bernhard's amazing work *in his free time, on top of what he's
already doing* I don't think the stable branch would be as useful as it is
right now. What you need is to get the stuff you need to get fixed in the
stable branch, and you should be happy afterwards. It truly is all you need
to satisfy your requirements.


On Wed, Oct 23, 2013 at 7:13 AM, Otavio Salvador ota...@ossystems.com.brwrote:

 Hello folks,

 On Wed, Oct 23, 2013 at 7:15 AM, Bernhard Miklautz
 bmikla...@thinstuff.at wrote:
  first of I'm truthfully sorry how it went with xrdp. Even if I wasn't
  directly involved I absolutely understand you and also think some not
  really right choices were made.. Sorry for that.

 I think Marc-Andre and ThinStuff need to step back and listen. Stop to
 tell excuses and do an analysis of state points instead to justify
 'your actions' learn from the feedback.

  On 10/23/2013 09:48 AM, Jay Sorg wrote:
  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.
  ... what do you understand by took over?
 
  Spending time on fixing bugs?
  Trying to get new features in?
  Spending money on improving OSS software?
  Helping out users?

 Jay did it a lot. I did it a lot.

 I stopped when I noticed FreeRDP will never be usable for me. My
 product still uses FreeRDP 0.8+GIT (before rewrite) and it works more
 or less but it is stable. FreeRDP suck in this aspect.

 ...
  Thinstuff didn't in *any* kind take over FreeRDP. To let me put this
  straight Marc-Andre is the project lead and I (like any other Thinstuff

 Marc-Andre is very skilled but not to manage a project. FreeRDP
 commitment from community reduced a lot and as he realized companies
 are commited to their own needs and don't expend money to fix bugs
 which they don't care about.

  employee) isn't favoured in any way when working on FreeRDP. We don't
 dictate any
  direction, we just regular contributors doing pull request and help on
  other stuff. - For me that doesn't look like taking over?

 Taking over can be of many forms. I don't know all the projects done
 but Marc-Andre needs to ensure not only Thinstuff needs are
 accomplished or it ends being a

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Marc-André Moreau

Hi Jay,

There's nothing to fix as there has never been a takeover. Where did you
get that from?!

And honestly, the comparison with Cendio is very insulting, you know how I
feel about them.

FreeRDP remains under my control, Thinstuff is *not* taking control over
the FreeRDP project. If I were a control freak then I would not delegate
any work, but I'm not, and Bernard has proven itself to be extremely
valuable to help especially in the areas which interest Otavio and you
(taking time to go over bug reports, fix bugs, set up a ci infrastructure,
you name it, the work that nobody wants to do, he's been doing it). You're
pointing the finger at the few people who help the most with this project.

We've always been very inclusive of everybody in the FreeRDP project, and
unlike the rdesktop project, we won't start rejecting meaningful
contributions. Your complaint is mostly that the code changes very fast and
that it's taken a direction which you personally do not like. I take the
personal blame and full responsibility for all the architectural decisions
I have taken and lead other people to follow me with (especially WinPR
which I know you really don't like), Thinstuff definitely has nothing to do
with this. We've been working VERY hard on getting the API much more stable
and extensible, and that doesn't mean freezing the entire code base to add
features at a very slow pace.

Please don't mix decisions you don't like with the project being suddenly
taken over. It's just taken a direction which helps us fit the requirements
of a larger number of people more efficiently, and most of these decisions
have been initiated by me. Also, I'm definitely putting code where my words
are, just look at the statistics on github. There has definitely been great
results already from a lot that's been undertaken, as ambitious as it is.

What do you think?

Best regards,
- Marc-Andre


On Wed, Oct 23, 2013 at 3:48 AM, Jay Sorg jay.s...@gmail.com 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


 On Tue, Oct 22, 2013 at 10:58 PM, Marc-André Moreau
 marcandre.mor...@gmail.com wrote:
  Hi Jay,
 
  I understand you are not in agreement with certain architectural
 decisions.
  However, they are not adding no value to the FreeRDP project, they are
  quite useful. WinPR has greatly enhanced the portability and reusability
 of
  the code.
 
  As for the lots of complaints and developers being discouraged by
 this,
  give me a break. FreeRDP is not a Linux-centric project, it's an
 RDP-centric
  project, and it is designed to be as portable, flexible and modular as
  possible. Also, it is not a secret that the Microsoft Remote Desktop
  Protocol (RDP) is involves a lot of the Windows API being remoted, which
  is
  why the WinPR approach feels natural. You may not like it, but that's
 still
  how we're doing it, and we can't make everybody happy at once.
 
  Regarding xrdp-ng, it was only a temporary name. We've chosen to name the
  project FreeRDS for FreeRDP Remote Desktop Services, and just like
  FreeRDP, it doesn't aim at being a Linux-centric project but a full blown
  cross-platform remote desktop services implementation. As for forking the
  project, I think we both know that we work at totally different speeds
 and
  that what Thinstuff and I need in the short term is fairly different from
  xrdp. If I were to make the major changes I've been doing in FreeRDS in
 xrdp
  you'd get a heart attack, as I know you wouldn't like most of it. No hard
  feelings, we're just working on our own project that fits our needs. It's
  something you're doing as well with NeutrinoRDP, the stabilization fork
  you're using with xrdp.
 
  It's not a competition, and I've never meant to insult you. I just need a
  project which is fairly different from what xrdp is. When I originally
 got
  started, I didn't have much imagination, so I just called it xrdp-ng.
  We've finally decided to name it FreeRDS as it will have nothing to do
 with
  xrdp in the future as it's taking a totally different direction. You
 already
  hate the WinPR approach, and that's exactly what FreeRDS is using now
 along
  with as much of FreeRDP as possible. Is it really such a bad thing that
 it's
  a separate project? It's a long term investment for us, as in total it's
  somewhere between 6 months to a year of development effort to get the
 first
  usable release of FreeRDS with enough features to be interesting. We've
 got
  customers who need this, that's why we're working on it, and we want it
 for
  ourselves as well because of its potential.
 
  What do you think?
 
  Best regards,
  - Marc-Andre
 
 
  On Wed, Oct 23, 2013 at 12:26 AM, Jay Sorg jay.s...@gmail.com wrote:
 
  I would like to express my concern too over the stability of FreeRDP.
  It was much better a year ago.
 
  I'm

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Marc-André Moreau

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=60135991iu=/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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Marc-André Moreau

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

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Jay Sorg

Thanks Marc and Vic.

I'm only trying to explain why there are not as many contributors as there was.

When any project gets too close to any company you loose contributor.

We spent a lot of time switching to the Apache lincese but we allow
GPL like code from one company.  Why?
Can other companies get non Apache code in FreeRDP?
Why won't this project accept an Apache IOS or Android client?

Why did the CEO of Thinstuff email we shortly after your xrdp fork and
ask me to join xrdp-ng?
You talk about insulting!

Jay


On Wed, Oct 23, 2013 at 9:39 AM, Marc-André Moreau
marcandre.mor...@gmail.com wrote:
 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=60135991iu=/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.

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Jay Sorg

I had a similar problem when I was using FreeRDP libraries in xrdp.
The API kept changing from day to day for things that add no value.

palette renamed to colorTable, then ColorTable
This breaks the API twice.  What value was added?

The API needs to be a special place that one guy maintains and only
justified changes get in.
I had to stop supporting the FreeRDP module in xrdp.

Jay


On Wed, Oct 23, 2013 at 12: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

Re: [Freerdp-devel] Stable release

2013-10-23 Thread Marc-André Moreau

Hi Jay,

I think you are living in a parallel universe, what is wrong with you? Come
on IRC more often and talk to us, you've lost touch with reality, seriously.

First, don't use GPL-like to refer to a license which has nothing to do
with the GPL. You know how I feel about the GPL and we're definitely not
accepting GPL code in FreeRDP.

What you are referring to is the MPL 2.0 license which is used for the
*mobile clients* that Thinstuff developed. If you think it's a one-company
kind of thing, it isn't, it's been done in collaboration with Awake Coding
Consulting Inc. and I was the one who gave advice to Thinstuff when they
decided which license to choose. The MPL 2.0 is a weak copyleft license,
which means that unlike the GPL license, it's not viral. You can add new
non-MPL files alongside MPL files in the same project, link them together
the way you want, it doesn't matter, you're not infected. I think the
licensing of the mobile ports was already well covered in the announcement
which covered their release, have you even read it? Why so much outrage now
and not back then?

As for accepting an Apache 2.0 licensed iOS and Android client, why do you
come to the conclusion that we won't accept that? Anybody is free to write
their own iOS and Android FreeRDP-based client without reusing the existing
MPL 2.0 source code and license it under the Apache 2.0 license if they
want.

This project is NOT too close to a specific company, there has never been a
takeover. We are highly inclusive of everybody's contributions and try to
cover everybody's use cases. Heck, I even was once proposed mountains of
money by some (unnamed) company just to put some free proprietary RDP
clients for download on freerdp.com and I SAID NO because I care about
keeping this project independent from a single company. If there's someone
making sure this project doesn't end the same way rdesktop ended, it's me,
and I've been taking my role very seriously over all these years.

As for contributions, they have only been INCREASING, and this is one of
the reasons why managing the project has become much harder over the years.
When you're just a few developers management is easy, when you have a
larger community with many different companies involved all with different
goals it's kind of hard to keep them all aligned around one single project.
Everybody wants a different thing and somehow they want to use the same
thing at the same time. Put yourself in my boots one day and I dare you to
do a better job.




On Wed, Oct 23, 2013 at 3:48 PM, Jay Sorg jay.s...@gmail.com wrote:

 Thanks Marc and Vic.

 I'm only trying to explain why there are not as many contributors as there
 was.

 When any project gets too close to any company you loose contributor.

 We spent a lot of time switching to the Apache lincese but we allow
 GPL like code from one company.  Why?
 Can other companies get non Apache code in FreeRDP?
 Why won't this project accept an Apache IOS or Android client?

 Why did the CEO of Thinstuff email we shortly after your xrdp fork and
 ask me to join xrdp-ng?
 You talk about insulting!

 Jay


 On Wed, Oct 23, 2013 at 9:39 AM, Marc-André Moreau
 marcandre.mor...@gmail.com wrote:
  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

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Marc-André Moreau

Hi Otavio,

I understand the lack of a proper release cycle is an issue, but to solve
this I really need the help of the community. We've got a lot of people
doing an amazing job fixing bugs and backporting fixes to the stable-1.1
branch. The problem is that working on the release and fixing bugs often
falls within the spare time of the developers and most of us are really
busy these days. Bernhard from Thinstuff has been doing an incredible
amount of work in that regard on top of what he's already doing, and
without him the situation would be much worse. The stable-1.1 branch is
actually good, all that's lacking is someone taking the time to make a new
beta out of it. Simply put, we need more help with that, since we're
working with very limited resources.

Best regards,
- Marc-Andre


On Tue, Oct 22, 2013 at 7:54 AM, Otavio Salvador ota...@ossystems.com.brwrote:

 Hello folks,

 I am quite concerned about the future of FreeRDP. We have many more
 or less working features and last stable release has been a while
 ago.

 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.

 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.

 What you think?

 --
 Otavio Salvador O.S. Systems
 http://www.ossystems.com.brhttp://code.ossystems.com.br
 Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Nik Twerdochlib

So would it be possible (assuming it is not already done) to define some roles 
with responsibilities that need be filled?  Then perhaps using that information 
ask for volunteers?  I would suggest defining these roles in a fashion that 
would allow the community participants to commit to a release to help avoid 
from asking someone to commit to a non-paying second job ;)

I personally like the product and would like to contribute to it.  I am working 
on some smartcard support now, and would be willing offer some of my free time 
to help out the release cycle.

Nik Twerdochlib
Software Developer

-Original Message-
From: Marc-André Moreau [mailto:marcandre.mor...@gmail.com] 
Sent: Tuesday, October 22, 2013 9:37 AM
To: Otavio Salvador
Cc: freerdp-devel
Subject: Re: [Freerdp-devel] Stable release

Hi Otavio,

I understand the lack of a proper release cycle is an issue, but to solve this 
I really need the help of the community. We've got a lot of people doing an 
amazing job fixing bugs and backporting fixes to the stable-1.1 branch. The 
problem is that working on the release and fixing bugs often falls within the 
spare time of the developers and most of us are really busy these days. 
Bernhard from Thinstuff has been doing an incredible amount of work in that 
regard on top of what he's already doing, and without him the situation would 
be much worse. The stable-1.1 branch is actually good, all that's lacking is 
someone taking the time to make a new beta out of it. Simply put, we need more 
help with that, since we're working with very limited resources.

Best regards,
- Marc-Andre


On Tue, Oct 22, 2013 at 7:54 AM, Otavio Salvador ota...@ossystems.com.brwrote:

 Hello folks,

 I am quite concerned about the future of FreeRDP. We have many more 
 or less working features and last stable release has been a while 
 ago.

 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.

 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.

 What you think?

 --
 Otavio Salvador O.S. Systems
 http://www.ossystems.com.brhttp://code.ossystems.com.br
 Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.c
 lktrk ___
 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=60135991iu=/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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Marc-André Moreau

Hi Nik,

Thank you for your offer! Regarding your work on smartcard, I'm sorry I
didn't find the time to take a closer look at it, but please keep doing
what you're doing :)

As for avoiding asking someone to commit to a non-paying second job, that's
pretty much always been the issue for community involvement. In fact,
getting true commitment is a rare thing, and being the ability to assign
tasks to people usually only works with the people who will actually do a
second, non-paying job of helping out. It's not an issue with FreeRDP, it's
an issue with open source projects in general, and that's why the number
one excuse why things don't get done is always time and resources.

I suggest you hop on IRC, this is where a lot of the day to day discussions
happen. The key people you need to synchronize with are also usually there.
We can guide you towards many tasks that would help for the release cycle,
and you can definitely give Bernhard a hand on the amazing job he's already
been doing.

Best regards,
- Marc-Andre


On Tue, Oct 22, 2013 at 9:44 AM, Nik Twerdochlib ntwerdoch...@bomgar.comwrote:

 So would it be possible (assuming it is not already done) to define some
 roles with responsibilities that need be filled?  Then perhaps using that
 information ask for volunteers?  I would suggest defining these roles in a
 fashion that would allow the community participants to commit to a release
 to help avoid from asking someone to commit to a non-paying second job ;)

 I personally like the product and would like to contribute to it.  I am
 working on some smartcard support now, and would be willing offer some of
 my free time to help out the release cycle.

 Nik Twerdochlib
 Software Developer

 -Original Message-
 From: Marc-André Moreau [mailto:marcandre.mor...@gmail.com]
 Sent: Tuesday, October 22, 2013 9:37 AM
 To: Otavio Salvador
 Cc: freerdp-devel
 Subject: Re: [Freerdp-devel] Stable release

 Hi Otavio,

 I understand the lack of a proper release cycle is an issue, but to solve
 this I really need the help of the community. We've got a lot of people
 doing an amazing job fixing bugs and backporting fixes to the stable-1.1
 branch. The problem is that working on the release and fixing bugs often
 falls within the spare time of the developers and most of us are really
 busy these days. Bernhard from Thinstuff has been doing an incredible
 amount of work in that regard on top of what he's already doing, and
 without him the situation would be much worse. The stable-1.1 branch is
 actually good, all that's lacking is someone taking the time to make a new
 beta out of it. Simply put, we need more help with that, since we're
 working with very limited resources.

 Best regards,
 - Marc-Andre


 On Tue, Oct 22, 2013 at 7:54 AM, Otavio Salvador ota...@ossystems.com.br
 wrote:

  Hello folks,
 
  I am quite concerned about the future of FreeRDP. We have many more
  or less working features and last stable release has been a while
  ago.
 
  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.
 
  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.
 
  What you think?
 
  --
  Otavio Salvador O.S. Systems
  http://www.ossystems.com.brhttp://code.ossystems.com.br
  Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.c
  lktrk ___
  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=60135991iu=/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

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Bernhard Miklautz

Hi Otavio,

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. 

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.

 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.

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).

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.

Best regards,
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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Otavio Salvador

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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Marc-André Moreau

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.brwrote:

 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

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Otavio Salvador

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.

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Marc-André Moreau

Hi Otavio,

You may not realize it, but the vast majority of the work I'm doing for
customers is upstream from the start, and this include bug fixes,
performance improvements, architectural fixes. The problem I think you have
is the features you care mostly about (serial, parallel, smartcard) are
those I have never got a request for by my customers. I'm not saying they
aren't important, because they are, but none of my customers had those
features on their priority list. I even bought a smartcard reader in hope
of taking the time to fix smartcard redirection, but never got the time to
really go in depth into it. I asked for help on how to simply configure a
terminal server environment with smartcard auth a long time ago, and I
still don't know how to do it. As for serial and parallel, I even bought
old crappy printers on eBay to do some bug fixing. I did a few fixes but
not enough, it's not fully working. Just figuring out how to test these
features is a major blocker for a lot of developers who just aren't
familiar with them. Combine that with being swamped with work from actual
paying clients and it goes down the list of priorities. I'm sorry most of
the customers come to me to improve and fix features which aren't on your
priority list.

As for justifying myself, well, you're talking like all of this is easy and
the only reason why it's not better is because we're not listening to your
words of wisdom. I actually agree these are all very important points, but
you don't seem to get the part where making it happen requires resources
which we don't have, and the resources we do have are allocated are mostly
put on what people pay me to work on. If people want better audio that
doesn't skip, or better multimedia redirection, or crazy awesome fast
RemoteFX, or RDP8 multitouch, or TS Gateway, or NLA, and these aren't part
of the serial, parallel, smartcard list, then what should I do? Tell them
to keep their money, find a day job which doesn't involve FreeRDP, and
spend even less time contributing to this project? It's a general
understanding that when you want something in an open source project that
nobody else is already working on free, you can't expect someone to just
take care of your specific problems in the same way one would get paid
support but without paying for it. Free software doesn't imply free
support. Most of the time free community support is really helpful but it
depends on people's generosity and free time. You cannot *require* that
they support you for free, that's the difference, even if a lot of the
times they will.

I hope I'm not being misunderstood here: we're happy to help to the best of
our abilities, but it still doesn't mean we're free unpaid employees who
have nothing to do but offer free support 24/7.

Best regards,
- Marc-Andre


On Tue, Oct 22, 2013 at 12:58 PM, Otavio Salvador
ota...@ossystems.com.brwrote:

 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

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Marc-André Moreau

Hi Otavio,

All of this being said, I actually do care about fixing serial, parallel
and smartcard. I'm quite happy to see Thinstuff's been putting some
resources on smartcard and serial recently, and that Nik who responded
earlier in this thread is now on IRC, ready to help. I think the most
problematic would remain parallel. The printer I bought which I thought had
a parallel port was in fact a serial port requiring a db25 to db9 adapter,
so not very helpful. I'm still looking for a good test device that actually
uses a true parallel port in 2013 that I can get for testing purposes. Any
recommendations? I don't feel like buying another random printer without
knowing for sure it's going to be useful. As for smartcard, I would really
use some instructions on how to configure smartcard authentication in a
terminal server environment. Hopefully we can finally get all of these
fixed within the current year. Just writing test procedures for features
which are very obscure to many developers would greatly enhance our
capabilities of frequently testing and improving them.

What do you think?

Best regards,
- Marc-Andre


On Tue, Oct 22, 2013 at 1:29 PM, Marc-André Moreau 
marcandre.mor...@gmail.com wrote:

 Hi Otavio,

 You may not realize it, but the vast majority of the work I'm doing for
 customers is upstream from the start, and this include bug fixes,
 performance improvements, architectural fixes. The problem I think you have
 is the features you care mostly about (serial, parallel, smartcard) are
 those I have never got a request for by my customers. I'm not saying they
 aren't important, because they are, but none of my customers had those
 features on their priority list. I even bought a smartcard reader in hope
 of taking the time to fix smartcard redirection, but never got the time to
 really go in depth into it. I asked for help on how to simply configure a
 terminal server environment with smartcard auth a long time ago, and I
 still don't know how to do it. As for serial and parallel, I even bought
 old crappy printers on eBay to do some bug fixing. I did a few fixes but
 not enough, it's not fully working. Just figuring out how to test these
 features is a major blocker for a lot of developers who just aren't
 familiar with them. Combine that with being swamped with work from actual
 paying clients and it goes down the list of priorities. I'm sorry most of
 the customers come to me to improve and fix features which aren't on your
 priority list.

 As for justifying myself, well, you're talking like all of this is easy
 and the only reason why it's not better is because we're not listening to
 your words of wisdom. I actually agree these are all very important points,
 but you don't seem to get the part where making it happen requires
 resources which we don't have, and the resources we do have are allocated
 are mostly put on what people pay me to work on. If people want better
 audio that doesn't skip, or better multimedia redirection, or crazy awesome
 fast RemoteFX, or RDP8 multitouch, or TS Gateway, or NLA, and these aren't
 part of the serial, parallel, smartcard list, then what should I do? Tell
 them to keep their money, find a day job which doesn't involve FreeRDP, and
 spend even less time contributing to this project? It's a general
 understanding that when you want something in an open source project that
 nobody else is already working on free, you can't expect someone to just
 take care of your specific problems in the same way one would get paid
 support but without paying for it. Free software doesn't imply free
 support. Most of the time free community support is really helpful but it
 depends on people's generosity and free time. You cannot *require* that
 they support you for free, that's the difference, even if a lot of the
 times they will.

 I hope I'm not being misunderstood here: we're happy to help to the best
 of our abilities, but it still doesn't mean we're free unpaid employees who
 have nothing to do but offer free support 24/7.

 Best regards,
 - Marc-Andre


 On Tue, Oct 22, 2013 at 12:58 PM, Otavio Salvador ota...@ossystems.com.br
  wrote:

 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

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Otavio Salvador

Hello Marc-Andre,

On Tue, Oct 22, 2013 at 4:18 PM, Marc-André Moreau
marcandre.mor...@gmail.com wrote:
 All of this being said, I actually do care about fixing serial, parallel and
 smartcard. I'm quite happy to see Thinstuff's been putting some resources on
 smartcard and serial recently, and that Nik who responded earlier in this
 thread is now on IRC, ready to help. I think the most problematic would
 remain parallel. The printer I bought which I thought had a parallel port
 was in fact a serial port requiring a db25 to db9 adapter, so not very
 helpful. I'm still looking for a good test device that actually uses a true
 parallel port in 2013 that I can get for testing purposes. Any
 recommendations? I don't feel like buying another random printer without
 knowing for sure it's going to be useful. As for smartcard, I would really
 use some instructions on how to configure smartcard authentication in a
 terminal server environment. Hopefully we can finally get all of these fixed
 within the current year. Just writing test procedures for features which are
 very obscure to many developers would greatly enhance our capabilities of
 frequently testing and improving them.

 What do you think?

Old and good Epson LX800/LX300 Parallel printers should work fine for this.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [Freerdp-devel] Stable release

2013-10-22 Thread Jay Sorg

I would like to express my concern too over the stability of FreeRDP.
It was much better a year ago.

I'm concerned / confused about the future of FreeRDP.
It seems like there is too many restructuring / refactoring of the
source code that add no value.
All the documentation on
http://www.freerdp.com/api/
is out of date.

Lack of help is the problem, but who wants to help?
I hear a lot of complains about the windows'ish push.
WinPR / window command line parameters / a registry on Linux.
Talented Linux developers are discouraged by this.

I'd have to say, I'm discouraged too.

Another thing, with FreeRDP is such a bad state, why is this project
forking my project xrdp?
Why are you duplicating all the good work done on xrdp?
And why call it xrdp-ng?  Are you suggesting you can do a better RDP
Linux server?
I find it quite insulting!

I think there are some tough management issues that need to be addressed.

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=60135991iu=/4140/ostg.clktrk
___
Freerdp-devel mailing list
Freerdp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freerdp-devel

Re: [FreeRDP-devel] Stable release

Re: [FreeRDP-devel] Stable release

Re: [FreeRDP-devel] Stable release

Re: [FreeRDP-devel] Stable release

Re: [FreeRDP-devel] Stable release

Re: [FreeRDP-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

Re: [Freerdp-devel] Stable release

31 matches

Site Navigation

Mail list logo

Footer information