Open Stack

Just checking on the progress of this. :)

> Monty Taylor <mailto:mordred at inaugust.com>
> April 7, 2017 at 7:05 AM
>
>
> There is a new repo now:
>
> http://git.openstack.org/cgit/openstack/project-navigator-data
>
> I have pushed up two different patches with two different approaches:
>
> https://review.openstack.org/#/c/454691
> https://review.openstack.org/#/c/454688
>
> One is a single file per release. The other is a file per service per 
> release.
>
> Benefits of the single-file are that it's a single file to pull and 
> parse.
>
> Benefits of the multi-file approach are that projects can submit 
> documents for themselves as patches without fear of merge conflicts, 
> and that the format is actually _identical_ to the format for version 
> discovery from the API-WG, minus the links section.
>
> I think I prefer the multi-file approach, but would be happy either way.
>
> __________________________________________________________________________ 
>
> 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
> Jimmy McArthur <mailto:jimmy at openstack.org>
> April 6, 2017 at 3:51 PM
> Cool. Thanks Monty!
>
>
> __________________________________________________________________________
> 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
> Monty Taylor <mailto:mordred at inaugust.com>
> April 6, 2017 at 3:21 PM
> On 04/06/2017 11:58 AM, Jimmy McArthur wrote:
>> Assuming this format is accepted, do you all have any sense of when this
>> data will be complete for all projects?
>
> Hopefully "soon" :)
>
> Honestly, it's not terribly difficult data to produce, so once we're 
> happy with it and where it goes, crowdsourcing filling it all in 
> should go quickly.
>
>>> Jimmy McArthur <mailto:jimmy at openstack.org>
>>> April 5, 2017 at 8:59 AM
>>> FWIW, from my perspective on the Project Navigator side, this format
>>> works great. We can actually derive the age of the project from this
>>> information as well by identifying the first release that has API data
>>> for a particular project. I'm indifferent about where it lives, so I'd
>>> defer to you all to determine the best spot.
>>>
>>> I really appreciate you all putting this together!
>>>
>>> Jimmy
>>>
>>>
>>> __________________________________________________________________________ 
>>>
>>> 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
>>> Thierry Carrez <mailto:thierry at openstack.org>
>>> April 5, 2017 at 5:28 AM
>>>
>>> Somehow missed this thread, so will repost here comments I made 
>>> elsewhere:
>>>
>>> This looks good, but I would rather not overload the releases
>>> repository. My personal preference (which was also expressed by
>>> Doug in the TC meeting) would be to set this information up in a
>>> "project-navigator" git repo that we would reuse for any information we
>>> need to collect from projects for accurate display on the project
>>> navigator. If the data is not maintained anywhere else (or easily
>>> derivable from existing data), we would use that repository to collect
>>> it from projects.
>>>
>>> That way there is a clear place to go to to propose fixes to the 
>>> project
>>> navigator data. Not knowing how to fix that data is a common complaint,
>>> so if we can point people to a git repo (and redirect people from there
>>> to the places where other bits of information happen to live) that 
>>> would
>>> be great.
>>>
>>> Monty Taylor <mailto:mordred at inaugust.com>
>>> April 4, 2017 at 5:47 PM
>>> Hey all,
>>>
>>> As per our discussion in today's TC meeting, I have made a document
>>> format for reporting versions to the project navigator. I stuck it in
>>> the releases repo:
>>>
>>>   https://review.openstack.org/453361
>>>
>>> Because there was already per-release information there, and the
>>> governance repo did not have that structure.
>>>
>>> I've included pseudo-code and a human explanation of how to get from a
>>> service's version discovery document to the data in this document, but
>>> also how it can be maintained- which is likely to be easier by hand
>>> than by automation - but who knows, maybe we decide we want to make a
>>> devstack job for each service that runs on tag events that submits a
>>> patch to the releases repo. That sounds like WAY more work than once a
>>> cycle someone adding a few lines of json to a repo - but *shrug*.
>>>
>>> Basing it on the version discovery docs show a few things:
>>>
>>> * "As a user, I want to consume an OpenStack Service's Discovery
>>> Document" is a thing people might want to do and want to do
>>> consistently across services.
>>>
>>> * We're not that far off from being able to do that today.
>>>
>>> * Still, like we are in many places, we're randomly different in a few
>>> minor ways that do not actually matter but make life harder for our
>>> users.
>>>
>>> Thoughts and feedback more than welcome!
>>> Monty
>>>
>>> __________________________________________________________________________ 
>>>
>>>
>>> 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
>>
>>
>>
>> __________________________________________________________________________ 
>>
>> 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
>>
>
>
> __________________________________________________________________________ 
>
> 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
> Jimmy McArthur <mailto:jimmy at openstack.org>
> April 6, 2017 at 11:58 AM
> Assuming this format is accepted, do you all have any sense of when 
> this data will be complete for all projects?
>
>
> __________________________________________________________________________
> 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
> Jimmy McArthur <mailto:jimmy at openstack.org>
> April 5, 2017 at 8:59 AM
> FWIW, from my perspective on the Project Navigator side, this format 
> works great. We can actually derive the age of the project from this 
> information as well by identifying the first release that has API data 
> for a particular project. I'm indifferent about where it lives, so I'd 
> defer to you all to determine the best spot.
>
> I really appreciate you all putting this together!
>
> Jimmy
>
>
> __________________________________________________________________________
> 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/20170413/d04fb4c8/attachment.html>