[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Benja Fallenstein
Subject: Re: [Fenfire-dev] 7 projects to one big branch?
Date: Fri, 16 Jul 2004 18:46:50 +0200
User-agent: Mozilla Thunderbird 0.7.1 (X11/20040708)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]