Hi,
Maybe we should just give a try:
1) I will prepare all modifications out of infra and show demo
2) Get it in Infra as experimental feature
3) Try it in Rally
4) Share experience and if it is worth keep it or get rid of it.
Best regards,
Boris Pavlovic
On Fri, Jun 5, 2015 at 9:21 PM,
Josh,
Yep let's just make experiment in Rally and I will share experience with
the rest of community.
Best regards,
Boris Pavlovic
On Wed, Jun 3, 2015 at 9:45 PM, Joshua Harlow harlo...@outlook.com wrote:
S, just some thoughts,
If boris thinks this might help rally, why not just let him
On 2015-06-03 13:22:50 -0700 (-0700), Joshua Harlow wrote:
[...]
I don't know if thats easy or not, but prolog seems like way
overkill.
[...]
Prolog is the extension mechanism Gerrit has settled on. If the goal
is to have Gerrit enforce voting permissions on changes based on
which files are
S, just some thoughts,
If boris thinks this might help rally, why not just let him try it?
If boris (and friends) will make the needed changes to jenkins or other
to have whatever ACL format (avoid a turing complete language please)
that says who can work in what directories in the rally
Robert,
Some of the the consequences of splitting up repos:
- atomic changes become non-atomic
- cross-cutting changes become more complex
- code analysis has to deal with more complex setups (can't lint
across boundaries as readily, for instance)
- distribution and installation via
Jeremy Stanley wrote:
On 2015-06-03 11:45:57 -0700 (-0700), Joshua Harlow wrote:
[...]
If boris (and friends) will make the needed changes to jenkins or
other to have whatever ACL format (avoid a turing complete
language please)
[...]
The proposal is to introduce Prolog into the Gerrit ACLs
On 2015-06-03 11:45:57 -0700 (-0700), Joshua Harlow wrote:
[...]
If boris (and friends) will make the needed changes to jenkins or
other to have whatever ACL format (avoid a turing complete
language please)
[...]
The proposal is to introduce Prolog into the Gerrit ACLs to match on
file
Ihar,
Reverting patches is unacceptable for Rally project.
This means that we merged bug and this is epic fail of PTL of project.
Let's take a look from other side, Ihar would you share with me
your password of your email?
You can believe me I won't do anything wrong with it.
And yes I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/03/2015 08:29 AM, Boris Pavlovic wrote:
Guys,
I will try to summarize all questions and reply on them:
*- Why not splitting repo/plugins?*
I don't want to make architectural decisions based on social or
not enough good tool for
Excerpts from Boris Pavlovic's message of 2015-06-02 16:36:20 -0700:
Jeremy,
the Infrastructure Project is now past 120 repos with more
than 70 core reviewers among those.
I dislike the idea of having 120 repos for single tool. It makes things
complicated for everybody:
Guys,
One more time it's NOT about reputation and it's NOT about believing
somebody.
It's about human nature. We are all making mistakes.
System that checks can code review merge patch is just extra check
to avoid unintentional mistakes of core reviewers and make things
self organized.
Best
On Wed, Jun 03 2015, Robert Collins wrote:
We *really* don't need a technical solution to a social problem.
I totally agree. The trust issues is not going to be solve with a tool.
--
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info
signature.asc
Description: PGP signature
On Wed, Jun 03, 2015 at 10:22:59AM +0200, Julien Danjou wrote:
On Wed, Jun 03 2015, Robert Collins wrote:
We *really* don't need a technical solution to a social problem.
I totally agree. The trust issues is not going to be solve with a tool.
+1 I can not believe people will commit
Guys,
I will try to summarize all questions and reply on them:
*- Why not splitting repo/plugins?*
I don't want to make architectural decisions based on social or
not enough good tool for review issues.
If we take a look at OpenStack that was splited many times: Glance,
Cinder, ...
we
Robert Collins said on Wed, Jun 03, 2015 at 11:12:35AM +1200:
So I'd like us to really get our heads around the idea that folk are
able to make promises ('I will only commit changes relevant to the DB
abstraction/transaction management') and honour them. And if they
don't - well, remove their
On 06/03/2015 12:32 PM, Boris Pavlovic wrote:
Guys,
One more time it's NOT about reputation and it's NOT about believing
somebody.
It's about human nature. We are all making mistakes.
And if we do, we can always revert a patch.
System that checks can code review merge patch is just extra
On Wed, Jun 03 2015, Boris Pavlovic wrote:
And I don't understand what so serious problem we have.
We were not able to do reverts so we build CI that doesn't allow us to
break master
so we don't need to do reverts. I really don't see here any big problems.
Doing revert does not mean
On Wed, Jun 3, 2015 at 9:33 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Wed, 2015-06-03 at 09:29 +0300, Boris Pavlovic wrote:
*- Why not just trust people*
People get tired and make mistakes (very often).
That's why we have blocking CI system that checks patches,
James B.
One more time.
Everybody makes mistakes and it's perfectly OK.
I don't want to punish anybody and my goal is to make system
that catch most of them (human mistakes) no matter how it is complicated.
Best regards,
Boris Pavlovic
On Wed, Jun 3, 2015 at 5:33 PM, James Bottomley
On Wed, 2015-06-03 at 09:29 +0300, Boris Pavlovic wrote:
*- Why not just trust people*
People get tired and make mistakes (very often).
That's why we have blocking CI system that checks patches,
That's why we have rule 2 cores / review (sometimes even 3,4,5...)...
In ideal work
Jeremy,
Except that reorganizing files in a repo so that you can have sane
pattern matches across them for different review subteams is
_exactly_ this. The question is really one of do you have a
separate .git in each of the directory trees for your subteams or
only one .git in the parent
On 2015-06-03 17:15:43 +0300 (+0300), Boris Pavlovic wrote:
I can't talk for other projects, so let's talk about Rally specific.
We have single .git in root for whole project.
We have 4 subdir that can have own maintainers:
- rally/deploy
- rally/verify
- rally/benchmark
- rally/plugins
On 2015-06-03 09:29:38 +0300 (+0300), Boris Pavlovic wrote:
I will try to summarize all questions and reply on them:
*- Why not splitting repo/plugins?*
I don't want to make architectural decisions based on social or
not enough good tool for review issues.
[...]
Except that
On Wed, Jun 03 2015, Boris Pavlovic wrote:
Reverting patches is unacceptable for Rally project.
Then you have a more serious problem than the rest of OpenStack.
This means that we merged bug and this is epic fail of PTL of project.
Your code is already full of bugs and misfeatures, like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/03/2015 01:56 PM, Boris Pavlovic wrote:
Ihar,
Reverting patches is unacceptable for Rally project. This means
that we merged bug and this is epic fail of PTL of project.
That's a bar set too high. Though I don't believe Rally team does
So yeah, that's precisely what we discussed at the cross-project
workshop about In-team scaling in Vancouver (led by Kyle and myself).
For those not present, I invite you to read the notes:
https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling
The conclusion was to explore
Julien,
If I were on you shoes I would pick words more carefully.
When you are saying:
Reverting patches is unacceptable for Rally project.
Then you have a more serious problem than the rest of OpenStack.
you means Rally community which is quite large.
On 06/03/2015 02:43 PM, Boris Pavlovic wrote:
I don't believe even my self, because I am human and I make mistakes.
My goal on the PTL position is to make such process that stops human
mistakes before they land in master. In other words everything should be
automated and pre not post
On Wed, 2015-06-03 at 17:45 +0300, Boris Pavlovic wrote:
James B.
One more time.
Everybody makes mistakes and it's perfectly OK.
I don't want to punish anybody and my goal is to make system
that catch most of them (human mistakes) no matter how it is complicated.
I'm not saying never do
+1 to ttx and Jame's points on trust and relationships, indeed
referencing the summit session that ttx mentioned:
https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling
On 3 June 2015 at 16:01, Nikola Đipanov ndipa...@redhat.com wrote:
On 06/03/2015 02:43 PM, Boris Pavlovic
On 06/03/2015 05:57 PM, John Garbutt wrote:
+1 to ttx and Jame's points on trust and relationships, indeed
referencing the summit session that ttx mentioned:
https://etherpad.openstack.org/p/liberty-cross-project-in-team-scaling
On 3 June 2015 at 16:01, Nikola Đipanov ndipa...@redhat.com
On 4 June 2015 at 02:51, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-06-03 17:15:43 +0300 (+0300), Boris Pavlovic wrote:
I can't talk for other projects, so let's talk about Rally specific.
We have single .git in root for whole project.
We have 4 subdir that can have own maintainers:
-
On Tue, Jun 2, 2015 at 4:12 PM, Robert Collins robe...@robertcollins.net
wrote:
On 3 June 2015 at 10:34, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-06-02 21:59:34 + (+), Ian Cordasco wrote:
I like this very much. I recall there was a session at the summit
about this that
On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
Really it's hard to find cores that understand whole project, but
it's quite simple to find people that can maintain subsystems of
project.
We are made wise not by the recollection of our past, but by the
responsibility for our future.
-
Jeremy,
the Infrastructure Project is now past 120 repos with more
than 70 core reviewers among those.
I dislike the idea of having 120 repos for single tool. It makes things
complicated for everybody:
documentation stuff, installation, maintaing, work that touches multiple
repos and so
On 2015-06-03 02:36:20 +0300 (+0300), Boris Pavlovic wrote:
I dislike the idea of having 120 repos for single tool. It makes things
complicated for everybody:
documentation stuff, installation, maintaing, work that touches multiple
repos and so on..
So I would prefer to have single repo
I like this idea. I agree, as things grow it is probably easier to find
folks that know certain areas a project rather than the full scope.
This could be a good way to handle the load and delegate some pieces
(such as driver reviews) to a different set of people.
On 06/02/2015 04:24 PM,
On 2 June 2015 at 23:59, Ian Cordasco ian.corda...@rackspace.com wrote:
On 6/2/15, 16:24, Boris Pavlovic bo...@pavlovic.me wrote:
Hi stackers,
Issue
---
Projects are becoming bigger and bigger overtime.
More and more people would like to contribute code and usually core
On 2015-06-02 21:59:34 + (+), Ian Cordasco wrote:
I like this very much. I recall there was a session at the summit
about this that Thierry and Kyle led. If I recall correctly, the
discussion mentioned that it wasn't (at this point in time)
possible to use gerrit the way you describe
On 6/2/15, 16:24, Boris Pavlovic bo...@pavlovic.me wrote:
Hi stackers,
Issue
---
Projects are becoming bigger and bigger overtime.
More and more people would like to contribute code and usually core
reviewers
team can't scale enough. It's very hard to find people that understand
full
On 3 June 2015 at 10:34, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-06-02 21:59:34 + (+), Ian Cordasco wrote:
I like this very much. I recall there was a session at the summit
about this that Thierry and Kyle led. If I recall correctly, the
discussion mentioned that it wasn't (at
On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand iwien...@redhat.com wrote:
On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
Really it's hard to find cores that understand whole project, but
it's quite simple to find people that can maintain subsystems of
project.
We are made wise not by the
On 3 June 2015 at 07:12, John Griffith john.griffi...@gmail.com wrote:
On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand iwien...@redhat.com wrote:
On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
Really it's hard to find cores that understand whole project, but
it's quite simple to find people
43 matches
Mail list logo
