Re: Workflow Idea for 4.10
Hello fellow plasma devs! Ping? Any info on there issues? I understand I'm not a core dev yet, so probably not enough experience to talk about workflows and affect decisions, but these are some really existing issues with the Gerrit system as used in Qt development. Bet regards, Ignat Semenov Ignat Semenov wrote: Hello fellow KDE devs! While I'm not an experienced developer nor manager, the planned transition to gerrit really troubles me. In particular, I have the following questions: 1)The gerrit installation used in qt makes it impossible to add comments other than directly to the diff. No way to add comments on the main review request page as it is in the RB installation we're currently using. Is there any way to overcome that limitation? 2)The user interface of gerrit is horrible to say the least. The diff / comment area is the last class citizen there. RR is way more clear and user- friendly (esp. newcomers). 3)Does this transition mean we will have to use the full gerrit contribution cycle, like it is in qt now, with branches and the special tools, even for the smallest fixes? This will drive off new contributors, I'm afraid. 4)The Qt gerrit installation requires authentication just to browse the existing requests read-only. Is it possible to do it differently or is this a shortcoming of gerrit ( or its design feature)? Pretty user- and newcomer-unfriendly, too. Best regards, Ignat Semenov Oh, and One More Thing (TM).It is impossible to add a detailed description to the change with the Qt installation of gerrit. You can only use the commit message for that, and commit messages, while in theory unlimited, still have some rules applied to them, and present only the gist of the change. What if I want to elaborate on the reasons of a particular design / code decision, or tell a story of the various approaches attempted, etc? It is impossible to add any comments or text besides what is in the commit message. Given all those limitations of Gerrit (some of them may actually be the limitations of the Qt Gerrit installation), it looks like a clear downgrade from ReviewBoard to me. Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Friday 16 March 2012 21:31:11 Alexander Neundorf wrote: Sounds good. But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) would be also a really good thing to have. It will make contributing easier. That's pretty much Aaron's point yes. And I clearly see the value in it of course. I've to take into account the current drawbacks identified with the current proposal too though. Would 2) be an option for KDE frameworks ? Could be[*]. But as you probably gathered from my previous email I'm purposefully not jumping on a definitive choice just yet. More options to investigate and consequences to take into account. Regards. [*] If we were to bless a single one, it's the one with most chances to make it as the one size fit all one in my books ATM. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com 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
Hello, On Saturday 17 March 2012 19:23:27 Stephen Kelly wrote: Am I the only person who values browsable history? Repositories where you can run gitk and see something useful. No, you can count me partly in. :-) That said, you shouldn't make the issue worse than it really is. Part of that is a tool issue, we have no good way to vizualize such an history... the real question is: yet? If that's something we can count to see solved later on then no big deal, if not then we have a large upcoming problem which will explode as we use more branches. What Aaron proposed is exactly what CMake does. The result is that if you run gitk, you can't see the actual patches. If you run gitk --first-parent on master you *only* see merges, so the only information you can see is the name of the branch that got merged (which is in the git commit message), not the actual patch, and to see the patches in a topic you have to know the name of the topic. You can't just browse the commits, so you can't practically do post-commit review with gitk, as I do. Using email for that really doesn't work for me for one thing. If I want to look at commits that I vaguely know exist but I don't know which topic branch it came from, I should be able to browse fot that. I have the git repo in front of me, so I should be able to use it without jumping through too many hoops. We're going to have small repos after splitting, not large ones. Having a branch and a merge per patch commit in small repos is way overkill. Let's have readable history instead please. As I pointed out earlier on, *for KDE Frameworks* and because of the splitting, the currently proposed workflow is clearly overkill in most cases. That was my main motive to step back and reevaluate the situation. [...] I think people think that if they're committing in a branch which is not master, that they are 'free' and their commits don't have to build, and that all that matters is that the end result actually gets merged, but that's not really true. We should have history which is both readable and buildable imo. +1, that's the important point which is often overlooked when leaning toward let's feature branch often. The other one which is kind of linked to that, is that it makes it much easier for someone to end up being more isolated, working in the branch for too long reducing communication. Part of the way we get to that is by not encouraging everyone to make lots of branches, encouraging people to have branches in scratch repos if they want to have a branch, and encouraging people to submit to master self contained patches which build instead. Yep, one of my investigations taking into account the profile of the contribution (as mentionned previously) instead of the profile of the component leans toward a similar solution. Making commits that don't build and making mistakes is understandable of course especially for new people (and I sometimes make commits that don't build too), but we should at least aim higher. Agreed. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com 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
Alexander Neundorf wrote: On Friday 16 March 2012, Kevin Ottens wrote: Hello, On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote: [...] this is what really piques my interest: merge based workflow. an integration branch would be fantastic. that branch should rebase periodically off of master and only be used to merge feature branches. this branch would largely take the place of current master: where development happens. feature branches should be merged into integration on a regular basis and developers and testers should track this integration branch in their day-to-day usage integration should always be open to feature branch merging. master should only be open for feature merge when not in freeze, however. when in freeze, either a stabilization branch could be made off of master for this purpose (probably a very good idea for larger fixes) which is then merged down in master at known good points .. or .. master is opened for bug fixes directly in those periods. the latter is probably not as good from a stability POV, but may be more reasonable and less of a workload for people doing the actual work. so what i'm interested in hearing is what sort of branch management scheme would work for people. i'm happy to maintain either an integration or the master branch (but not both). [...] note that the methods being (slowly) adopted for frameworks devel are also moving in the direction noted above. I'd just like to add my 0.02€ here. I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. I'm not 100% sure what the final solution will be but it's likely to end up being a short list of blessed workflows: 1) Full game, one branch per feature with review time in an integration/testing branch before hitting master; 2) Intermediate, one branch per feature with merge in master after reviewers/maintainer validation; 3) Easy, features directly developped in master[1]. Sounds good. But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) would be also a really good thing to have. It will make contributing easier. Would 2) be an option for KDE frameworks ? :/ Am I the only person who values browsable history? Repositories where you can run gitk and see something useful. What Aaron proposed is exactly what CMake does. The result is that if you run gitk, you can't see the actual patches. If you run gitk --first-parent on master you *only* see merges, so the only information you can see is the name of the branch that got merged (which is in the git commit message), not the actual patch, and to see the patches in a topic you have to know the name of the topic. You can't just browse the commits, so you can't practically do post-commit review with gitk, as I do. Using email for that really doesn't work for me for one thing. If I want to look at commits that I vaguely know exist but I don't know which topic branch it came from, I should be able to browse fot that. I have the git repo in front of me, so I should be able to use it without jumping through too many hoops. We're going to have small repos after splitting, not large ones. Having a branch and a merge per patch commit in small repos is way overkill. Let's have readable history instead please. My vote is for 3 (for frameworks in general at least), and if people want to create branches like the actions or colors ones we currently have, lets do that in scratch or personal repos. They can be rebased/squashed to readable patches when the learning about how to create a framework by a contributor is done (that's not useful history). The actions branch should all be squashed into one commit because originally the contributor didn't realize the steps that are needed to make a split (move the files, update some include_directories, give the new framework a name which doesn't have kdeui in it, rename the deprecated and export macros). Currently none of those commits actually build because they don't do all of the necessary steps and even the tip of the branch isn't complete because the export macros haven't been changed. Once the branch is fixed to build, I will squash and rebase it to origin/frameworks to commit. The colors branch also contains lots of commits with typos, fixes for typos, adding missing files, removing stuff from CMake files which should have been removed in previous commits, etc, so I will also fix/squash/rebase that one when it's ready, but likely into more commits. Note that I say I'll do the rebase. I'm not expecting anyone else to have to know how to do it. (In CMake, despite using a new branch for everything they do sometimes request rebases to that the commits are clean). I think people think that if
Re: Workflow Idea for 4.10
On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote: I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. is this to make life better for the maintainer or the developers? one thing that git as used by kde has done so far for me is severely limit my occasional hacker pattern where i dive into a given app or library and do a bit of work to scratch an itch. this is because we now have a gajillion little repositories and as a result i rarely build them these days. this is in large part due to me having kdesrc-build around, but not really using it much. why? partly because it's a change in my workflow (that takes time) and in part because i now have two workflows: one for the KDE projects i work on a lot (where i do no use kdesrc-build, because it is not appropriate there) and those that i just track. with the let everyone pick a workflow approach we'll be making this absurdely worse for Frameworks. i won't even know what workflow to be using when i work on a library, so wave goodbye to my involvement. given that Frameworks really benefits from the occassional developers such as myself fixing things here and there, implementing missing functionality here and there, this should be taken seriously. i know when i said in the past that my involvement with other projects would disipate due to the choices being made around git nobody really cared :) well, it's happened, i'm sure nobody still cares .. and that makes me sad. because i'm one of many. and by being too focused on tools and maintainers rather than developers we are screwing ourselves over. please disabuse yourself of the notion of maintainer chooses and work on a single workflow that all of Frameworks will adhere to for the sanity of all future developers. seriously, this is the should we have a coding style? discussion all over again, isn't it? [1] And before any we should always branch zealot cringe (not blaming you, been there as well), please take a few minutes and read[2]: http://martinfowler.com/bliki/FeatureToggle.html i honestly can't imagine a worse idea for a library like libplasma. -- 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: Workflow Idea for 4.10
On Friday 16 March 2012 12:58:56 Aaron J. Seigo wrote: On Friday, March 16, 2012 00:08:04 Kevin Ottens wrote: I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. is this to make life better for the maintainer or the developers? Both really... If I was still maintaining libsolid for instance (so putting virtual maintainer hat), the very nature of it would make me think that not going for feature branches followed by merges in an integration branch would be dangerous (and libplasma, akonadi, kio are in a similar corner I think) and harder for me to test and review. As a developer? Yes, maybe a bit more work than putting stuff into master, but comparatively to the complexity of the component it's understandable. Now, if I want to contribute a feature in karchive (or kdbusaddons, kplotting), as a developer it'd look silly to me to have to publish a branch, get it merged in an integration branch, push the result, wait for approval and then get that merged in master. Hmm, also probably makes it more work for the maintainer who'd need to test both the feature branch and the integration branch to be able to give a enlightened go/no-go. With the low complexity of something like karchive, everyone would be way better off with a private branch on the developer side and publishing on reviewboard or discussing on a pastebin over IRC. And we have such different products in frameworks. I don't feel like forcing inadequate workflows on them for the sake of it. one thing that git as used by kde has done so far for me is severely limit my occasional hacker pattern where i dive into a given app or library and do a bit of work to scratch an itch. this is because we now have a gajillion little repositories and as a result i rarely build them these days. this is in large part due to me having kdesrc-build around, but not really using it much. why? partly because it's a change in my workflow (that takes time) and in part because i now have two workflows: one for the KDE projects i work on a lot (where i do no use kdesrc-build, because it is not appropriate there) and those that i just track. Of course transition takes time. Now, I wonder what blocks you with kdesrc- build though. I personally manage to use it for everything just fine, it's just that when I jump on a module to work on it I trigger make as usual. Didn't find it disruptive, but I might be missing something. with the let everyone pick a workflow approach we'll be making this absurdely worse for Frameworks. i won't even know what workflow to be using when i work on a library, so wave goodbye to my involvement. Sure, but there's really no good answer here. It's either Meh, absurd workflow for this component I'm too lazy to comply to it, wave goodbye to my involvement or Meh, I've to look up the workflow used here I'm too lazy to do it, wave goodbye to my involvement. (Of course replace lazy, by overworked, overcommitted, overwhelmed as you see fit) Now if someone can point me to a workflow which will work on all the spectrum of components without creating absurd bureaucracy in more than 30% of the cases I'm all ears. Currently I don't have one. given that Frameworks really benefits from the occassional developers such as myself fixing things here and there, implementing missing functionality here and there, this should be taken seriously. And it is, but see above. i know when i said in the past that my involvement with other projects would disipate due to the choices being made around git nobody really cared :) well, it's happened, i'm sure nobody still cares .. and that makes me sad. because i'm one of many. and by being too focused on tools and maintainers rather than developers we are screwing ourselves over. I'm definitely not focused on tools, hoped my previous email made that clear. please disabuse yourself of the notion of maintainer chooses I'll just add a few more thoughts regarding that because of your first question in this email, which I think was a bait to make me claim that it's to allow the maintainer to make his life easier against the developer comfort (in case anyone still wonder: no it's not the motive). As I tried to make clear above, I think what's critical is to have for a given component the right workflow for it. The nature of the components varying greatly, their needs regarding the workflow vary as well. So a workflow will have to balance quality of the outcome vs level of bureaucracy. Now the component itself not being able to tell us what workflow fits best, we have to rely on someone ultimately making the choice. And here the assumption is that the maintainer is among the people with the best overview of the component hence relying on him to pick a solution out of the shortlist. Now of
Re: Workflow Idea for 4.10
Hello, On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote: [...] this is what really piques my interest: merge based workflow. an integration branch would be fantastic. that branch should rebase periodically off of master and only be used to merge feature branches. this branch would largely take the place of current master: where development happens. feature branches should be merged into integration on a regular basis and developers and testers should track this integration branch in their day-to-day usage integration should always be open to feature branch merging. master should only be open for feature merge when not in freeze, however. when in freeze, either a stabilization branch could be made off of master for this purpose (probably a very good idea for larger fixes) which is then merged down in master at known good points .. or .. master is opened for bug fixes directly in those periods. the latter is probably not as good from a stability POV, but may be more reasonable and less of a workload for people doing the actual work. so what i'm interested in hearing is what sort of branch management scheme would work for people. i'm happy to maintain either an integration or the master branch (but not both). [...] note that the methods being (slowly) adopted for frameworks devel are also moving in the direction noted above. I'd just like to add my 0.02€ here. I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. I'm not 100% sure what the final solution will be but it's likely to end up being a short list of blessed workflows: 1) Full game, one branch per feature with review time in an integration/testing branch before hitting master; 2) Intermediate, one branch per feature with merge in master after reviewers/maintainer validation; 3) Easy, features directly developped in master[1]. The choice for a given framework to use one or the other workflow will likely be left up to the maintainer discretion. I guess the criteria to pick a workflow will be: * Overall size of the framework; * Overall number of contributors; * Spread of the contributors in the framework repository (aka how independent from each other contributions are, linked to the internal complexity of the framework); * Automated tests coverage; * Overall modularity of the framework (e.g. lots of small plugins or not); * Probably more that I missed so far. I think that's also relevant to the current discussion at hand for the workspaces. It's reaching a critical mass in size, and you might want to have a similar balanced position instead of a one size fit all being unilateraly applied on every one. Of course kde-workspace is in a different situation since AFAIK there's not plan to have finer grained repositories. In which case one size fit all might sound more realistic to reduce confusion... Just please try to be careful with the oh look shiny cool tool effect (been there...[3]), which generally don't solve social problems or might even create new ones (be careful what you ask, you might get it). Definitely more food for thought than anything in the context of the workspaces. Thought it could help finding the right course. ;-) Regards. [1] And before any we should always branch zealot cringe (not blaming you, been there as well), please take a few minutes and read[2]: http://martinfowler.com/bliki/FeatureToggle.html If you want to be really complete you can also stop by: http://martinfowler.com/bliki/FeatureBranch.html (but maybe not necessary) [2] BTW, Martin Fowler has really great pieces in his bliki it's definitely worth spending time reading in there. [3] And of course regularly fall in the trap again. :-) -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com 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 Friday, March 9, 2012 00:27:51 Alex Fiestas wrote: - Keep the 6 month release period release periods and development periods are not the same thing. the release period is, imho, uninteresting in these kinds of dicussions. we're discussing development process, which is only marginally related to release processes. regardless of the development process, the release process must continue and be aided. - Keep the current schedule (soft freeze, hard freeze...) this, however, is very relevant. :) for release coordination it is fine, but keeping development tied to this is a mistake imo. this should only direct when merging into master can happen, but not constrain what development is actually happening. keep in mind that those who may be creating products around this software, as we have learned in plasma active, simply can not be tied to kde's release cycles. on the other hand, kde needs release cycles and can never time those to match every downstream's needs simultaneously (there are too many downstream schedule conflicts and variance in needs). - Move to a review based workflow before hard freeze (we need gerrit). for certain components, yes. for other non-critical ones, this will just kill what development efforts were put into them for no real gain. every time we raise the bar on development, we shrink the pool of people who will engage. so i'm 100% supportive of the idea to ensure core components are more stable and purposefully developed and less chaotic, but would like to see a process that keeps additional components more freely developed. - Once we are on hard freeze, open merge for everyone so we can continue fixing things easily. review is also important here, of course, as fixes can (and sometimes do) break things. that said: things we have right now and it will allow us to explore the benefits of the merge based workflow. this is what really piques my interest: merge based workflow. an integration branch would be fantastic. that branch should rebase periodically off of master and only be used to merge feature branches. this branch would largely take the place of current master: where development happens. feature branches should be merged into integration on a regular basis and developers and testers should track this integration branch in their day-to-day usage integration should always be open to feature branch merging. master should only be open for feature merge when not in freeze, however. when in freeze, either a stabilization branch could be made off of master for this purpose (probably a very good idea for larger fixes) which is then merged down in master at known good points .. or .. master is opened for bug fixes directly in those periods. the latter is probably not as good from a stability POV, but may be more reasonable and less of a workload for people doing the actual work. so what i'm interested in hearing is what sort of branch management scheme would work for people. i'm happy to maintain either an integration or the master branch (but not both). in any case, i'm personally less interested about the details of the review process (many different ways to do that) and more interested in the branching strategy. note that the methods being (slowly) adopted for frameworks devel are also moving in the direction noted above. -- 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: Workflow Idea for 4.10
Hello fellow KDE devs! While I'm not an experienced developer nor manager, the planned transition to gerrit really troubles me. In particular, I have the following questions: 1)The gerrit installation used in qt makes it impossible to add comments other than directly to the diff. No way to add comments on the main review request page as it is in the RB installation we're currently using. Is there any way to overcome that limitation? 2)The user interface of gerrit is horrible to say the least. The diff / comment area is the last class citizen there. RR is way more clear and user- friendly (esp. newcomers). 3)Does this transition mean we will have to use the full gerrit contribution cycle, like it is in qt now, with branches and the special tools, even for the smallest fixes? This will drive off new contributors, I'm afraid. 4)The Qt gerrit installation requires authentication just to browse the existing requests read-only. Is it possible to do it differently or is this a shortcoming of gerrit ( or its design feature)? Pretty user- and newcomer-unfriendly, too. Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Tue, Mar 13, 2012 at 7:58 PM, Ignat Semenov ragnarok...@gmail.com wrote: Hello fellow KDE devs! While I'm not an experienced developer nor manager, the planned transition to gerrit really troubles me. In particular, I have the following questions: 1)The gerrit installation used in qt makes it impossible to add comments other than directly to the diff. No way to add comments on the main review request page as it is in the RB installation we're currently using. Is there any way to overcome that limitation? 2)The user interface of gerrit is horrible to say the least. The diff / comment area is the last class citizen there. RR is way more clear and user- friendly (esp. newcomers). 3)Does this transition mean we will have to use the full gerrit contribution cycle, like it is in qt now, with branches and the special tools, even for the smallest fixes? This will drive off new contributors, I'm afraid. Direct contributions by those people who have a KDE Developer account will always be possible and will never be forced to go through Gerrit. Whilst code review is a nice thing, it is completely unnecessary with trivial changes or minor bugfixes. How it is used with larger changes is up to the projects themselves - but use of it will never be compulsory - direct access will always be available. 4)The Qt gerrit installation requires authentication just to browse the existing requests read-only. Is it possible to do it differently or is this a shortcoming of gerrit ( or its design feature)? Pretty user- and newcomer-unfriendly, too. Best regards, Ignat Semenov ___ 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
Re: Workflow Idea for 4.10
Ben Cooksley wrote: On Tue, Mar 13, 2012 at 7:58 PM, Ignat Semenov ragnarok...@gmail.com wrote: Hello fellow KDE devs! While I'm not an experienced developer nor manager, the planned transition to gerrit really troubles me. In particular, I have the following questions: 1)The gerrit installation used in qt makes it impossible to add comments other than directly to the diff. No way to add comments on the main review request page as it is in the RB installation we're currently using. Is there any way to overcome that limitation? 2)The user interface of gerrit is horrible to say the least. The diff / comment area is the last class citizen there. RR is way more clear and user- friendly (esp. newcomers). 3)Does this transition mean we will have to use the full gerrit contribution cycle, like it is in qt now, with branches and the special tools, even for the smallest fixes? This will drive off new contributors, I'm afraid. Direct contributions by those people who have a KDE Developer account will always be possible and will never be forced to go through Gerrit. Whilst code review is a nice thing, it is completely unnecessary with trivial changes or minor bugfixes. How it is used with larger changes is up to the projects themselves - but use of it will never be compulsory - direct access will always be available. OK, I see. Actually, there is a bit of a problem there ATM, in my opinion, in that very few projects seem to be using ReviewBoard. Plasma, KWin and Telepathy are the main users of RB, with some occasional kdelibs requests, from what I can see. I think we have a lot more projects being developed? :) 4)The Qt gerrit installation requires authentication just to browse the existing requests read-only. Is it possible to do it differently or is this a shortcoming of gerrit ( or its design feature)? Pretty user- and newcomer-unfriendly, too. Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Regards, Ben Cooksley KDE Sysadmin Oh, and One More Thing (TM).It is impossible to add a detailed description to the change with the Qt installation of gerrit. You can only use the commit message for that, and commit messages, while in theory unlimited, still have some rules applied to them, and present only the gist of the change. What if I want to elaborate on the reasons of a particular design / code decision, or tell a story of the various approaches attempted, etc? It is impossibel to add any comments or text besides what is in the commit message. Given all those limitations of Gerrit (some of them may actually be the limitations of the Qt Gerrit installation), it looks like a clear downgrade form ReviewBoard to me. Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On Friday 09 March 2012, Alex Fiestas wrote: 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. that's sounds good. to me the ideal(tm) would be to not have much open/frozen master periods but rather have a master that is always in a releasable state, so a bit more destructured, but that seems even harder and this seems a good first step for it -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On each occasion the conclusion reached was that Gerrit would be difficult to maintain and would increase the complexity involved for pre-existing contributors. On big/complex projects contributors are using branches instead of the reviewboard, because it is to difficult to keep track on which changes has be done. Also with git diff it is more difficult to avoid git conflicts. Furthermore testing big patches with git diff is not possible. For examples on kdelibs-frameworks. So contributors MUST learn how to handle git branches and merges between their branch and the origin one. Which sometimes, is very stressful for the contributor, also some mistakes are happen. And as a result of that, the mentors and the contributors are losing a lot of time in order to fix those. 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. In my opinion, before we make a big change into our infrastructure, we must first test it. Because without testing, we cannot be sure if the new infrastructure is useful/harmful for our community. Also big changes like that should not be applied in the whole KDE. Because they might create some panic. So in my opinion the best think that we have to do is to search for some teams which they want to test it, and based on the result, then we can either start applied the new infrastructure to the whole KDE or we could just reject the idea. Of course a new infra might not cover our needs with its original structure, so we could keep both gerrit and reviewboard. And as regards the contributors, they can choose which one they want to use. Also when KDE moved from svn to git, the amarok was one of the projects which was moved to the gitorious. In order to test if the gitorious fit our needs. So since we are talking about the infra i do not see a valid reason for which we should not do the same here. As regards the ssh keys, gerrit allows the contributor to upload his ssh key and a trusted user to approve it. So this close the security issue. Also in order for someone to take git access, he need someone to approve him. So it is clear that when a developer from plasma,kwin,kdelibs,amarok etc is approving someone then it is his own responsibility to choose wise, before he says the ok. As regards the contributor, it is clear enough that people that don't know how to copy/paste their ssh key into gerrit, that they don't even know what git means. So those people are not ready to have access on those tools. They could simple use the reviewboard. Of course the above idea is just a work around, i don't say that this will be our policy but until we decide if gerrit is good for us or not, then it will simple do its work :) - 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. After we test gerrit, we could simple decide if we have the infra which is required or not. Also on active projects, the mentors are using the commitfilter.kde.org and the rss from the projects.kde.org, so they could see if there is a bug or some kind of an abuse. After all this is the meaning of the testing. EVERY change into the infra might cause some security issues but there is nothing that we can do with that. Also your custom patches might not work without a little adjustment BUT when you rewrite an application or the infra this is something that cannot be avoid. Also if we always want to have an application/infra which was going to be 98% secure (there is nothing like 100% SAFE :)) then we shouldn't move from git to svn and we shouldn't move from KDE3 to KDE4. In every thing there are cons and ads. The point is if there are more ads than the cons. :) Also KDE4 is much bigger than the KDE3 was. And KDE5 will be even bigger. So we must change our infra in order the mentors will not lose time trying to fix the mistakes of the contributors which might happen because of a bad merge or push. Also gerrit can build projects or try to see if their unit tests are 100% ok. So WITH GERRIT will we be able to reduce the REGRASSIONS!!! In conclusion, i think that we should use gerrit because it will simple make our lives easier and our code better :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
On 9 March 2012 01:27, Alex Fiestas afies...@kde.org wrote: - Move to a review based workflow before hard freeze (we need gerrit). That's really great. We need gerrit and I hope that we will have it available soon. The usage of gerrit has some cons but eventually we have to use it. 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
Re: Workflow Idea for 4.10
Hello, 2012/3/9 Alex Fiestas afies...@kde.org: 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. As many of you might know, I have been a strong advocate of such a thing for quite some time and I cannot be more in agreement with Alex here. I think we should really improve the way our reviews are handled, and enforce more control over the quality of our code. 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 ___ 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
