Re: Re: reflecting on 4.10
On Monday 14 January 2013 17:37:28 Aaron J. Seigo wrote: I'll add only one semi-new point: * active, healthy communication between components teams. no more developing in caves. no more not talking to each other. broad, inter-component coordination. Development plans and progress should be shared with others on this mailing list, recorded on the wiki, etc. We need irc meetings at important moments, we need more people blogging about what theya re working on, which may also help with our other goal of getting more people trying newer things. By letting each other know what we are doing, we can coordinate with each other effectively and produce a better end product together. Amen brother. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Saturday 12 January 2013 17:56:14 Kevin Ottens wrote: [*] Historical note no one will probably care about actually, i care :) i rather suspected this was the case, given the number of developers i've heard this same kind of story from. the reason for moving to packages varies, but fewer KDE devs run master than probably ever before. it seems a recent phenomenon, just as with you. i'm personally very excited that more people will be running master again. and i hope with an integration branch, that will extend even further. ... what I was describing here. More people running master and reporting findings. I'll sound like an old grump but it's one thing we did better in the past. I think we should actively try to restore that custom. This morning I started a kdesrc-build and once it has compiled through I'll do the reboot to know everything is up to date. I'll do that each week from now on (probably also shifting to Friday instead of Monday morning). 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: Re: Re: reflecting on 4.10
On Monday 14 January 2013 11:16:43 Martin Gräßlin wrote: On Saturday 12 January 2013 17:56:14 Kevin Ottens wrote: [*] Historical note no one will probably care about actually, i care :) i rather suspected this was the case, given the number of developers i've heard this same kind of story from. the reason for moving to packages varies, but fewer KDE devs run master than probably ever before. it seems a recent phenomenon, just as with you. i'm personally very excited that more people will be running master again. and i hope with an integration branch, that will extend even further. ... what I was describing here. More people running master and reporting findings. I'll sound like an old grump but it's one thing we did better in the past. I think we should actively try to restore that custom. This morning I started a kdesrc-build and once it has compiled through I'll do the reboot to know everything is up to date. I'll do that each week from now on (probably also shifting to Friday instead of Monday morning). I do this every night, some times twice a day. From my experience, we can live in master with no bigger issue, some times something will break but nothing that will prevent me to work. Also, I have the distribution installation so in case master is super broken I can switch to it or use some app's from it (I can't remember the last time I had to resource to this). Cheers ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Friday 11 January 2013 20:37:58 Aaron J. Seigo wrote: On Friday, January 11, 2013 18:37:44 Alex Fiestas wrote: If we want to discuss this, we should start another thread for not going off topic. imho it's completely on topic. Very well then We talked about quality, reviews and process during more or less all the sprint, it was kind of a lunch/coffee/break/beer topic. One of the results of these talks was a proposal to change how we do releases, and how we do development, if my memory is not tricking me sebas sent an email somewhere proposing it, but nothing happened. We talked about using the development process we designed in the Platform11 sprint and was presented by Cornelious as well of shorting release cycles when the new way of worked was proven. For those who don't know about this development process, basically all the magic happens in branches 2 of which are used for releases. -Master -Integration Master will be always stable and release ready, also the strings will be frozen so every time something is merged into master it means strings won't change until next release. Integration is where all working branches will be merged and what users (including us) that wants to be in the cutting edege will use. The merge process is important since it is exactly what will (in theory) prevent us from breaking Integration. This merge process was afaik not completely drafted/agreed on, but from the top of my head: -It will be merged only when it is release ready (minimum quality check) -It will go through a review process similar to what we have today but it will happen within the kde-workspace module (or any other) and it won't have a time limit. If nobody reviews it it won't be merged. All of that is from my memory. It may be wrong but community.kde.org is down at the moment of writing this email so I can't check notes (I think we wrote some). Then, there were talks about feature planning and how everybody involved in the Workspace should be aware of what we are doing (I remember we talked about blogs being not enough to announce stuff) and the things we work on should be agreed/created in group so everybody understand them. This was specially discussed after the afternoon we used to make clear what all the new terms meant (Active, Plasma, Shell, Workspaces, Desktop, Countour, etc). That's more or less a memory dump written down in a few lines, it is not my opinion but rather what I remember we discussed/concluded there. If you ask me, best way to sort this down will be Akademy. Cheerz. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
This is my opinion now (no longer what I remember from the sprint). On Saturday 12 January 2013 15:54:39 Aaron J. Seigo wrote: On Saturday, January 12, 2013 14:08:44 Alex Fiestas wrote: -Master -Integration this is what we are doing now in plasma-mobile. it has taken a bit to get used to (mostly for me doing the integration branch; we were already using branches heavily). i think it is working pretty well. i blogged about this recently, in fact :) it should come as no surprise but i'm very much in favour of this model and would love to see it tried in kde-workspace as well. this would require buy-in from kwin, plasma, system settings, powerdevil, etc. developers. but i think we can get that with a bit of communication. the only way this works, however, (in addition to the communication you covered in your email) is if someone is actively managing the integration branch and if we developers use that branch on a regular basis. Imho there should be a group of people managing integration we should not depend on a single person in almost anything. Also, the branch should be stable enough so all distros can have a repo with daily packages of it and promote their usage (not just saying oh look we have snapshots but it may kill kitties). If you ask me, best way to sort this down will be Akademy. people often say this, and i have a slightly different viewpoint after having done this for many years now. what i've noticed is that anything that gets decided on *at* Akademy, or any larger event (e.g. platform 11), tends not to get implemented or put underway for sometime. often, not until the next big event. what seems to work a lot better is to arrive at the event with an understanding or agreement on what to try to accomplish and then spend time at the event either starting actual work on it and/or reviewing how things have worked in practice up to that point and then working on modifications / tweaks / improvements on the already-agreed-upon-and-started-to-be-put-into-practice process. sometimes we can get to agreement without an in-person meeting, and then there's no option. but when we can get to such a meeting with some agreement and even some work already happening, it seems to quite reliably speed up the process of implementation by 6-18 months. i can point to numerous examples in the past few years that bear this out. in fact, the master/integration (aka always summer in trunk) methodology is a good example of this :) so my hope is that out of this thread we can find 3-4 ideas that we can decide on together online and then put into place as best we can so that when we gather in Bilbao in the summer we will already have some experience in the matter and can use that opportunity to improve (or drop :) what we're doing. Very good points, let's start to draft something then. Maybe, we can have a hangout to kickstart this? I'd really like to talk this in a channel which offer more bandwidth. Cheerz ! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Saturday 12 January 2013 17:57:37 Aaron J. Seigo wrote: On Saturday, January 12, 2013 17:38:03 Marco Martin wrote: wonder how much scales for something as big as the kde-workspace repo... my experience with plasma-mobile seems to indicate that it is easily done by one person. i wouldn't want to see one person doing all of kdelibs, kde- runtime, kde-workspace, kdeplasma-addons, plasma-mobile, etc ;) that woudl be a bit much, to say the least. but kde-workspace as a repo, no problem. it would probably take a couple hours per week maximum. keeping record of which branches are being merge (and sometimes in which order), what conflict resolution choices are made (when needed) and what cherry-picks (if any) are done seems to be the biggest chore. the next biggest job is when merging a new branch in, sometimes there are conflicts or a newer version of master is needed, or ... and that can take a few minutes at times. once the first merge is done, it tends to be a cakewalk after that. i was honestly pretty hesitant about how much work it would be at first, but it's proving to be very, very little work compared to what i was expecting. actually *testing* the results takes far, far more time and that is something that must be parallelized anyways so we cover as many different configurations and hit as many code paths as possible. so i think it is reasonable and possible to see one integration branch maintainer per repository, with a backup person for each repo. also, for maintaining integration merged.. woder if there could be a bit of automation ivolved? probably, but git already makes it so fast that i think little more is really needed. i'm more interested in tools for nominating branches as merge candidates. I like what I read we can use this experience as a base to specify a new way of working in kde-workspace. In the recent past, we have had people giving ship it in reviewboard to code that was not maintained by them and what is worst modifications that broke (or still breaks) stuff, we should prevent this from happening. Some extra information I think can be useful to brainstorm about this is how we work in Solid, let me show it with a practical example: Somebody creates a reviewrequest for PowerDevil which ideally should be reviewed by Dario since he's the master of it (even though it is within solid umbrella). The community waits for Dario to show up and review the modification. Given an unspecified amount of time Lukáš will jump and review it since he's kind of the second aboard on PowerDevil. If more time passes and neither Lukáš or Dario has review it, I take it as my responsibility (as Solid maintainer) to review it. Of course int he dead times I will poke Dario/Lukáš to remember them that there is a review that should be attended. In the case of Solid, this has been happening organically we haven't had the need to specify it anywhere, I suspect Kevin made the community work that way before I join. This way of working has worked great for us and I can see it working great in kde-workspace. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Saturday 12 January 2013 18:45:07 Aaron J. Seigo wrote: if they are targetted for 4.11 (or some future release even?) we'll need to figure out how to deal with these separate repos. do they end up merged into kde-workspace? do we put them as child repos of kde-workspace and rely on kdesrc-build to bring them together? if the latter do we work on breaking up the rest of kde-workspace as well into multiple small repos? these are not questions we need to, or probably even should, answer right now in this thread .. but they are questions that are coming. one more example of where coordination is really going to make or break our future releases. yes, it doesn't belong into the thread. But it would be great to have a new thread about it to discuss it. We should have a decision once the repos are ready to go. It is an interesting topic - personally I do not know what to think about it. I see benefits for both approaches. 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: Re: reflecting on 4.10
On Saturday 12 January 2013 18:54:23 Aaron J. Seigo wrote: so i'd like to see *more* reviewboard input rather than less. it would be totally awesome if more people would do reviews outside their normal teritory. E.g. me doing more reviews of Plasma stuff, but also Plasma people doing more reviews on KWin stuff. Just going there, looking at the change and ask if one doesn't understand a change. I'm sure everyone would like to share the knowledge about a piece of code. and it's one thing i love about feature and bug fix branches going into integration: it lets people thumbs-up the review request without any implications for maste ShipIt would no longer mean the changeset goes into master, but schedule it for merge into the integration branch. in theory, more people will be testing integration than looking at the initial review, which will catch breakage that currently sometimes makes its way straight into master. Sounds like we want gerrit... 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: reflecting on 4.10
On Saturday 12 January 2013 18:54:23 Aaron J. Seigo wrote: On Saturday, January 12, 2013 18:29:22 Alex Fiestas wrote: In the recent past, we have had people giving ship it in reviewboard to code that was not maintained by them and what is worst modifications that broke (or still breaks) stuff, we should prevent this from happening. we already generally follow maintainence responsibilities in reviews (e.g. kwin reviews are pretty well always stamped ShipIt by kwin devs; there's one going through this process right now, in fact) however, i don't agree that we should discourage broad participation as a few things happen when we do: * it becomes easier to have reviews drop on the ground as we wait patiently/blindly for maintainers (we have dozens of components in kde- workspace) * fewer people take an active interest in the code because they aren't ever reviewing anything, so what should motivate them? * some idividual maintainers end up with more than their share of reviews and end up with little time for anything else if not careful (i sometimes spend entire days doing only patch review..) * we do have components that are under- or simply un-maintained .. then what? :) i don't agree that more careful review will catch significantly more issues than are already found out as many breakages will not show up to those doing initial testing. so i'd like to see *more* reviewboard input rather than less. and it's one thing i love about feature and bug fix branches going into integration: it lets people thumbs-up the review request without any implications for master ShipIt would no longer mean the changeset goes into master, but schedule it for merge into the integration branch. in theory, more people will be testing integration than looking at the initial review, which will catch breakage that currently sometimes makes its way straight into master. I have explained myself terribly wrong since you are making statements that I haven't. Let me be more clear to address many of your points. I want to prevent the fact that broken code can go into the integration branch because people reviewing it know C++/QML/etc but don't know the code base of the destination project. This means that everybody is welcomed to review and point mistakes and give Thumbs up but only people knowing the project itself should be able to mark it to be merged. How many times have you seen in the current reviewboard something like: It is ok now but let's wait until XXX gives the ship it ? I have seen it plenty of times in almost all KDE project and that's precisely what I'm talking about. One of the benefits of having a more review based development process is that maintainers and code owners can review code BEFORE it goes in instead of what happens now that you have to post-review things which is imho more time consuming. For unmaintained projects I agree with you, it is better to make the modification available in integration than to let it rot in reviewboard/review process. So, to sump it up: -The more reviewers the better -Something like Thumbs up could be implemented -Give a chance to the people that know the code base to review it before marking the change to be merged. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: reflecting on 4.10
On Saturday 12 January 2013 19:13:29 Martin Gräßlin wrote: On Saturday 12 January 2013 18:45:07 Aaron J. Seigo wrote: if they are targetted for 4.11 (or some future release even?) we'll need to figure out how to deal with these separate repos. do they end up merged into kde-workspace? do we put them as child repos of kde-workspace and rely on kdesrc-build to bring them together? if the latter do we work on breaking up the rest of kde-workspace as well into multiple small repos? these are not questions we need to, or probably even should, answer right now in this thread .. but they are questions that are coming. one more example of where coordination is really going to make or break our future releases. yes, it doesn't belong into the thread. But it would be great to have a new thread about it to discuss it. We should have a decision once the repos are ready to go. It is an interesting topic - personally I do not know what to think about it. I see benefits for both approaches. Muehehe you only have to watch KDE tea time to know my opinions about this or at least some of them :p So, let's open a new thread and discuss about this :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Saturday 12 January 2013 18:45:07 Aaron J. Seigo wrote: we have 3 repositories which probably should target 4.11: * kscreen (playground/base/) * libkscreen (playground/libs/) * kio_mtp (playground/base/) they have a few things in common: * they are all worked on by Alex F. :) * they are in their own repositories in playground You could even add more stuff to this list if you include extragear, like: bluedevil networkmanagement And future stuff like: webaccounts User-manager New pulse audio support. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Friday 11 January 2013 17:26:39 Marco Martin wrote: On Friday 11 January 2013, Marco Martin wrote: On Thursday 10 January 2013, Aaron J. Seigo wrote: hello. we're nearly at the point of releasing 4.10. with this development cycle very fresh in mind, it is a reasonble time to reflect on how it went. this thread can be a place for us to do so, if we so wish. and i hope we do so that we can improve our processes in the future. so how do you think 4.10 went? mixed feelings: we did a lot, but definitely as already noted the process wasn't managed so well and the qa was not at the top (putting also myself in the blame list for that, is something that each of us shares a bit) thinking more about it... maybe what we actually need is someone with a wide enough knowledge of the codebase, that continuously uses master and tests, poking people when regressions happen? (especially in areas far from what one usually works in, since for own area proximity blindness can happen) this kindof happens already, but there isn't anythng formal about it I had kind of hoped that the kde-quality team would become exactly that. Some dedicated people who look around, who are trusted and who we know don't report junk. The team sees itself in a different position and I'm not the person to question it ;-) I think it's needed and I think nobody in our inner development circle can be part of it. We are all blind :-) it would be something not fun to do at all, but perhaps is kinda needed? a figure that help the release manager? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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: Re: reflecting on 4.10
If we want to discuss this, we should start another thread for not going off topic. In the workspace sprint we had some ideas about this. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: reflecting on 4.10
On Friday 11 January 2013 20:37:37 Aaron J. Seigo wrote: On Friday, January 11, 2013 17:53:34 Martin Gräßlin wrote: I think it's needed and I think nobody in our inner development circle can be part of it. We are all blind :-) i've already said this in another email, but this is only half true. we need people outside our inner circle looking at things, indeed. they will catch things and be able to test more configurations than we can. at the same time, we also need people who know what the code base looks like, what is changing, who is changing it and what our goals our. right, kind of what I do with the this week in KWin posts. That would *in theory* make it easy for someone to follow what's going on. it's both/and. -- Aaron J. Seigo 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: reflecting on 4.10
On Friday 11 January 2013 15:20:42 Weng Xuetian wrote: On Friday 11 January 2013 17:26:39，Marco Martin : On Friday 11 January 2013, Marco Martin wrote: On Thursday 10 January 2013, Aaron J. Seigo wrote: hello. we're nearly at the point of releasing 4.10. with this development cycle very fresh in mind, it is a reasonble time to reflect on how it went. this thread can be a place for us to do so, if we so wish. and i hope we do so that we can improve our processes in the future. so how do you think 4.10 went? mixed feelings: we did a lot, but definitely as already noted the process wasn't managed so well and the qa was not at the top (putting also myself in the blame list for that, is something that each of us shares a bit) thinking more about it... maybe what we actually need is someone with a wide enough knowledge of the codebase, that continuously uses master and tests, poking people when regressions happen? (especially in areas far from what one usually works in, since for own area proximity blindness can happen) this kindof happens already, but there isn't anythng formal about it Maybe the solution is to have extra milestone, do extra alpha/beta, let distribution handle the testing work. That would be much more helpful for doing it from KDE side. kubuntu project-neon? I can hardly imagine an easier way to test it. Granted, not everyone is using Kubuntu, but I do think that other distros could do similar (not looking into a particular direction, but there's a Geeko on my desk) I guess another problem is, KDE devs are also KDE user themselves, which means unless they have extra machine for clean test, people will be much more lazy to test all changes since keeping two desktop environment and do all UI hard test is hardly impossible. Obviously, at least in KDE 4.10, people don't pull all changes all the time. That's clearly a problem. I always think that I have a complete unique software stack. A random pull of kdelibs + a random pull of kde-workspace and git master + patches on KWin. It's very seldom that I actually pull in the latest changes, basically just when I need to restart the system. Back in the days of early 4.x I did rebuild almost every day. To me it's a sign that our software got better, I don't have the need to rebuild just to get the latest bug fix and most components are so feature complete that I don't need the yet latest feature. It's then only if I see a blog post which motivates me to try out the latest version (as just happened with Marble). 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: Re: reflecting on 4.10
On Saturday 12 January 2013 00:52:36 Luca Beltrame wrote: In data venerdì 11 gennaio 2013 22:58:49, Martin Gräßlin ha scritto: Granted, not everyone is using Kubuntu, but I do think that other distros could do similar (not looking into a particular direction, but there's a Geeko on my desk) OpenSUSE has KDE:Unstable:SC which is made up of (regularly) updated snapshots of current git master. yes, but you cannot install it into a different directory AFAIK. It overwrites your stable installation. 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
