Re: [gentoo-dev] Re: Git workflow
William Hubbs wrote: > I think I understand what he's asking for... > > I think he is asking the question, "What changed in commit ". > > If you use the hash of a merge commit with "git show", you get nothing, > so the merge commit is useless in terms of following changes. I have explained why merge commits are often empty and what you need to ask the Git data model for in order to view each of the changes that lead up to the merge commit. There is even a shorthand for it; the ^ suffix: git show mergecommit^1 shows the last commit on the first branch, git show mergecommit^2 shows the last commit on the second branch, etc. Understanding the Git data model is critical in order to wrap head around the fact that a merge commit ideally does *not* contain any modifications. Modifications (patches if you will) come before the merge commit, on the respective merged branches. C Bergström wrote: > I have responded to every point - 1 by 1, but the "passionate people" > (most polite term I can find) Nice one! I knew you too could do subtle insults. > haven't addressed most of the "problems" or why commit reordering > is a particular problem in gentoo's typical case. Me and others have actually explained the problems exhaustively. I don't know why you don't understand the explanations and you don't say why, so we arrive at a halt. That's fine, the thread is just treading water anyway. :) Kind regards //Peter
[gentoo-dev] Last rites: app-arch/dczip net-p2p/frostwire
# Patrice Clement (5 Jul 2015) # SRC_URI unreachable. Upstream looks dead. # Removal in 30 days. See bug #502994. app-arch/dczip # Patrice Clement (5 Jul 2015) # Package does not compile with recent JDKs (>= jdk-1.8). More recent versions # use Gradle which we don't have packaged in Gentoo yet. # Removal in 30 days. See bug #552452. net-p2p/frostwire pgpQ99CJ4o3g7.pgp Description: PGP signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On Sat, Jul 4, 2015 at 11:05 PM, 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. 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
On Mon, 06 Jul 2015 07:25:03 +0800 Patrick Lauer 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 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
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 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 07/06/2015 07:27 PM, Ciaran McCreesh wrote: > On Mon, 06 Jul 2015 13:04:35 -0400 > Michael Orlitzky 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 Mon, 06 Jul 2015 19:34:05 +0200 hasufell wrote: > On 07/06/2015 07:27 PM, Ciaran McCreesh wrote: > > On Mon, 06 Jul 2015 13:04:35 -0400 > > Michael Orlitzky 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 Mon, Jul 6, 2015 at 9:42 AM, 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. > 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 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
[gentoo-dev] Re: Code Review Systems Was: Git Migration: launch plan & schedule
hasufell posted on Mon, 06 Jul 2015 19:20:14 +0200 as excerpted: > However, we should encourage gentoo-internal projects to become more > strict (and e.g. only have one or two "pushers"). Just noting there's also the "review required, but after getting it, go ahead and push" model. Same number of pushers, but better professionalism and code quality. It seems to be working very well for portage, now, and I'm pleased to see the greater bus factor as well as higher professionalism and code quality, that seems to be the result. =:^) And the fact that they're pushing the posting and reviews to the portage- dev list increases transparency as well, for those non-devs that like to follow developments on such system- and gentoo-critical packages. =:^) -- 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
Re: [gentoo-dev] Re: Git workflow
On 7 July 2015 at 01:48, Peter Stuge wrote: > fact that a merge commit ideally does *not* contain any > modifications. That's not /entirely/ true. The merge commit will have a new TREE object which is a composite TREE object of both of its PARENT TREE objects ( But all BLOBs in the resulting TREE will have existed on one of the parents as-is ) But as I mentioned in another reply, there's no way to view only the treewise diffs in a format suitable for diff, because diffs pertain to file contents, not SHA1s of BLOBs and SHA1s of TREEs. And yes, "Ideally" is where it gets messy. Non-Ideal commits have *new* BLOB objects that don't exist on either parent, and these can be hard to deal with. There's additionally lots of git tools that use the merge infrastructure to create non-merge commits with multiple parents. ( Git subtree for instance ), and some of them may inject *files* into the tree that don't exist in either parent, or entirely re-order the structure of one of the parents before applying it to master. The problem with those "merge" commits is those commits contain a significant amount of state in the merge itself, such that you cannot trivially recreate the merge commit from either of its parents alone. You can additionally turn any existing commit into one with two parents without changing the commits own changes, simply by abusing the model and git grafts and telling git "This commit now has two parents". Git goes "Sure, I'll put that SHA1 there and make no other changes". -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On 7 July 2015 at 12:04, Patrick Lauer 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
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
