On 2/28/19 12:30 PM, Dan Kenigsberg wrote:
I am afraid of fresh starts; I'd very much prefer to start from
the
sh*tty thing we have, and evolve it. A lot of time, re-writing a piece
of software is tempting, but existing code is imbued with knowledge of
past problems, which is often forgotten when you do a hard cut.
In general, this is very true.
However, in the *specific case* of the spec file, it is mostly an
aggregation of fixes, hacks and workarounds
arised from contingent issues. Or at very least this is my experience
with the spec file.
My point is the spec file is mostly a snapshot of the fixes needed for a
given set of supported OSes.[1]
There isn't much to salvage here, and for what's worth keeping, git
history is the best record, and this is not going to be lost.
For these reasons, I support Marcin's plan to start afresh side by side
with a new spec file, using the old one as reference.
I trust Marcin (and us) to be careful and look back often at the old
spec file when writing the new one, to avoid forgetting
the lessons of the past.
+++
[1] the current spec file looks much more like a scratchpad full of
scribbled notes than a careful curated chronicle imbued with knowledge.
Bests,
--
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh