Hi!
On Thu, 09 Jul 2015, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann 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
On Thu, Jul 9, 2015 at 2:56 PM, hasufell 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
On 07/09/2015 01:47 PM, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 5:31 AM, hasufell 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, becaus
On Thu, 09 Jul 2015 00:11:34 -0500
Steev Klimaszewski 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
On Thu, Jul 9, 2015 at 11:45 AM, Alec Warner wrote:
>
> On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman wrote:
>>
>>
>
> 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 packag
On 07/09/2015 10:45 AM, Alec Warner wrote:
On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman mailto:ri...@gentoo.org>> wrote:
On Thu, Jul 9, 2015 at 5:31 AM, hasufell mailto:hasuf...@gentoo.org>> wrote:
>
> The quality problem is that we have too many developers. If you make
> commu
On Thu, Jul 9, 2015 at 4:47 AM, Rich Freeman wrote:
> On Thu, Jul 9, 2015 at 5:31 AM, hasufell 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 a
On Thu, Jul 9, 2015 at 10:51 AM, Tobias Klausmann 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 opt
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
> > - dependen
On Thu, Jul 9, 2015 at 8:25 AM, Peter Stuge 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
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
On Thu, Jul 9, 2015 at 5:31 AM, hasufell 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
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
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 manpowe
On Wed, Jul 8, 2015 at 10:11 PM, Steev Klimaszewski
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 wrote:
> > > > In essence, assuming we can "just scal
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 wrote:
> > > In essence, assuming we can "just scale" to make CI work is
> > > ignoring the matter of the slower archs. And
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 argume
Hi!
On Wed, 08 Jul 2015, Alec Warner wrote:
> On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann
> 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!
> Re
Hi!
On Wed, 08 Jul 2015, Ciaran McCreesh wrote:
> On Wed, 8 Jul 2015 20:07:34 +0200
> Tobias Klausmann 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 somethin
On Wed, Jul 8, 2015 at 11:07 AM, Tobias Klausmann
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!
Realistica
On Wed, 8 Jul 2015 20:07:34 +0200
Tobias Klausmann 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 cle
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 wrote:
> > I'll laugh about it next time I
On Tue, 07 Jul 2015 08:04:47 +0800
Patrick Lauer wrote:
> 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.
>
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 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
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 t
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, patche
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. Stab
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 b
On July 4, 2015 1:49:20 PM EDT, Peter Stuge 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 int
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 fo
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" wrote:
>On 03.07.2015 22:22, Robin H. J
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
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 e
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
(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 pat
47 matches
Mail list logo
