integration branch in plasma-mobile
hello ... so i *finally* got around to creating the integration branch in plasma-mobile. from this point forward, only peer reviewed bug fixes and obvious, can't-be- wrong trivial fixes should be pushed into master. ALL other activity must occur in topic branches. once the branch is ready to be pushed, create a review request on reviewboard.kde.org and after initial review, i will merge it into the integration branch. topic branches should be started from the master branch. all pre-release testing should be done using the integration branch. every monday, all topic branches will be merged into master that have: * successfully been merged in the integration branch * have been tested and peer reviewed with an explicit +1 from at lesat one other core developer and/or tester at that point, i will then rebase the integration branch on master and re- integrate all branches under review. this will make it a messy branch in terms of git history since it will be rebased often; this is not a problem as it will never merged back into master. this means *no commits* should ever be made directly to the integration branch. only to topic branches. cheers, and best of luck to us all in this new experiment :) -- Aaron J. Seigo signature.asc Description: This is a digitally signed message part. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: integration branch in plasma-mobile
On Wednesday 14 November 2012 16:08:31 Aaron J. Seigo wrote: hello ... so i *finally* got around to creating the integration branch in plasma-mobile. from this point forward, only peer reviewed bug fixes and obvious, can't-be- wrong trivial fixes should be pushed into master. ALL other activity must occur in topic branches. once the branch is ready to be pushed, create a review request on reviewboard.kde.org and after initial review, i will merge it into the integration branch. topic branches should be started from the master branch. all pre-release testing should be done using the integration branch. Will there be Mer-based images which contain packages from Integration? That would be necessary for testing the integration branch. I'd use such an image on my daily-use Wetab then and test it continuously (of course knowing that it may break from time to time ;). every monday, all topic branches will be merged into master that have: * successfully been merged in the integration branch * have been tested and peer reviewed with an explicit +1 from at lesat one other core developer and/or tester Great! I also like that we'll be using Reviewboard. I love that tool, even as a non-developer :) at that point, i will then rebase the integration branch on master and re- integrate all branches under review. this will make it a messy branch in terms of git history since it will be rebased often; this is not a problem as it will never merged back into master. this means *no commits* should ever be made directly to the integration branch. only to topic branches. cheers, and best of luck to us all in this new experiment :) It's surely going to give quality a big boost! ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
Re: integration branch in plasma-mobile
On Wednesday 14 November 2012 16:08:31 Aaron J. Seigo wrote: hello ... so i *finally* got around to creating the integration branch in plasma-mobile. from this point forward, only peer reviewed bug fixes and obvious, can't-be- wrong trivial fixes should be pushed into master. ALL other activity must occur in topic branches. once the branch is ready to be pushed, create a review request on reviewboard.kde.org and after initial review, i will merge it into the integration branch. topic branches should be started from the master branch. all pre-release testing should be done using the integration branch. every monday, all topic branches will be merged into master that have: * successfully been merged in the integration branch * have been tested and peer reviewed with an explicit +1 from at lesat one other core developer and/or tester at that point, i will then rebase the integration branch on master and re- integrate all branches under review. this will make it a messy branch in terms of git history since it will be rebased often; this is not a problem as it will never merged back into master. this means *no commits* should ever be made directly to the integration branch. only to topic branches. cheers, and best of luck to us all in this new experiment :) Oh and currently Master contains some quite severe regressions compared to PA3 (already reported to BKO), which should be fixed before we have a releasable state. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
[Bug 310074] New: lockscreen locks screen when full screen app running(e.g. movie)
https://bugs.kde.org/show_bug.cgi?id=310074 Bug ID: 310074 Severity: normal Version: unspecified Priority: NOR Assignee: active@kde.org Summary: lockscreen locks screen when full screen app running(e.g. movie) Classification: Unclassified OS: Linux Reporter: van...@msn.com Hardware: openSUSE RPMs Status: UNCONFIRMED Component: General Product: Active When watching movies using kafeine or vlc screen gets locked after time specified in lockers setting. Reproducible: Always Steps to Reproduce: 1. open video 2. watch it for 5 minutes(default setting) 3. get screen locked Actual Results: Screen locks. Expected Results: It should not lock while watching movies. -- You are receiving this mail because: You are the assignee for the bug. ___ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active
