Re: [DISCUSS] Unblocking Juju development

[Konstantin Boudnik <co...@apache.org>]

Sorry for the belated joining of the party - crazy travel schedule an all
that. I like the idea of making a special branch for this development, so ppl
working on would have the ability to commit the code as they see fit and, once
it is ready, we can simply merge it into the master.

Is this something along the lines you had in mind, Roman?
  Cos

On Tue, Jul 19, 2016 at 03:13PM, Roman Shaposhnik wrote:
> On Tue, Jul 19, 2016 at 3:06 PM, Cory Johns <co...@canonical.com> wrote:
> > Also, we realized that while we did internal review among the four of us of
> > the PRs we created, we didn't document those reviews on the Jira tickets.
> > I'd like to have us go back and re-review those to have it documented on
> > the Jira tickets exactly what we did to test those charms and what the
> > results were, which I think would be very helpful for your review.
> 
> Sure that would be helpful, but like I said -- my biggest hurdle is not being
> able to see forest for the trees. That's why I can't really review
> much as it stands.
> 
> Well, I suppose I can recreate that branch I'm talking about myself,
> but I'd rather
> you guys maintained it ;-)
> 
> Thanks,
> Roman.

Re: [DISCUSS] Unblocking Juju development

[Pete Vander Giessen <pe...@canonical.com>]

Hi All,

> I don't think a mega PR will help with the issue much, as the review of mega-anything
is a mega-PITA.

A mega PR sounds like a hassle to me, too. :-) Maybe we're misunderstanding
what you're asking us to do.

> Sometimes these fixes are intertwined with the charms and that's where
the snug is: most of us don't have enough hands-on experience with Juju at
this point to make an informed review and/or test the changes (as has
been discussed
earlier).

Would it help to put a charm and the puppet changes in the same PR? I know
that I generally try to separate them, partially to encourage myself to
only make puppet changes that make sense alone, outside of the context of a
charm. I do tend to validate and test inside a charm, though.

Is testing the main blocker? I typically test by building a charm and then
using bundletester to deploy the charm to AWS and run tests, including the
Bigtop smoke tests. If anybody needs an AWS account for charm testing
purposes, they can go to https://developer.juju.solutions/ and set one up.
I made some improvements to the juju documentation on running tests (
https://jujucharms.com/docs/stable/developer-testing#executing-tests-via-bundletester),
but I'm happy to help people out on IRC if anything is unclear (more
feedback means that I can write better documentation).

Regards,
~ PeteVG

Re: [DISCUSS] Unblocking Juju development

[Konstantin Boudnik <co...@apache.org>]

On Tue, Aug 09, 2016 at 05:58PM, Pete Vander Giessen wrote:
> Hi All,
> 
> Would it make sense to to make a branch that lived in our fork of the
> bigtop project (github.com/juju-solutions/bigtop)? That way, we charmers
> all have commit access, and can grant commit access to those working on a
> charm. We can then open a sort of mega PR against the Apache bigtop repo,
> and you can review and merge that when you're ready.

Having a branch on your own never was prohibited nor it should be :) The way
people choose to collaborate on the GH isn't really a concern here, but the
way we can efficiently get the changes into the project master is. 

I don't think a mega PR will help with the issue much, as the review of
mega-anything is a mega-PITA. This is the reason most of the projects are
trying to make commits narrowly focused and reasonable in size.

> The issue that I see is coordinating upstream merges with downstream
> additions. Are there points where you want us to freeze the branch while
> you prepare to merge it?

The coordination is a part of it. Another part is the addition of the charms
which lead to discovery of various issues in the Puppet and elsewhere.
Sometimes these fixes are intertwined with the charms and that's where the
snug is: most of us don't have enough hands-on experience with Juju at this
point to make an informed review and/or test the changes (as has been
discussed earlier). This results in slowing down of the rate of the acceptance
of the changes. Which isn't good for anybody.

> Also, are you proposing that the branch contain just the charms themselves
> -- the files in in bigtop-packages/src/charms -- or do you want us to
> include puppet fixes and changes in the branch? I think that it might make
> a lot of sense to keep all the directly charm related stuff in a branch,
> but would strongly prefer to keep the puppet related fixes in their own,
> per ticket, branches. That mega branch is going to get rebased frequently,
> and I'd rather cut down the chances of conflicts and messiness to a minimum.

Bigtop source code doesn't live in multiple repositories, so I don't see how
we can fragment the code this way. In my practice, you'd have all the code on
the branch, but people will be working just on the particular areas of the
code as they see fit. Once there's a consensus that the branch is in a good
shape it should be merged back to the master, It is normally done in one swift
motion. No need to freeze anything as the granularity of the branches could
vary - per feature, per fix, per mega-functionality, etc.

Hope it makes sense.
  Cos

Re: [DISCUSS] Unblocking Juju development

[Pete Vander Giessen <pe...@canonical.com>]

Hi All,

Would it make sense to to make a branch that lived in our fork of the
bigtop project (github.com/juju-solutions/bigtop)? That way, we charmers
all have commit access, and can grant commit access to those working on a
charm. We can then open a sort of mega PR against the Apache bigtop repo,
and you can review and merge that when you're ready.

The issue that I see is coordinating upstream merges with downstream
additions. Are there points where you want us to freeze the branch while
you prepare to merge it?

Also, are you proposing that the branch contain just the charms themselves
-- the files in in bigtop-packages/src/charms -- or do you want us to
include puppet fixes and changes in the branch? I think that it might make
a lot of sense to keep all the directly charm related stuff in a branch,
but would strongly prefer to keep the puppet related fixes in their own,
per ticket, branches. That mega branch is going to get rebased frequently,
and I'd rather cut down the chances of conflicts and messiness to a minimum.

Regards,
~ PeteVG

Re: [DISCUSS] Unblocking Juju development

[Konstantin Boudnik <co...@apache.org>]

On Mon, Aug 08, 2016 at 09:53PM, Roman Shaposhnik wrote:
> Now my time to be late with a replay, but the good news -- I'm back
> from vacation! :-)

Not sure what's good about it, unless you enjoy slaving for the man ;)

> On Tue, Aug 2, 2016 at 12:09 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > Sorry for the belated joining of the party - crazy travel schedule an all
> > that. I like the idea of making a special branch for this development, so ppl
> > working on would have the ability to commit the code as they see fit and, once
> > it is ready, we can simply merge it into the master.
> >
> > Is this something along the lines you had in mind, Roman?
> 
> Yes. That's exactly what I had in mind. But if we agree that the
> branch is the right
> way to proceed, we then need to ask how to enable non-committers to be able
> to commit it.

The only way to do it is to have give people a commit-bit. I don't think git
(unlike SVN) has a way of opening commit-access just to some branches. Please
correct me if I am mistaken.

Cos

Re: [DISCUSS] Unblocking Juju development

[Roman Shaposhnik <ro...@shaposhnik.org>]

Now my time to be late with a replay, but the good news -- I'm back
from vacation! :-)

On Tue, Aug 2, 2016 at 12:09 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Sorry for the belated joining of the party - crazy travel schedule an all
> that. I like the idea of making a special branch for this development, so ppl
> working on would have the ability to commit the code as they see fit and, once
> it is ready, we can simply merge it into the master.
>
> Is this something along the lines you had in mind, Roman?

Yes. That's exactly what I had in mind. But if we agree that the
branch is the right
way to proceed, we then need to ask how to enable non-committers to be able
to commit it.

Thanks,
Roman.