[Development] Branching for Qt 5 repositories

[Thiago Macieira]

On sexta-feira, 28 de setembro de 2012 09.06.42, Laszlo Papp wrote:
> > That's the point: it's not the most common way, at least not in Git. If
> > you
> > take for example Git's Git, the "master" branch contains the latest
> > release, whereas the next release is in the "next" branch.
> 
> Well, you can say that it is not common, but I could enumerate quite a
> few examples including KDE, gnome, webkit (trunk?), and numerous other
> big projects where trunk/master is the development branch. Another
> variant is what Loaden mentioned, but I do not prefer the initially
> proposed way in this thread.

I actually prefer Loaden's suggestion, but in the interest of avoiding exactly 
the confusion that you're seeing now, we preferred to remove "master" 
completely. This way, there's no ambiguity.

> Speaking of common way, I would stick to master or "next". As I have

Some people didn't like "next". I don't mind it.

> > No, I really do and those qualifiers are required, but note that they
> > apply to each feature individually. That is, if you want to merge the
> > command-line parser, it needs to be feature-complete, working,
> > documented, tested and a few more qualifiers (cf. Qt Project's "Technical
> > Fit") before I or anyone else should click that +2.
> 
> If those all fully apply, I would call it "release" since there is
> nothing to fix anymore or stabilize since it is "completely". My point
> is that there may be bugs on certain platforms where it is not well
> tested, or the documentation is written and approved by developers and
> cannot get better until it is released to the public for further
> feedback and improvement.

Yeah, right... We've been feature-complete for a while. So why is Qt 5.0.0 not 
released yet?

Feature-complete means all features (for this particular project) are 
developed and unit tested. It means they've been tested to work according to 
the design on, at *least*, the reference platforms, though we're likely to be 
a little lax here for small features and allow the integration to be the test 
on the reference platforms.

In particular, it does not mean there are no bugs. And also note that I did 
not say anything about API reviews, though a minimal review of larger features 
is necessary, of course. The point of an alpha release is to get feedback on 
the *functionality* and whether it actually serves the purpose it was intended 
to. That means all the code in the dev branch, which is alpha quality and 
ready to go into beta, must be ready for that kind of feedback.

Incomplete features, like stuff that doesn't compile, doesn't work on all 
reference platforms, has missing implementations, misses documentation or unit 
testing, hasn't had even a minimal API review, does not belong in the dev 
branch.

> >> 1) Bug that was already fixed in the development branch.
> > 
> > Not a problem. That indicates that either the fix was submitted to the
> > wrong branch or that this particular fix did not apply to more stable
> > branches. If this person developing the new fix comes up with a fix that
> > is acceptable for the stable branch, then it makes sense to accept it, in
> > spite of a different fix existing in dev.
> 
> Even if the fix does not apply against the stable or release branch,
> the fix in dev might contain the idea which needs to be adopted. That
> can occasionally spare a lot of time for the contributor trying to fix
> the issue in stable or release. Like I said, perhaps this could be
> avoided with a very good workflow documentation, but then there is
> always the factor, not everybody can read that carefully from A-Z.

We cannot design an idiot-proof system. I'm not calling our contributors 
idiots: in fact, quite to the contrary, I'm calling our contributors 
reasonable and intelligent people, who will realise that there are more 
branches they could look at.

Moreover, complete newbies will need some handholding and then it falls to the 
existing contributors to point out where solutions might be developed already.

This post of mine here is intended to become part of the wiki, which is that 
workflow documentation you're looking for.

> >> 2) Feature that may have been already put into the development branch,
> >> but it is not yet in the stable or release due to its current quality.
> >> However, a new developer should not reinvent that due to a mistake.
> > 
> > I don't think it's a problem either. This developer may develop new
> > features on top of the stable release (I used to do that in Qt 4), but
> > should pay attention to the development branch. Qt is big, but it's not
> > hard to pay attention to the areas one is developing on.
> 
> Well, it happens to many from time to time even with top developers
> occasionally. We always see this around due to our human nature as we
> are not perfect. We make mistakes if we have additional factors like
> this. So "should pay attention" is yet another fact for confusion,
> misunderstanding, and overlooking.

Yeah, and so? I prefer to design a system that has the most chance of being 
stable, at the cost of having some slight mistakes in redeveloping, than 
developing a system that has a bigger chance of generating unstable code and 
longer release times. In my opinion, the human mistake factor is much bigger 
and has a larger impact in the stabilisation process.

> > The intention is that new developers who
> > clone Qt repositories for the first time are presented with a stable
> > codebase they can begin working on, bugfixing and even developing new
> > features for.
> Also, this is a bit in contradiction with this qualifier, at least for me:
> 
> "[*] alpha quality is feature complete, working, documented, tested, etc."

I don't get it. I don't see a contradiction here. The alpha quality code is 
not bug-free nor is it stable. It's just feature complete and does at least 
what it intended to do.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120928/70e65c14/attachment.sig>