This looks like good news to me: I've noticed that Pylons and Repoze shared a lot of common ground. Ben and Chris are seriously smart dudes, and I'm excited to see what they come up with when they put their heads together.
I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, and announced as a fait accompli. Was there really no step that involved consulting users of both frameworks to find out what they wanted?
I ask because we (Django developers) spend a lot of time obsessing over backwards compatibility, often to the point where we have to compromises our grand goals for more pragmatic ones. I'd be terrified of making a move like this, so I'm curious to hear if users feel they've been slighted, or if they're pretty much happy to go with the flow.
Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components.
Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configuration setup. It's code was also out there, and ppl poked at it some:
http://bitbucket.org/chrism/marco
It got a little ways, but it kept looking more and more like the existing repoze.bfg... which brought us to a point where pylons-trunk was built on BFG. This entire discussion is on the pylons-dev list here:
http://groups.google.com/group/pylons-devel/browse_thread/th...
Then, in an effort to resolve remaining differences in the code, several of us flew out to meet in person to discuss remaining issues in the code and see if a better collaboration could work out. We decided to try out the idea of a merger, since pylons-trunk for Pylons 2 was doing little more than minor extensions of repoze.bfg anyways, which was collapsed into the pyramid code-base (and is a distinction in that respect from repoze.bfg which doesn't have those bits).
It worked out quite well from some attempts at 'trying it out' and the news of this leaked quite a bit earlier than we anticipated making it hard to try and put together what I think could've been a better process.
Was there a discussion where we asked everyone in both communities for their input on merging? Not really, we talked to primary contributors and developers who had worked on each stack to try and solicit input and ensure they were all in favor of it. But yes, I agree entirely that I should've solicited feedback from the pylons community at large.
For pylons the code-base, there really isn't going to be any difference from what there is right now, and has been. A maintained, stable, mature code-base, that has hit a point where there's little more to be done with it. It's been at a feature-standstill for about 2+ years now. It's not going away, and it will still be maintained.
So I think the way the merger was done definitely could've been announced differently, with more emphasis on what it meant for the pylons code-base (nothing really), vs. the continuing development efforts of myself and other pylons developers.
As mentioned below, there's no "leaving" involved. The pylons code-base has been maintained for several years with little in the way of new features, just bug fixes, some minor clean-ups, and security fixes. That isn't changing... so there's nothing 'different' for the pylons code-base involved.
I'm confused where this notion of leaving pylons comes from, when nothing is changing with it.
Not quite the same, because the new version has a bunch of features added. If you'd like to stick with the camera analogy, you should think of the pylons framework more as a good lens for the DSLR. Most of the features are from the body, so you upgrade that and keep using the same lens.
The Pylons framework was almost entirely just glue between your choices of ORM/templates along with using WebHelpers and Beaker. Those projects are still in use with pyramid, still getting updates (and thus a pylons project will still get feature updates via them).
I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, and announced as a fait accompli. Was there really no step that involved consulting users of both frameworks to find out what they wanted?
I ask because we (Django developers) spend a lot of time obsessing over backwards compatibility, often to the point where we have to compromises our grand goals for more pragmatic ones. I'd be terrified of making a move like this, so I'm curious to hear if users feel they've been slighted, or if they're pretty much happy to go with the flow.