To follow blog post from Marco on RadStudio Quality :
To follow blog post from Marco on RadStudio Quality :
http://blog.marcocantu.com/blog/2018-08-qualityportal_tokyoR1.html
Why do not you put the source code of RTL and Firemonkey on community platforms as GitHub or Bitbucket?
Why quality portal is private ?
The current organization deprives you of big gain for embarcadero and its customers. All delphi community could help to correct bugs in RTL or Firemonkey. In return, we could have an instant access to new features and bugs fix as soon they are committed.
Please Marco, give me only one good reason of not change?
http://blog.marcocantu.com/blog/2018-08-qualityportal_tokyoR1.html
http://blog.marcocantu.com/blog/2018-08-qualityportal_tokyoR1.html
Why do not you put the source code of RTL and Firemonkey on community platforms as GitHub or Bitbucket?
Why quality portal is private ?
The current organization deprives you of big gain for embarcadero and its customers. All delphi community could help to correct bugs in RTL or Firemonkey. In return, we could have an instant access to new features and bugs fix as soon they are committed.
Please Marco, give me only one good reason of not change?
http://blog.marcocantu.com/blog/2018-08-qualityportal_tokyoR1.html
> Why do not you put the source code of RTL and Firemonkey on community platforms as >GitHub or Bitbucket?
ReplyDeleteI distinct the concept of sharing sources code and the licence applied.
For me, you can share sources code but only customer can use it … As costumer we already have the source code provided with the product. These tools bring more agility between embarcadero and customers. That’s all. Open sources delphi is another debate. 😊
> Why quality portal is private ?
>Private meaning what? That you need to login with a free account? It is a instance of JIRA we >are hosting "privately", yes.. Not sure what's the problem...
Simply to have bugs and issues indexed by google. It changes everything for us.
> In return, we could have an instant access to new features and bugs fix as soon they are >committed.
>No, you really have no clear idea of the side effects of doing this. We are more than happy to >accept code fix proposals in bug reports and contribute to those -- but this is fundamentally >different from what you are asking. Having infinite variations of custom-built runtime packages >would cause a DLL-hell!
I understand, but in fact we have already this problem.
I'm sure that I'm not the only customer that has internal custom patches from all over the rtl or firemonkey. We manage already custom patched source with prebuilt runtime packages… For me it is another delphi problem.
With a public git repository, you could manage differents branchs (Master, Tokyo, berlin, etc…)
It is at your own risk if you want to use the last sources of the branch master of RTL for instance ...
But at least it is possible
I like the idea of the rtl/vcl/fmx being open sourced, but it would take a monumental shift in policy to do this. It would also possibly result in people not upgrading or purchasing software assurance, which then leads to a revenue problem... however less would need to be spent on fixing rtl/vcl/fmx bugs and more could be assigned to the compiler & IDE, both of which you have to have SA to get updates/upgrades to. I think the idea has merit, I suggested it a few years back but didn't get any traction. It's a big change in the revenue model... can't see it happening.
ReplyDeleteVincent Parrett You don't have to opensource it to put it on github. You can even lock it behind a private repo, like EpicGames does with their UE4 source. It would allow for better colaboration, yet i agree with Marco Cantù. This would cause quite some DLL-Hell. Lets not forget you need 2 versions of rtl/vcl. One you use for production, and one for the IDE(which at the same time is the one you have to compile against for packages/plugins). Unless changes are restricted to non interface breaking. But there is just way more than just "throw in on github"
ReplyDelete