<p dir="ltr"> Responses inline. </p>
<p dir="ltr">On 29 May 2015 6:15 pm, "Haïkel" <<a href="mailto:hguemar@fedoraproject.org">hguemar@fedoraproject.org</a>> wrote:<br>
><br>
> 2015-05-29 15:41 GMT+02:00 Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>:<br>
> > Hi everyone,<br>
> ><br>
> > TL;DR:<br>
> > - We propose to stop tagging coordinated point releases (like 2015.1.1)<br>
> > - We continue maintaining stable branches as a trusted source of stable<br>
> > updates for all projects though<br>
> ><br>
><br>
> Hi,<br>
><br>
> I'm one of the main maintainer of the packages for Fedora/RHEL/CentOS.<br>
> We try to stick as much as possible to upstream (almost zero<br>
> downstream patches),<br>
> and without intermediate releases, it will get difficult.</p>
<p dir="ltr">If you consider *every* commit to be a release, then your life becomes easier. This is just a case of bumping the SemVer patch version per commit (as eloquently put by Jeremy).  We even have tooling to automate the version generation via pbr..</p>
<p dir="ltr">Therefore, you might want to jump from X.X.100 to X.X.200 which would mean 100 commits since the last update. </p>
<p dir="ltr">> I'm personally not fond of this as it will lead to more fragmentation.<br>
> It may encourage<br>
> bad behaviors like shipping downstream patches for bug fixes and CVE instead<br>
> of collaborating upstream to differentiate themselves.<br>
> For instance, if we had no point-based release, for issues tracking<br>
> purposes, we would<br>
> have to maintain our sets of tags somewhere.</p>
<p dir="ltr">I disagree, each distro already does security patching and whilst I expect this to still happens, it actually *encourages* upstream first workflow as you can select a release on your own cadence that includes commits you need, for your users.</p>
<p dir="ltr">> There's also the release notes issue that has already been mentioned.<br>
> Still continuous release notes won't solve the problem, as you wouldn't<br>
> be able to map these to the actual packages. Will we require operators<br>
> to find from which git commit, the packages were built and then try to figure<br>
> out which fixes are and are not included?</p>
<p dir="ltr">Can you provide more detail? I'm not understanding the problem.</p>
<p dir="ltr">> > Long version:<br>
> ><br>
> > At the "stable branch" session in Vancouver we discussed recent<br>
> > evolutions in the stable team processes and how to further adapt the<br>
> > work of the team in a "big tent" world.<br>
> ><br>
> > One of the key questions there was whether we should continue doing<br>
> > stable point releases. Those were basically tags with the same version<br>
> > number ("2015.1.1") that we would periodically push to the stable<br>
> > branches for all projects.<br>
> ><br>
> > Those create three problems.<br>
> ><br>
> > (1) Projects do not all follow the same versioning, so some projects<br>
> > (like Swift) were not part of the "stable point releases". More and more<br>
> > projects are considering issuing intermediary releases (like Swift<br>
> > does), like Ironic. That would result in a variety of version numbers,<br>
> > and ultimately less and less projects being able to have a common<br>
> > "2015.1.1"-like version.<br>
> ><br>
><br>
> And that's actually a pain point to track for these releases in which<br>
> OpenStack branch belong. And this is probably something that needs to<br>
> be resolved.<br>
><br>
> > (2) Producing those costs a non-trivial amount of effort on a very small<br>
> > team of volunteers, especially with projects caring about stable<br>
> > branches in various amounts. We were constantly missing the<br>
> > pre-announced dates on those ones. Looks like that effort could be<br>
> > better spent improving the stable branches themselves and keeping them<br>
> > working.<br>
> ><br>
><br>
> Agreed, but why not switching to a time-based release?<br>
> Regularly, we tag/generate/upload tarballs, this could even be automated.<br>
> As far as I'm concerned, I would be more happy to have more frequent releases.<br>
><br>
> > (3) The resulting "stable point releases" are mostly useless. Stable<br>
> > branches are supposed to be always usable, and the "released" version<br>
> > did not undergo significantly more testing. Issuing them actually<br>
> > discourages people from taking whatever point in stable branches makes<br>
> > the most sense for them, testing and deploying that.<br>
> ><br>
> > The suggestion we made during that session (and which was approved by<br>
> > the session participants) is therefore to just get rid of the "stable<br>
> > point release" concept altogether for non-libraries. That said:<br>
> ><br>
> > - we'd still do individual point releases for libraries (for critical<br>
> > bugs and security issues), so that you can still depend on a specific<br>
> > version there<br>
> ><br>
> > - we'd still very much maintain stable branches (and actually focus our<br>
> > efforts on that work) to ensure they are a continuous source of safe<br>
> > upgrades for users of a given series<br>
> ><br>
> > Now we realize that the cross-section of our community which was present<br>
> > in that session might not fully represent the consumers of those<br>
> > artifacts, which is why we expand the discussion on this mailing-list<br>
> > (and soon on the operators ML).<br>
> ><br>
><br>
> Thanks, I was not able to join this discussion, and that was the kind<br>
> of proposal<br>
> that I was fearing to see happen.<br>
><br>
> > If you were a consumer of those and will miss them, please explain why.<br>
> > In particular, please let us know how consuming that version (which was<br>
> > only made available every n months) is significantly better than picking<br>
> > your preferred time and get all the current stable branch HEADs at that<br>
> > time.<br>
> ><br>
><br>
> We provide both type of builds<br>
> * git continuous builds => for testing/CI and early feedback on potential issues<br>
> * point-release based builds => for GA, and production<br>
><br>
> Anyway, I won't force anyone to do something they don't want to do but I'm<br>
> willing to step in to keep point releases in one form or another.<br>
><br>
> Regards,<br>
> H.<br>
><br>
> > Thanks in advance for your feedback,<br>
> ><br>
> > [1] <a href="https://etherpad.openstack.org/p/YVR-relmgt-stable-branch">https://etherpad.openstack.org/p/YVR-relmgt-stable-branch</a><br>
> ><br>
> > --<br>
> > Thierry Carrez (ttx)<br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>