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
  

[Freerdp-devel] Peter Novodvorsky has invited you to use Google Talk

2013-10-23 Thread Peter Novodvorsky





Peter Novodvorsky has invited you to sign up for Google Talk so you can talk to 
each other for free over your computers.

To sign-up, go to:
http://www.google.com/accounts/NewAccount?service=talksendvemail=trueskipvpage=truereqemail=freerdp-devel@lists.sourceforge.netcontinue=http://www.google.com/talk/service/handleinvite?p%3DjRFstkMBAAA.QDDp59g_f_hv-AWFHD8Z3WBBBrcnicQv_inrWca5BhaqzPqCL0mcLKgGzAY2wvp50C1jfHwkoRzJCHoa6pZYBg.jjQXKgM9DfW_vW9EUXKv5wfollowup=http://www.google.com/talk/service/HandleEmailVerified?ee%3DjRFstkMBAAA.TUQOpHG9DG4s_0w99GeggCxnL_b-CbKVNjfN0DZ2nPKp8EOLC6zw2zOAM432kJTD.HXM5_-iuNhZT0ec3R5J5Kw%26p%3DjRFstkMBAAA.QDDp59g_f_hv-AWFHD8Z3WBBBrcnicQv_inrWca5BhaqzPqCL0mcLKgGzAY2wvp50C1jfHwkoRzJCHoa6pZYBg.jjQXKgM9DfW_vW9EUXKv5w

Google Talk is a downloadable Windows* application that offers:
- Free calls over your computer anytime, from anywhere, and for as long as you 
want
- A simple and intuitive user interface for sending instant messages or making 
calls--no clutter, pop-ups or ads
- Superior voice quality through just a microphone and computer speaker
- Fast file transfers with no restrictions on file type

After signing-up, download Google Talk and sign in with your new Google Account 
username and password.
You can then begin inviting anyone you want to talk to for free.

Google Talk works with any computer speaker and microphone, such as the ones 
built-in to many PC laptops today,
as well as with wired and wireless headsets and USB phones. Google Talk also 
works across all firewalls.

Google Talk is still in beta. Just like with Gmail, we're working hard to add 
features and make improvements,
so we might also ask for your comments and suggestions periodically. We 
appreciate your help in making it even better!

Thanks,

The Google Talk Team

To learn more about Google Talk before signing up, visit:

http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into 
the address bar of your browser).

* Not a Windows user? No problem. You can also connect to the Google Talk 
service from any platform using third-party clients
(http://www.google.com/talk/otherclients.html).

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