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

[Glenn Tarbox, PhD]

2009/7/7 Thorbjørn Lindeijer <thorbjorn.lindeijer at nokia.com>

> 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.


Thats true and I think its important to state that the world is massively
better off with Qt going LGPL... this sort of clue-full decision is almost
extinct in the corporate world.  Obviously there are going to be issues
during transition which is fine (at least with me)


> 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).


Bugs are part of "the life we've chosen".

A small detail might be inserted here.  While its not mandated, "master" is
the generally accepted name of the "it works" branch of a repo.  Obviously,
we can use "master-stable" but methinks it would be better to have master be
master and any other "less than working" branch be named accordingly.

But, this isn't all that important... just that I'm not sure I see a reason
for the deviation from convention.


>
>
> 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.


The concept of "push" is one of the broken concepts in SVN.  Git is based on
the "pull" model.  The flexibility of git has to do with how a community
operates WRT "core" repos vs "important" repos vs "some guy made some change
and we should take a look" repos.



> 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.


One thing is becoming clear.  The fact that there is a legal barrier which
effectively removes the bulk of the Qt development from group participation
is going to greatly limit Qt's evolution into a true open-source project.
That Qt rocks will carry it a long way, perhaps it will even dominate... but
it will be less than it could be.


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


This clarified quite a bit.  Thanks

-glenn


>
>
> Regards,
> Bjørn
>
> --
> Thorbjørn Lindeijer
> Software Engineer
> Nokia, Qt Software
>
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
>



-- 
Glenn H. Tarbox, PhD ||  206-274-6919
http://www.tarbox.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-creator-old/attachments/20090707/9f11c144/attachment.html