)]}'
{"README.rst":[{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"b5a81515a55ef859a92000f92e7bde2ae1701bb6","unresolved":false,"context_lines":[{"line_number":19,"context_line":""},{"line_number":20,"context_line":"A \"deliverable\" is a unit of distribution of a useful project. It may"},{"line_number":21,"context_line":"be a single library or several server components that are packaged"},{"line_number":22,"context_line":"separately but used together. Rather than base the definition on"},{"line_number":23,"context_line":"technical terms such as packaging, we use the social organization of"},{"line_number":24,"context_line":"the project to identify deliverables. If the contents of two"},{"line_number":25,"context_line":"repositories share a bug reporting tool and use the same version"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa31d9ce_1fb62d3d","line":22,"updated":"2017-02-13 14:46:59.000000000","message":"I would say \"released and used together\".","commit_id":"7864283576439ac477102e9766eecd7b94a42ce6"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"c0d1927814454fc8302eae1447c1ce35576634c7","unresolved":false,"context_lines":[{"line_number":19,"context_line":""},{"line_number":20,"context_line":"A \"deliverable\" is a unit of distribution of a useful project. It may"},{"line_number":21,"context_line":"be a single library or several server components that are packaged"},{"line_number":22,"context_line":"separately but used together. Rather than base the definition on"},{"line_number":23,"context_line":"technical terms such as packaging, we use the social organization of"},{"line_number":24,"context_line":"the project to identify deliverables. If the contents of two"},{"line_number":25,"context_line":"repositories share a bug reporting tool and use the same version"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa31d9ce_4378c78f","line":22,"in_reply_to":"fa31d9ce_1fb62d3d","updated":"2017-02-13 16:42:50.000000000","message":"Done","commit_id":"7864283576439ac477102e9766eecd7b94a42ce6"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"39d14dcf005ee3bf89c17f070f85a98a85789f30","unresolved":false,"context_lines":[{"line_number":21,"context_line":"be a single library or several server components that are packaged"},{"line_number":22,"context_line":"separately but released and used together. Rather than base the"},{"line_number":23,"context_line":"definition on technical terms such as packaging, we use the social"},{"line_number":24,"context_line":"organization of the project to identify deliverables. If the contents"},{"line_number":25,"context_line":"of two repositories share a bug reporting tool and use the same"},{"line_number":26,"context_line":"version numbers for all releases, they are both part of the same"},{"line_number":27,"context_line":"deliverable."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Within this repository, each deliverable is represented by a separate"},{"line_number":30,"context_line":"file within the release series directory or the _independent"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_7c72ccae","line":27,"range":{"start_line":24,"start_character":54,"end_line":27,"end_character":12},"updated":"2017-02-13 17:57:31.000000000","message":"Just some commentary since we talked about this in IRC last week. I know this came up with the puppet modules as perhaps they should be a single deliverable. However given this line I\u0027m not sure they wouldn\u0027t fall under the \u0027single deliverable\u0027 umbrella. Each module has their own independent bug reporting section in launchpad.  Or in this case do you mean since they just share launchpad they should all be the same deliverable?  Additionally how would one handle the individual release notes for each repo if they were to be merged together under one \u0027deliverable\u0027?  It doesn\u0027t look like the release yaml structure would support each of these being independent while having them all be \u0027single deliverable\u0027","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"b05ab9b7f60ef8b925df6164f2f3d3272f36f8c6","unresolved":false,"context_lines":[{"line_number":21,"context_line":"be a single library or several server components that are packaged"},{"line_number":22,"context_line":"separately but released and used together. Rather than base the"},{"line_number":23,"context_line":"definition on technical terms such as packaging, we use the social"},{"line_number":24,"context_line":"organization of the project to identify deliverables. If the contents"},{"line_number":25,"context_line":"of two repositories share a bug reporting tool and use the same"},{"line_number":26,"context_line":"version numbers for all releases, they are both part of the same"},{"line_number":27,"context_line":"deliverable."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Within this repository, each deliverable is represented by a separate"},{"line_number":30,"context_line":"file within the release series directory or the _independent"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_b7d7fdbd","line":27,"range":{"start_line":24,"start_character":54,"end_line":27,"end_character":12},"in_reply_to":"fa31d9ce_1738c99f","updated":"2017-02-13 18:23:09.000000000","message":"Fair enough, thanks for the info.","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6236d4ccf1c7f820b1b2e69cab4539478c4e97d6","unresolved":false,"context_lines":[{"line_number":21,"context_line":"be a single library or several server components that are packaged"},{"line_number":22,"context_line":"separately but released and used together. Rather than base the"},{"line_number":23,"context_line":"definition on technical terms such as packaging, we use the social"},{"line_number":24,"context_line":"organization of the project to identify deliverables. If the contents"},{"line_number":25,"context_line":"of two repositories share a bug reporting tool and use the same"},{"line_number":26,"context_line":"version numbers for all releases, they are both part of the same"},{"line_number":27,"context_line":"deliverable."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Within this repository, each deliverable is represented by a separate"},{"line_number":30,"context_line":"file within the release series directory or the _independent"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_1738c99f","line":27,"range":{"start_line":24,"start_character":54,"end_line":27,"end_character":12},"in_reply_to":"fa31d9ce_7c72ccae","updated":"2017-02-13 18:10:53.000000000","message":"We\u0027ve already agreed that if the puppet modules are actually released separately, they should be separate deliverables.\n\nI can make it more clear that by \"bug reporting tool\" we mean the same launchpad project, and not just launchpad itself.\n\nThe releases repo has support for separate notes URLs in separate repositories under a single deliverable. Neutron uses this feature. See the schema description later in this file for details.","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"39d14dcf005ee3bf89c17f070f85a98a85789f30","unresolved":false,"context_lines":[{"line_number":82,"context_line":" * Do not increment version numbers artificially to maintain"},{"line_number":83,"context_line":"   consistent versions between deliverables. We expect versions of"},{"line_number":84,"context_line":"   compatible deliverables to drift apart over time, and made the"},{"line_number":85,"context_line":"   decision to embrace this by using other tools to document for users"},{"line_number":86,"context_line":"   which combinations of packages go together."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"   http://lists.openstack.org/pipermail/openstack-dev/2015-June/065992.html"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_bcf44487","line":85,"range":{"start_line":85,"start_character":37,"end_line":85,"end_character":60},"updated":"2017-02-13 17:57:31.000000000","message":"What are these other tools?  Are they language agnostic such that they can be consumed by $everyone?\n\n\nPartially why in the puppet modules we have specific version numbers is related to tooling and to reduce the overhead to manage this.  When I asked in IRC it was mentioned that the version numbers might be used to determine maturity which doesn\u0027t seem like something documented here.  Perhaps this should be a \u0027Should not\u0027 rather an a \u0027Do not\u0027?  I understand the \u0027don\u0027t just line versions with other projects\u0027 but I think there are times when this rule might need to be adapted based on the type of project.  \n\n\nI see this being a sticking point for the \u0027support\u0027 type of projects such as ansible, puppet, charms, salt, etc where we have a list of deliverables that we loosely joined together and apply to a specific set of other projects but they all work together (i.e. 10.x.x is for Ocata). That being said each of our deliverables are still independent of each other because it doesn\u0027t make sense to release 40 modules when only 1 has changed but usually that\u0027s a minor update (10.x.1, 10.x.2, etc).  In the puppet modules, each one of the modules is sharing an underlying single version for the shared structure and each new cycle brings a major version bump because we drop a level of backwards compatibility which is why we have the version we have.  Does this concept fall under the \u0027artificial version increment\u0027?","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"},{"author":{"_account_id":14985,"name":"Alex Schultz","email":"aschultz@next-development.com","username":"mwhahaha"},"change_message_id":"b05ab9b7f60ef8b925df6164f2f3d3272f36f8c6","unresolved":false,"context_lines":[{"line_number":82,"context_line":" * Do not increment version numbers artificially to maintain"},{"line_number":83,"context_line":"   consistent versions between deliverables. We expect versions of"},{"line_number":84,"context_line":"   compatible deliverables to drift apart over time, and made the"},{"line_number":85,"context_line":"   decision to embrace this by using other tools to document for users"},{"line_number":86,"context_line":"   which combinations of packages go together."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"   http://lists.openstack.org/pipermail/openstack-dev/2015-June/065992.html"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_f7733513","line":85,"range":{"start_line":85,"start_character":37,"end_line":85,"end_character":60},"in_reply_to":"fa31d9ce_77e105fe","updated":"2017-02-13 18:23:09.000000000","message":"So that\u0027s the thing, a new module from puppet doesn\u0027t start from scratch.  It automatically inherits 10+ releases worth of maturity because we have tooling and shared patterns. Maybe that\u0027s where I don\u0027t agree around this specific \u0027Do not\u0027 rule.  I\u0027d be ok with this being a firm guideline (\u0027$entity should not...\u0027 vs \u0027$entity do not...\u0027) but I don\u0027t agree with it being a hard rule because I think it requires an understanding of the deliverable that maybe the release folks wouldn\u0027t necessarily have.","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"6236d4ccf1c7f820b1b2e69cab4539478c4e97d6","unresolved":false,"context_lines":[{"line_number":82,"context_line":" * Do not increment version numbers artificially to maintain"},{"line_number":83,"context_line":"   consistent versions between deliverables. We expect versions of"},{"line_number":84,"context_line":"   compatible deliverables to drift apart over time, and made the"},{"line_number":85,"context_line":"   decision to embrace this by using other tools to document for users"},{"line_number":86,"context_line":"   which combinations of packages go together."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"   http://lists.openstack.org/pipermail/openstack-dev/2015-June/065992.html"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fa31d9ce_77e105fe","line":85,"range":{"start_line":85,"start_character":37,"end_line":85,"end_character":60},"in_reply_to":"fa31d9ce_bcf44487","updated":"2017-02-13 18:10:53.000000000","message":"This repository, for one. Dependencies between deliverables are another. Distros have their own tools, too.\n\nThe problem isn\u0027t with incrementing the major version number at a cycle boundary. We have a lot of projects that do that. The problem is releasing a brand new thing with version number 10. I can add something more specific about maturity.","commit_id":"aa735c5a95f0f883fe29efdbd51e99b915590e95"}]}