bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use getgrouplist where available.


From: Jim Meyering
Subject: Re: [PATCH] Use getgrouplist where available.
Date: Sun, 24 Feb 2008 09:15:57 +0100

Mike Frysinger <address@hidden> wrote:
> On Saturday 23 February 2008, Jim Meyering wrote:
>> Mike Frysinger <address@hidden> wrote:
>> > On Saturday 23 February 2008, Jim Meyering wrote:
>> >> Jim Meyering <address@hidden> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]