Open Stack

Can we make this (at least) two (community?) goals?

#1 Make a thing that is not paste that is better than paste (i.e. > works,
ie >= works & is maintained)
#2 Have some people/projects "migrate" to it

If the goal is just "take over paste maintenance" that's maybe ok - but is
that an "OpenStack community" goal or just something that someone who has
the bandwidth to do could do?  It also sounds cheaper and probably about as
good.

Alternatively we can just keep using paste until we're tired of working
around it's bugs/limitations - and then replace it with something in tree
that implements only 100% of what the project using it needs to get done -
then if a few projects do this and they see they're maintaining similar
code they could extract it to a common library - but iff sharing their
complexity isolated behind an abstraction sounds better than having
multiple simpler and more agile ways to do similar-ish stuff - and only
*then* make a thing that is not paste but serves a similar use-case as
paste and is also maintained and easy to migrate too from paste.  At which
point it might be reasonable to say "ok, community, new goal, if you're not
already using the thing that's not paste but does about the same as paste -
then we want to organize some people in the community experienced with the
effort of such a migration to come assist *all openstack projects* (who use
paste) in completing the goal of getting off paste - because srly, it's
*that* important"

-Clay

On Wed, May 31, 2017 at 1:38 PM, Mike <thingee at gmail.com> wrote:

> Hello everyone,
>
> As part of our community wide goals process [1], we will discuss the
> potential goals that came out of the forum session in Boston [2].
> These discussions will aid the TC in making a final decision of what
> goals the community will work towards in the Queens release.
>
> For this thread we will be discussing migrating off paste. This was
> suggested by Sean Dague. I’m not sure if he’s leading this effort, but
> here’s a excerpt from him to get us started:
>
> A migration path off of paste would be a huge win. Paste deploy is
> unmaintained (as noted in the etherpad) and being in etc means it's
> another piece of gratuitous state that makes upgrading harder than it
> really should be. This is one of those that is going to require
> someone to commit to working out that migration path up front. But it
> would be a pretty good chunk of debt and upgrade ease.
>
>
> [1] - https://governance.openstack.org/tc/goals/index.html
> [2] - https://etherpad.openstack.org/p/BOS-forum-Queens-Goals
>
> —
> Mike Perez
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170602/e68138f1/attachment.html>