[coreboot] [PATCH] We're not just version 2 anymore

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Oct 30 17:25:59 CET 2009

On 30.10.2009 08:47, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> If one action breaks the tree unintentionally, I doubt more of the same
>> will be a good idea.
> Are you saying that software development in general is a bad idea? ;-)

No. If I had not mentioned the tree breakage, nobody would have noticed
it until it was too late. Now we know the multi-move _as proposed_ is a
bad idea.
Software development usually tries to improve the codebase (if we ignore
developmestruction environments). This move is guaranteed to make the
codebase worse, and even after fixups the end result will still be worse
than what we had before.

On 29.10.2009 13:38, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> 1. Does it fix a bug?
> Yes.
>> 2. Does it add a new feature?
> No. It's an infrastructure bug fix.

Sorry, if you call this a "bug fix", then renaming util/ would be the
next obvious bug fix because lots of stuff in util/ is not a utility.
And src/mainboard/ and targets/ would have to be merged as well (they
are both mainboard stuff).

>> 3. Does it make the lives of developers easier?
> Yes. Because
> - people will ask why v4 is called v2 and we will waste time to answer.

We need at most one minute to answer such a question.
This move will cost every developer more than five minutes (if warned,
and everything goes well) and perhaps an hour (if unwarned) per tree.
Assuming two trees per developer and an average of twenty minutes per
tree, multiplied by the number of committers in the v2 tree for this
year (eighteen), this move has a total cost of roughly 18*2*20=720
minutes for the core committers. At least a dozen other people don't
have commit privileges and still contribute patches. We shouldn't ignore
them either.

If you expect core developers to answer the question "why is the tree
called v2" more than 720 times, the move is a net benefit. If you expect
to answer less often, the move is a net loss. If any non-committer
developers (or even users) answer the questions, the move is even worse.

This suspiciously sounds like Gentoo. "I can save 2 seconds of startup
if I recompile the whole system for days." (No offense intended, some
people use Gentoo and avoid such claims.)

> - if we go down path 2, we will finally have all utilities together
> again. (Something I want to see anyways), so branching and merging will
> become substantially easier.

With that move (which is a revert), we admit that the original move was
a bad idea.
What are we going to say about the current move proposal a year from
now? "Bad idea, let's revert the revert?"
And it will increase checkout size by ~20%.

I don't buy the branching/merging argument. So far I've seen exactly
zero branches for anything in v2/util or util/.

>> I'm intrigued, though. How exactly should things move around even more?
>> Please enlighten me.
> tags/
> tags/coreboot-some-importand-snapshot
> branches/
> branches/coreboot-v1
> branches/coreboot-v1/src
> branches/...
> trunk/
> trunk/Makefile
> trunk/Kconfig
> trunk/src
> trunk/...
> trunk/util
> Same like flashrom, basically. Same as most other projects, really.

Totally different from flashrom. flashrom doesn't carry around
flash-and-burn, nor does it carry around any of the mtd tools. AFAIK v1
is a totally different codebase, so branches/ is the wrong place. And
I've not seen anybody suggest to merge v3 into the v2 repo under branches/.

> plus, it would elegantly solve us the trouble of whether the other
> utilities should "go back into the v2 tree or not"

Please see above.


Developer quote of the week: 
"We are juggling too many chainsaws and flaming arrows and tigers."

More information about the coreboot mailing list