--- On Fri, 10/28/11, Jürgen Schmidt wrote:
> > 4) I know you want ucpp there too, but since that
> > stuff is used in idlc, I think I'd prefer it in
> > idlc/source/preproc/
> > as it was before. No idea if we can use the system cpp
> > for the rest but that would probably make sense.
> mmh,
On 10/27/11 8:28 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidt wrote:
In any case, yes.. I think this is the way to go. I am
just hoping there will be a way to opt out those
components in favor of the system libraries when those
available.
me too but we should move forward
Hi Matthias;
--- On Thu, 10/27/11, Mathias Bauer wrote:
...
>
> >> > In any case, yes.. I think this is the way to
> go. I am
> >> > just hoping there will be a way to opt out
> those
> >
> > I am OK with that, but let me attempt to dump what I
> think:
> >
> > 1) you are not bringing in *anyth
Am 27.10.2011 20:28, schrieb Pedro Giffuni:
> --- On Thu, 10/27/11, Jürgen Schmidt wrote:
>
>> >
>> > In any case, yes.. I think this is the way to go. I am
>> > just hoping there will be a way to opt out those
>> > components in favor of the system libraries when those
>> > available.
>>
>> me
On Thu, Oct 27, 2011 at 2:28 PM, Pedro Giffuni wrote:
>
>
> --- On Thu, 10/27/11, Jürgen Schmidt wrote:
>
>> >
>> > In any case, yes.. I think this is the way to go. I am
>> > just hoping there will be a way to opt out those
>> > components in favor of the system libraries when those
>> > availab
--- On Thu, 10/27/11, Jürgen Schmidt wrote:
> >
> > In any case, yes.. I think this is the way to go. I am
> > just hoping there will be a way to opt out those
> > components in favor of the system libraries when those
> > available.
>
> me too but we should move forward and we can change it a
On 10/27/11 6:13 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidt wrote:
...
i think we still haven't finished on this topic but it is
somewhat
important to move forward with our IP clearance and the
whole
development work.
So if nobody has real objections i would like to move
--- On Thu, 10/27/11, Jürgen Schmidt wrote:
...
>
> i think we still haven't finished on this topic but it is
> somewhat
> important to move forward with our IP clearance and the
> whole
> development work.
>
> So if nobody has real objections i would like to move
> forward with this
> prop
2011/10/27 Jürgen Schmidt :
> On 9/22/11 1:19 PM, Jürgen Schmidt wrote:
>
>> ok, we have several arguments for and against but no decision how we
>> want to move forward. Let us take again a look on it
>>
>> 1. we have a working mechanism to get the externals from somewhere,
>> check md5 sum, unpac
On 9/22/11 1:19 PM, Jürgen Schmidt wrote:
ok, we have several arguments for and against but no decision how we
want to move forward. Let us take again a look on it
1. we have a working mechanism to get the externals from somewhere,
check md5 sum, unpack, patch, build
1.1 "somewhere" is configur
On Fri, Oct 14, 2011 at 8:35 PM, Pedro Giffuni wrote:
> Hi;
>
> When I saw this thread about machine-generate files, I never
> imagined we would be taking about code in OpenOffice.org but
> I found that this file:
> icc/source/create_sRGB_profile/create_sRGB_profile.cpp
>
> indeed generates viral
oon, even though there may be conditions on the
> license of the source code that carries over onto those
> binaries.
> >
> > And, yes, it is murky all the way down.
> >
> > - Dennis
> >
> > -Original Message-
> > From: Dennis E. Hamilton [m
On 10/14/2011 8:58 AM, Pedro Giffuni wrote:
--- On Fri, 10/14/11, Robert Burrell Donkin wrote:
...
A branch would save us from having say... 1000 commits
with header changes in the history.
Apache uses version control as the canonical record. It's
therefore essential to know why a header was
--- On Fri, 10/14/11, Robert Burrell Donkin wrote:
...
>
> > A branch would save us from having say... 1000 commits
> > with header changes in the history.
>
> Apache uses version control as the canonical record. It's
> therefore essential to know why a header was changed and
> by whom.
>
And o
On Thu, Oct 13, 2011 at 9:29 PM, Pedro Giffuni wrote:
>
>
> --- On Thu, 10/13/11, Robert Burrell Donkin wrote:
>
>> I recommend separating review from (automated) execution.
>> If this is done, a branch shouldn't be necessary...
>>
>
> Uhm.. can you elaborate a bit more?
For projects of this scal
--- On Thu, 10/13/11, Robert Burrell Donkin wrote:
> I recommend separating review from (automated) execution.
> If this is done, a branch shouldn't be necessary...
>
Uhm.. can you elaborate a bit more?
A branch would save us from having say... 1000 commits with
header changes in the history.
On Sun, Oct 9, 2011 at 7:42 PM, Pedro Giffuni wrote:
> Hi;
>
> Looking at how big, and mostly cosmetic but necessary, a
> change it will be to bring in all the SGA license changes,
> and given that it requires manual intervention and is not
> something that can be done in one huge mega commit ...
Hi;
Looking at how big, and mostly cosmetic but necessary, a
change it will be to bring in all the SGA license changes,
and given that it requires manual intervention and is not
something that can be done in one huge mega commit ...
I think we should create a branch for this changes in merge
them
Am 01.10.2011 00:17, schrieb Michael Stahl:
> On 30.09.2011 21:24, Mathias Bauer wrote:
>> On 28.09.2011 17:32, Pedro F. Giffuni wrote:
>
>> Another advantage of unpacking the tarballs: the patches will become
>> *real* patches that just contain changes of the original source code.
>> Often the p
--- On Fri, 9/30/11, Mathias Bauer wrote:
>
> I'm not against unpacking the tarballs and applying the
> patches, but we should keep the patches somewhere so that
> updates could be done with the same effort as today.
>
This could fly.
I like having the patches around. I would only request
th
On 30.09.2011 21:24, Mathias Bauer wrote:
> On 28.09.2011 17:32, Pedro F. Giffuni wrote:
> Another advantage of unpacking the tarballs: the patches will become
> *real* patches that just contain changes of the original source code.
> Often the patches nowadays contain additional files that we just
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
> FWIW;
>
> I don't like the patches because I can't really examine well
> the code, besides this is something the VCS handles acceptably:
> commit the original sourcecode and then apply the patches in a
> different commit. If we start with up to date ve
.
>
> And, yes, it is murky all the way down.
>
> - Dennis
>
> -Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Wednesday, September 28, 2011 22:32
> To: 'ooo-dev@incubator.apache.org'
> Subject: RE: A systemat
: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Wednesday, September 28, 2011 22:32
To: 'ooo-dev@incubator.apache.org'
Subject: RE: A systematic approach to IP review?
Not to put too fine a point on this, but it sounds like you are talking about
boilerplate (and auth
thieb...@gmail.com]
Sent: Wednesday, September 28, 2011 22:11
To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: A systematic approach to IP review?
On Wed, Sep 28, 2011 at 7:55 PM, Dennis E. Hamilton
wrote:
> I'll stand by my original statement.
>
> I'm not going to
On Wed, Sep 28, 2011 at 7:55 PM, Dennis E. Hamilton
wrote:
> I'll stand by my original statement.
>
> I'm not going to get into the Pixar case since it doesn't apply here.
I did not say it applied to the Visual studio generated cruft... I
merely commented on the blanket assertion that 'computer g
--- On Wed, 9/28/11, Norbert Thiebaud wrote:
...
> On Wed, Sep 28, 2011 at 5:42 PM,
> Dennis E. Hamilton wrote:
> > It is unlikely that machine-generated files of any
> kind are copyrightable subject matter.
>
> I'd imagine that Pixar, for instance, would have a problem
> with that
> blanket stat
artifacts. I did neglect to consider that.
- Dennis
-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com]
Sent: Wednesday, September 28, 2011 16:41
To: ooo-dev@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: A systematic approach to IP review?
On Wed, Sep 28
On Wed, Sep 28, 2011 at 5:42 PM, Dennis E. Hamilton
wrote:
> It is unlikely that machine-generated files of any kind are copyrightable
> subject matter.
I'd imagine that Pixar, for instance, would have a problem with that
blanket statement...
The very existence of this paragraph in the Bison ma
t]
> Sent: Wednesday, September 28, 2011 04:25
> To: ooo-dev@incubator.apache.org
> Subject: Re: A systematic approach to IP review?
>
> On 19.09.2011 02:27, Rob Weir wrote:
>
>> 1) We need to get all files needed for the build into SVN. Right now
>> there are some that are copied down f
a tar-ball, etc. In short: nice!
- Dennis
-Original Message-
From: Mathias Bauer [mailto:mathias_ba...@gmx.net]
Sent: Wednesday, September 28, 2011 04:25
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?
On 19.09.2011 02:27, Rob Weir wrote:
> 1)
On 28.09.2011 17:32, Pedro F. Giffuni wrote:
> FWIW;
>
> I don't like the patches because I can't really examine well
> the code, besides this is something the VCS handles acceptably:
> commit the original sourcecode and then apply the patches in a
> different commit. If we start with up to date v
e-
> From: Pedro F. Giffuni [mailto:giffu...@tutopia.com]
>
> Sent: Wednesday, September 28, 2011 08:32
> To: ooo-dev@incubator.apache.org
> Subject: Re: handling of ext_sources - Juergen's suggestion
> [was: Re: A systematic approach to IP review?]
>
> FWIW;
On 19.09.2011 02:27, Rob Weir wrote:
1) We need to get all files needed for the build into SVN. Right now
there are some that are copied down from the OpenOffice.org website
during the build's bootstrap process. Until we get the files all in
one place it is hard to get a comprehensive view of
x27;s suggestion [was: Re: A
systematic approach to IP review?]
FWIW;
I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start
FWIW;
I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date versions there
would not be much trouble.
just my $0.02,
On Wed, Sep 28, 2011 at 9:23 AM, Mathias Bauer wrote:
> What might be the best way to handle 3rd party code in AOOo probably will
> depend on the needs of the developers as well as on legal requirements.
>
> We had these tarballs plus patches IIRC because Sun Legal required that all
> used 3rd par
On 20.09.2011 16:36, Pavel Janík wrote:
Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external
tarballs in the VCS, but then we moved them out and it worked very
well. There never was a
Sent: Thursday, September 22, 2011 05:24
To: ooo-dev@incubator.apache.org
Subject: Re: handling of ext_sources - Juergen's suggestion [was: Re: A
systematic approach to IP review?]
2011/9/22 Pavel Janík :
>> Proposed way to move forward
>>
>> 1. put the externals
t;
> *Rob Weir *
>
> 2011-09-22 21:18
> Please respond to
> ooo-dev@incubator.apache.org
>
>
>
> To
>
> ooo-dev@incubator.apache.org,
> cc
>
>
> Subject
>
> Re: handling of ext_sources - Juergen's suggesti
On Thu, Sep 22, 2011 at 3:18 PM, Rob Weir wrote:
> It is possible that we have this wrong. Adding in site/ and ooo-site/
> brings in a different convention. They have are set up to have
> trunk/tags/branches underneath them. That is fine, because the
> website does not "release" in synch with
hi,
Based on this result, an other trunk will be like the following if IBM
symphony checked in:
/ooo/symphony-src/trunk/main
/ooo/symphony-src/trunk/extras
/ooo/symphony-src/tags
/ooo/symphony-src/branches
thus it introduces a problem:
How to merge the two trunks of symphony-src and ooo-src?
2011/9/22 Jürgen Schmidt :
> 2011/9/22 Jürgen Schmidt
>
>> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir wrote:
>>
>>>
>>> I was thinking something similar. We only need to use the SVN
>>> interface to the files when we're adding or updating. But we can have
>>> bootstrap continue to download via h
2011/9/22 Jürgen Schmidt
> On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir wrote:
>
>>
>> I was thinking something similar. We only need to use the SVN
>> interface to the files when we're adding or updating. But we can have
>> bootstrap continue to download via http. The location, using
>> Juergen
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir wrote:
>
> I was thinking something similar. We only need to use the SVN
> interface to the files when we're adding or updating. But we can have
> bootstrap continue to download via http. The location, using
> Juergen's proposed location, would be
> ht
2011/9/22 Pavel Janík :
>> Proposed way to move forward
>>
>> 1. put the externals under .../trunk/ext_sources
>> .../trunk/ext_sources
>> .../trunk/main
>> .../trunk/extras
>> 2. adapt configure to use this as default, disable the download (maybe
>> reactivate it later if we move to a DSCM)
>> 3.
> don't know if it is what you are looking for but
>
> wget http://svn.apache.org/viewvc/incubator/ooo/trunk/main/
> ?view=co
>
> should download the head version.
Then we should be able to have both things solved - files in SVN and with a
relatively small change in the download script also the
2011/9/22 Pavel Janík
> > Proposed way to move forward
> >
> > 1. put the externals under .../trunk/ext_sources
> > .../trunk/ext_sources
> > .../trunk/main
> > .../trunk/extras
> > 2. adapt configure to use this as default, disable the download (maybe
> > reactivate it later if we move to a DSCM
On 22.09.2011 13:19, Jürgen Schmidt wrote:
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtienwrote:
On 09/20/2011 05:26 PM, Rob Weir wrote:
...
Placing all the external tarballs in the VCS is a real killer if using a
distributed SCM like git or Mercurial, thats why we had moved them out.
> Proposed way to move forward
>
> 1. put the externals under .../trunk/ext_sources
> .../trunk/ext_sources
> .../trunk/main
> .../trunk/extras
> 2. adapt configure to use this as default, disable the download (maybe
> reactivate it later if we move to a DSCM)
> 3. keep the process with checking t
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien wrote:
> On 09/20/2011 05:26 PM, Rob Weir wrote:
>
>> Ai2011/9/20 Pavel Janík:
>>
>>> Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
>>>
>>>
>>> Maybe Heiner will say more, but i
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janík:
Have we ever considered using version control to...uh...manage file versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external tarballs
in the VCS, but then we moved them out and it worked ve
Am 20.09.2011 16:36, schrieb Pavel Janík:
Have we ever considered using version control to...uh...manage file versions?
Just an idea.
Maybe Heiner will say more, but in the past, we have had the external tarballs
in the VCS, but then we moved them out and it worked very well. There never was
2011/9/20 Jürgen Schmidt :
> On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru wrote:
>
>> So... has anyone actually run Apache RAT yet? It has a scan only mode
>> which I'd think would be the simplest place to start.
>>
>> it's on my todo list to take a look on it, probably i will come back with
>
> Is your main concern performance? Even as individual tarballs,
> ext-sources is 86 files, 250MB. ooo/extras is 243 files and 822 MB.
> And ooo/main is 76,295 files for over 900MB. So ext-sources is not a
> huge contributor to download time.
You have to think about compressed data. ext_csource
Ai2011/9/20 Pavel Janík :
>> Have we ever considered using version control to...uh...manage file versions?
>>
>> Just an idea.
>
>
> Maybe Heiner will say more, but in the past, we have had the external
> tarballs in the VCS, but then we moved them out and it worked very well.
> There never was a
> Have we ever considered using version control to...uh...manage file versions?
>
> Just an idea.
Maybe Heiner will say more, but in the past, we have had the external tarballs
in the VCS, but then we moved them out and it worked very well. There never was
a reason to track external.tar.gz fil
+1
- This will make it easier to update the BSD/MIT unrestricted stuff.
- Hopefully it also means we will eventually stop depending on GNU
patch for the build.
Welcome Oliver!
Great job Juergen: it's the first code replacement and a very
necessary one for OO forks too (unless they want to carry
2011/9/20 Pavel Janík :
>> Would we be able to do this? What if the flaw was related to code in
>> ext_sources?
>
> Then we patch it. Patch will be in the trunk/main, as always.
>
>> And if not us, in the project, what if some "downstream consumer" of
>> AOOo 3.4.0 wants to rebuild 3.4.0 later, fo
On 20.09.2011 15:58, Rob Weir wrote:
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand wrote:
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote:
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
...
What do others think about a structure where we have "ext_sources"
besides
"trunk".
incubator
> Would we be able to do this? What if the flaw was related to code in
> ext_sources?
Then we patch it. Patch will be in the trunk/main, as always.
> And if not us, in the project, what if some "downstream consumer" of
> AOOo 3.4.0 wants to rebuild 3.4.0 later, for a patch or whatever. But
> we
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand wrote:
> On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote:
>>
>> Hi,
>>
>> On 20.09.2011 14:37, Jürgen Schmidt wrote:
>
> ...
>>>
>>> What do others think about a structure where we have "ext_sources"
>>> besides
>>> "trunk".
>>>
>>> incubator/ooo/t
On 20.09.2011 15:33, Oliver-Rainer Wittmann wrote:
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
...
What do others think about a structure where we have "ext_sources"
besides
"trunk".
incubator/ooo/trunk
incubator/ooo/ext_source
...
I like this idea.
From a developer point of view I on
Hi,
> I like this idea.
>
> From a developer point of view I only have to checkout "ext_sources" once and
> reference it from all my "trunks" using the already existing configure-switch
> 'with-external-tar=""'
when we will have such repository, we will surely modify the current sources so
yo
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir wrote:
2011/9/19 Jürgen Schmidt:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
...
Suggestions:
1) We need to get all files needed for the build into SVN. Right now
there are some that are copie
On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru wrote:
> So... has anyone actually run Apache RAT yet? It has a scan only mode
> which I'd think would be the simplest place to start.
>
> it's on my todo list to take a look on it, probably i will come back with
questions
Juergen
> Personally, I
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir wrote:
> 2011/9/19 Jürgen Schmidt :
> > On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
> >
> >> If you haven't looked it closely, it is probably worth a few minutes
> >> of your time to review our incubation status page, especially the
> >> items under
So... has anyone actually run Apache RAT yet? It has a scan only mode
which I'd think would be the simplest place to start.
Personally, I'd recommend working on basic RAT scans, with the scripts
to run them and any exception rules (for known files, etc.) all checked
into SVN with the build to
On Mon, Sep 19, 2011 at 7:05 PM, Rob Weir wrote:
> On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo)
> wrote:
> > Am 09/19/2011 04:47 PM, schrieb Rob Weir:
> >>
> >> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)
> >> wrote:
> >>>
> >>> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>
> 2011/9
On Mon, Sep 19, 2011 at 4:32 PM, Dennis E. Hamilton
wrote:
> I agree that there is no escape from managing down to the individual file.
> It is a question of organization now, where the entire base is involved.
>
RAT or something RAT-like.
> Later, if the svn:property is to be trusted, the pro
: Re: A systematic approach to IP review?
[ ... ]
The granularity we need to worry about is the file. That is the
finest grain level of having a license header. That is the unit of
tracking in SVN. That is the unit that someone could have changed the
content in SVN.
Again, it is fine if
: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?
Am 09/19/2011 07:05 PM, schrieb Rob Weir:
[ ... ]
> 3) Running RAT against the source is how we ensure that the code is clean
OK, I don't know what this can do your us. Maybe it's the solution for
the pro
I agree running rat is important ...
I haven't heard any suggestion that such an important tool not be used.
-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Monday, September 19, 2011 10:05
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach
longer
>>> term. It would be interesting to know what the additional-review work has
>>> become for other projects that have a substantial code base (e.g., SVN
>>> itself, httpd, ...). I have no idea.
>>>
>>
>> The IP review needs to occur with every release. So
Am 09/19/2011 07:05 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo) wrote:
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)
wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidt:
On Mon, Sep 19, 2011 at 2:
th every
release.
I invite you to investigate what other projects do. When you do I
think you will agree.
- Dennis
-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Monday, September 19, 2011 07:47
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP
On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo) wrote:
> Am 09/19/2011 04:47 PM, schrieb Rob Weir:
>>
>> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)
>> wrote:
>>>
>>> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidt:
>
> On Mon, Sep 19, 2011 at 2:27 AM, Rob We
From: Rob Weir [mailto:robw...@apache.org]
> Sent: Monday, September 19, 2011 07:47
> To: ooo-dev@incubator.apache.org
> Subject: Re: A systematic approach to IP review?
>
> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) wrote:
>> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>&
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidt:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirwrote:
If you haven't looked it closely, it is probably worth a few minutes
of yo
--
From: Jürgen Schmidt [mailto:jogischm...@googlemail.com]
Sent: Monday, September 19, 2011 01:45
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
[ ... ]
> 7) Goal should be for anyone today to be able to see
-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Monday, September 19, 2011 07:47
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) wrote:
> Am 09/19/2011 01:59 PM, schrieb Rob W
--- On Mon, 9/19/11, Rob Weir wrote:
...
> 2011/9/19 Jürgen Schmidt :
...
> >
> > do you mean to check in the files under ext_source
> into svn and remove it
> > later on when we have cleaned up the code. Or do you
> mean to put it
> > somehwere on apache extras?
> > I would prefer to save these
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) wrote:
> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>>
>> 2011/9/19 Jürgen Schmidt:
>>>
>>> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
>>>
If you haven't looked it closely, it is probably worth a few minutes
of your time to review our i
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidt:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation status page, especially the
items under "Copyright" and "Verify Distr
2011/9/19 Jürgen Schmidt :
> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
>
>> If you haven't looked it closely, it is probably worth a few minutes
>> of your time to review our incubation status page, especially the
>> items under "Copyright" and "Verify Distribution Rights". It lists
>> the
On Sun, Sep 18, 2011 at 9:34 PM, Pedro Giffuni wrote:
> Hi;
>
> Is there an updated SGA already?
>
Not that I know of. But we can and should go ahead with IP clearance
using the SGA we already have. In fact, starting that process will
help us identify exactly which files needed to be added to
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir wrote:
> If you haven't looked it closely, it is probably worth a few minutes
> of your time to review our incubation status page, especially the
> items under "Copyright" and "Verify Distribution Rights". It lists
> the things we need to do, including:
On Mon, Sep 19, 2011 at 3:34 AM, Pedro Giffuni wrote:
> Hi;
>
> Is there an updated SGA already?
>
good question and where can we find it?
Juergen
>
> I think there will likely be a set of files of uncertain license
> that we should move to apache-extras. I am refering specifically
> to the d
Hi;
Is there an updated SGA already?
I think there will likely be a set of files of uncertain license
that we should move to apache-extras. I am refering specifically
to the dictionaries: Oracle might have property over some but not
all. I propose we rescue myspell in apache-extras and put the
d
+1
-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Sunday, September 18, 2011 17:27
To: ooo-dev@incubator.apache.org
Subject: A systematic approach to IP review?
If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation
90 matches
Mail list logo
