[Kde-scm-interest] Package splitting

[Thiago Macieira]

Em Quarta-feira 27 Janeiro 2010, às 14:46:21, Oswald Buddenhagen escreveu:
> On Wed, Jan 27, 2010 at 02:01:28PM +0100, Thiago Macieira wrote:
> > Git submodule isn't atomic at all. It cannot be used to indicate
> > atomicity because it requires at *least* two operations (two pushes),
> > any of which could fail. In our case, it would require three: two
> > submodules and the supermodule.
> > 
> > If we have split repositories, then we lose atomicity. Period.
> > 
> > This includes for example having kdelibs separated from kdebase. If
> > someone adds a new feature to kdelibs and then uses it in any
> > application, that already requires non-atomic updates.
> > 
> > And no one is suggesting making one huge KDE repository with everything
> > in.
> > 
> > So forget atomicity. It's not an argument.
> 
> indeed.
> 
> but i think that's non-critical for dependencies on "additive" changes,
> as it is sufficient to commit the lib change first, then the supermodule
> change and finally app change.

I don't think updating the supermodule is necessary.

What gain do you have here?

> it becomes a problem if the change really needs to be atomic because the
> lib change is "substitutive", i.e., breaks existing functionality. the
> "pseudo-atomicity" would be still sufficient to eliminate most cases of
> "update foolibs, sucker" cases, though.

> btw, in theory, it is possible to split every substitutive change into
> five additive/neutral ones: add improved version of class, make app use
> new class, replace old class with new class, make app use old class,
> delete new class. of course this is purely academical ...

That's why we have "Binary Incompatible Mondays" for.

If you're going to break BC for an unreleased API, do it on Monday.

This includes changes to behaviour compatibility. Which in turn includes 
reverse-dependency changes: if you modify code in kdelibs that depends on new 
behaviour on the daemons from runtime (kded, kglobalaccel, kwallet, etc.).

> > > 1) Interestingly; when we introduced cmake the atomicity of commits was
> > > expected already. Typing 'make' in your app will cause cmake to compile
> > > your libs dir first, as it depends on that.
> > 
> > That's not atomicity.
> > 
> > That's dependency tracking, done by CMake.
> 
> that's actually an interesting idea: one could have micro-versionchecks
> (on sha1's) in the cmake files. however, updating them manually would be
> a royal pita.

Doesn't need to be sha1. Libraries have version numbers. We just have to have 
room in the numbering to increase it when necessary.

Anyway, most of the time it's not necessary. If we have CMakeLists.txt files 
*outside* the repositories -- i.e., in the supermodules or generated by the 
manifest tool -- then KDE becomes one big build.

Then an app could rebuild just kdeui, if it doesn't need kio.

But I think this is not a good idea. First, there would be issues with 
detecting libraries, detecting whether you're a standalone build or you're 
part of something else. Second, it would take ages to run cmake.

With standalone builds, you can run cmake in parallel several times.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100127/9afa21e7/attachment.sig