On Thursday, November 1, 2012 4:44:46 PM UTC-5, Michael Stanhke wrote: > > I'm trying to close the loop on this thread. >
I appreciate that. > Completed: > * The upgrade guide has been updated to mention software > pinning/freezing etc: http://docs.puppetlabs.com/guides/upgrading.html > * We have filed an enhancement request to allow range pinning in > puppet itself. http://projects.puppetlabs.com/issues/17102 If this > is interesting to you, please watch, upvote and/or submit patches for > this. > Those are good things, but they don't really address the core issue as far as I'm concerned. > > Commitments: > * Puppet Labs Software Delivery org will be publishing policies around > our repositories > * We will do more communication around breaking changes landing in our > repositories, and evaluate needs to address breakage on a case-by-case > basis. > > Again, those are good things, but not directly responsive to the problem. > > Comments: > * We've had over 90,000 downloads of Puppet 3 from our repositories > (not counting Mac, Windows, Solaris, or rubygems.org). We've had > concerns voiced by less than 15 people total. I realize this doesn't > mean everybody who had issues reported anything to us. > > It is reasonable to attempt to gauge the scope and impact of the issue as part of your decision process for how to address it, but the number of people voicing concerns to PL about the issue is a really poor statistic for that purpose. It may indeed be that the issue is insignificant, but I don't appreciate that implication being made on such an unsound basis. > > The idea of separate repositories has been brought up, and debated > heavily internally. We currently have over 500 package repository > targets based on versions, architectures and repo-streams (devel, > deps, products) etc. Branching for each major product (puppet, > puppetdb, mcollective) is multiplicative and would result in many, > many more each time we branch. That's a larger technical challenge than I appreciated, but it still isn't responsive to the issue. > This could easily cause confusion > about which repositories to enable, disable, use for migrations from > one version to the next etc. > > *That* problem is (or should be) addressed by all the revised and augmented documentation described. It's a different issue than the one I thought we were discussing, however, which was about people who did not intend or want to migrate at all. No amount of upgrade / migration documentation is useful to people who weren't looking to upgrade in the first place. > While we haven't ruled out this approach in the future, it requires > quite a lot of build toolchain and automation changes. It's likely as > a user you would get more value from Puppet Labs spending their > efforts elsewhere. > I'll have to take your word on that, though I find it surprising. Multiplicative changes such as that tend to be cheap on the development side. It's normally the resulting resource requirements (disk space, number of virtual web hosts, etc.) that are at risk of being large. What I'm hearing is that it is a challenging problem to address in the way that I would consider right, and that although PL sees some benefits to doing it that way, it is not convinced that doing so would be an overall win. Inasmuch as I am unlikely to raise any new points that have not already been covered above or in PL's internal discussions on the subject, I will stop here. I can only say that I am disappointed. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/1iKmgqa_m7gJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
