>>> I don't have a patch history; hwclock has not been a big enough project
>>> to warrant such code control process.
>
><blink> Really?
Maybe you lack perspective on this. Projects come in all sizes, and
the kind of code control bureaucracy util-linux-ng has is totally
unwarranted for a project with as few users, few developers, and
infrequent changes as my hwclock -- it's one of the simplest pieces of
code I work on. And it isn't nearly _enough_ process for some
corporate projects I've worked on. I do have the ability to recover
past versions of hwclock source code, via an archive system, but so far,
I've never used it and never needed to know when or why some piece of
the code changed.
>>> Do you think there's any way to ship a stable and advanced version,
>>> where the advanced version might some day have enough exposure that
>>> you'd consider it stable?
>
>Plenty of projects do this.
Including all large projects I'm responsible for; I know it works in
general, and I'm a big believer in it. But that doesn't mean it's right
for util-linux-ng.
The first time I set up a multi-tiered system for public software, I
expected people to ignore the less stable tiers ("let somebody else
test it") so that the stable release series was doomed always to have
an unstable period whenever code got promoted from the next tier. But
I was wrong. The majority went for the "latest and greatest" even if
they didn't need any particular new feature. That was Netpbm; I'm not
claiming util-linux-ng/hwclock would have the same characteristic.
There's another thing I always have to remind myself when I start to
think people are being selfish and using only the stable code: The
more people who use the stable code, the less it matters if the
advanced code is broken. And when it gets really stable, it costs
almost nothing to maintain; there's no reason ever to take it away
from the people for whom it works. Meanwhile, a few people _will_
want some esoteric feature that was recently developed and will suck
it up and suffer the bugs.
For code that changes frequently, I generally maintain 4 release
streams, but two of them are essentially what some processes would
call a "next" branch and not release at all. The other two are the
ones people really want. For slow-moving projects, two is enough
because there are long periods without any non-stabilizing code
changes just naturally.
--
Bryan Henderson San Jose, California
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
