Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi! On Thu, 09 Jul 2015, Rich Freeman wrote: On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann klaus...@gentoo.org wrote: What I meant is when I get a stabilization bug for cat-egory/foo-1.2.3 which depends on =other-cat/bar-1.0.5. The latter is amd64 but not alpha or ~alpha. And it, in turn, has yet more deps in the same vein. Now I have several options: If bar-1.0.5 isn't alpha or ~alpha, then foo-1.2.3 shouldn't be ~alpha either, and repoman should complain about this for any non-dev/exp arches. What can I say? Apparently some devs file stabilization bugs without checking these things. I run repoman full before committing anything, so that's where the buck stops. If it isn't ~alpha to begin with, then it shouldn't be going stable on alpha. Ack. Hence my mention of keyword and soak. I am confident that nobody here would argue that casual stabilization bugs are okay and the arch teams should just suck it up. But unfortunately, it still happens. Regards, Tobias -- Sent from aboard the Culture ship GCU (River Class) Displacement Activity
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann klaus...@gentoo.org wrote: What I meant is when I get a stabilization bug for cat-egory/foo-1.2.3 which depends on =other-cat/bar-1.0.5. The latter is amd64 but not alpha or ~alpha. And it, in turn, has yet more deps in the same vein. Now I have several options: If bar-1.0.5 isn't alpha or ~alpha, then foo-1.2.3 shouldn't be ~alpha either, and repoman should complain about this for any non-dev/exp arches. If it isn't ~alpha to begin with, then it shouldn't be going stable on alpha. I do agree that at the first bump that triggers the need to drop alpha keywords (testing or stable) there should be a keyword request submitted to the alpha team to get that sorted out. They could choose at that time to do the testing/keywording/etc to get foo-1.2.3 back onto ~alpha so that it is ready to be stabilized at the right time (or at least with less delay), or they could choose at that time to just leave the keywords off in which case they aren't pestered about stabilization. -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi! On Thu, 09 Jul 2015, Steev Klimaszewski wrote: On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: The truly arch-dependent bugs are what wastes my time: For example: - dependencies not being keyworded for arch or ~arch but only amd64/~amd64 - dependencies not even building on ~arch, but on ~amd64 - package assuming availability of gcc/ghc/Python-X.Y when arch/~arch only has something for Y or X - my favourite: assuming udev is at version X for arch/~arch when it has been broken there for roughly twelve kernel versions due to udev/systemd upstream not caring. The information is one equery-y command line away, but no, let's file that bug. That's a failing of the arch team or the committer then - or whomever keyworded the package without testing the dependencies. That's why the keywording bugs happen when dependencies change - and yes, occasionally a dependency loses it's keywords and that may be where the issue comes from, I'm not sure. This used to be watched very closely, but I believe the tool being used broke at some point. What exactly do you mean, it's just one command line away but let's file the bug - yes a bug SHOULD be filed, so that the people know of the issue so it doesn't get repeated, over and over. What I meant is when I get a stabilization bug for cat-egory/foo-1.2.3 which depends on =other-cat/bar-1.0.5. The latter is amd64 but not alpha or ~alpha. And it, in turn, has yet more deps in the same vein. Now I have several options: 1/ Pull in all dependencies and test them. This may mean I have to let the deps soak in ~alpha for 30 days, leading the original dev to complain that the arches are slow. 2/ Try and figure out if I can mask a USE flag on foo-1.2.3 that avoids the dependency. If there isn't I can try and make one, which leads into another hell of dep chasing for revdeps of foo-1.2.3. 3/ Complain on the bug that the maintainer of foo-1.2.3 should figure out the deptrees before CCing arches. 4/ Opt out of stabilization for foo-1.2.3 If it turns out that bar-1.0.5 or one of its deps breaks a completely unrelated package, I get to revert all of this until a fix is found. And then do it all over again. What instead should happen: The maintainer of cat-egory/foo sees that 1.2.3 has a new dep, which is =other-cat/bar-1.0.5. A quick check with equery* shows that it isn't stable/keyworded for alpha and hppa. Thus, the maintainer files a bug for bar-1.0.5 to be stable on alpha and hppa, possibly/ideally checking with bar's maintainer. The stabilization for foo-1.2.3 on amd64 can continue, just don't CC alpha and hppa yet. Once bar-1.0.5 is stable (or alpha/hppa have opted out), CC them on the foo-1.2.3 bug. *(An alternative is to add all the keywords you want and run repoman full. Just don't accidentally commit that edit.) The bad case (ignoring the non-amd64 deptree) is not the majority, but it's a very frustrating and time consuming experience for archtesters. Often, the deptrees for the minor archs are broken in subtly different ways, resulting in the time wasting to be multiplied. Option #3 above I have shied away from, since it would feel sort of aggressive, pedantic and picky when that is not really in my nature. If everyone is okay(ish) with it, I'll start doing it. Having every arch team chase the deps for every package is very, very frustrating, since it is so trivial a problem. We need a tool that answers the question: I want to mov cat/pkg-1.2.3 to stable for arches a, b and c, what do I need? for _every package_. Some groups seem to have tooling for this, but it is far from easily (obviously?) available, so every team gets to re-discover dependency hell. Ruby is especially bad since FEATURES=test make the depgraph explode (and sometimes circular). The only fear I have about CI, is that we turn into every other distro out there where it builds, ship it! - I know I prefer to have our arm team actually test the packages more than just doing FEATURES=test (assuming the tests aren't broken on arm) emerge, although I know there are some people on the team who feel that it's too much to actually test all of the arm boards. For a long time, certain binary distros were compiling anything and everything, and if it built for other arches it was available. Even if there was no way it would possibly work on that arch. We're already partway down that road of IC,SI. For Alpha, it's not because we don't want to, but rather because we know that if we do it 100% properly, we will quickly fall even further behind. I guess we do speculative testing: If it compiles+tests, great. If the package actually breaks, a user will surely tell us. Yes, CI is nice to have if you have the hardware to do it. But if parts of our workflow start depending on it, we will quickly lose the minor archs. Regards, Tobias -- prom_printf(No VAC. Get some bucks and buy a real computer.);
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman ri...@gentoo.org wrote: On Thu, Jul 9, 2015 at 5:31 AM, hasufell hasuf...@gentoo.org wrote: The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially pull in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes and no. I'll agree that with a review workflow we might only need one reviewer for every 10 contributors, or something like that. If we have 100 active devs today, in theory we could instead turn 20 of them into reviewers, and now we can support 2000 contributors. There are some big assumptions with this kind of argument, though: 1. We might find that we don't even have 20 devs interested in doing a substantial amount of review. 2. The main repository is very diverse. If 50% of our packages have only one person interested in maintaining them, then they get dropped since reviewers will ignore their contributions. Or, they'll just rubber-stamp them which is adding valueless work. So, a review system could make manpower either more of an issue or less of one. I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, and a new crop signs up who is interested in using the new workflow, and then they're starting with zero experience. I think a review model is best implemented by individual project teams. They could use it to track changes in an overlay or branch in the main tree, and then move those into the main tree using whatever quality system seems best. The team can figure out what is working best for it, and if over time a large number of devs feel that it is a good way to work we could then talk about doing it with the main tree. I still suspect we'll end up having problems with the 70% of packages that don't fall into a project though. So basically Gentoo Sunrise? :) -A -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/09/2015 10:45 AM, Alec Warner wrote: On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman ri...@gentoo.org mailto:ri...@gentoo.org wrote: On Thu, Jul 9, 2015 at 5:31 AM, hasufell hasuf...@gentoo.org mailto:hasuf...@gentoo.org wrote: The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially pull in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes and no. I'll agree that with a review workflow we might only need one reviewer for every 10 contributors, or something like that. If we have 100 active devs today, in theory we could instead turn 20 of them into reviewers, and now we can support 2000 contributors. There are some big assumptions with this kind of argument, though: 1. We might find that we don't even have 20 devs interested in doing a substantial amount of review. 2. The main repository is very diverse. If 50% of our packages have only one person interested in maintaining them, then they get dropped since reviewers will ignore their contributions. Or, they'll just rubber-stamp them which is adding valueless work. So, a review system could make manpower either more of an issue or less of one. I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, and a new crop signs up who is interested in using the new workflow, and then they're starting with zero experience. I think a review model is best implemented by individual project teams. They could use it to track changes in an overlay or branch in the main tree, and then move those into the main tree using whatever quality system seems best. The team can figure out what is working best for it, and if over time a large number of devs feel that it is a good way to work we could then talk about doing it with the main tree. I still suspect we'll end up having problems with the 70% of packages that don't fall into a project though. I think everybody is getting a bit heated over CI/Quality/automation, when clearly there is no good reason to get so heated. Let me explain. YES industry, commercial, research, FOSS and everybody is moving to some sort of paradigm where as much automation of code examination is streamline. Surely these efforts are a work in progress and as such will evolved over time. It does not mean the existing, wonderfully manual processes are being replaced, it just means that the simple, routine, (scriptable if you like) filters are automated. In fact those manual processes still need to occur, because the next generation of coders have to learn how things work in order to extent the paradigm. Resources. Surely the major arches are at an advantage. But the current cluster offerings are soon going to render very powerful processing so even gargantuan, single threaded codes can be automated for CI, quality, security etc etc. Both a cross-compile and native compile strategy needs to experimented with. Those smaller arches will follow the bigger arches; so in that we should just let x86 and other such arches blaze the path for gentoo (in a non binding manner) while the various other arches (with more humble resources) figure out how to build clusters on these other arches. Lots of folks are clustering smalller arches to get big tasks back into the realm of viability. The big benefit for those other (more constrained arches) is that folks that build embedded products on those arches will be very, very interested in work on how to build a cluster, specific to those (sub) arches for CI/quality/security. In fact mesos-distcc does not limit the various arch types. So I would think all arches would get on-board and just follow this paradigm in an easy, non-stressful manner. But the Gentoo leadership does have a responsibility to include those other arches in just how this occurs, during some extended transition period, so that these other arch's still fell like they are part of this extended gentoo family. Loosing those arches would be a horrible damage to gentoo's reputation, imho. That is our diversity in arches is something gentoo is widely know for and sets us apart, imho. hth, James
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 11:45 AM, Alec Warner anta...@gentoo.org wrote: On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman ri...@gentoo.org wrote: Lots of stuff except for the part below. So basically Gentoo Sunrise? :) In any case, to some extent the review workflow already exists on the proxy maintainer project. There is no limit to the number of packages they can maintain, or the number of reviewers they can have. Answered and asked. :) -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, 09 Jul 2015 00:11:34 -0500 Steev Klimaszewski st...@gentoo.org wrote: The only fear I have about CI, is that we turn into every other distro out there where it builds, ship it! This would be an improvement over the current situation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/09/2015 01:47 PM, Rich Freeman wrote: On Thu, Jul 9, 2015 at 5:31 AM, hasufell hasuf...@gentoo.org wrote: The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially pull in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes and no. I'll agree that with a review workflow we might only need one reviewer for every 10 contributors, or something like that. If we have 100 active devs today, in theory we could instead turn 20 of them into reviewers, and now we can support 2000 contributors. There are some big assumptions with this kind of argument, though: 1. We might find that we don't even have 20 devs interested in doing a substantial amount of review. 2. The main repository is very diverse. If 50% of our packages have only one person interested in maintaining them, then they get dropped since reviewers will ignore their contributions. Or, they'll just rubber-stamp them which is adding valueless work. So, a review system could make manpower either more of an issue or less of one. I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, and a new crop signs up who is interested in using the new workflow, and then they're starting with zero experience. I think a review model is best implemented by individual project teams. They could use it to track changes in an overlay or branch in the main tree, and then move those into the main tree using whatever quality system seems best. The team can figure out what is working best for it, and if over time a large number of devs feel that it is a good way to work we could then talk about doing it with the main tree. I still suspect we'll end up having problems with the 70% of packages that don't fall into a project though. I'm not sure if you followed my argumentation. I basically said that it is unrealistic to enforce a review-only workflow and that it should/can start within gentoo-internal projects. You are just repeating what I already said. My point was that I am not mixing up different issues as Andrew claimed, because a review workflow can be seen in a different context. And then, the repeated argument of not enough manpower for review workflow doesn't make a lot of sense. The problem is the mindest/culture. However, it makes sense to provide review workflow tools. And they have been demanded quite a few times now I think, even from vapier afair.
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 2:56 PM, hasufell hasuf...@gentoo.org wrote: I'm not sure if you followed my argumentation. I basically said that it is unrealistic to enforce a review-only workflow and that it should/can start within gentoo-internal projects. You are just repeating what I already said. My point was that I am not mixing up different issues as Andrew claimed, because a review workflow can be seen in a different context. And then, the repeated argument of not enough manpower for review workflow doesn't make a lot of sense. The problem is the mindest/culture. To an extent I agree with you. However, a workflow that works great for a tight-knit group of 6 devs working on one set of packages that were designed by upstream to work together might not work as well for a set of 50 devs working on 300 packages that are completely independent. We should start with small teams, but I think it remains to be seen if it ever grows to encompass most of the tree. That said, it might grow to cover the core system components and that might be good enough for most purposes. Users might not notice if one of the 15 reversi implementations in the tree breaks, but would prefer that gcc, glibc, and qt be of a higher quality. -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote: On 07/05/2015 08:05 AM, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. People misinterpret manpower. If we successfully switch to a code-review approach, then we will need _less_ manpower in the sense of actual gentoo developers. You're mixing different issues here. Code review process for contributors (outside of development team) will indeed save time and manpower. But code review for each developer commit will kill time and effort undoubtedly, while net quality will have little to negligible improvement. Best regards, Andrew Savchenko pgp40PFnATWYC.pgp Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Wed, Jul 8, 2015 at 10:11 PM, Steev Klimaszewski st...@gentoo.org wrote: On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: Hi! On Wed, 08 Jul 2015, Ciaran McCreesh wrote: On Wed, 8 Jul 2015 20:07:34 +0200 Tobias Klausmann klaus...@gentoo.org wrote: In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. It works on amd64 on a clean build system is a heck of a lot better than it may or may not work on one developer's heavily modified box... The point of testing is not to catch all problems. It's just there to catch some simple screwups, cheaply. Agreed. Still, in my experience, problems that are not seen on amd64 are the vast majority of timesinks. Usually, by the time non-amd64 shows up on a non-security bug, the Basic Bullshit™ has been sorted. And even if it isn't: Arches are usually quick to point it out and the rest of arches move on to the next bug. The truly arch-dependent bugs are what wastes my time: For example: - dependencies not being keyworded for arch or ~arch but only amd64/~amd64 - dependencies not even building on ~arch, but on ~amd64 - package assuming availability of gcc/ghc/Python-X.Y when arch/~arch only has something for Y or X - my favourite: assuming udev is at version X for arch/~arch when it has been broken there for roughly twelve kernel versions due to udev/systemd upstream not caring. The information is one equery-y command line away, but no, let's file that bug. That's a failing of the arch team or the committer then - or whomever keyworded the package without testing the dependencies. That's why the keywording bugs happen when dependencies change - and yes, occasionally a dependency loses it's keywords and that may be where the issue comes from, I'm not sure. This used to be watched very closely, but I believe the tool being used broke at some point. What exactly do you mean, it's just one command line away but let's file the bug - yes a bug SHOULD be filed, so that the people know of the issue so it doesn't get repeated, over and over. Having every arch team chase the deps for every package is very, very frustrating, since it is so trivial a problem. We need a tool that answers the question: I want to mov cat/pkg-1.2.3 to stable for arches a, b and c, what do I need? for _every package_. Some groups seem to have tooling for this, but it is far from easily (obviously?) available, so every team gets to re-discover dependency hell. Ruby is especially bad since FEATURES=test make the depgraph explode (and sometimes circular). Regards, Tobias The only fear I have about CI, is that we turn into every other distro out there where it builds, ship it! - I know I prefer to have our arm team actually test the packages more than just doing FEATURES=test (assuming the tests aren't broken on arm) emerge, although I know there are some people on the team who feel that it's too much to actually test all of the arm boards. For a long time, certain binary distros were compiling anything and everything, and if it built for other arches it was available. Even if there was no way it would possibly work on that arch. So don't keyword or stabilize packages you don't test thoroughly. I see how CI *could* be used to do bad things; but I don't see anyone proposing it be used in that way; nor do you have to accept such suggestions (its your arch, after all.) -A Regards, Steev
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 5:31 AM, hasufell hasuf...@gentoo.org wrote: The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially pull in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes and no. I'll agree that with a review workflow we might only need one reviewer for every 10 contributors, or something like that. If we have 100 active devs today, in theory we could instead turn 20 of them into reviewers, and now we can support 2000 contributors. There are some big assumptions with this kind of argument, though: 1. We might find that we don't even have 20 devs interested in doing a substantial amount of review. 2. The main repository is very diverse. If 50% of our packages have only one person interested in maintaining them, then they get dropped since reviewers will ignore their contributions. Or, they'll just rubber-stamp them which is adding valueless work. So, a review system could make manpower either more of an issue or less of one. I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, and a new crop signs up who is interested in using the new workflow, and then they're starting with zero experience. I think a review model is best implemented by individual project teams. They could use it to track changes in an overlay or branch in the main tree, and then move those into the main tree using whatever quality system seems best. The team can figure out what is working best for it, and if over time a large number of devs feel that it is a good way to work we could then talk about doing it with the main tree. I still suspect we'll end up having problems with the 70% of packages that don't fall into a project though. -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Rich Freeman wrote: I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, I think you're right. I also think those developers should quit right here and now. I don't think they will. //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/09/2015 09:19 AM, Andrew Savchenko wrote: On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote: On 07/05/2015 08:05 AM, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. People misinterpret manpower. If we successfully switch to a code-review approach, then we will need _less_ manpower in the sense of actual gentoo developers. You're mixing different issues here. Code review process for contributors (outside of development team) will indeed save time and manpower. But code review for each developer commit will kill time and effort undoubtedly, while net quality will have little to negligible improvement. No, I am not mixing issues here. The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially pull in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes, it will slow down random commits. And sometimes that is what you need to keep good quality up. But as I said, this is currently not realistic, but not because it cannot be done. It can. And there are lots of projects that do. And I don't mean small projects. Most of the confusion comes from the fact that some gentoo devs have been doing this broken workflow for so long that they can barely imagine a workflow that is not broken. The other problems comes from the fact that a huge potential contributor base has withdrawn from contributing to the tree and now sticks to overlays. Those are our main problems, not tools. And because of that, a workflow transition will have to be executed step-wise.
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Thu, Jul 9, 2015 at 8:25 AM, Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: I suspect that trying to force it would basically end up putting the entire distro on hold until most of the current devs quit, I think you're right. I also think those developers should quit right here and now. I don't think they will. The thing is that if a bunch of devs want to create a review-only Gentoo fork they can just do it. The result would be about the same. Trying to force it on Gentoo would just result in most of the Gentoo devs changing the name and proceeding basically as it is, and Gentoo would just become another XFree86. The way you change an FOSS project is to influence the current contributions, or to make contributions of your own. Trying to order people around doesn't really change anything in the end. Hence my suggestion to try something like this out in a project where there is interest. Build from success, and win people over. In the end the hard power of a body like the Council is just the power to halt progress, not create it. That power should be focused on situations where the progress is self-destructive. Obviously a body like the Council also has soft powers like leadership/etc, but that really isn't enough to just order change by fiat. Plus, we're all elected for our ability to generally represent the will of the developer community, so you shouldn't be too surprised when we don't try to push policies that most devs disagree with. In any case, to some extent the review workflow already exists on the proxy maintainer project. There is no limit to the number of packages they can maintain, or the number of reviewers they can have. -- Rich
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Wed, 8 Jul 2015 20:07:34 +0200 Tobias Klausmann klaus...@gentoo.org wrote: In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. It works on amd64 on a clean build system is a heck of a lot better than it may or may not work on one developer's heavily modified box... The point of testing is not to catch all problems. It's just there to catch some simple screwups, cheaply. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi! This got a bit rambly, sorry 'bout that. tl;dr: Continuous Integration is a neat idea if you have the Hardware. The off-mainstream arch teams don't. On Tue, 07 Jul 2015, Ciaran McCreesh wrote: On Tue, 07 Jul 2015 08:04:47 +0800 Patrick Lauer patr...@gentoo.org wrote: I'll laugh about it next time I update OpenFOAM: Fri Jun 27 12:52:19 2014 sci-libs/openfoam-2.3.0 merge time: 1 hour, 5 minutes and 8 seconds. or Sun Jun 29 20:36:09 2014 sci-mathematics/nusmv-2.5.4 merge time: 2 hours, 58 minutes. What's the problem? Better the build bot wastes that time once than a whole bunch of users do. Just be aware that that Just Won't Happen for the off-mainstream archs. We just don't have the hardware to keep up with something like that. Unless you want to employ several people reordering the CI checks so a test for glibc doesn't make mutt, util-linux, iptables and 55 other packages wait for hours. 'Cause invariably, if the CI system is delayed beyond the expectation for the package itself, it will be ignored. It would also mean that the other purposes the devboxes are used for will be delayed non-trivially. In the case of Alpha, that would for example be upstream gcc testing, and stage3 building. I am sure arches like PPC64, IA64 and so on have the same problem. That's without dependencies, so from a clean minimal starting point (once you figure out what useflags are needed) you're looking at 12+ hours of walltime to get that checked. (On a reasonably modern Xeon with SSDs ...) Uh, no, because you use binary packages for the dependencies, and you use a package mangler that can figure out the use flags for you. Even with binary package usage (which is not as efficient as it could be due to USE flags), testing Qt4 (as in compile it and run the test suite, which is the bare minimum) took me close to 10 hours the other day. Not including fixing fetch problems halfway through. During this time, very little else got done on the one devbox we have. So thanks for your intentional comedy, but let's be serious here. Exherbo's been doing all this for years, and it works rather well. The only comedy is that Gentoo doesn't even realise this is trivial to do nowadays. Exherbo is not supporting as many off-mainstream architectures as we do, so the comparison is flawed at best. Yes, sure, let's run CI for amd64 and maybe x86 and whoever else has the hardware. But it will not speed up stabilization bugs regarding the long tail. It might even lead to people completely ignoring the slow architectures and the rift between amd64 and the rest becoming yet wider. Don't get me wrong, abandoning Alpha and other architectures is an option, but remember that for some of these, we are the last distro that still provides install media and a decent (as in: current and complete-ish) set of packages. The very fact that we are able to let amd64 and the rest drift a bit is the reason why we can still pull it off. I have considered dropping Alpha entirely (for myself, that is; I'd resign as the arch team lead and stop working on it; the devbox, which is soft-donated through me, would stay available). But I would rather not, for various reasons, none of which are technical. Then again, I'm not a Gentoo dev because it makes sense rationally (it does, but it's not my reason). In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. Regards, Tobias` -- Sent from aboard the Culture ship GSV (System Class) Empiricist
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/08/2015 09:14 PM, Tobias Klausmann wrote: I explicitly point out that amd64 is welcome to do whatever they want regarding CI, but that I suspect that the rift between it and the lesser architectures will become wider. That is technically correct, but it's not really an argument. The quality of the lesser arches will be the same as it was before, it will not get worse. The quality of the different arches has _never_ been consistent. Not even between x86 and amd64. It always depends on manpower, resources and how much it is used in the community. I feel we are drifting a bit offtopic.
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Wed, 2015-07-08 at 21:11 +0200, Tobias Klausmann wrote: Hi! On Wed, 08 Jul 2015, Ciaran McCreesh wrote: On Wed, 8 Jul 2015 20:07:34 +0200 Tobias Klausmann klaus...@gentoo.org wrote: In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. It works on amd64 on a clean build system is a heck of a lot better than it may or may not work on one developer's heavily modified box... The point of testing is not to catch all problems. It's just there to catch some simple screwups, cheaply. Agreed. Still, in my experience, problems that are not seen on amd64 are the vast majority of timesinks. Usually, by the time non-amd64 shows up on a non-security bug, the Basic Bullshit™ has been sorted. And even if it isn't: Arches are usually quick to point it out and the rest of arches move on to the next bug. The truly arch-dependent bugs are what wastes my time: For example: - dependencies not being keyworded for arch or ~arch but only amd64/~amd64 - dependencies not even building on ~arch, but on ~amd64 - package assuming availability of gcc/ghc/Python-X.Y when arch/~arch only has something for Y or X - my favourite: assuming udev is at version X for arch/~arch when it has been broken there for roughly twelve kernel versions due to udev/systemd upstream not caring. The information is one equery-y command line away, but no, let's file that bug. That's a failing of the arch team or the committer then - or whomever keyworded the package without testing the dependencies. That's why the keywording bugs happen when dependencies change - and yes, occasionally a dependency loses it's keywords and that may be where the issue comes from, I'm not sure. This used to be watched very closely, but I believe the tool being used broke at some point. What exactly do you mean, it's just one command line away but let's file the bug - yes a bug SHOULD be filed, so that the people know of the issue so it doesn't get repeated, over and over. Having every arch team chase the deps for every package is very, very frustrating, since it is so trivial a problem. We need a tool that answers the question: I want to mov cat/pkg-1.2.3 to stable for arches a, b and c, what do I need? for _every package_. Some groups seem to have tooling for this, but it is far from easily (obviously?) available, so every team gets to re-discover dependency hell. Ruby is especially bad since FEATURES=test make the depgraph explode (and sometimes circular). Regards, Tobias The only fear I have about CI, is that we turn into every other distro out there where it builds, ship it! - I know I prefer to have our arm team actually test the packages more than just doing FEATURES=test (assuming the tests aren't broken on arm) emerge, although I know there are some people on the team who feel that it's too much to actually test all of the arm boards. For a long time, certain binary distros were compiling anything and everything, and if it built for other arches it was available. Even if there was no way it would possibly work on that arch. Regards, Steev
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann klaus...@gentoo.org wrote: Hi! This got a bit rambly, sorry 'bout that. tl;dr: Continuous Integration is a neat idea if you have the Hardware. The off-mainstream arch teams don't. Clearly because we cannot be perfect, we should not even try! Realistically aside from the major arches none of the other arches have large userbases. I think quality for the sake of quality is pretty silly; but if we can improve the quality of arches where hardware is readily available we should do so (regardless of minority architecture objections.) -A On Tue, 07 Jul 2015, Ciaran McCreesh wrote: On Tue, 07 Jul 2015 08:04:47 +0800 Patrick Lauer patr...@gentoo.org wrote: I'll laugh about it next time I update OpenFOAM: Fri Jun 27 12:52:19 2014 sci-libs/openfoam-2.3.0 merge time: 1 hour, 5 minutes and 8 seconds. or Sun Jun 29 20:36:09 2014 sci-mathematics/nusmv-2.5.4 merge time: 2 hours, 58 minutes. What's the problem? Better the build bot wastes that time once than a whole bunch of users do. Just be aware that that Just Won't Happen for the off-mainstream archs. We just don't have the hardware to keep up with something like that. Unless you want to employ several people reordering the CI checks so a test for glibc doesn't make mutt, util-linux, iptables and 55 other packages wait for hours. 'Cause invariably, if the CI system is delayed beyond the expectation for the package itself, it will be ignored. It would also mean that the other purposes the devboxes are used for will be delayed non-trivially. In the case of Alpha, that would for example be upstream gcc testing, and stage3 building. I am sure arches like PPC64, IA64 and so on have the same problem. That's without dependencies, so from a clean minimal starting point (once you figure out what useflags are needed) you're looking at 12+ hours of walltime to get that checked. (On a reasonably modern Xeon with SSDs ...) Uh, no, because you use binary packages for the dependencies, and you use a package mangler that can figure out the use flags for you. Even with binary package usage (which is not as efficient as it could be due to USE flags), testing Qt4 (as in compile it and run the test suite, which is the bare minimum) took me close to 10 hours the other day. Not including fixing fetch problems halfway through. During this time, very little else got done on the one devbox we have. So thanks for your intentional comedy, but let's be serious here. Exherbo's been doing all this for years, and it works rather well. The only comedy is that Gentoo doesn't even realise this is trivial to do nowadays. Exherbo is not supporting as many off-mainstream architectures as we do, so the comparison is flawed at best. Yes, sure, let's run CI for amd64 and maybe x86 and whoever else has the hardware. But it will not speed up stabilization bugs regarding the long tail. It might even lead to people completely ignoring the slow architectures and the rift between amd64 and the rest becoming yet wider. Don't get me wrong, abandoning Alpha and other architectures is an option, but remember that for some of these, we are the last distro that still provides install media and a decent (as in: current and complete-ish) set of packages. The very fact that we are able to let amd64 and the rest drift a bit is the reason why we can still pull it off. I have considered dropping Alpha entirely (for myself, that is; I'd resign as the arch team lead and stop working on it; the devbox, which is soft-donated through me, would stay available). But I would rather not, for various reasons, none of which are technical. Then again, I'm not a Gentoo dev because it makes sense rationally (it does, but it's not my reason). In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. Regards, Tobias` -- Sent from aboard the Culture ship GSV (System Class) Empiricist
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi! On Wed, 08 Jul 2015, Ciaran McCreesh wrote: On Wed, 8 Jul 2015 20:07:34 +0200 Tobias Klausmann klaus...@gentoo.org wrote: In essence, assuming we can just scale to make CI work is ignoring the matter of the slower archs. And I suspect the it works on amd64, fuck everyone else is not something we want to pick as a motto. It works on amd64 on a clean build system is a heck of a lot better than it may or may not work on one developer's heavily modified box... The point of testing is not to catch all problems. It's just there to catch some simple screwups, cheaply. Agreed. Still, in my experience, problems that are not seen on amd64 are the vast majority of timesinks. Usually, by the time non-amd64 shows up on a non-security bug, the Basic Bullshit™ has been sorted. And even if it isn't: Arches are usually quick to point it out and the rest of arches move on to the next bug. The truly arch-dependent bugs are what wastes my time: For example: - dependencies not being keyworded for arch or ~arch but only amd64/~amd64 - dependencies not even building on ~arch, but on ~amd64 - package assuming availability of gcc/ghc/Python-X.Y when arch/~arch only has something for Y or X - my favourite: assuming udev is at version X for arch/~arch when it has been broken there for roughly twelve kernel versions due to udev/systemd upstream not caring. The information is one equery-y command line away, but no, let's file that bug. Having every arch team chase the deps for every package is very, very frustrating, since it is so trivial a problem. We need a tool that answers the question: I want to mov cat/pkg-1.2.3 to stable for arches a, b and c, what do I need? for _every package_. Some groups seem to have tooling for this, but it is far from easily (obviously?) available, so every team gets to re-discover dependency hell. Ruby is especially bad since FEATURES=test make the depgraph explode (and sometimes circular). Regards, Tobias -- Sent from aboard the Culture ship GSV (System Class) Empiricist
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi! On Wed, 08 Jul 2015, Alec Warner wrote: On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann klaus...@gentoo.org wrote: tl;dr: Continuous Integration is a neat idea if you have the Hardware. The off-mainstream arch teams don't. Clearly because we cannot be perfect, we should not even try! Realistically aside from the major arches none of the other arches have large userbases. I think quality for the sake of quality is pretty silly; but if we can improve the quality of arches where hardware is readily available we should do so (regardless of minority architecture objections.) Read what I wrote further down. I explicitly point out that amd64 is welcome to do whatever they want regarding CI, but that I suspect that the rift between it and the lesser architectures will become wider. Regards, Tobias -- Sent from aboard the Culture ship GSV (System Class) Empiricist
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Hi, On Tue, 7 Jul 2015 16:16:02 +1200 Kent Fredric wrote: It would be really nice if we could define some sort of variable in the ebuild itself with a relative cost metric for the ebuilds install time. It wouldn't need to be precise, just ballpark figures so the testing boxes can go Ok, a full build of this will block testing everything else for XUNIT time, is this worth it?. there is no need to increase overhead for developers for a stuff that can be easily generated: just fill a raw build time (without ccache/distcc) during test runs themselves. Best regards, Andrew Savchenko pgpf6H0T2HXJY.pgp Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Tue, 07 Jul 2015 08:04:47 +0800 Patrick Lauer patr...@gentoo.org wrote: On 07/07/15 01:27, Ciaran McCreesh wrote: On Mon, 06 Jul 2015 13:04:35 -0400 Michael Orlitzky m...@gentoo.org wrote: I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. Well, you could at least get your commits reviewed by an automated build system that starts from a clean stage each time. That's better than nothing. I'll laugh about it next time I update OpenFOAM: Fri Jun 27 12:52:19 2014 sci-libs/openfoam-2.3.0 merge time: 1 hour, 5 minutes and 8 seconds. or Sun Jun 29 20:36:09 2014 sci-mathematics/nusmv-2.5.4 merge time: 2 hours, 58 minutes. What's the problem? Better the build bot wastes that time once than a whole bunch of users do. That's without dependencies, so from a clean minimal starting point (once you figure out what useflags are needed) you're looking at 12+ hours of walltime to get that checked. (On a reasonably modern Xeon with SSDs ...) Uh, no, because you use binary packages for the dependencies, and you use a package mangler that can figure out the use flags for you. So thanks for your intentional comedy, but let's be serious here. Exherbo's been doing all this for years, and it works rather well. The only comedy is that Gentoo doesn't even realise this is trivial to do nowadays. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/05/2015 08:05 AM, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. People misinterpret manpower. If we successfully switch to a code-review approach, then we will need _less_ manpower in the sense of actual gentoo developers. However, this does not and cannot happen over night since it requires a shift of thinking and a change of culture, involving the whole community. But if we just want to add more independent committers to the core gentoo tree, then we are definitely making quality worse. I'm not particularly sure that an alternative review-based workflow can work here, given that our workflow has been broken for quite a few years. Such things become a strong habit and may leave some of our developers in confusion. But it could start (and already has, afaik) with project-internal requirements (e.g. kde project demanding reviews). When the different projects increase workflow strictness, it will increase overall strictness as well. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. This is not enough to maintain high quality. I've seen some ebuilds in user overlays which have higher quality than their gx86 counterpart. However, that said... I don't think it currently makes sense to enforce a strict global review workflow. However, we should encourage gentoo-internal projects to become more strict (and e.g. only have one or two pushers).
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Mon, 06 Jul 2015 07:25:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On Sunday 05 July 2015 13:46:10 William Hubbs wrote: On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Agreed. Forcing all commits from developers to go through a code review from another developer before they hit the tree would potentially kill the entire project. I would strongly veto something like this, because we flat out don't have the manpower to keep up with it. ... or you have some pranksters just ok-ing all commits during their morning coffee, independent of content, which would keep things working at the cost of quality ... Spoken like someone who's never used a code review system. Pranksters can no more ok all commits than they can commit whatever they like, since you treat giving +2 permissions like you treat giving push access. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Mon, 06 Jul 2015 19:34:05 +0200 hasufell hasuf...@gentoo.org wrote: On 07/06/2015 07:27 PM, Ciaran McCreesh wrote: On Mon, 06 Jul 2015 13:04:35 -0400 Michael Orlitzky m...@gentoo.org wrote: I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. Well, you could at least get your commits reviewed by an automated build system that starts from a clean stage each time. That's better than nothing. That makes sense. But it will probably have to run on a gentoo infra server. Can you see the problem? I dunno, maybe if you ask the Exherbo people nicely they might share their setup. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/06/2015 07:27 PM, Ciaran McCreesh wrote: On Mon, 06 Jul 2015 13:04:35 -0400 Michael Orlitzky m...@gentoo.org wrote: I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. Well, you could at least get your commits reviewed by an automated build system that starts from a clean stage each time. That's better than nothing. That makes sense. But it will probably have to run on a gentoo infra server. Can you see the problem?
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sat, Jul 4, 2015 at 11:05 PM, Andrew Savchenko birc...@gentoo.org wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. Manpower issues aside, my perception of the project is that speed is valued over quality; and this has been the case for many many years. Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I realize that a subset of the community wants quality and code review is certainly one way to improve quality. I'd be curious how many subprojects use review (I know infra did it informally, particularly when making changes to parts of the infrastructure that we were unfamiliar with; for learning purposes.) I'd also be curious what adoption of a code review system would be like if it was not required (but was available, and perhaps required for specific subprojects that adopt it.) -A And as was already told in this thread, the best is the enemy of the good. In no way we should delay git migration due to possible git review. Best regards, Andrew Savchenko
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or ignorance?) to lack the humility to say that I would prefer my commits to be reviewed by peers. It is obviously easier to stick my head in the sand, but then I should probably keep my crap in an overlay. (I do, and am happy!) If I were committing to gentoo I would want help from my peers to ensure that what I commit is not just done well but also done right. I'd be curious how many subprojects use review I suspect that it's rare. Most developers are in my experience unable to work with review. learning purposes. Another significant benefit of review, besides the obvious quality benefit. I'd also be curious what adoption of a code review system would be like if it was not required (but was available, and perhaps required for specific subprojects that adopt it.) I think this is a lovely idea! I'd really like that setup! //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/06/2015 12:42 PM, Peter Stuge wrote: Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or ignorance?) to lack the humility to say that I would prefer my commits to be reviewed by peers. I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. So what it comes down to is that I would rather have my work reviewed by no one and get committed rather than be reviewed by no one and sit in a review queue for months or years. And while it's not quite as good, the stabilization process serves a similar purpose.
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
hasufell wrote: that said... I don't think it currently makes sense to enforce a strict global review workflow. For the record, neither do I, and I never proposed that it should hold up starting to use Git. //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Mon, 06 Jul 2015 13:04:35 -0400 Michael Orlitzky m...@gentoo.org wrote: I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. Well, you could at least get your commits reviewed by an automated build system that starts from a clean stage each time. That's better than nothing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Mon, Jul 6, 2015 at 9:42 AM, Peter Stuge pe...@stuge.se wrote: Alec Warner wrote: Its difficult to make a large change like all commits require review, particularly for long-time contributors who are expecting to move quickly. I think it's a character flaw (maybe hubris due to lack of experience and/or ignorance?) to lack the humility to say that I would prefer my commits to be reviewed by peers. Oh I'm not making that argument (its a tough one anyway.) I haven't done any research in Gentoo in terms of error rates (how many), who makes errors (newbies? oldbies? everyone?), what the error impact is (minor, major, data loss?), and so on. On my old team at work we had code review, but it did not impact quality very much because (manual) review catches a pretty specific set of conditions some of the time. We had vastly superior quality by adopting linters (to prevent really dumb mistakes that code review also didn't catch consistently) and fast[1] enough automated testing that caught large subsets of other really common errors. Of course, these are all quite low hanging fruit. [1] for some subset of fast; I think tests still took 5 minutes or so. It is obviously easier to stick my head in the sand, but then I should probably keep my crap in an overlay. (I do, and am happy!) If I were committing to gentoo I would want help from my peers to ensure that what I commit is not just done well but also done right. I think the past has proven that not all Gentoo developers feel this way (I never did; although I have not committed to the tree in some time.) I'd be curious how many subprojects use review I suspect that it's rare. Most developers are in my experience unable to work with review. learning purposes. Another significant benefit of review, besides the obvious quality benefit. I'd also be curious what adoption of a code review system would be like if it was not required (but was available, and perhaps required for specific subprojects that adopt it.) I think this is a lovely idea! I'd really like that setup! //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 07/07/15 01:27, Ciaran McCreesh wrote: On Mon, 06 Jul 2015 13:04:35 -0400 Michael Orlitzky m...@gentoo.org wrote: I would love my commits to be reviewed, but I usually don't feel like reviewing anyone else's. That's... not uncommon. Well, you could at least get your commits reviewed by an automated build system that starts from a clean stage each time. That's better than nothing. I'll laugh about it next time I update OpenFOAM: Fri Jun 27 12:52:19 2014 sci-libs/openfoam-2.3.0 merge time: 1 hour, 5 minutes and 8 seconds. or Sun Jun 29 20:36:09 2014 sci-mathematics/nusmv-2.5.4 merge time: 2 hours, 58 minutes. That's without dependencies, so from a clean minimal starting point (once you figure out what useflags are needed) you're looking at 12+ hours of walltime to get that checked. (On a reasonably modern Xeon with SSDs ...) So thanks for your intentional comedy, but let's be serious here. Have fun, Patrick
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 7 July 2015 at 12:04, Patrick Lauer patr...@gentoo.org wrote: So thanks for your intentional comedy, but let's be serious here. It would be really nice if we could define some sort of variable in the ebuild itself with a relative cost metric for the ebuilds install time. It wouldn't need to be precise, just ballpark figures so the testing boxes can go Ok, a full build of this will block testing everything else for XUNIT time, is this worth it?. Then you could have the primary test box exclude things over a certain unit size and adjust the text boxes unit until the workflow is right. ( and then have auxliary boxes that test XUNIT packages on demand or something ). I would also like a flying magical pony. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. And as was already told in this thread, the best is the enemy of the good. In no way we should delay git migration due to possible git review. Best regards, Andrew Savchenko pgpaeQblTgCEP.pgp Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Agreed. Forcing all commits from developers to go through a code review from another developer before they hit the tree would potentially kill the entire project. I would strongly veto something like this, because we flat out don't have the manpower to keep up with it. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. Agreed; I could see something like this being beneficial. William signature.asc Description: Digital signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sunday 05 July 2015 13:46:10 William Hubbs wrote: On Sun, Jul 05, 2015 at 09:05:59AM +0300, Andrew Savchenko wrote: On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Agreed. Forcing all commits from developers to go through a code review from another developer before they hit the tree would potentially kill the entire project. I would strongly veto something like this, because we flat out don't have the manpower to keep up with it. ... or you have some pranksters just ok-ing all commits during their morning coffee, independent of content, which would keep things working at the cost of quality ...
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On 03.07.2015 22:22, Robin H. Johnson wrote: (Breaking the thread, because I believe this topic needs further discussion). On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: Are there still any plans to use a code review system like gerrit that will avoid merges, rebases etc. to the tree by just accepting and serializing patches? Merges are a fact of life, they will be happening. This was included on: https://wiki.gentoo.org/wiki/Gentoo_git_workflow Rebases of already published commits must be avoided. But beyond that, the general discussion was that a code review system was not in the immediate future... If the merge workflow becomes too problematic due to the high rate of change, then we can revisit those systems, to take advantage of their auto-merging functionality, but probably only in combination with the QA testsuites. Using a Code Review System and allowing direct commits are not mutually exclusive. If infra has got time to set it up, this could be an option in addition to direct commits for developers and we could make it obligatory (e.g. for the first month) for new developers. It would also allow proxied maintainers to commit to the tree more easily, as it will require just an additional ack by the proxy maintainer. Manuel signature.asc Description: OpenPGP digital signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
William Hubbs wrote: If we do add a code review system, it should be fully accessible from the command line. Pybugz is almost there for bugzilla; the only thing it lacks is the ability to reply to specific comments. Gerrit is also almost there, it has an ssh interface which is very usable for most operations, but not so much for writing inline comments within patches, which is a nice feature of Gerrit that I would like to use. At the moment I have to revert to the web interface to do it. NP-Hardass wrote: I am unfamiliar with how other big projects that use code review systems. Do they generally make (almost) everyone participate, In coreboot, which admittedly isn't such a big project, my impression is that the introduction of Gerrit has lead to increased participation. Previously patches and review went across the mailing list, and many simply filtered the whole list into a folder. or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On July 4, 2015 1:49:20 PM EDT, Peter Stuge pe...@stuge.se wrote: NP-Hardass wrote: I am unfamiliar with how other big projects that use code review systems. Do they generally make (almost) everyone participate, In coreboot, which admittedly isn't such a big project, my impression is that the introduction of Gerrit has lead to increased participation. Previously patches and review went across the mailing list, and many simply filtered the whole list into a folder. or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? //Peter Well, it was just proposed earlier in the thread that it could be used for non-devs (primarily/only), hence two classes of users, those subjected to review and those not. An alternative is a situation where all users, developer and non developer alike require review with the review requirements different between the two, e.g. devs need one signoff, non devs need two. Additionally, for certain aspects, a hybrid of those two might be useful. A project or herd accepts direct commits to its packages from its members and has code review for non members (with the number of signoffs dependent on the group/content. -- NP-Hardass
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
NP-Hardass wrote: or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? Well, it was just proposed earlier in the thread that it could be used for non-devs (primarily/only), hence two classes of users, those subjected to review and those not. Ah I understand. Personally I think review is just as important for devs as for non-devs. The big win with a review tool/flow is that it becomes *at all possible* for non-devs to contribute efficiently to the project, and if the review tool is good then giving review is also efficient. Some will always be more equal than others, but.. An alternative is a situation where all users, developer and non developer alike require review I feel that this is the only way to achieve the best quality. with the review requirements different between the two I don't feel that this is as useful for quality. Devs produce crap too. It's important that the review flow is well-understood and efficient. It's important that everyone working is *motivated* to participate in review. I've had plenty of experience with smart people who simply do not want to participate in a review flow and that's all it takes for the review flow to fail. //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
I am unfamiliar with how other big projects that use code review systems. Do they generally make (almost) everyone participate, or do they typically restrict review to a certain class of users? -- NP-Hardass On July 4, 2015 4:14:14 AM EDT, Manuel Rüger mr...@gentoo.org wrote: On 03.07.2015 22:22, Robin H. Johnson wrote: (Breaking the thread, because I believe this topic needs further discussion). On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: Are there still any plans to use a code review system like gerrit that will avoid merges, rebases etc. to the tree by just accepting and serializing patches? Merges are a fact of life, they will be happening. This was included on: https://wiki.gentoo.org/wiki/Gentoo_git_workflow Rebases of already published commits must be avoided. But beyond that, the general discussion was that a code review system was not in the immediate future... If the merge workflow becomes too problematic due to the high rate of change, then we can revisit those systems, to take advantage of their auto-merging functionality, but probably only in combination with the QA testsuites. Using a Code Review System and allowing direct commits are not mutually exclusive. If infra has got time to set it up, this could be an option in addition to direct commits for developers and we could make it obligatory (e.g. for the first month) for new developers. It would also allow proxied maintainers to commit to the tree more easily, as it will require just an additional ack by the proxy maintainer. Manuel -- NP-Hardass
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
On Sat, Jul 04, 2015 at 10:14:14AM +0200, Manuel Rüger wrote: On 03.07.2015 22:22, Robin H. Johnson wrote: (Breaking the thread, because I believe this topic needs further discussion). On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: Are there still any plans to use a code review system like gerrit that will avoid merges, rebases etc. to the tree by just accepting and serializing patches? Merges are a fact of life, they will be happening. This was included on: https://wiki.gentoo.org/wiki/Gentoo_git_workflow Rebases of already published commits must be avoided. But beyond that, the general discussion was that a code review system was not in the immediate future... If the merge workflow becomes too problematic due to the high rate of change, then we can revisit those systems, to take advantage of their auto-merging functionality, but probably only in combination with the QA testsuites. Using a Code Review System and allowing direct commits are not mutually exclusive. If infra has got time to set it up, this could be an option in addition to direct commits for developers and we could make it obligatory (e.g. for the first month) for new developers. It would also allow proxied maintainers to commit to the tree more easily, as it will require just an additional ack by the proxy maintainer. If we do add a code review system, it should be fully accessible from the command line. Pybugz is almost there for bugzilla; the only thing it lacks is the ability to reply to specific comments. William signature.asc Description: Digital signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan schedule
Robin H. Johnson posted on Fri, 03 Jul 2015 20:22:25 + as excerpted: On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: Are there still any plans to use a code review system like gerrit [...] [T]he general discussion was that a code review system was not in the immediate future... I believe the general sense of previous discussion was that the git switch has been delayed too long already, and while code review, etc, might be nice, in this case it's the perfect being the enemy of the good, in that it would likely result in another half-decade of gentoo on cvs while these /additional/ things were worked out, and that was simply judged to be an unacceptable tradeoff to make. Which I (strongly!) agree with. The switch to git won't be perfect, but we /can/ do it now, and we should. If code review, etc, is to happen, once we're on git it can happen incrementally, but we're not losing anything we have already by not doing it with the switch to git, while just the switch to git alone is already a huge improvement, bringing us into the current era, at least. And there's always going to be one more thing we could change to make things better... at the cost of putting off the big switch yet again... ultimately indefinitely, letting the perfect be the enemy of the good, to the benefit of the otherwise generally agreed to be unacceptable status quo. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
