Open Stack

> However, the OpenStack community is also about a shared set of tools,
> development methodologies, and common perspectives.

I completely agree with you, Jay, but the same principle may be
applied much wider. Why Openstack Community decided to use its own
unstable project instead of existing solution, which is widely used in
Python community? To avoid being a team player? Or, at least, why it's
recommended way even if it doesn't provide the same features other
frameworks have for a long time already? I mean, there is no doubt
everyone would use stable and technically advanced tool, but imposing
everyone to use it by force with a simple hope that it'll become
better from this is usually a bad approach.

I personally would surely contribute to Pecan in case we decide to use
it and there will be some gaps and uncovered cases. I'm just curious,
does it worth it?

On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 12/03/2014 10:16 AM, Nikolay Markov wrote:
>>
>> It would be great to look at some obvious points where Pecan is better
>> than Flask despite of the fact that it's used by the community. I
>> still don't see a single and I don't think the principle "jump from
>> the cliff if everyone does" works well in such cases.
>
>
> This is part of why the Fuel development team is viewed as not working with
> the OpenStack community in many ways. The Fuel team is doing a remarkable
> job in changing previously-all-internal-to-Mirantis communication patterns
> to instead be on a transparent basis in the mailing lists and on IRC. I
> sincerely applaud the Fuel team for that.
>
> However, the OpenStack community is also about a shared set of tools,
> development methodologies, and common perspectives. It's expected that when
> you have an OpenStack REST API project, that you try to use the tools that
> the shared community uses, builds, and supports. Otherwise, you aren't being
> a team player.
>
> In the past, certain teams have chosen to use something other than Pecan due
> to technical reasons. For example, Zaqar's team chose to use the Falcon
> framework instead of the Pecan framework. Zaqar, like Swift, is a data API,
> not a control API, and raw performance is critical to the project's API
> endpoint). This is, incidentally, why the Swift team chose to use its swob
> framework over Webob (which Pecan uses).
>
> However, the reason that these were chosen was definitely not "it doesn't
> support the coding patterns I like". There's something that comes from being
> a team player. And one of those things is "going with the flow" when there
> isn't a real technical reason not to. All of us can and do find things we
> don't like about *all* of the projects that we work on. The difference
> between team players and non-team players is that team players strongly
> weigh their decisions and opinions based on what the team is doing and how
> the team can improve.
>
> Best,
>
> -jay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best regards,
Nick Markov