On 6/2/2017 1:14 PM, Clay Gerrard wrote:
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


I don't think the maintenance issue is the prime motivator, it's the fact paste is in /etc which makes it a config file and therefore an impediment to smooth upgrades. The more we can move into code, like default policy and privsep, the better.

--

Thanks,

Matt

__________________________________________________________________________
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

Reply via email to