Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

2016-12-24 Thread Paul Belanger 
On Wed, Dec 21, 2016 at 10:17:42AM -0600, Ian Cordasco wrote:
> -Original Message-
> From: Andrey Kurilin 
> Reply: OpenStack Development Mailing List (not for usage questions) 
> 
> Date: December 21, 2016 at 10:13:09
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject:  Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects
> 
> > On Wed, Dec 21, 2016 at 5:46 PM, Andreas Jaeger wrote:
> >  
> > > On 2016-12-21 16:22, Ian Cordasco wrote:
> > > > [...]
> > > > That said, I think there are two better places for this information
> > > > that are already standards in OpenStack:
> > > >
> > > > * README.rst
> > > > * HACKING.rst
> > > >
> > > > Most projects include links to the contributing documentation in at
> > > > least one of these files. I think the effort here is to standardize,
> > > > albeit in a brand new file, and that's admirable.
> > >
> > > If that's the goal - to standardize - then I would expect that we move
> > > all the documentation out of those files in one place.
> > >
> > > Right now, the changes duplicate information that exists - and the new
> > > information is often wrong. It points to place that do not exist or
> > > where better places exist. ;(
> > >
> >  
> > Duplication can be reduced by using `.. include:: ` directive.
> 
> That does not render anywhere except our documentation (via Sphinx). 
> Git{Hub,Lab} don't render the include directive at all.
> 
> So, no, that's not an option.
> 
No, this is a valid option. We do it today with various documentation.

They will however render to docs.o.o, which we consider source of truth. The
topic of rendering RST files to github has come up a few times, but each time
comes back to the fact we simply mirror to github.

It is possible to have git.openstack.org render RST too, but we've opted to do
it with docs.openstack.org.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

2016-12-24 Thread Amrith Kumar 
So Jeremy, that's great. so all someone has to do is pick this file and
blast it out to 150 projects :)

Merry Christmas, Happy Hanukah, Happy Festivus and best wishes for the feats
of strenght, Happy Holidays, Have a good weekend ... (pick as many as you'd
like)

-amrith

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Saturday, December 24, 2016 9:58 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
projects
> 
> On 2016-12-22 09:52:21 -0600 (-0600), Anne Gentle wrote:
> [...]
> > Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be
> > .md for github, Ian?) for all projects? Is it similar to the nova 2012
> > version or is there a more modern take?
> 
> The reference example is maintained at
> http://git.openstack.org/cgit/openstack-
> dev/cookiecutter/tree/%7b%7bcookiecutter.repo_name%7d%7d/CONTRIB
> UTING.rst
> (or at least that's the closest we have to one that's supposed to be kept
> "modern").
> --
> Jeremy Stanley
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

2016-12-24 Thread Britt Houser (bhouser) 
Seems like these are some of the same growing pains (cores can’t be experts on 
all technologies) neutron went through.  Maybe at the PTG we could pick their 
brain and see if the path they have chosen would work well for Kolla.

Thx,
britt

On 12/24/16, 10:31 AM, "Steven Dake (stdake)"  wrote:

My response wasn’t clear and I’ve also thought more about your proposal.  
I’d be highly in favor of the approach you mentioned as long as 2 was modified 
in your proposal to include some larger number then 2 individuals.  One option 
that comes to mind is a majority of each core review sub-team for point 2 
taking into account some of our core reviewers have issues that temporarily 
prevent them from fulfilling their core reviewer duties (although they plan to 
re-engage).

I agree we don’t want to duplicate the TC – that would be super heavy – not 
that the TC is heavy – but rather that Kolla doesn’t need its own governance 
structure as the technical governance of OpenStack is directed by the technical 
committee.  I for one, don’t want to have a full-blown governance structure for 
Kolla, although I can’t speak for other core reviewers.

Regards
-steve


-Original Message-
From: "Steven Dake (stdake)" 
Date: Friday, December 23, 2016 at 3:53 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

WFM – I’d be partly in favor of such an approach although I can’t speak 
for others.  I think we should require some larger set then 2 individuals from 
the kolla-policy-core; perhaps a majority of active reviewers for some 
definition of active reviewers.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage 
questions)" 
Date: Friday, December 23, 2016 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt 
deliverable

So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm 
referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?

So let me throw an idea there, one which we should vote on:

Prep:
1. We create kolla-policy-core-team which is sum of all core teams 
of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s

Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to 
Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team

This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.

Thoughts?
Michal

On 23 December 2016 at 13:11, Steven Dake (stdake) 
 wrote:
> Michal,
>
> Really what I was getting at was placing in the governance 
repository as a kolla deliverable.  In days past we *always* voted on additions 
and removals of deliverables.  It doesn’t seem like a gray area to me – we have 
always followed a voting pattern for adding and removal of deliverables.  This 
repo could be added to the git openstack namespace but then not have it as a 
kolla deliverable without a vote I think; this is sort of what Fuel did with 
Fuel-ccp – that proposal is a gray area.  I found when Fuel did  that to be 
extremely odd personally ☺  I’m not sure if there is a trademark policy or 
something similar that affects the use of Kolla and OpenStack together.

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

2016-12-24 Thread Steven Dake (stdake) 
My response wasn’t clear and I’ve also thought more about your proposal.  I’d 
be highly in favor of the approach you mentioned as long as 2 was modified in 
your proposal to include some larger number then 2 individuals.  One option 
that comes to mind is a majority of each core review sub-team for point 2 
taking into account some of our core reviewers have issues that temporarily 
prevent them from fulfilling their core reviewer duties (although they plan to 
re-engage).

I agree we don’t want to duplicate the TC – that would be super heavy – not 
that the TC is heavy – but rather that Kolla doesn’t need its own governance 
structure as the technical governance of OpenStack is directed by the technical 
committee.  I for one, don’t want to have a full-blown governance structure for 
Kolla, although I can’t speak for other core reviewers.

Regards
-steve


-Original Message-
From: "Steven Dake (stdake)" 
Date: Friday, December 23, 2016 at 3:53 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

WFM – I’d be partly in favor of such an approach although I can’t speak for 
others.  I think we should require some larger set then 2 individuals from the 
kolla-policy-core; perhaps a majority of active reviewers for some definition 
of active reviewers.

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 23, 2016 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?

So let me throw an idea there, one which we should vote on:

Prep:
1. We create kolla-policy-core-team which is sum of all core teams of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s

Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team

This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.

Thoughts?
Michal

On 23 December 2016 at 13:11, Steven Dake (stdake)  
wrote:
> Michal,
>
> Really what I was getting at was placing in the governance repository 
as a kolla deliverable.  In days past we *always* voted on additions and 
removals of deliverables.  It doesn’t seem like a gray area to me – we have 
always followed a voting pattern for adding and removal of deliverables.  This 
repo could be added to the git openstack namespace but then not have it as a 
kolla deliverable without a vote I think; this is sort of what Fuel did with 
Fuel-ccp – that proposal is a gray area.  I found when Fuel did  that to be 
extremely odd personally ☺  I’m not sure if there is a trademark policy or 
something similar that affects the use of Kolla and OpenStack together.  I’ve 
included the [tc] in the topic so they can provide guidance on the route you 
suggested (incubation for new kolla deliverables that are not actually 
deliverables).
>
> I think we really don’t need the tc to intervene here though, we can 
just make new policies on our own via the typical policy voting process we have 
followed in the past.  Before we make any decisions about that though, I think 
we need a vote on the topic. ☺
>
> Regards
> -steve
>
> -Original Message-
> From: Michał

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

2016-12-24 Thread Jeremy Stanley 
On 2016-12-22 09:52:21 -0600 (-0600), Anne Gentle wrote:
[...]
> Does anyone have a "perfect" CONTRIBUTING.rst (or does it need to be .md
> for github, Ian?) for all projects? Is it similar to the nova 2012 version
> or is there a more modern take?

The reference example is maintained at
http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/%7b%7bcookiecutter.repo_name%7d%7d/CONTRIBUTING.rst
(or at least that's the closest we have to one that's supposed to be
kept "modern").
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev