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. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
