Hi Lukas.

About maintainance of stuff, that Fabien do not lead, we might use Linus 
Torvalds convention of responsibility pyramid. Suppose, that you're leader of 
TwigBundle development. You fork Symfony and your fork becomes main development 
branch for TwigBundle. People send pull requests TO YOU and you review/merge 
them. After some time, you make your own big pull request to Fabien's Symfony 
repo and Fabien will merge it almost immediatly, cuz you're the trustee for 
TwigBundle and that's your area of responsibility. That's how Linux kernel 
development works. So i don't see the problem here.

The real problem is how to solve situation when the new version of TwigBundle 
gets released between Symfony releases. New version of TwigBundle is now 
stable, but stable branch of Symfony points to previous version of this bundle. 
And when we'll have more than 3 such sub-projects - it will become a hell for 
users.

I like the idea of separation for every component and bundle. In this case we 
need package management tool like Ruby Bundler, that will solve dependencies 
and install newest versions of components/bundles right after they become 
available. But until we have such tool - separation of Symfony repository will 
definetly become a hell for users, developers & contributors. 
--------------------------------------------------Konstantin Kudryashov 
(everzet)
http://about.me/everzet/bio 
On пятница, 18 февраля 2011 г. at 1:25, Lukas Kahwe Smith wrote:
Hi Fabien,
> 
> other approach .. fabien how do you envision that the components be 
> maintained? especially compared to the current model
> do you still think that people should send pulls to fabpot/master, especially 
> for stuff you do not lead. how do we encourage users to send them else where 
> in stead?
> do we want separate release cycles? for the weak dependencies we have, how to 
> test out different combinations of versions? or do we have separate versions 
> but release in sync and since we require full BC we kind expect things to 
> just continue to work and we do not allow a component to come out with a BC 
> breaking major version for the lifetime of Symfony2?
> 
> regards,
> Lukas Kahwe Smith
> [email protected]
> 
> 
> 
> -- 
> If you want to report a vulnerability issue on symfony, please send it to 
> security at symfony-project.com
> 
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
> 

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to