Re: [Fenfire-dev] 7 projects to one big branch?

[Benja Fallenstein]

Janne Kujala wrote:
> On Fri, Jul 16, 2004 at 01:46:37PM +0200, Benja Fallenstein wrote:
> > I prefer coding being driven by actual needs, rather than creating
> > interfaces and classes &c in thin air and later discovering that they
> > don't actually do what is needed. It's more fun, too. And that's
> > important, too :-)
>
> You can do that in Loom and move the code to Libvob once
> it is stable enough to be useful elsewhere.

But then it's code that is in the wrong place, which means code clutter. 
This is even worse when it's adding features to an existing class, i.e. 
introducing a copy-and-pased second version. What's the gain from this? 
Theoretical cleanliness. What does it cost? Practical cleanliness. I'm 
not willing to give up the latter for the former.

> > Well, with that logic, all of Libvob could be in the Fenfire project, 
> > because it's not used anywhere except in Fenfire at the moment.
>
> It is used elsewhere, e.g., the color experiment stuff uses Libvob.

Well, perhaps, but as far as I know that's a collection of small scripts 
and not the reason why Libvob is in its own project. It wouldn't be a 
reason to keep Libvob in an own project, for me -- for me, the reason is 
that Libvob should be designed so that it is independently usable in 
other applications.

> And there are stable parts of Libvob that should be in Libvob.

Such as?

> All of Callgl is stable; there haven't been any backward 
> incompatible changes for a long time.

True. Callgl is an exception.

> > The point is to make it *possible* to use it independently.
>
> It can be done as soon as some stability is reached.

It can be done immediately, and it is cleaner that way.

> Changes are either added features or backward incompatible.
> Backward incompatible changes are the only changes that require
> atomic commits in order to have everything always compile.

Nonsense. When you add features, you cannot roll back the independent 
project without rolling back the dependent project if you want the 
dependent project to compile.

> > The usual scenario is that you want to undo a change done in the last 
> > few days, either because you don't like it or because it introduced a 
> > bug. In both cases, you would usually want to roll back both projects, 
> > I'd think.
>
> In that case, it would have been better to have the unstable code
> only in the dependent project.

I don't agree. Unclean code isn't better even if it makes versioning easier.

> > I don't agree, because NONE of our code is stable enough that we can 
> > guarantee that code depending on it doens't need to be changed. Our code 
> > *can* be used by code that *can* be changed when our code changes, of 
> > course.
>
> Such changes are fine as long as they don't happen too often.
>
> I'm saying that interrelated fragments of unstable code 
> (particularly new code) do not necessarily need to cross
> project boundaries. 

Perhaps they don't necessarily need to, but it's cleaner than having 
code in the wrong project and perhaps forgetting it there.

- Benja