PATCH: Add myself as libbid maintainer

PATCH: Add myself as libbid maintainer

[H.J. Lu]

I am checking in this patch to add myself as libbid maintainer.


H.J.
-----
Index: ChangeLog
===================================================================
--- ChangeLog	(revision 126366)
+++ ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2007-07-05  H.J. Lu  <hongjiu.lu@intel.com>
+
+	* MAINTAINERS (libbid): Add myself.
+
 2007-07-03  Julian Brown  <julian@codesourcery.com>
 
 	* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===================================================================
--- MAINTAINERS	(revision 126366)
+++ MAINTAINERS	(working copy)
@@ -132,6 +132,7 @@
 
 			Various Maintainers
 
+libbid			H.J. Lu			hjl@lucon.org
 libcpp			Per Bothner		per@bothner.com
 libcpp			All C and C++ front end maintainers
 fp-bit			Ian Lance Taylor	ian@airs.com
@@ -354,7 +355,7 @@
 Manuel López-Ibáñez                             manu@gcc.gnu.org
 Dave Love					d.love@dl.ac.uk
 Martin v. Löwis					loewis@informatik.hu-berlin.de
-HJ Lu						hjl@lucon.org
+H.J. Lu						hjl@lucon.org
 Ziga Mahkovec					ziga.mahkovec@klika.si
 Simon Martin					simartin@users.sourceforge.net
 Ranjit Mathew					rmathew@hotmail.com

Re: PATCH: Add myself as libbid maintainer

[Ian Lance Taylor]

"H.J. Lu" <hjl@lucon.org> writes:

> I am checking in this patch to add myself as libbid maintainer.

Normally changes to the list of maintainers are approved by the
steering committee.  I didn't see any notice about this one.  I would
just like to confirm that this change was approved.

I'm also uncertain as to just who approved the commit of
libgcc/config/libbid into mainline.  When I look at the code I see
that it is not formatted to the GNU standard, and it includes C++
style comments which we do not normally use in C code.

I'm also uncertain as to the relationship of the code in gcc mainline
and the code at Intel.  This code was written at Intel and I see there
is now a ChangeLog entry which starts
	Updated from Intel BID library:
Where can the Intel BID library sources be found?  What license is it
under?  What should happen with changes that we want to make to the
libbid sources now in mainline?  Should we send them back to Intel?

I see that bid_intrinsics.h has a #ifdef IN_LIBGCC2 which seems
redundant for code that is in libgcc.

Ian

Re: PATCH: Add myself as libbid maintainer

[H.J. Lu]

On Thu, Jul 05, 2007 at 09:46:27AM -0700, Ian Lance Taylor wrote:
> "H.J. Lu" <hjl@lucon.org> writes:
> 
> > I am checking in this patch to add myself as libbid maintainer.
> 
> Normally changes to the list of maintainers are approved by the
> steering committee.  I didn't see any notice about this one.  I would
> just like to confirm that this change was approved.

I thought libbid in gcc needed a maintainer. It was my mistake. I
will remove myself. Sorry for that.

> 
> I'm also uncertain as to just who approved the commit of
> libgcc/config/libbid into mainline.  When I look at the code I see

http://gcc.gnu.org/ml/gcc/2007-06/msg00457.html
http://gcc.gnu.org/ml/gcc/2007-06/msg00491.html

Both x86 maintainer and build/libgcc maintainer reviewed the patch.

> that it is not formatted to the GNU standard, and it includes C++
> style comments which we do not normally use in C code.

This library is a general BID library developed at Intel, not just
for gcc. Can we have an exception or some compromise?

> 
> I'm also uncertain as to the relationship of the code in gcc mainline
> and the code at Intel.  This code was written at Intel and I see there
> is now a ChangeLog entry which starts
> 	Updated from Intel BID library:
> Where can the Intel BID library sources be found?  What license is it
> under?  What should happen with changes that we want to make to the
> libbid sources now in mainline?  Should we send them back to Intel?
> 

> I see that bid_intrinsics.h has a #ifdef IN_LIBGCC2 which seems
> redundant for code that is in libgcc.

The beta Intel BID library was announced at

http://gcc.gnu.org/ml/gcc/2007-04/msg00903.html

which has a BSD license. The one submitted to gcc is under GPL v2
+ exception. This library isn't just for libgcc.  We'd like to keep
libbid in gcc as close to Intel BID library as possible. I would
prefer bug to be fixed in Intel BID library first if all possible.  We
should track gcc libbid bugs in gcc bugzilla. We can add a new libbid
component and assign all libbid bugs to me.


H.J.

Re: PATCH: Add myself as libbid maintainer

[Ian Lance Taylor]

"H.J. Lu" <hjl@lucon.org> writes:

> > I'm also uncertain as to just who approved the commit of
> > libgcc/config/libbid into mainline.  When I look at the code I see
> 
> http://gcc.gnu.org/ml/gcc/2007-06/msg00457.html
> http://gcc.gnu.org/ml/gcc/2007-06/msg00491.html
> 
> Both x86 maintainer and build/libgcc maintainer reviewed the patch.

I must have missed the approval from a libgcc maintainer.


> > that it is not formatted to the GNU standard, and it includes C++
> > style comments which we do not normally use in C code.
> 
> This library is a general BID library developed at Intel, not just
> for gcc. Can we have an exception or some compromise?

Well, perhaps we can.  But I would have expected that the time to
discuss an exception or compromise would be before the commit.


> > I'm also uncertain as to the relationship of the code in gcc mainline
> > and the code at Intel.  This code was written at Intel and I see there
> > is now a ChangeLog entry which starts
> > 	Updated from Intel BID library:
> > Where can the Intel BID library sources be found?  What license is it
> > under?  What should happen with changes that we want to make to the
> > libbid sources now in mainline?  Should we send them back to Intel?
> > 
> 
> > I see that bid_intrinsics.h has a #ifdef IN_LIBGCC2 which seems
> > redundant for code that is in libgcc.
> 
> The beta Intel BID library was announced at
> 
> http://gcc.gnu.org/ml/gcc/2007-04/msg00903.html
> 
> which has a BSD license. The one submitted to gcc is under GPL v2
> + exception. This library isn't just for libgcc.  We'd like to keep
> libbid in gcc as close to Intel BID library as possible. I would
> prefer bug to be fixed in Intel BID library first if all possible.  We
> should track gcc libbid bugs in gcc bugzilla. We can add a new libbid
> component and assign all libbid bugs to me.

Is there any public access to the source code control of the Intel BID
library?  I don't see how we can fix bugs in the Intel BID library
first otherwise.  I appreciate that you are able to change both.  But
we shouldn't make plans for gcc based on the premise that you will
continue to work at Intel indefinitely.

And where is this information documented?

Ian

Re: PATCH: Add myself as libbid maintainer

[H.J. Lu]

On Thu, Jul 05, 2007 at 10:58:35AM -0700, Ian Lance Taylor wrote:
> "H.J. Lu" <hjl@lucon.org> writes:
> 
> > > I'm also uncertain as to just who approved the commit of
> > > libgcc/config/libbid into mainline.  When I look at the code I see
> > 
> > http://gcc.gnu.org/ml/gcc/2007-06/msg00457.html
> > http://gcc.gnu.org/ml/gcc/2007-06/msg00491.html
> > 
> > Both x86 maintainer and build/libgcc maintainer reviewed the patch.
> 
> I must have missed the approval from a libgcc maintainer.
> 

I take that you didn't review my libgcc patch. Since other build
machinery maintainers reviewed my libgcc patch, which only changes
Makefile.in, I felt it was sufficient.

> 
> > > that it is not formatted to the GNU standard, and it includes C++
> > > style comments which we do not normally use in C code.
> > 
> > This library is a general BID library developed at Intel, not just
> > for gcc. Can we have an exception or some compromise?
> 
> Well, perhaps we can.  But I would have expected that the time to
> discuss an exception or compromise would be before the commit.

No one raised any issues for several weeks until now. I hope it isn't
too late.

> 
> > > I'm also uncertain as to the relationship of the code in gcc mainline
> > > and the code at Intel.  This code was written at Intel and I see there
> > > is now a ChangeLog entry which starts
> > > 	Updated from Intel BID library:
> > > Where can the Intel BID library sources be found?  What license is it
> > > under?  What should happen with changes that we want to make to the
> > > libbid sources now in mainline?  Should we send them back to Intel?
> > > 
> > 
> > > I see that bid_intrinsics.h has a #ifdef IN_LIBGCC2 which seems
> > > redundant for code that is in libgcc.
> > 
> > The beta Intel BID library was announced at
> > 
> > http://gcc.gnu.org/ml/gcc/2007-04/msg00903.html
> > 
> > which has a BSD license. The one submitted to gcc is under GPL v2
> > + exception. This library isn't just for libgcc.  We'd like to keep
> > libbid in gcc as close to Intel BID library as possible. I would
> > prefer bug to be fixed in Intel BID library first if all possible.  We
> > should track gcc libbid bugs in gcc bugzilla. We can add a new libbid
> > component and assign all libbid bugs to me.
> 
> Is there any public access to the source code control of the Intel BID
> library?  I don't see how we can fix bugs in the Intel BID library

We are investigating it now. We have several options. But the process
isn't as fast as I hoped.

> first otherwise.  I appreciate that you are able to change both.  But
> we shouldn't make plans for gcc based on the premise that you will
> continue to work at Intel indefinitely.

Certainly. I am very glad that you raised those issues. It will
help move our process forward.

Thanks.


H.J.

Re: PATCH: Add myself as libbid maintainer

[Daniel Berlin]

I must have missed the  message from the steering committee that
approved this.  Can you give me a link to it?


On 7/5/07, H.J. Lu <hjl@lucon.org> wrote:
> I am checking in this patch to add myself as libbid maintainer.
>

Re: PATCH: Add myself as libbid maintainer

[Uros Bizjak]

Hello!

> I'm also uncertain as to just who approved the commit of
> libgcc/config/libbid into mainline.  When I look at the code I see
> that it is not formatted to the GNU standard, and it includes C++
> style comments which we do not normally use in C code.
>   

IMO the situation here is the same as with current soft-fp situation. 
The library should be considered as imported from upstream, and the 
decisions w.r.t formatting are inherited from the upstream. In soft-fp 
case, functions don't have prototypes, and we (as in gcc developers) 
can't do nothing about that.

In contrast with soft-fp,  libbid library doesn't produce any warnings...

Although not explicitly said, the fixes should be sent upstream (and 
then "imported" from upstream), at least this is the case with all other 
"foreign" libraries.

IMO, of course.

Uros.

Re: PATCH: Add myself as libbid maintainer

[Tom Tromey]

>>>>> "Uros" == Uros Bizjak <ubizjak@gmail.com> writes:

Uros> IMO the situation here is the same as with current soft-fp
Uros> situation. The library should be considered as imported from upstream,
Uros> and the decisions w.r.t formatting are inherited from the
Uros> upstream.

In this case the library has to follow the external project policy:

    http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html

It at least needs an entry on the "coding conventions" page.

Tom

Re: PATCH: Add myself as libbid maintainer

[Gerald Pfeifer]

On Mon, 23 Jul 2007, H.J. Lu wrote:
> Here is a patch. We are working on an external libbid open source
> website. I will update it when it is up and running.

Thanks!  I believe you'd ment the first sentence to read "The master
sources come from the Intel BID library..."?  The patch is fine with
this, or a similar patch.

Gerald

Re: PATCH: Add myself as libbid maintainer

[Ian Lance Taylor]

Uros Bizjak <ubizjak@gmail.com> writes:

> IMO the situation here is the same as with current soft-fp
> situation. The library should be considered as imported from upstream,
> and the decisions w.r.t formatting are inherited from the upstream. In
> soft-fp case, functions don't have prototypes, and we (as in gcc
> developers) can't do nothing about that.
> 
> In contrast with soft-fp,  libbid library doesn't produce any warnings...
> 
> Although not explicitly said, the fixes should be sent upstream (and
> then "imported" from upstream), at least this is the case with all
> other "foreign" libraries.

The situation seems somewhat different to me, since soft-fp is being
inherited from another free software project.  In fact, a GNU project.

It doesn't mean that we can work that way, but I would like these
issues to be out on the table, discussed, and documented.

Ian