Re: GSOC 2012 project: Make plasmate ready for release
Hello, this is my modified proposal, -Task 1 --Problem 1 Right now plasmate doesn't support all the debugging tools which we offer. Those debugging tools live under kde-workspace/plasma/generic/tools. --Solution 1 a.Move all the debugging tools from kde-workspace/plasma/generic/tools and kde-runtime/plasma/tools into plasmate's repository(maybe we should rename the repository to Plasma SDK) Expected time: this task has to be done by a sysadmin since I don't have that kind of access. b.make plasmate use those tools. c.our debugging tools will still live as standalone applications and also us plasmate's plugins. Some of our devs doesn't like plasmate and we shouldn't force them to use it. So having our debugging tools both as standalone application and as plasmate's plugins solves the issue. Regarding the build system I can add the debugging tools and plasmate as option in order not to force some developer to build the entire repository. Expected time: Approximately one week Priority: this is the last one(7) -Task 2 --Problem 2 Plasmate and plasmoidviewer have duplicate code. Also plasma-previewer(the plasmate's code for plasmoid debugging) is more modular than the plasmoidviewer's code. Plasma-previewer is more modular but plasmoidviewer has more features than the plasma-previewer. --Solution 2 Replace plasma-previewer's code with plasmoidviewer's and make plasmoidviewer's code more modular in order to be reused by plasmate. Also a side note here both plasma components for desktop and for active live with the same names. So in order to use the plasma components for active the developer has to change an environment variable. Plasmoidviewer should provide an option for that (I will add this option). Expected time: Approximately one week Priority: pre-last one(6) -Task 3 --Problem 3 There is no plasma tool for us to open our svg images add see the available layers. Since we want to offer a nice sdk our users should be able to browse our svgs easier. --Solution 3 Sreich's svgviewer solves the half of the problem(thank you Sreich) the other half(there is no way to see the available layers of each svg). I will implement this option. Expected time: approximately one week Priority:5 -Task 4 --Problem 4 KConfigXT editor isn't finished. There is still some code which has to be written. --Solution 4 Finish the KConfigXT editor and also make it available as a standalone application. All of our debugging tools shouldn't force our developers to use plasmate. Expected time: approximately 2/3 weeks Priority:4 -Task 5 --Problem 5 Plasmate's editor doesn't support actions.(Like undo/redo,etc) --Solution 5 Make plasmate support those. Expected time: approximately 1 week Priority: 1 -Task 6 --Problem 6 There is no way to install remotely a plasmoid package --Solution6 Create a remote installer, so that you can push a button which copies your plasmoid package onto a device running Plasma (Active) and runs it, so you can try it on a touch screen. That could be done with scp, for example. Expected time: 2/3 weeks Priority: 2 Task 7 Problem 7 If the user is using plasmate there is no way to see the output of print/console.log Solution7 Add a console in plasmate which will contain the output from the debugger like plasmoidviewer. Expected time: 2 weeks Priority:3 P.S.: sorry for my delay to reply but I send the modified proposal only to sebas(bad misclick!) when I had it ready. Regards, Giorgos. -- Giorgos Tsiapaliwkas (terietor) KDE Developer terietor.gr ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Workflow Idea for 4.10
Hi there At Active sprint we've used a lunch break for talking about some Workflow Issues we find with the current way of using git in the workspace, just for mention a few discussed things from the top of m head: - People merge things not ready to be merged (aka using git as we did svn) - We don't want to change to a 3 month release (or something like that). - Reviewboard is not the perfect tool for big changes - Current time schedule has its benefits The resulting workflow if we take into account all of that is: - Keep the 6 month release period - Keep the current schedule (soft freeze, hard freeze...) - Move to a review based workflow before hard freeze (we need gerrit). - Once we are on hard freeze, open merge for everyone so we can continue fixing things easily. Putting manpower aside, I think that this would be a good tentative attempt for moving to a different thing, we keep a lot of the good things we have right now and it will allow us to explore the benefits of the merge based workflow. What do you think of it? BTW don't mention what we don't have enough reviewers, that's something that can be work on later, ATM let's just assume we have infinite man power ;p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Faster Implementation of AbstractMetadataModel::propertyUrl
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104172/ --- Review request for Plasma and Marco Martin. Description --- Use a hash to store all the abbreviations. It provides faster lookups. Diffs - components/metadatamodel/CMakeLists.txt a10978b components/metadatamodel/abstractmetadatamodel.h e973ccf Diff: http://git.reviewboard.kde.org/r/104172/diff/ Testing --- Nope. I have no idea how to test this. I'm just reviewing the code. Thanks, Vishesh Handa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
In data venerdì 09 marzo 2012 00:27:51, Alex Fiestas ha scritto: - Move to a review based workflow before hard freeze (we need gerrit). Do you mean for the Workspace, or for the entirety of KDE? For both cases, what does sysadmin think? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Workflow Idea for 4.10
On Friday 09 March 2012 07:52:37 Luca Beltrame wrote: In data venerdì 09 marzo 2012 00:27:51, Alex Fiestas ha scritto: - Move to a review based workflow before hard freeze (we need gerrit). Do you mean for the Workspace, or for the entirety of KDE? For both cases, what does sysadmin think? only for workspace. Sysadmin have not yet been contacted about it, but in general sysadmins are very open to requests from the community :-) Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Fri, Mar 9, 2012 at 12:27 PM, Alex Fiestas afies...@kde.org wrote: Hi there At Active sprint we've used a lunch break for talking about some Workflow Issues we find with the current way of using git in the workspace, just for mention a few discussed things from the top of m head: - People merge things not ready to be merged (aka using git as we did svn) - We don't want to change to a 3 month release (or something like that). - Reviewboard is not the perfect tool for big changes - Current time schedule has its benefits The resulting workflow if we take into account all of that is: - Keep the 6 month release period - Keep the current schedule (soft freeze, hard freeze...) - Move to a review based workflow before hard freeze (we need gerrit). I should note that Sysadmin has on several occasions assessed Gerrit. On each occasion the conclusion reached was that Gerrit would be difficult to maintain and would increase the complexity involved for pre-existing contributors. Among the issues found: - Gerrit implements the git protocol itself, and has an internal SSH server. - Changes would be necessary to integrate it with Identity as we store SSH keys in Identity. It is not clear how invasive these changes would be. - Gerrit is a Java application, and past experience with them indicate that are very resource intensive. - Gerrit operates with the assumption it has permission to push to the master repositories, providing a security vulnerability to our infrastructure. - Permissions would need to be duplicated between Gerrit and Gitolite, the system responsible for managing git repositories on git.kde.org. The security of git.kde.org and svn.kde.org is something which can never be affected or weakened in any form. - Once we are on hard freeze, open merge for everyone so we can continue fixing things easily. Putting manpower aside, I think that this would be a good tentative attempt for moving to a different thing, we keep a lot of the good things we have right now and it will allow us to explore the benefits of the merge based workflow. What do you think of it? BTW don't mention what we don't have enough reviewers, that's something that can be work on later, ATM let's just assume we have infinite man power ;p ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regards, Ben Cooksley KDE Sysadmin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
