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.
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
