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, Valeriy
If such possibility appears then definitely will be people that will try it
without weighing in to this discussion (like me).
And, the only social problem is that such "maintainers" of
project-sub-parts should be responsible enough. It is very likely that some
vendor-specific-things maintainers ca
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 mo
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 to
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 patte
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 wrote:
> S, just some thoughts,
>
> If boris thinks this might help rally, why not just let him try it?
>
> If bo
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
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 r
On 4 June 2015 at 02:51, Jeremy Stanley 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:
>> - rally
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 wrote:
>> On 06/03
+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 wrote:
> On 06/03/2015 02:43 PM, Boris Pavlovic wrote:
>>
>> I don't bel
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
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 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
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 Lieu
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 <
james.bot
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 check
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 paren
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 b
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
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.
http://stackalytics.com/?release=li
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 splitt
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
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
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 ch
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 re
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 the
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 s
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
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:
> do
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, ...
On 3 June 2015 at 07:12, John Griffith wrote:
>
>
> On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand 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
On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand 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 recollecti
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.
- Geor
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 rep
On Tue, Jun 2, 2015 at 4:12 PM, Robert Collins
wrote:
> On 3 June 2015 at 10:34, Jeremy Stanley 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 corre
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
On 3 June 2015 at 10:34, Jeremy Stanley 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 this point
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 describ
On 2 June 2015 at 23:59, Ian Cordasco wrote:
>
>
> On 6/2/15, 16:24, "Boris Pavlovic" 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'
On 6/2/15, 16:24, "Boris Pavlovic" 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 proje
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, Boris
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
project and have enough time to do code reviews. As a result t
45 matches
Mail list logo