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
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
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
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
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
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
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
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
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
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
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,
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
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 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
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
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
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
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
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.
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
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
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
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 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.
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
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
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.
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
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,
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
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
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 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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
47 matches
Mail list logo
