[V2] manual/string.texi: Add description of envz_remove

  Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
---
 manual/string.texi | 8 ++++++++
 1 file changed, 8 insertions(+)
  

Thanks.  We're going to need a ChangeLog entry for this patch (and for
your other pending patch, too).  With this one (unlike the other, that
just removes safety keywords) your contributions to the manual would be
getting dangerously close to the limit of what I believe we could
reasonably accept without a copyright assignment on file.

If you plan on making further contributions, how about we get the
copyright assignment process started?  The paperwork may take some time
to process, so the sooner we get it started the better.

Thanks,
  

Ping

On 11/26/2014 08:17 PM, Ma Shimiao wrote:
> Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
> ---
>  manual/string.texi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/manual/string.texi b/manual/string.texi
> index ba5a2c7..a033d67 100644
> --- a/manual/string.texi
> +++ b/manual/string.texi
> @@ -2782,6 +2782,14 @@ being added to @var{envz}, if @var{override} is false.
>  
>  @comment envz.h
>  @comment GNU
> +@deftypefun {void} envz_remove (char **@var{envz}, size_t *@var{envz_len}, const char *@var{name})
> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> +The @code{envz_remove} function removes an entry from @code{*@var{envz}} with
> +the name @var{name}, updating @code{*@var{envz}} and @code{*@var{envz_len}}.
> +@end deftypefun
> +
> +@comment envz.h
> +@comment GNU
>  @deftypefun {void} envz_strip (char **@var{envz}, size_t *@var{envz_len})
>  @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
>  The @code{envz_strip} function removes any null entries from @var{envz},
>
  

On 03/03/2015 08:32 AM, Ma Shimiao wrote:
> Ping

See Alexandre's comment:

  <https://sourceware.org/ml/libc-alpha/2014-12/msg00215.html>

Do you know if Fujitsu already has a copyright assignment on file which
covers your work?
  

Hi Florian,

On 03/03/2015 06:33 PM, Florian Weimer wrote:
> On 03/03/2015 08:32 AM, Ma Shimiao wrote:
>> Ping
> 
> See Alexandre's comment:
> 
>   <https://sourceware.org/ml/libc-alpha/2014-12/msg00215.html>
> 
> Do you know if Fujitsu already has a copyright assignment on file which
> covers your work?
> 
The Fujitsu's legal department ever told us they have got a copyright assignment.
But Joseph S. Myers<joseph@codesourcery.com> said it has not appeared in copyright.list.
So I'm not sure whether Fujitsu has successfully got a copyright assignment or not.

Best regards,
  

On 03/04/2015 02:51 AM, Ma Shimiao wrote:
> Hi Florian,
> 
> On 03/03/2015 06:33 PM, Florian Weimer wrote:
>> On 03/03/2015 08:32 AM, Ma Shimiao wrote:
>>> Ping
>>
>> See Alexandre's comment:
>>
>>   <https://sourceware.org/ml/libc-alpha/2014-12/msg00215.html>
>>
>> Do you know if Fujitsu already has a copyright assignment on file which
>> covers your work?
>>
> The Fujitsu's legal department ever told us they have got a copyright assignment.
> But Joseph S. Myers<joseph@codesourcery.com> said it has not appeared in copyright.list.
> So I'm not sure whether Fujitsu has successfully got a copyright assignment or not.

I see no copyright assignment in place for glibc from Fujitsu.

Until you have a copyright assignment we can't accept legally
significant patches :-(

Cheers,
Carlos.
  

On Mar  5, 2015, "Carlos O'Donell" <carlos@redhat.com> wrote:

> I see no copyright assignment in place for glibc from Fujitsu.

I see Ma Shimiao's assignment on file since 2015-02-18.  We don't need
an assignment from Fujitsu, as long as Fujitsu does not hold a copyright
over the contributed changes, and I understand the assignment process
has already covered that question.  Is that not so?
  

On Thu, 5 Mar 2015, Alexandre Oliva wrote:

> On Mar  5, 2015, "Carlos O'Donell" <carlos@redhat.com> wrote:
> 
> > I see no copyright assignment in place for glibc from Fujitsu.
> 
> I see Ma Shimiao's assignment on file since 2015-02-18.  We don't need
> an assignment from Fujitsu, as long as Fujitsu does not hold a copyright
> over the contributed changes, and I understand the assignment process
> has already covered that question.  Is that not so?

I don't think copyright.list recording an individual assignment carries 
any implication as to whether an employer disclaimer is also needed.

maintain.texi says "We may also need an employer's disclaimer from the 
person's employer, which confirms that the work was not part of the 
person's job and the employer makes no claim on it.  However, a copy of 
the person's employment contract, showing that the employer can't claim 
any rights to this work, is often sufficient.".  So either there should be 
a disclaimer in copyright.list, or the FSF should confirm that they've 
seen the employment contract and a disclaimer isn't needed or that the "Do 
you have an employer who might have a basis to claim to own your changes?  
Do you attend a school which might make such a claim?" question in 
request-assign.* was answered in a way indicating no disclaimer is needed.
  

On 03/06/2015 02:00 PM, Joseph Myers wrote:
> On Thu, 5 Mar 2015, Alexandre Oliva wrote:
> 
>> On Mar  5, 2015, "Carlos O'Donell" <carlos@redhat.com> wrote:
>>
>>> I see no copyright assignment in place for glibc from Fujitsu.
>>
>> I see Ma Shimiao's assignment on file since 2015-02-18.  We don't need
>> an assignment from Fujitsu, as long as Fujitsu does not hold a copyright
>> over the contributed changes, and I understand the assignment process
>> has already covered that question.  Is that not so?
> 
> I don't think copyright.list recording an individual assignment carries 
> any implication as to whether an employer disclaimer is also needed.
> 
> maintain.texi says "We may also need an employer's disclaimer from the 
> person's employer, which confirms that the work was not part of the 
> person's job and the employer makes no claim on it.  However, a copy of 
> the person's employment contract, showing that the employer can't claim 
> any rights to this work, is often sufficient.".  So either there should be 
> a disclaimer in copyright.list, or the FSF should confirm that they've 
> seen the employment contract and a disclaimer isn't needed or that the "Do 
> you have an employer who might have a basis to claim to own your changes?  
> Do you attend a school which might make such a claim?" question in 
> request-assign.* was answered in a way indicating no disclaimer is needed.

Agreed.

Further to that I think the FSF should be documenting the requirement
for a corporate disclaimer in the copyright.list file itself. That way
we can avoid doing this request from FSF legal every time we encounter
a personal assignment or disclaimer with a matching corporate one.

Cheers,
Carlos.