[Qt-creator] Creator segmentation faults becoming common...

[Thorbjørn Lindeijer]

ext Glenn Tarbox, PhD wrote:
> On Mon, Jul 6, 2009 at 10:58 AM, Andre Poenitz 
> <andre.poenitz at mathematik.tu-chemnitz.de 
> <mailto:andre.poenitz at mathematik.tu-chemnitz.de>> wrote:
> 
> 
>      > (can't imagine why that policy exists other than CVS / SVN
>     hangover...
>      > git branches and direct repo access are a much better approach)
> 
>     It is a good idea to have a grace period to press the red button in case
>     of accidental commits.
> 
> 
> Thats the thing... DVCS doesn't have the same notion of "commit" which 
> lies at the heart of why SVN / CVS is broken / painful / bad.  The idea 
> is that one can publish to a separate repo or non-master branch but it 
> doesn't get merged into  "blessed" branch / repo until its been vetted.  
> The model moves from a central store with "controls" to one based on a 
> "web of trust"... the Qt community / Nokia identifies this branch... but 
> other fixes can be made available by anyone at any time, tested, and 
> easily backed out if necessary or, more importantly, incorporated when 
> one synchronizes with the blessed branch.
> 
> Take last weekend.  There was a trivial bug which broke the build 
> (needed a header file).  Easy fix but the patch needed to be pushed 
> around by pastebin because of this, um, somewhat broken use of git.  The 
> google tech talks by Linus and Schwarz (i recommend the latter) describe 
> the development and dissemination model and the "web of trust".  It has 
> nothing to do with controlling dissemination, and everything to do with 
> trusted branches and repos.

It's is not so easy to change around a companies entire workflow. The 
switch to git is still relatively recent. If you look closely, I think 
you'll notice that we are trying to move to the workflow you're 
describing, in that 'master' is kept stable and work is done on separate 
branches (some public, some private), until it is ready to be merged 
into master. Many Qt development teams already develop in their own 
repository and merge into master when it's ready. This workflow is also 
possible (and used) with gitorious' merge requests system.

That once in a while bugs do creep into master is for the moment 
unavoidable, and that's why 'master-stable' exists which, as far as I 
know, at least makes sure the autotests are passing (I'm not sure 
exactly what the process is).

Whether we are pushing directly to gitorious.org, or pushing to internal 
repositories that are synced to gitorious.org with a delay, doesn't 
change anything (at least, it doesn't affect the basic workflow). All 
that does is to introduce a period during which we can verify nothing 
sensitive gets pushed out, at the inconvenience of exposing fixes a bit 
later. I agree wholly that this isn't ideal, but this is purely for 
legal reasons as far as I am aware. Having to share a patch via other 
means for a few hours isn't the end of the world though, it's not like 
it happens every day and most developers are pretty used to that due to 
reviewing or testing other people's work.

Did that clear things up a bit or am I still missing something?

Regards,
Bjørn

-- 
Thorbjørn Lindeijer
Software Engineer
Nokia, Qt Software