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