Re: [boost] Git Modularization Ready for Review

Subject: Re: [boost] Git Modularization Ready for Review
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-05-13 17:06:34

> It's a question of degree.  Daniel et. al.'s recent work shows that you
> can keep that loss pretty low.  "Where there's a will there's a way?"

Agreed. With enough effort anything is possible. But tough on those tasked
with the grunt work.

> >> What happens in a few years time when Git is replaced with the next big
> > thing?
> >> Do we lose the history again?  And then again when that gets replaced
too?
> >
> > That's exactly what happens. Bitrot is always inevitable in the long
run.
> > Here call it "non-fatal bitrot" :)
> >
> > My only red line is corruption of past and present source code releases.
It
> > must *always* be possible to check out tag X and build release X.
> 
> So why have a VCS at all?  Named tarballs meet your red line.

VCS is for workflow and collaboration. Optionally for blaming bugs through
automated regression analysis. They can be useful for generating some
interesting stats.

And yes, I do use named tarballs (or ZFS snapshots more recently) of the VCS
store exactly for history preservation. VCSs aren't for history
preservation, especially as they're usually not bitrot tolerant.

> > Well, the Git way of helping stuff get out of step is that everyone gets
> > their own full copy of the whole repo, and their copy is just as
important
> > as anyone else's copy. You clone, you develop and test, and optionally
push
> > changes elsewhere which could be your friend, your team, your employer,
or
> > of course some central authoritative copy.
> 
> That works for a monolithic project.  Boost is not monolithic but it's
> single repo model was forcing it to act like one.  As well as making
> life a little easier for library developers, the modularisation effort
> should help end users too.  For a while now people have been wanting to
> take only what they need from Boost and ignore the rest.  It's
> especially important in commercial environments where manager (rightly
> or wrongly) are reluctant to depend on huge quantities of unreviewable
> code with unknown interactions.  Modularisation won't solve the problem
> overnight but it helps.

I disagree with pretty much all of this. And I think modularization, as
currently proposed if I understand it correctly, actually makes those feared
interactions much worse and/or much more work to avoid.

> > So I'm afraid I just don't get the present design for a library as
> > small and as tightly integrated as Boost.
> 
> You must be talking about some other Boost.

It's all subjective. I agree there are a chunk of Boost libraries which are
fairly standalone and I have no problem with those being turned into git
submodules.

> > I'm a great believer in refusing to let programmers commit code which
breaks
> > other code rather than nagging them later to fix an earlier commit. The
> > point of failure notification ought to be as close to cause as
> > possible.
> 
> Surely the developer sees the breakage the moment they update the
> versions of the other libraries they are working against.  And then they
> can fix it at their leisure while early adopters get to use their code
> with the previous version of the conflicting library.

My point is this isn't automatic. It requires programmers not to be lazy.
That hasn't been hugely successful in the past.

> When you are talking about breakages are you talking about merge
> conflicts or compile/test-failures?  Up till now I've assumed you mean
> the latter.  But now I'm thinking you might be asking what happens if
> the developer of library X makes a change to header H and developer Y
> also makes a change to _the same header_?

No that's easily detectable. My concern is when modifications to submodule A
and submodule B cause arbitrary C in some submodule D to suddenly fail.

> The way the modularisation works, I'm not even sure this is possible.
> The libraries are meant to be self-contained so you only ever change
> your own headers.  It's a good question and one I hand't thought about.
> Perhaps the people working on this can weigh in here.

Git submodules are too loosely coupled for anything but loosely coupled,
fairly standalone libraries.

Niall

---
Opinions expressed here are my own and do not necessarily represent those of
BlackBerry Inc.