On Mon, Oct 27, 2008 at 12:07:45AM +0000, Bryan Henderson wrote: > > If you agree with this development model we can start to talk > > about the merge. > > OK, I have an idea of what it would take to work within util-linux-ng -- > considerably more work than a separate project, but I'm still willing > to try. You're right from a short-term point of view. But in long-term it's much better to maintain the code on one place and share the code with maximum number of Linux users. > What kind of merge do you have in mind? You said you like the > stability of code which has changed only slightly since 1999, and of Yes, stability is important, but it does not mean that we have to freeze the code forever. (I don't want to blindly copy & past any code to util-linux-ng. That's the reason why I have disagreed with "please, replace hwclock(8) with any other implementation". I prefer evolution.) > course the great majority of users don't require any more than that. See the mailing list archive. We have some feature requests, some fixes/features have been already committed. * all hwclock(8) topics: http://search.gmane.org/search.php?group=gmane.linux.utilities.util-linux-ng&query=hwclock * hwclock(8) delay: - committed: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/1620/focus=1699 - still on my TODO list: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/1621 * the --correct or /sys/class/rtc/rtc0/settime_offset_ms idea: (http://article.gmane.org/gmane.linux.utilities.util-linux-ng/1512) http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/1453/focus=1499 * "atomic" CMOS operations, use mlockall() and SCHED_FIFO: http://lkml.org/lkml/2008/10/12/132 I'm sure that when we start to work on hwclock(8) we will see a feedback and more requests from users and RTC developers. My big wish is to have some hwclock(8) regression tests. Now we have http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=blob;f=tests/ts-hwclock-systohc (it checks for --systohc imprecision) > So how do we merge in all the extra function that the minority wants? Good question. We have to found a way that does not suck :-) I'd like to merge the changes as "a single logical change into a single patch" -- it's a way how to easily review and discuss the changes. The "one huge patch" with all changes is nightmare. Can you easily create a set of patches from your hwclock? Do you have CVS, GIT? It would be nice to export your changes (history of your hwclock) as set of patches. Or at least a separate patch per release, ideally single issue + relevant entry from your HISTORY file. These patches we can try to port to util-linux. I can create a hwclock branch and ask people for feedback, etc... (CC += Alain, because it seems he also cares about hwclock:-) Karel -- Karel Zak <kzak@xxxxxxxxxx> -- 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
