The Linux model sounds very good indeed. One problem of the current approach is that we do not enforce this pyramid. Right now, I don't send a pull request for every change (unless it's really an urgent problem), but gather some fixes, and then send a batch request. Now, if someone has also fixed any of the things I already fixed locally, but does that slightly differently and that gets merged, then I end up with nasty merge conflicts which could have prevented if the PR had been sent through my fork.
I'm not sure if we can teach people to send to the correct repo, especially if we have many repos, or if a pull request overlaps two areas, then it's probably better sent to a single development repo. I guess we could start by trying the first approach, and if we see that this is not practical still switch to the single development repo. Regarding releases cycling, I think we could still have a symfony release even if components could have different release cycles. For example, for Security most of the code is contained in the Component, and the bundle is mostly set-up code, or code that is aware of the DIC. So, in this case it makes sense if the SecurityBundle is tied to a release cycle of the Security Component that simply allows for faster iterations. It doesn't mean that we couldn't have a symfony release anymore, but we could call it a Symfony Framework release (meaning a release of the FrameworkBundle with related components DIC, HttpFoundation, HttpKernel, etc.). So, we would basically have "projects" which have release cycles such as - Symfony Framework - Symfony Forms - Symfony Security - Symfony Payment ? - Symfony Webservices ? - ... Kind regards, Johannes On Fri, Feb 18, 2011 at 8:08 AM, Fabien Potencier < [email protected]> wrote: > On 2/18/11 1:15 AM, Konstantin Kudryashov wrote: > >> 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. >> > > I think the Linus model is very good. That's mostly how it already works > today with Johannes (Security) and Bernhard (Form/Validation). But I never > merge things blindly. My responsibility is also to review the code. > > The only problem I see right now is how someone can identify where to send > a pull request. > > Let's say someone wants to submit a patch for the security component. He > should submit it to the Johannes's fork. But for Twig, he must use my fork. > And to submit a new validator, he must use Bernhard's fork. > > So, instead of the current way, where everything is submitted to my repo, > things should start to be submitted at the right place... or on a special > development repo. What do you think? > > 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. >> > > The right question is: "What is a Symfony release?" > > If each component and each bundle can have their own release cycle, there > is no Symfony release anymore. > > So, my idea is the following: > > * All components have the same release cycle > * Each bundle has its own release cycle > > Releasing Symfony means releasing a new version of the components. > > That's also why I have introduced the notion of a distribution. A > distribution is a pre-made Symfony project (like the sandbox): the Symfony > components, a selection of bundles (and version), and a default > configuration. > > So, releasing Symfony also means releasing a distribution of Symfony where > we choose which bundles to include and at which version. > > 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. >> > > The installation tool is really a end-user problem. We need to solve it of > course, but this is totally independent from how we develop Symfony. > > Fabien > > --------------------------------------------------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 > -- 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
