Open Stack

One of the big things to consider is which of these items directly
support one of the key PWG issues: "painless upgrades"

The following items: movinging paste.ini out of config, new style
olso.policy (in code), and rootwrap -> privsep all eliminate files in
/etc that dramatically impact code execution, and need careful merging
during upgrades.

These are kind of the trifecta of content that really never should have
been in /etc, except it was easy to hack out in an initial version.

So, it may not be evident to users that this is what's getting in the
way of features rolling out to them, or them being 2 to 3 releases
behind master, it's a huge part of it. As such, I think any/all of them
should be considered as top level item for the next round of priorities.

I'd argue that until upgrades become really easy, everything else is
pretty secondary, because if people don't upgrade they'll never get any
of the other enhancements you are making.

On 12/15/2016 04:11 AM, Jean-Philippe Evrard wrote:
> Hello,
> 
> Maybe this will sound dumb …
> 
> I received this email on openstack-dev mailing list. I don’t know if it was sent to any other place, because it’s basically agreeing on development to be done, which makes sense to me.
> So openstack-dev people (called further “devs”) will push their company agenda on these goals based on what they know in their company. I see the work done together there, and I find it great, but…
> 
> Wouldn’t that be better if we open this discussion to the general population (openstack users, operators, and devs) instead of just devs?
> I submit this question because what I see on https://etherpad.openstack.org/p/community-goals is not only tech debt items that we have to fix, but also ideas of improvement on the long run for our users.
> It makes sense to me to keep the tech debt items as a devs only topic (I don’t see why a user cares _at least at first_ about using oslo.privsep vs oslo.rootwrap), and it makes also sense to me to align “community goals” with the broad community.
> 
> What do you think? Should we remove the non tech-debt items in this dev-community-goals etherpad?
> Should we have another set of community goals that could serve as a basis for the OpenStack user survey?
> Or should we keep these goals merged together, with the risk of having tech-debt items having lower priority the user requirements? (For that, the TC would be a good judge for final cycle prioritization)
> 
> I think having community goals is great for openstack, and I’d be happy to understand how we’ll adapt http://governance.openstack.org/goals/index.html into real life work usable for everyone.
> 
> Thanks for your clarifications.
> 
> Best regards,
> Jean-Philippe Evrard
> 
> 
> On 12/12/2016, 12:19, "Emilien Macchi" <emilien at redhat.com> wrote:
> 
>     On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi <emilien at redhat.com> wrote:
>     > A few months ago, our community started to find and work on
>     > OpenStack-wide goals to "achieve visible common changes, push for
>     > basic levels of consistency and user experience, and efficiently
>     > improve certain areas where technical debt payments have become too
>     > high – across all OpenStack projects".
>     >
>     > http://governance.openstack.org/goals/index.html
>     >
>     > We started to define a first Goal in Ocata (Remove Copies of Incubated
>     > Oslo Code) and we would like to move forward in Pike.
>     > I see 3 actions we could take now:
>     >
>     > 1) Collect feedback of our first iteration of Community Goals in
>     > OpenStack during Ocata. What went well? What was more challenging?
>     >
>     > Some examples:
>     > - should we move the goal documents into a separate repo to allow a
>     > shorter review time, where we could just have 2 TC members approve
>     > them instead of waiting a week?
>     > -  we expected all teams to respond to all goals, even if they have no
>     > work to do. Should we continue that way?
>     > - should we improve the guidance to achieve Goals?
>     >
>     > I created an etherpad if folks want to give feedback:
>     > https://etherpad.openstack.org/p/community-goals-ocata-feedback
>     >
>     > 2) Goals backlog - https://etherpad.openstack.org/p/community-goals
>     > - new Goals are highly welcome.
>     > - each Goal would be achievable in one cycle, if not I think we need
>     > to break it down into separated Goals (with connections).
>     > - some Goals already have a team (ex: Python 3) but some haven't.
>     > Maybe could we dress a list of people able to step-up and volunteer to
>     > help on these ones.
>     > - some Goals might require some documentation for how to achieve it.
>     >
>     > I think for now 2) can be discussed on the etherpad, though feel free
>     > to propose another channel.
>     >
>     > 3) Choose Goals for Pike.
>     > Some of us already did, but we might want to start looking at what
>     > Goals we would like to achieve during Pike cycle.
>     > I was thinking at giving a score to the Goals, that could be
>     > calculated by its priority (I know it's vague but we know what is
>     > really urgent for us versus what can wait 6 months); but also the
>     > number of people who are interested to contribute on a Goal (if this
>     > Goal doesn't have a team yet).
>     > For now, openstack/governance is the repository for Goals, please
>     > propose them here.
>     >
>     >
>     > Please give feedback, we're doing iterations here, and hopefully we'll
>     > improve our Community Goals over the next cycles.
>     > Thanks for your time,
> 
>     Two weeks happened, here's a digest version of the etherpad:
> 
>     - Most of projects achieved the goal for Ocata, and we saw strong
>     interest to do it on time
>     - Some confusion between the ACK'ing of a goal, and actually doing the work.
>     - Some projects were slow on the uptake (of starting the work) and
>     even reviewing the patches.
>     - For now, keep using openstack/governance repo for documenting Goals.
>     - Improve guidance on what projects are expected to do when updating
>     the status of the Goal.
>     - For each Goal, document who the "guides" are and how to find them
>     when help is needed.
>     - It seems like achieving multiple Goals in a single cycle wouldn't be
>     possible for all teams, we could prioritize them to let teams achieve
>     more than one Goal within a cycle.
> 
>     What's next?
>     https://etherpad.openstack.org/p/community-goals
>     Now that we have a good set of Goals that are proposed in this
>     etherpad, we might want to rank them by priority (1 is the most
>     important). Feel free to do it in the etherpad, by putting a rank in
>     "Priority rank".
> 
>     Also, I've noticed some Goals might be too big to be achievable within
>     a single cycle and might need to be split (Rolling upgrades for
>     example). If you're author of one these goals, please do so.
>     I hope we can start defining Pike Goals by next week, so we can start
>     documenting what we would expect and the guidance to achieve it/them.
> 
>     Any feedback is welcome,
>     --
>     Emilien Macchi
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> ________________________________
> Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net