On Fri, 2011-03-04 at 16:38 -0500, Reed L O'Brien wrote: > On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote: > > > That said we definitely need to communicate the right message, provide > > the right level of documentation for the targeted audience, have a > > better way to expose tools and contributions, etc... > > > Who is the targeted audience? Currently it seems to be everyone with a > complaint. I was very happy with repoze.bfg as it shipped and am very happy > with pyramid as it currently ships. It was only a minor nuisance to add > pyramid_zcml as a dependency to the projects I had using it. I subsequently > stopped using it, so I don't have to manage another dependency; it is just > spelling... > > I used to know the docs in and out pretty well. Now I no longer do, because > things keep moving every time someone complains. Mostly I can find what I am > looking for by searching, but not if it moves out of the core docs... If the > same thing starts happening with pyramid's code/packages and it becomes a > game of thimblerig I will be very disappointed. I suspect there is a silent > majority out there that feels similarly. That is just a suspicion, however. > > There currently seem to be to disjoint desires: > > - make pyramid more opinionated with less ways to do things > - make pyramid smaller and remove all dependencies > > I think that pyramid and bfg before it were clearly not trying to be either > the kitchen sink or the micro-est of frameworks. I think it has also been > well documented that higher level frameworks should be built on pyramid > rather than into it. > > As for a smaller pyramid, for those embedded webapps... perhaps we should > apply the same approach. Keep pyramid shipping with its current features and > create a smaller core (say Prism) for it to depend on. "Prism" might not have > any templating, paste or other undesirable and offensive packages, but could > be used by people who need to conserve space. I wouldn't likely ever use it > as I would want the things that currently ship with pyramid and am not > worried about mako taking up 1MB of space unused. > > WRT the docs, perhaps we don't need to change (or rearrange) perfectly good > reference materials every day. If we need introductory docs why not a second > "Intro to Pyramid" doc? If we just want recipes to do basic things without > "too many" options, could we appeal to people (particularly people frustrated > with a recent experience) to add how-tos to the cookbook? Isn't that what it > is for? > > > The roof on this bike shed should definitely be tin. > Cheers, > ~ro >
I'm not averse to changing things in major releases, but we do need to recognize that major refactorings have a cost for both producers and consumers. All major docs work has historically been done by one person (me, or at least someone I've hired). The amount of time it took to write the software was long ago dwarfed by an order of magnitude the time it takes to write and maintain docs. Seemingly insignificant changes (from a developer perspective) to Pyramid can require hours of docs work if a feature is newly exposed or one is removed. I'm not complaining about this, it's just the way things are. On the consumer side, as Reed mentioned, it's very difficult to keep up when things change quickly. So, given that the costs are high, if we do make major functionality changes, I'd like it to be at the boundaries of first-dot major releases. For example, I don't think it makes sense to have a Pyramid 1.1 that does not ship with Mako or Chameleon or Paster, but nothing should be off the table for a 2.X. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
