Open Stack

On Thu, Dec 15, 2016 at 10:58 AM, Sean Dague <sean at dague.net> wrote:

> 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.
>

Yep -- this is the heart of the comms difficulty with these goals. I
struggled myself to understand why there were perceived "tech debt" items
high on the list. I had to have the cascading need explained to me that got
the end user outcome from the goal. So, adding that additional context to
the goal proposals helps.

Anne


>
> 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
>
> __________________________________________________________________________
> 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
>



-- 
Anne Gentle
--
Read my blog: justwrite.click <https://justwriteclick.com>
Subscribe to Docs|Code: docslikecode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161215/da6dacaa/attachment.html>