On Fri, Feb 4, 2011 at 8:47 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 2/5/11, bulia byak wrote:
Distributed VCSes have their place in projects where a lot of forking and merging happens, or where all developers are comfortable with that model and newbies are not welcome (such as Linux kernel). But Inkscape is not like that at all - it has traditionally preferred gradual in-the-trunk reworking rather than branches even for complex refactorings, and while it is complex it has a lot of places that are newbie-hackable to great benefit and with little danger (such as filters).
With all respect due, our primary tradition these days seems to be in the lines of "can we pretty please try to release this year?". What you are referring to stopped taking place years ago. Since 2007 or so half of our new features come from GSoC projects that live in branches first and get merged later. There's no rule for things happening any more.
IMO, there's nothing bad about working in branches as long as trunk doesn't undergo any major infrastructure changes and as long as there are people who are willing to do QA before merging stuff from branches.
Actually, even major changes in trunk (or master, in case of Git) are not exactly such a pain. I never tried merging from trunk into local clone in bzr, buit I did it once or twice with Git, and it wasn't such a big deal.
Am I the only one who just views the dvcs model as the norm? It seems like more than half of the projects I checkout and compile from are using either bzr or git... given that my contributions to said projects tend to be very minimal, but it just doesn't seem as nasty as a lot of people seem to experience. Doing a pull/update prior to starting a commit process just seems like the normal procedure. To me it's much like turning on the ignition to the car, releasing the parking brake if on a hill, placing my foot on the brake, and changing to a gear from park. It doesn't take long before it becomes routine.
Cheers, Josh