'latest' branch for kde-qt (was: kdelibs (tests) doesn't build against qt 4.6.0-tp1)

[Thiago Macieira]

Em Quinta-feira 17. Setembro 2009, às 18.30.16, Matthew Woehlke escreveu:
> Thiago Macieira wrote:
> > qt-copy was the import of a tarball.
> 
> ...which is convenient for people (/me waves) that want latest Qt
> (especially when trunk occasionally depends on a pre-release), but
> usually aren't interested in making changes to Qt.

Indeed, but this is the answer to the call for more transparency. I understand 
that some people don't need this more data.

There is a way to update to "the current latest branch". There's a branch link 
called "HEAD" in the repository that points to the latest. You just have to 
every now and then verify where it's pointing.

But if you're going to do that, you may as well just look at the website.

> > Forcing the update on you will not work. The reason why is because 4.5.2-
> > patched contains commits that are not and will not be in 4.6.
> 
> As a serious question, why not? If they were legitimate patches for 4.5,
> why are they not acceptable for 4.6? If they are, they should be kept,
> no? If they are no longer applicable, then they should be reverted.
> Either way I don't see the problem.

There are various reasons why there are KDE patches that will not be in Qt. Off 
the top of my head:

1) patch was rejected by Qt development (example: 0180)
2) patch breaks binary, source and/or behaviour compatibility (example: 0231)
3) patch is specific to qt-copy (example: 0209)
4) patch will be in the next minor version of Qt, not patch-level

Those are patches that will persist. Besides those, there are patches that are 
either wrong or have been superseded by other changes in Qt (0280 for 
example), patches that haven't been processed yet by Qt developers, etc.

Even if all patches had been accepted for the next patch-level release, when 
they are merged into Qt, they are usually rebased, which means SHA-1s change.

The way I create the branches in kde-qt.git allows us to "start anew" at every 
Qt release, without holding to all previous patches that we had, in the 
history.

> > Git supports
> > updating branches, as long as the new branch tip is a descendant of the
> > current one.
> >
> > If it doesn't contain all commits in the current branch tip, it's called
> > history rewriting. I can't do that. Well, I can, but it'll break for you
> > later.
> 
> Would this work?
> - check out 'latest'¹
> - revert patches that won't be kept after the update

Revert by applying the reverse of the patch? Yes. But then we have two changes 
on top of Qt, instead of 0, per patch that won't be kept.

We cannot rewrite history if we expect "git pull" to work.

> - merge the next branch (e.g. 4.6-stable)
> - tack on an "adjustment commit" dumping any changes from the previous
> 'latest' that aren't in the new upstream²
> - push this as new 'latest'
> - pull from the new "parent" (in this example, 4.6-stable) frequently so
> that the head of 'latest' tracks the head of the parent and push the result

It's possible to do everything that you're saying, except for removing 
completely the old patches.

The only possibility is to keep them and then apply the reverse of them. 
They'll be in history forever this way and KDE's delta on top of Qt will never 
be 0.

The current solution allows us to "start anew". It's also easy for packagers 
to extract all changes. Though I strongly advise against any packager taking 
kde-qt changes wholesale -- please at least understand what the package is 
doing.

If we go with the patch + reverse patch solution, then the script I gave 
packagers to extract commits will have those two patches too.

> Is it perfect? No. Maybe not even "pretty", and you probably wouldn't
> want to submit patches off of it. Fortunately, git makes it really easy
> to migrate patch sets :-).
> 
> I'd be willing to do the branch cutovers (but someone will need to help
> me with what patches should be kept/dropped). I'm /not/ willing to do
> updates by hand, but I would hope that can be automated.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- 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://mail.kde.org/pipermail/kde-core-devel/attachments/20090917/abc067c6/attachment.sig>