On 10/27/11 8:28 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidtjogischm...@googlemail.com 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
--- On Fri, 10/28/11, Jürgen Schmidt jogischm...@googlemail.com wrote:
snip mental dump
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
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
2011/10/27 Jürgen Schmidt jogischm...@googlemail.com:
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
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com 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
On 10/27/11 6:13 PM, Pedro Giffuni wrote:
--- On Thu, 10/27/11, Jürgen Schmidtjogischm...@googlemail.com 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
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com 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
On Thu, Oct 27, 2011 at 2:28 PM, Pedro Giffuni p...@apache.org wrote:
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com 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
Hi Matthias;
--- On Thu, 10/27/11, Mathias Bauer mathias_ba...@gmx.net 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
--- 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 of course
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
.
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 systematic approach to IP review?
Not to put too fine
On Sun, Oct 9, 2011 at 7:42 PM, Pedro Giffuni p...@apache.org 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
--- 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.
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
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 patches
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
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
: 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 authored) template code that Bison incorporates in its
output. It is also
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
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,
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 with up to date
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
: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;
I don't like the patches because I can't really examine
well
the code, besides this is something the VCS handles
acceptably:
commit
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
in 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) We need
@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 from the OpenOffice.org website
during the build's bootstrap process. Until we get the files
On Wed, Sep 28, 2011 at 5:42 PM, Dennis E. Hamilton
dennis.hamil...@acm.org 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
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, 2011 at 5:42 PM, Dennis
--- 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 statement...
On Wed, Sep 28, 2011 at 7:55 PM, Dennis E. Hamilton
dennis.hamil...@acm.org 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
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtien jhrecht...@web.dewrote:
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janíkpa...@janik.cz:
Have we ever considered using version control to...uh...manage file
versions?
Just an idea.
Maybe Heiner will say more, but in
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 the md5
On 22.09.2011 13:19, Jürgen Schmidt wrote:
On Thu, Sep 22, 2011 at 12:40 AM, Jens-Heiner Rechtienjhrecht...@web.dewrote:
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
2011/9/22 Pavel Janík pa...@janik.cz
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)
don't know if it is what you are looking for but
wget http://svn.apache.org/viewvc/incubator/ooo/trunk/main/
filename?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
2011/9/22 Pavel Janík pa...@janik.cz:
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.
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org 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,
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org 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
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com:
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com
On Thu, Sep 22, 2011 at 2:23 PM, Rob Weir robw...@apache.org wrote:
I was thinking something similar. We only need to use the SVN
interface to the files when we're adding or updating.
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?
On Thu, Sep 22, 2011 at 3:18 PM, Rob Weir robw...@apache.org 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
to
ooo-dev@incubator.apache.org
To
ooo-dev@incubator.apache.org,
cc
Subject
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic
approach to IP review?]
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com:
2011/9/22 Jürgen Schmidt jogischm...@googlemail.com
: 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 pa...@janik.cz:
Proposed way to move forward
1. put the externals under .../trunk/ext_sources
On 09/20/2011 05:26 PM, Rob Weir wrote:
Ai2011/9/20 Pavel Janíkpa...@janik.cz:
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
On Mon, Sep 19, 2011 at 7:05 PM, Rob Weir robw...@apache.org wrote:
On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo) marcus.m...@wtnet.de
wrote:
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:
Am 09/19/2011 01:59 PM,
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
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir robw...@apache.org wrote:
2011/9/19 Jürgen Schmidt jogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir robw...@apache.org wrote:
If you haven't looked it closely, it is probably worth a few minutes
of your time to review our
On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru a...@shanecurcuru.org 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
Hi,
On 20.09.2011 14:37, Jürgen Schmidt wrote:
On Mon, Sep 19, 2011 at 1:59 PM, Rob Weirrobw...@apache.org wrote:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirrobw...@apache.org wrote:
...
Suggestions:
1) We need to get all files needed
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=path to ext_sources'
when we will have such repository, we will surely modify the current
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grand armin.le.gr...@me.com 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/trunk
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've
On 20.09.2011 15:58, Rob Weir wrote:
On Tue, Sep 20, 2011 at 9:48 AM, Armin Le Grandarmin.le.gr...@me.com 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
+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
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 files
Ai2011/9/20 Pavel Janík pa...@janik.cz:
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
2011/9/20 Jürgen Schmidt jogischm...@googlemail.com:
On Tue, Sep 20, 2011 at 2:34 PM, Shane Curcuru a...@shanecurcuru.org 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
On Mon, Sep 19, 2011 at 3:34 AM, Pedro Giffuni giffu...@tutopia.com 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
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir robw...@apache.org 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,
On Sun, Sep 18, 2011 at 9:34 PM, Pedro Giffuni giffu...@tutopia.com 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
2011/9/19 Jürgen Schmidt jogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir robw...@apache.org 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
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirrobw...@apache.org 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
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo) marcus.m...@wtnet.de wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirrobw...@apache.org wrote:
If you haven't looked it closely, it is probably worth
--- On Mon, 9/19/11, Rob Weir robw...@apache.org wrote:
...
2011/9/19 Jürgen Schmidt jogischm...@googlemail.com:
...
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
-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) marcus.m...@wtnet.de wrote:
Am 09/19/2011 01:59 PM
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 robw...@apache.org wrote:
[ ... ]
7) Goal should be for anyone today to be able to see what
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)marcus.m...@wtnet.de wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirrobw...@apache.orgwrote:
If you
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) marcus.m...@wtnet.de wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob
On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo) marcus.m...@wtnet.de wrote:
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On
with 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
Am 09/19/2011 07:05 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo)marcus.m...@wtnet.de wrote:
Am 09/19/2011 04:47 PM, schrieb Rob Weir:
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19
Subject: Re: A systematic approach to IP review?
On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)marcus.m...@wtnet.de
wrote:
Am 09/19/2011 01:59 PM, schrieb Rob Weir:
2011/9/19 Jürgen Schmidtjogischm...@googlemail.com:
On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirrobw...@apache.org
wrote:
If you
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 to IP
To: 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 problem.
How do
: 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
On Mon, Sep 19, 2011 at 4:32 PM, Dennis E. Hamilton
dennis.hamil...@acm.org 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
+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
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
79 matches
Mail list logo
