Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Saturday 23 February 2008, Jim Meyering wrote: >> Mike Frysinger <[EMAIL PROTECTED]> wrote: >> > On Saturday 23 February 2008, Jim Meyering wrote: >> >> Jim Meyering <[EMAIL PROTECTED]> wrote: >> >> > But I suspect your point is that I need to check for overflow. >> >> > That's true. I'm adding this: >> >> > >> >> > diff --git a/gl/lib/mgetgroups.c b/gl/lib/mgetgroups.c >> >> > index 317cc7c..ba8818e 100644 >> >> >> >> Thanks again. >> >> I've pushed the result: >> >> >> >> id: avoid race when a group is added between getgrouplist calls >> >> >> >> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=a15329798c >> >> >> >> id: use getgrouplist when possible >> >> >> >> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=49f7ebaac4 >> > >> > any chance of a 6.10.1 with this fix (and any other small ones) ? >> >> It's not impossible, but I'd rather wait for an autoconf release. >> Any particular reason? >> >> > do you plan >> > on doing a small .x branch for stable releases ? >> >> Currently, I don't see that there would be much point. >> Do you find some of the post-6.10 patches to be too risky? > > my view on the matter is more along the lines of there are reasonable fixes > that get added post release and all the random maintainers out there need to > individually accumulate these. cutting small point releases eliminates this > duplicated effort. another idea may be to do something like bash or readline > or busybox: create a directory full of post-last-release patches that were > cut from git but a new release hasnt been made that incorporates them. so > after you `git commit`, you `git-format-patch HEAD^` and just upload that > somewhere for people.
Yes, it would be good to make more frequent releases. Maybe in a couple weeks, after the queue is emptied (e.g., after df --total integration, and maybe after switching fts->gfts). However, given the low volume of behavior-changing (or risky-looking) patches, it's not easy for me to justify maintaining separate branches. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
