Re: [kde-community] Request to join the Kde incubator for GCompris
Le 19/02/2014 21:24, David Edmundson a écrit : What I see as a problem is that this has an implicit attached request to our current KDE Windows releasing team saying they shouldn't package and release GCompris. It would be unfair on Bruno for our KDE Windows team to do so. Legally they absolutely can, but it would still be more than a little bit rude. It's also equally unfair on our KDE Windows team to ever prevent them from doing so. I think it does open up some very interesting questions, not just here but for other cases where our Android/iOS porting becomes popular on how to do this in a manner that is fair to everyone. Money can easily cause a lot of tension and arguments. I'd like a discussion on it and maybe some guidelines. Hi, Yes I confirm that this is an important question and we must think about it before going further. Distributing 2 different binary versions of GCompris, one on gcompris.net with an activation code and one on kde.org without would be unfair and confusing for the users. Like you mention it would be much more confusing on Android/iOS. Even if you take out the activation issue, it is very confusing to have different application with the same name being build and distributed by several organization. It is the rule on GNU/Linux and we are used to work that way but on the other platforms it is not practical. Bruno. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Future Git Plans
On Thu, Feb 20, 2014 at 5:26 AM, Àlex Fiestas afies...@kde.org wrote: On Tuesday 18 February 2014 13:45:41 Frederik Gladhorn wrote: On Saturday 15. February 2014 15.30.54 Àlex Fiestas wrote: On Friday 14 February 2014 22:52:04 Jeff Mitchell wrote: This email serves two purposes: one, to inform the community of the direction we would like to go with KDE's Git hosting and request feedback; two, to ask for volunteer projects that are willing to act as crash test dummies for the new system, helping us figure out the best way to set it up, work out kinks, etc. Due to the bleeding-edge nature, we're currently limiting this to self-contained projects, such as those in Extragear. Since most of the projects I work on are in extragear I would very much like to participate in the beta-alpha-thing testing :p Personally I have some experience with gitlab and and github workflow and I would like very much to adopt it in kde. I tried working with github for a project, using a workflow of reviewing each commit. I personally really disliked it for creating a merge commit for each commit, that just clutters up the history (try looking at any github project with a few contributors). Is this the same with gitlabs or can it cherry-pick after successful reviews? In both, github and gitlab you can have teams that have access to a repository, those team members do not need any review. If we want to continue with our policy of KDE hackers can commit everywhere then we just have to create a team with all of us on it. At this point in time, that policy will be continued. Merge Requests could be used by other developers if they wished however. In terms of whether it's automatic merge creates a history mess, this is unknown - it will likely come out in testing I imagine. It also offers information and instructions on performing the merge manually. Thanks, Ben ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Request to join the Kde incubator for GCompris
Le 20/02/2014 09:37, Martin Gräßlin a écrit : On Thursday 20 February 2014 09:03:04 Bruno Coudoin wrote: Le 19/02/2014 21:24, David Edmundson a écrit : What I see as a problem is that this has an implicit attached request to our current KDE Windows releasing team saying they shouldn't package and release GCompris. It would be unfair on Bruno for our KDE Windows team to do so. Legally they absolutely can, but it would still be more than a little bit rude. It's also equally unfair on our KDE Windows team to ever prevent them from doing so. I think it does open up some very interesting questions, not just here but for other cases where our Android/iOS porting becomes popular on how to do this in a manner that is fair to everyone. Money can easily cause a lot of tension and arguments. I'd like a discussion on it and maybe some guidelines. Hi, Yes I confirm that this is an important question and we must think about it before going further. Distributing 2 different binary versions of GCompris, one on gcompris.net with an activation code and one on kde.org without would be unfair and confusing for the users. Like you mention it would be much more confusing on Android/iOS. Even if you take out the activation issue, it is very confusing to have different application with the same name being build and distributed by several organization. It is the rule on GNU/Linux and we are used to work that way but on the other platforms it is not practical. But you cannot prevent it. If for example I don't like that you distribute it with an activation code I can take the source and distribute it without the activation code. Hi, It is true and this is not specific to free software or to GCompris. The software industry at large learned to live with people distributing unauthorized version. The difference with free software is that it is legal to do so. What happens in this case is that the original author request the unauthorized distributor to change the name of the software. It is what happened with RedHat versus CentOS or Firefox versus Iceweasel. In our case the situation is different because it would be legitimate to have a build on gcompris.net and one on kde.org thus both parties have to define the rules. Given that I don't think it really matters at the moment. You have to be prepared that others will provide binaries (whether it's friendly (e.g. KDE) or unfriendly (someone just going for the money)). I am prepared to that and this issue is already present for the Gtk+ version. I have been somewhat protected by the complexity of doing a build on Windows and MacOSX. Maybe this could be split of into a new thread to brainstorm ideas around that and how to fairly distribute the income as that can raise conflicts. I am open do discussion on this matter. Bruno. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Future Git Plans
On Feb 17, 2014 9:14 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Monday 17 Feb 2014 08:03:24 Alexander Dymo wrote: That said, last time I tried it was a resource consumer monster, has that been fixed? Is it going to scale KDE size? It's a Rails app. Those tend to use more resources. But deploying with Ruby 2.1 might have a huge difference performance-wise. Yes, Ruby made *huge* speed improvements in 2.0, and again in 2.1. I recently updated some of our company's internal Rails-based tools from 1.9.3 to 2.1.0, and the speed improvements are really quite gratifying :) For even faster results, one could use JRuby (Ruby running on JVM). Twitter did this before moving the entire system to Scala. Paul ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
