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
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
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 TR
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
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 automa
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 exper
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.
>
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 a
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
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
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 re
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-unders
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/o
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 woul
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, stabi
# 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.
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
17 matches
Mail list logo
