Re: [Openstack] Related Projects
I just discovered these different sites thanks to this mail thread. I guess different people are looking for different types of info, judging by these exchanges. Whatever you decide as to where the list is hosted, I just wanted to say that I appreciated the simple *but* informative format of the related projects page https://wiki.openstack.org/wiki/RelatedProjectsrather than the more dashboard like interfaces. My 2 cts, Mike. On 3 May 2013 22:07, Marton Kiss marton.k...@gmail.com wrote: It is a good idea, it was the original plan with this project. If Harvard also like to use it we can refactor the current stackmeat distro into a common project distribution (like openatrium or openpublish) and OpenStack and Harvard distribution can inherit the commonly maintained codebase. M. 2013/5/3 Stefano Maffulli stef...@openstack.org On Fri 03 May 2013 12:15:26 PM PDT, Marton Kiss wrote: I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. I would vote to include stackmeat inside the OpenStack infrastructure so that others can contribute to it and the site can go on. What do you guys think? /stef -- Ask and answer questions on https://ask.openstack.org ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Gabriel Hurley wrote: I'll throw it out there again: We really ought to deploy an OpenComparison site (http://opencomparison.org/) for OpenStack. It's awesome, and does massive amounts of goodness for managed information and discovery. Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? I'd hate it if related projects had to register to multiple sites to get properly discovered. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? -- Jeremy Stanley ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. Regards, Márton 2013/5/3 Thierry Carrez thie...@openstack.org Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
On Fri 03 May 2013 12:15:26 PM PDT, Marton Kiss wrote: I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. I would vote to include stackmeat inside the OpenStack infrastructure so that others can contribute to it and the site can go on. What do you guys think? /stef -- Ask and answer questions on https://ask.openstack.org ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
It is a good idea, it was the original plan with this project. If Harvard also like to use it we can refactor the current stackmeat distro into a common project distribution (like openatrium or openpublish) and OpenStack and Harvard distribution can inherit the commonly maintained codebase. M. 2013/5/3 Stefano Maffulli stef...@openstack.org On Fri 03 May 2013 12:15:26 PM PDT, Marton Kiss wrote: I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. I would vote to include stackmeat inside the OpenStack infrastructure so that others can contribute to it and the site can go on. What do you guys think? /stef -- Ask and answer questions on https://ask.openstack.org ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Do you have plans to add comparison matrices, user counts, github stats, categories (aside from arbitrary tags), etc.? No offense meant to stackmeat, but the OpenComparison project is way ahead in terms of features that make it easy for consumers to make educated choices about the projects/tools they're choosing. It's Python-based and used for lots of other Python communities. If stackmeat wants to re-invest the energy to get there that's your prerogative, but we desperately need better tooling for our ecosystem. All the best, - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Marton Kiss Sent: Friday, May 03, 2013 12:15 PM To: Thierry Carrez Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. Regards, Márton 2013/5/3 Thierry Carrez thie...@openstack.orgmailto:thie...@openstack.org Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.orghttp://stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
The original plan with stackmeat was to provide a space for related projects with relatively small effort as part of .openstack.orginfrastructure. I got a lot of support from Stefano (thanks for that!), but finally it was launched as separate project, because we cannot move it under projects.openstack.org without a consensus/support from other board members. Of course we can always find better solutions, but without strong community support/contribution neither framework could work. So stackmeat currently exists, and if we can find some support from community, we can focus on content improvement and lead generation. Currently it doesn't have a too huge traffic, so I not feel that we need to add very complex feature set. If we reach the 100 visits / day, and current implementation is a limit, let's consider a change. M. 2013/5/3 Gabriel Hurley gabriel.hur...@nebula.com Do you have plans to add comparison matrices, user counts, github stats, categories (aside from arbitrary tags), etc.? No offense meant to stackmeat, but the OpenComparison project is way ahead in terms of features that make it easy for consumers to make educated choices about the projects/tools they’re choosing. It’s Python-based and used for lots of other Python communities. If stackmeat wants to re-invest the energy to get there that’s your prerogative, but we desperately need better tooling for our ecosystem. ** ** All the best, ** ** **- **Gabriel ** ** *From:* Openstack [mailto:openstack-bounces+gabriel.hurley= nebula@lists.launchpad.net] *On Behalf Of *Marton Kiss *Sent:* Friday, May 03, 2013 12:15 PM *To:* Thierry Carrez *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] Related Projects ** ** I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. ** ** Regards, Márton ** ** 2013/5/3 Thierry Carrez thie...@openstack.org Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ** ** ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Michael, thanks for the feedback, I record it as a feature request as a different view of projects. M. 2013/5/3 Michael Bright mjbrigh...@gmail.com I just discovered these different sites thanks to this mail thread. I guess different people are looking for different types of info, judging by these exchanges. Whatever you decide as to where the list is hosted, I just wanted to say that I appreciated the simple *but* informative format of the related projects page https://wiki.openstack.org/wiki/RelatedProjects rather than the more dashboard like interfaces. My 2 cts, Mike. On 3 May 2013 22:07, Marton Kiss marton.k...@gmail.com wrote: It is a good idea, it was the original plan with this project. If Harvard also like to use it we can refactor the current stackmeat distro into a common project distribution (like openatrium or openpublish) and OpenStack and Harvard distribution can inherit the commonly maintained codebase. M. 2013/5/3 Stefano Maffulli stef...@openstack.org On Fri 03 May 2013 12:15:26 PM PDT, Marton Kiss wrote: I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. I would vote to include stackmeat inside the OpenStack infrastructure so that others can contribute to it and the site can go on. What do you guys think? /stef -- Ask and answer questions on https://ask.openstack.org ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
This is going to come off as a bit of a rant. Pardon me. I feel it needs saying. There's a few ways to look at what OpenStack is. It's an IaaS solution. It's a cloud solution. But at it's heart, core to the design principles of OpenStack development ideology it is a collection of tools designed specifically to support elastic design patterns. The reason I bring this up is because of some thinking I've been doing about the future of OpenStack. Where it's place is in the world. Where it's place will be in the world. I've found that despite the crass nature of the puppies vs cattle explanation of elastic design, it really does get the most important selling point home to potential customers, and engineers who don't do ec2 already. And that point is that OpenStack exists to further a design pattern. It's not about clouds, or IaaS. It's about a design pattern. The pattern of horizontal scalability. The pattern of ephemeral resources. The pattern of share nothing. These core design ethics allow us to build software in a fashion that makes it consumable, scalable, and fault tolerant beyond any existing pattern by far. It makes development efforts become commodities that can be openly traded on a market free or otherwise. We need to stop thinking of OpenStack as just an IaaS solution. Or just a cloud. It's a development platform. It's a way of building software well. Once we do that, we can look to the past and see where we need to go. We want OpenStack to enjoy the some level of success as Java, or python as a collaborative development environment. We want kids in colleges to be training to write the next 50 years of applications in our environment, following our design patterns. But to do that, and to do it well, we'll need to solve a few things. This thread points to a growing problem in our community. One that was a primary focus of discussion in the last summit. OpenStack deployments are growing up and they are growing apart. We're building things too differently. The reason we employed PEP-8 gate tests, and the reason python works as a language in general is in part because when you give developers too many options, you end up losing a common language, or methodology that allows us to easily come up to speed on each others work. It makes collaboration hard. Now, not to start a language war, but I love perl. Nothing rips apart text like perl. Nothing. But, at the same time, I know that if I write perl code, it's going to be a pain in the ass for someone to come back to that code later and maintain it. Python on the other hand, especially with PEP-8, restricts a developers aesthetic options. It forces us to follow a common grammar. My point here, is that when you ask people what languages work with a 100+ active developers working on the same project, you get responses like Java, C#, maybe python. And you say, well why? And one of the responses is that Java and C# have an extensive common library. It allows developers to share a common method set. We've already begun the task of creating oslo to solve part of that problem for us in development. But in deployment, we're woefully behind the curve. We want to support diversity in the market eco system, but we also want to ensure that an OpenStack environment is adherent to some sort of baseline or flavor set. That is why folks have begun pushing things like refstack. I look at this thread, and what I see is a further need to unify solutions into a community supported method set that trumps outliers and one offs. A common set of tools. A common library of solutions. If OpenStack is to be the development environment of the next 75 years or more, we need to build this. It's one part of the many things we need to and are doing. But it's an important part. I think we can't just say, this isn't part of openstack, or this is outside of scope. It's part of the development environment that OpenStack is the runtime environment for ( forgive the analogy ). Anyways, That's my rant. -Matt On Fri, May 3, 2013 at 1:27 PM, Marton Kiss marton.k...@gmail.com wrote: Michael, thanks for the feedback, I record it as a feature request as a different view of projects. M. 2013/5/3 Michael Bright mjbrigh...@gmail.com I just discovered these different sites thanks to this mail thread. I guess different people are looking for different types of info, judging by these exchanges. Whatever you decide as to where the list is hosted, I just wanted to say that I appreciated the simple *but* informative format of the related projects page https://wiki.openstack.org/wiki/RelatedProjects rather than the more dashboard like interfaces. My 2 cts, Mike. On 3 May 2013 22:07, Marton Kiss marton.k...@gmail.com wrote: It is a good idea, it was the original plan with this project. If Harvard also like to use it we can refactor the current stackmeat distro into a common project distribution (like openatrium or
Re: [Openstack] Related Projects
Hi Matt, I mostly agree with your post, but from other side we are not living in an ideal world, and just doing the first steps on a long road. OpenStack is a very young platform, the wider ecosystem is forming, and a lot of things for me or you seems to be evident, not even known for others. I think the devops model / CI / Community is the real driver of the components, and core / incubated projects are using those technologies and policies. Related or satellite projects are more diverse, even from language aspect, and some of them not so tightly coupled to OpenStack API-s as others. This type of categorization works currently, and satellite is an entrance to incubated or even core status, if the project owners have such intentions. From my perspective refstack is good initiative to provide a common understanding and acceptance of basic principles, and forcing the interoperability between stacks. I feel we need to give time to forming policies, and common practices, and of course need try to find a good consensus among the lot of interests involved in the community, supporter companies and organizations. I din't want to stir up too much emotions in this topic, and sorry for that, if this was the outcome. M. 2013/5/3 Matt Joyce matt.jo...@cloudscaling.com This is going to come off as a bit of a rant. Pardon me. I feel it needs saying. There's a few ways to look at what OpenStack is. It's an IaaS solution. It's a cloud solution. But at it's heart, core to the design principles of OpenStack development ideology it is a collection of tools designed specifically to support elastic design patterns. The reason I bring this up is because of some thinking I've been doing about the future of OpenStack. Where it's place is in the world. Where it's place will be in the world. I've found that despite the crass nature of the puppies vs cattle explanation of elastic design, it really does get the most important selling point home to potential customers, and engineers who don't do ec2 already. And that point is that OpenStack exists to further a design pattern. It's not about clouds, or IaaS. It's about a design pattern. The pattern of horizontal scalability. The pattern of ephemeral resources. The pattern of share nothing. These core design ethics allow us to build software in a fashion that makes it consumable, scalable, and fault tolerant beyond any existing pattern by far. It makes development efforts become commodities that can be openly traded on a market free or otherwise. We need to stop thinking of OpenStack as just an IaaS solution. Or just a cloud. It's a development platform. It's a way of building software well. Once we do that, we can look to the past and see where we need to go. We want OpenStack to enjoy the some level of success as Java, or python as a collaborative development environment. We want kids in colleges to be training to write the next 50 years of applications in our environment, following our design patterns. But to do that, and to do it well, we'll need to solve a few things. This thread points to a growing problem in our community. One that was a primary focus of discussion in the last summit. OpenStack deployments are growing up and they are growing apart. We're building things too differently. The reason we employed PEP-8 gate tests, and the reason python works as a language in general is in part because when you give developers too many options, you end up losing a common language, or methodology that allows us to easily come up to speed on each others work. It makes collaboration hard. Now, not to start a language war, but I love perl. Nothing rips apart text like perl. Nothing. But, at the same time, I know that if I write perl code, it's going to be a pain in the ass for someone to come back to that code later and maintain it. Python on the other hand, especially with PEP-8, restricts a developers aesthetic options. It forces us to follow a common grammar. My point here, is that when you ask people what languages work with a 100+ active developers working on the same project, you get responses like Java, C#, maybe python. And you say, well why? And one of the responses is that Java and C# have an extensive common library. It allows developers to share a common method set. We've already begun the task of creating oslo to solve part of that problem for us in development. But in deployment, we're woefully behind the curve. We want to support diversity in the market eco system, but we also want to ensure that an OpenStack environment is adherent to some sort of baseline or flavor set. That is why folks have begun pushing things like refstack. I look at this thread, and what I see is a further need to unify solutions into a community supported method set that trumps outliers and one offs. A common set of tools. A common library of solutions. If OpenStack is to be the development
Re: [Openstack] Related Projects
+1. And I'd add that we need to do everything in our collective power to treat OpenStack as a coherent whole, not as a loosely federated set of projects that are released together. We are still a young community, but doing things to build supporting tools, expose commonalities and overlaps, and further healthy competition are all tremendously valuable. Don't force the solutions, build the ecosystem in which projects can compete. Tend the garden so the plants can thrive. The line between fragmentation and healthy competition lies mostly in the bounds set by the community and the leadership. Let's work on that. - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Friday, May 03, 2013 2:25 PM To: Marton Kiss Cc: Michael Bright; Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects This is going to come off as a bit of a rant. Pardon me. I feel it needs saying. There's a few ways to look at what OpenStack is. It's an IaaS solution. It's a cloud solution. But at it's heart, core to the design principles of OpenStack development ideology it is a collection of tools designed specifically to support elastic design patterns. The reason I bring this up is because of some thinking I've been doing about the future of OpenStack. Where it's place is in the world. Where it's place will be in the world. I've found that despite the crass nature of the puppies vs cattle explanation of elastic design, it really does get the most important selling point home to potential customers, and engineers who don't do ec2 already. And that point is that OpenStack exists to further a design pattern. It's not about clouds, or IaaS. It's about a design pattern. The pattern of horizontal scalability. The pattern of ephemeral resources. The pattern of share nothing. These core design ethics allow us to build software in a fashion that makes it consumable, scalable, and fault tolerant beyond any existing pattern by far. It makes development efforts become commodities that can be openly traded on a market free or otherwise. We need to stop thinking of OpenStack as just an IaaS solution. Or just a cloud. It's a development platform. It's a way of building software well. Once we do that, we can look to the past and see where we need to go. We want OpenStack to enjoy the some level of success as Java, or python as a collaborative development environment. We want kids in colleges to be training to write the next 50 years of applications in our environment, following our design patterns. But to do that, and to do it well, we'll need to solve a few things. This thread points to a growing problem in our community. One that was a primary focus of discussion in the last summit. OpenStack deployments are growing up and they are growing apart. We're building things too differently. The reason we employed PEP-8 gate tests, and the reason python works as a language in general is in part because when you give developers too many options, you end up losing a common language, or methodology that allows us to easily come up to speed on each others work. It makes collaboration hard. Now, not to start a language war, but I love perl. Nothing rips apart text like perl. Nothing. But, at the same time, I know that if I write perl code, it's going to be a pain in the ass for someone to come back to that code later and maintain it. Python on the other hand, especially with PEP-8, restricts a developers aesthetic options. It forces us to follow a common grammar. My point here, is that when you ask people what languages work with a 100+ active developers working on the same project, you get responses like Java, C#, maybe python. And you say, well why? And one of the responses is that Java and C# have an extensive common library. It allows developers to share a common method set. We've already begun the task of creating oslo to solve part of that problem for us in development. But in deployment, we're woefully behind the curve. We want to support diversity in the market eco system, but we also want to ensure that an OpenStack environment is adherent to some sort of baseline or flavor set. That is why folks have begun pushing things like refstack. I look at this thread, and what I see is a further need to unify solutions into a community supported method set that trumps outliers and one offs. A common set of tools. A common library of solutions. If OpenStack is to be the development environment of the next 75 years or more, we need to build this. It's one part of the many things we need to and are doing. But it's an important part. I think we can't just say, this isn't part of openstack, or this is outside of scope. It's part of the development environment that OpenStack is the runtime environment for ( forgive the analogy ). Anyways
[Openstack] Related Projects
Searching the wiki, I was unable to find any existing list of Related Projects so I started a new one at https://wiki.openstack.org/wiki/RelatedProjects. Please take a minute and ensure that your project is represented. Could one of the admins link it from https://wiki.openstack.org/wiki/Projects? Michael - Michael Fork Architect, OpenStack Development IBM Systems Technology Group___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
On 2013-05-02 07:05:46 -0700 (-0700), Michael J Fork wrote: [...] Could one of the admins link it from https://wiki.openstack.org/ wiki/Projects? I've added a section heading for this and transcluded your article at... https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects Hopefully this satisfies everyone involved, but if not we can easily change it. -- Jeremy Stanley ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
I'll throw it out there again: We really ought to deploy an OpenComparison site (http://opencomparison.org/) for OpenStack. It's awesome, and does massive amounts of goodness for managed information and discovery. - Gabriel -Original Message- From: Openstack [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jeremy Stanley Sent: Thursday, May 02, 2013 3:45 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects On 2013-05-02 07:05:46 -0700 (-0700), Michael J Fork wrote: [...] Could one of the admins link it from https://wiki.openstack.org/ wiki/Projects? I've added a section heading for this and transcluded your article at... https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects Hopefully this satisfies everyone involved, but if not we can easily change it. -- Jeremy Stanley ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
