date:20120821

Rob: I believe it is rather foolish to argue that Roy is incorrect.

For starters, he wrote the Bylaws, and is well-versed in the intent of this
Foundation. Second, the Foundation policies take precedence over
third-party concepts, so whether you/OSI may define a binary as open source
is wholly immaterial. And lastly, you cannot defer to most would disagree
as the only authority is the Foundation, rather than most.

-g
On Aug 20, 2012 5:11 PM, Rob Weir robw...@apache.org wrote:

 On Mon, Aug 20, 2012 at 3:45 PM, Marvin Humphrey mar...@rectangular.com
 wrote:
  On Sat, Aug 18, 2012 at 5:24 AM, Andre Fischer awf@gmail.com
 wrote:
 
  [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating)
  [ ]  0 Don't care
  [ ] -1 Do not release this package because...
 
  -1
 
  I object to the claim that the AOO binaries are officially part of this
  release:
 
  http://s.apache.org/ha
 
  We are officially voting on binaries as well and these are being
 inspected
  and these will be part of the official release.
 
  The policy I am basing my vote on is section 6.3 of the the ASF bylaws as
  interpreted by Roy Fielding:
 
  http://apache.org/foundation/bylaws.html#6.3
 
  Each Project Management Committee shall be responsible for the active
  management of one or more projects identified by resolution of the
 Board
  of Directors which may include, without limitation, the creation or
  maintenance of open-source software for distribution to the public
 at no
  charge.
 
  http://s.apache.org/rk5
 
  This issue is not open for discussion. It is is a mandate from the
  certificate of this foundation -- our agreement with the State of
 Delaware
  that I signed as incorporator. It is fundamental to our status as an
 IRS
  501(c)3 charity. It is the key charter delegated by the board as
 part of
  every TLP resolution: charged with the creation and maintenance of
  open-source software ... for distribution at no charge to the
 public.
 
  Class files are not open source. Jar files filled with class files
 are not

 Actually, the bylaws do not define open source or software.  So
 pick your definition.  The industry standard was the OSI definition,
 or so I thought, which makes it clear that open source also includes
 binaries that are accompanied by source code, or where
 well-publicized means of obtaining the source code are given.

 See:  http://opensource.org/osd.html

 I'd point out that the ALv2 applies to source as well as binaries.


  open source. The fact that they are derived from open source is
 applicable
  only to what we allow projects to be dependent upon, not what we
 vote on
  as a release package. Release votes are on verified open source
 artifacts.
  Binary packages are separate from source packages. One cannot vote to
  approve a release containing a mix of source and binary code because
 the
  binary is not open source and cannot be verified to be safe for
 release
  (even if it was derived from open source).
 

 Again, most would disagree with the assertion that binaries are not open
 source.

 Regards,

 -Rob

  I thought that was frigging obvious. Why do I need to write
 documentation
  to explain something that is fundamental to the open source
 definition?
 
  I intend to withdraw my -1 on clarification from those IPMC members
  casting +1 binding votes that this release VOTE is limited to the source
  release.
 
  Marvin Humphrey
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Aug 20, 2012 5:06 PM, Dave Fisher dave2w...@comcast.net wrote:
 On Aug 20, 2012, at 12:45 PM, Marvin Humphrey wrote:
...
  -1
 
  I object to the claim that the AOO binaries are officially part of this
  release:
...
 I am not surprised at your response, but it is hard and unproductive to
argue with Rob.

This sounds like a problem that the PPMC needs to solve.

(at a minimum, the term should be discuss; rarely should a healthy
community argue, let alone concerns about unproductive discussions)

-g

Re: [VOTE] Graduate Oozie podling from Apache Incubator

2012-08-21 Thread Bertrand Delacretaz

On Mon, Aug 20, 2012 at 10:04 PM, Alejandro Abdelnur t...@cloudera.com wrote:
 Please cast your votes:

 [X] +1 Graduate Oozie podling from Apache Incubator

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache DeltaSpike 0.3-incubating

2012-08-21 Thread Matthias Wessendorf

+1

On Mon, Aug 20, 2012 at 3:47 PM, Mark Struberg strub...@yahoo.de wrote:
 Hi Folks!

 The deltaspike-0.3-incubating vote has internally passed with lots of +1.

 We have 2 IPMC +1 so far and like to ask for a tough review from fellow IPMCs.

 [+1] all fine, ship it
 [+0] I don't care but smells fine
 [-1] stop it, this stuff contains a blocker ${insertreason}

 The VOTE is open for 72h.


 txs and LieGrue,
 strub



 - Forwarded Message -
 From: Mark Struberg strub...@yahoo.de
 To: deltaspike-...@incubator.apache.org 
 deltaspike-...@incubator.apache.org
 Cc:
 Sent: Monday, August 20, 2012 3:43 PM
 Subject: Re: [VOTE] [RESULT] Apache DeltaSpike 0.3-incubating

T ime to tally the vote.

 +1: Mark Struberg (IPMC), Shane Bryzak, Gerhard Petracek (IPMC),  Mehdi
 Heidarzadeh (nonbinding), Lincoln Baxter, Romain Manni-Buccau, Thomas Herzog
 (nonbinding), Cody Lerum, Arne Limburg, Charles Moulliard, Jason Porter, Ken
 Finnigan, Christian Kaltepoth, Antoine Sabot-Durand

 no -1 and no 0.

 I'll forward the vote mail for a rewiew to general@incubator.

 LieGrue,
 strub


 - Original Message -
  From: Mark Struberg strub...@yahoo.de
  To: deltaspike deltaspike-...@incubator.apache.org
  Cc:
  Sent: Wednesday, August 15, 2012 11:56 AM
  Subject: [VOTE] Apache DeltaSpike 0.3-incubating

  Hi!

  I like to call a VOTE on the Apache DeltaSpike 0.3-incubating release.


  The Maven staging repository:
  https://repository.apache.org/content/repositories/orgapachedeltaspike-010/

  The source release package:

 https://repository.apache.org/content/repositories/orgapachedeltaspike-010/org/apache/deltaspike/deltaspike-project/0.3-incubating/

  I've pushed the GIT release branch to my github account:

 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-0.3-incubating

  (The branch will be pushed and merged to master after the VOTE passed.)

  The TAG can be found here:

 https://github.com/struberg/incubator-deltaspike/tree/deltaspike-project-0.3-incubating

  Please note:
  This VOTE is majority approval with a minimum of three +1votes
 of
  PPMC members.

  The VOTE is open for 72 hours.


  [+1] all fine, ship it

  [+0] I don't care but smells fine

  [-1] stop it, this stuff contains a blocker ${insertreason}



  LieGrue,
  strub



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

2012-08-21 Thread Bertrand Delacretaz

On Tue, Aug 21, 2012 at 5:30 AM, Benson Margulies bimargul...@gmail.com wrote:
 Officially, no Apache project has ever, ever, released a binary.

 Apache projects have published convenience binaries to accompany their
 releases, which have been, by definition, source

Agreed - for the Flex podling the mentors have asked for a distinct
binaries folder, see
http://apache.org/dist/incubator/flex/4.8.0-incubating/

I think that's a good step, and it would be even better to add a
README in there which points to an URL that explains the source/binary
release thing.

The best way to clarify that is to probably to create an issue at
https://issues.apache.org/jira/browse/LEGAL and discuss on the
legal-discuss list, where people from multiple projects that are
affected by this can join. It's an ASF-wide issue, not an Incubator
issue.

-Bertrand (not volunteering - busy enough)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On 8/21/12 8:14 AM, Marvin Humphrey wrote:
 On Mon, Aug 20, 2012 at 5:30 PM, Dave Fisher dave2w...@comcast.net wrote:
 
 In my mind as an IPMC member and Apache Member, this is a source release
 VOTE with convenience binary artifacts.
 
 Thank you, Dave.  I consider your statement to override the assertion on
 ooo-dev that binaries are part of the official release, and that suffices to
 address my concern about this specific VOTE: no ASF policy is being
 challenged.
 
 I withdraw my -1.
 
 Edge case and RAT check discussion at the bottom, if that balances your vote
 in either direction.
 
 I've read through a number of recent threads in the ooo-dev archives.
 
 It bothers me a bit that AFAICT the RAT report was not run prior to cutting
 the RC.  As a freelance IPMC vote, I have few tools at my disposal to assess
 a release and I have to rely on the diligence of the PPMC with regards to IP
 integrity.  In and of itself, RAT is just a helper, but whether it gets run is
 a heuristic.  :)  I wonder why Run RAT did not end up on a pre-release
 checklist anywhere.
 
 Please advise about whether you think the PPMC needs to respin the VOTE
 and/or the Artifacts in any way.
 
 *   Sums and sigs look good for all 3 source archives.
 *   All archives contain identical source files.
 *   I could not find a version control tag for 3.4.1-rc2, but I was
 able to obtain the AOO34 branch at the specified revision 1372282; it was
 close, though seemingly not exact.  The discrepancies are shown below.
 I don't believe this should block, but it would be nice to know why the

I can explain this because I prepared the source release. The binaries
(MacOS) and the first build of the src release were made on clean source
tree based on revision r1372282.

After this I analyzed a potential further bugfix on the same tree. I
made some debug output in 3 cxx files. But after deeper analysis we
decided that we don't want include this fix in 3.4.1. The risk to break
something else was to high and we postponed the fix to the next release.

After this we recognize some problems with the RAT output. I deleted
some svn generated *.rej files and built the src package again to clean
up the RAT output. It seems that I have overseen the debug messages in
the changed cxx files.

I can easy repackage the src release on the same tree where I revert the
local changes to revision 1372282.

If we all agree I can easy exchange the src release packages with the
new ones.


 differences exist.
 *   I did not attempt to build and test, as I believe others have this
 covered.
 
 The one thing I want to follow up on is the outcome of the posthumous RAT
 audit:
 
 http://markmail.org/message/yrb4ujtj5s4poi5b
 
  ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar
 
 No idea. But it is test code, not needed for building.
 
  ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar
 
 Not needed for building. It is part of a test setup for testing
 Certification Revocation Lists.
 
 So for the last two we should verify license. If the license allows
 redistribution, then I think we're fine. If not, then we need to build a
 new src ZIP without them.
 
 If I hear that those files pass muster, I expect to vote +1.

Both jars are checked in and this can be seen as mistake. The reason is
that they are built by Netbeans projects and whoever checked in the code
has checked in the dist folder as well. And a further mistake is that
both project don't move the output in the output directory of the
module. That is the default behaviour in all modules, generated output
during the build process goes into the module output directory.

For example:
module_name/unxmacxi.pro/...

The ant script that package the src release takes care of the output
directories and exclude them. In this case the by mistake checked in
jars are packed as well.

This have to be fixed definitely and we have already started to fix it
on trunk. See issues [1] and [2].

The question is if it is release critical or not at this point? I think
it isn't because the jars are the output of 2 existing NetBeans projects
that are part of the src release as well. And I would like to prevent if
possible a new revision number because that means new binaries as well.


I propose the following for this release:

1. revert the debug output in the 3 *.cxx files and repackage the src
release based on r1372282

Cleanup for future releases on trunk.
2. Remove the 2 jars (the dist folder) from svn, adapt the projects to
deliver the output in the module output directory

3. Check other binaries again and make the RAT exclude list more fine
grained to document better for what reason the binaries have to be kept...

Juergen

[1] https://issues.apache.org/ooo/show_bug.cgi?id=120634
[2] https://issues.apache.org/ooo/show_bug.cgi?id=120635

 
 Marvin Humphrey
 
 
 marvin@smokey:~/Desktop/aoo341 $ gpg --verify
 aoo-3.4.1-incubating-src.tar.gz.asc
 gpg:

Re: [VOTE] Graduate Oozie podling from Apache Incubator

2012-08-21 Thread Arvind Prabhakar

[X] +1 Graduate Oozie podling from Apache Incubator

(binding)

Regards,
Arvind Prabhakar

On Mon, Aug 20, 2012 at 10:25 AM, Alejandro Abdelnur t...@cloudera.comwrote:

 This is the second call for vote to graduate Oozie podling from Apache
 Incubator, comments and suggestions received during the first call have
 been addressed.

 Oozie entered the Incubator in July of 2011. Since then it has added
 two new committers and made two significant releases following the ASF
 policies and guidelines. The community of Oozie is active, healthy and
 growing and has demonstrated the ability to self-govern using accepted
 Apache practices. Oozie community has voted to proceed with graduation
 [1] and the result can be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Oozie podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Oozie podling
 [  ] -1 Reject graduation of Oozie podling from Apache Incubator

 This vote will be open for at least 72 hours. Please find the proposed
 board resolution below.

 [1] http://s.apache.org/WDb
 [2] http://s.apache.org/AB2

 Regards,
 Alejandro Abdelnur

 -

 X. Establish the Apache Oozie Project

WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to a system for managing and
scheduling workflows that run different types of Hadoop
jobs (such as MapReduce, Pig, Hive and Sqoop) as well as
system specific jobs (such as Java programs and shell
scripts) for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Oozie Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Oozie Project be and hereby is
responsible for the creation and maintenance of software
related to a system for managing and scheduling workflows
that run different types of Hadoop jobs (such as MapReduce,
Pig, Hive and Sqoop) as well as system specific jobs (such
as Java programs and shell scripts); and be it further

RESOLVED, that the office of Vice President, Apache Oozie be
and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Oozie Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Oozie Project; and be it further

RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Oozie Project:

 * Alan Gatesga...@apache.org
 * Alejandro Abdelnurt...@apache.org
 * Andreas Neumann   a...@apache.org
 * Angelo Huang  ange...@apache.org
 * Chao Wang broo...@apache.org
 * Chris Douglas cdoug...@apache.org
 * Devaraj Das   d...@apache.org
 * Harsh Chouraria   ha...@apache.org
 * Mayank Bansal may...@apache.org
 * Mohammad Islamkam...@apache.org
 * Virag Kothari vi...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alejandro Abdelnur
be appointed to the office of Vice President, Apache Oozie,
to serve in accordance with and subject to the direction of the
Board of Directors and the Bylaws of the Foundation until
death, resignation, retirement, removal or disqualification,
or until a successor is appointed; and be it further

RESOLVED, that the initial Apache Oozie PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Oozie Project; and be it further

RESOLVED, that the Apache Oozie Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Oozie podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Oozie podling encumbered upon the Apache Incubator
Project are hereafter discharged.

Re: [VOTE] Apache OpenOffice Community Graduation Vote

On 8/21/12 12:03 AM, drew wrote:
 On Mon, 2012-08-20 at 13:32 -0700, Marvin Humphrey wrote:
 On Sun, Aug 19, 2012 at 8:53 AM, Rob Weir robw...@apache.org wrote:
 Per the IPMC's Guide to Successful Graduation [1] this is the
 optional, but recommended, community vote for us to express our
 willingness/readiness to govern ourselves.  If this vote passes then
 we continue by drafting a charter, submitting it for IPMC endorsement,
 and then to the ASF Board for final approval.   Details can be found
 in the Guide to Successful Graduation.

 Everyone in the community is encouraged to vote.  Votes from PPMC
 members and Mentors are binding.  This vote will run 72-hours.


 [ ] +1  Apache OpenOffice community is ready to graduate from the
 Apache Incubator.
 [ ] +0 Don't care.
 [ ] -1  Apache OpenOffice community is not ready to graduate from the
 Apache Incubator because...

 In my opinion, the issue of binary releases ought to be resolved before
 graduation.

 If the podling believes that ASF-endorsed binaries are a hard requirement,
 then it seems to me that the ASF is not yet ready for AOO and will not be
 until suitable infrastructure and legal institutions to support binary
 releases (sterile build machines, artifact signing, etc) have been created
 and a policy has been endorsed by the Board.

 One possibility discussed in the past was to have downstream commercial
 vendors release binaries a la Subversion's example, which would
 obviate the need for all the effort and risk associated with providing 
 support
 for ASF-endorsed binaries.  For whatever reason, the AOO podling seems not to
 have gone this direction, though.

 Marvin Humphrey
 
 Hi Marvin,
 
 Well, for myself, I don't have a problem with the AOO project not having
 official binary releases - in such a circumstance I would strongly
 prefer no binary release at all. 

As one of the active developers I would have a serious problem if we as
project couldn't provide binary releases for our users. And I thought
the ASF is a serious enough institution that can ensure to deliver
binaries of these very popular end user oriented software and can of
course protect the very valuable brand OpenOffice that the ASF now owns
as well.

The satisfaction of developers (at least my personal) is the fact that I
work on a piece of software used by millions of users worldwide and
these users require a binary version. And one of a trusted source and
that is allowed to name it OpenOffice.

I thought also that the ASF could leverage the brand in a way to
generate more donations for the ASF and benefit even more from the
overall success of the project. I know people who didn't know Apache
before but now because of OpenOffice. Maybe worth to think about it!

But I get ones more the impression that I am probably wrong. If the day
should come that I will leave this project it will have nothing to do
with the project itself.

Juergen


 
 On the other hand if there is a binary release from the AOO project then
 I believe it should be treated as a fully endorsed action.
 
 One guys opinion.
 
 Thanks
 
 Drew Jensen
 AOO PPMC member
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 4:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 8/21/12 8:14 AM, Marvin Humphrey wrote:
 On Mon, Aug 20, 2012 at 5:30 PM, Dave Fisher dave2w...@comcast.net wrote:

 In my mind as an IPMC member and Apache Member, this is a source release
 VOTE with convenience binary artifacts.

 Thank you, Dave.  I consider your statement to override the assertion on
 ooo-dev that binaries are part of the official release, and that suffices to
 address my concern about this specific VOTE: no ASF policy is being
 challenged.

 I withdraw my -1.

 Edge case and RAT check discussion at the bottom, if that balances your vote
 in either direction.

 I've read through a number of recent threads in the ooo-dev archives.

 It bothers me a bit that AFAICT the RAT report was not run prior to cutting
 the RC.  As a freelance IPMC vote, I have few tools at my disposal to 
 assess
 a release and I have to rely on the diligence of the PPMC with regards to IP
 integrity.  In and of itself, RAT is just a helper, but whether it gets run 
 is
 a heuristic.  :)  I wonder why Run RAT did not end up on a pre-release
 checklist anywhere.

 Please advise about whether you think the PPMC needs to respin the VOTE
 and/or the Artifacts in any way.

 *   Sums and sigs look good for all 3 source archives.
 *   All archives contain identical source files.
 *   I could not find a version control tag for 3.4.1-rc2, but I was
 able to obtain the AOO34 branch at the specified revision 1372282; it was
 close, though seemingly not exact.  The discrepancies are shown below.
 I don't believe this should block, but it would be nice to know why the

 I can explain this because I prepared the source release. The binaries
 (MacOS) and the first build of the src release were made on clean source
 tree based on revision r1372282.

 After this I analyzed a potential further bugfix on the same tree. I
 made some debug output in 3 cxx files. But after deeper analysis we
 decided that we don't want include this fix in 3.4.1. The risk to break
 something else was to high and we postponed the fix to the next release.

 After this we recognize some problems with the RAT output. I deleted
 some svn generated *.rej files and built the src package again to clean
 up the RAT output. It seems that I have overseen the debug messages in
 the changed cxx files.

 I can easy repackage the src release on the same tree where I revert the
 local changes to revision 1372282.

 If we all agree I can easy exchange the src release packages with the
 new ones.


 differences exist.
 *   I did not attempt to build and test, as I believe others have this
 covered.

 The one thing I want to follow up on is the outcome of the posthumous RAT
 audit:

 http://markmail.org/message/yrb4ujtj5s4poi5b

  
 ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar

 No idea. But it is test code, not needed for building.

  ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar

 Not needed for building. It is part of a test setup for testing
 Certification Revocation Lists.

 So for the last two we should verify license. If the license allows
 redistribution, then I think we're fine. If not, then we need to build a
 new src ZIP without them.

 If I hear that those files pass muster, I expect to vote +1.

 Both jars are checked in and this can be seen as mistake. The reason is
 that they are built by Netbeans projects and whoever checked in the code
 has checked in the dist folder as well. And a further mistake is that
 both project don't move the output in the output directory of the
 module. That is the default behaviour in all modules, generated output
 during the build process goes into the module output directory.


Or said otherwise, these two JAR's are built from ALv2-licensed source
code, part of the source artifact distribution:

 ./testgraphical/ui/java/ConvwatchGUIProject/dist/ConvwatchGUIProject.jar

 ./xmlsecurity/test_docs/tools/httpserv/dist/httpserv.jar

So we have license to distribute and no special notice is required.

Apparently this redundancy was inherited from the initial code that
came in via the Oracle SGA.  We'll fix in the trunk.

Regards,

-Rob

 For example:
 module_name/unxmacxi.pro/...

 The ant script that package the src release takes care of the output
 directories and exclude them. In this case the by mistake checked in
 jars are packed as well.

 This have to be fixed definitely and we have already started to fix it
 on trunk. See issues [1] and [2].

 The question is if it is release critical or not at this point? I think
 it isn't because the jars are the output of 2 existing NetBeans projects
 that are part of the src release as well. And I would like to prevent if
 possible a new revision number because that means new binaries as well.


 I propose the following for this release:

 1. revert the debug output in the 3 *.cxx files and repackage the src

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread sebb

On 18 August 2012 13:24, Andre Fischer awf@gmail.com wrote:
 Hi all,

 this is a call for vote on releasing the following candidate as Apache
 OpenOffice 3.4.1 (incubating). This will be the second incubator release for
 Apache OpenOffice after the 3.4 release with already more than 11 million
 downloads.


 This release candidate provides the following important key changes
 compared to the OpenOffice 3.4 release:

 (1) Five more translations: Finnish, British English, Khmer, Slovak, and
 Slovenian.

 (2) As of 2012/08/16, there were 69 verified issues that have been
 resolved. (Complete list at http://s.apache.org/Huv)

 (3) Update of the NOTICE file: it now properly mentions CoinMP as numerical
 equation solver.

 (3) Most external source archives are now downloaded from their project
 servers.
 For all of them exists a fallback at
 http://ooo-extras.apache-extras.org.codespot.com/files/.
 The Apache SVN repository is only used as secondary fallback and
 is not used in practice.
 It will be removed in the next release.


 For a detailed feature overview please see the release notes at
 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes.

 The release candidate artifacts (source release, as well as binary
 releases for 20 languages) and further information how to verify and
 review Apache OpenOffice 3.4.1 (incubating) can be found on the following
 wiki page:


 https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1

 Please vote on releasing this package as Apache OpenOffice 3.4.1
 (incubating).

I think the NOTICE file included in the source release is wrong.
NOTICE files are for *required* notices only, and should be as short
as possible, and should only relate to software that is actually
included in the particular artifact in which they appear.

There are several repeated instances of

===
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
===

There should only be one instance at the head of the file.

The Tomcat (Tomcat? is that really included?) section mentions NSIS -
is that really included?

There are lots of other entries which look superfluous.
It's vital that the NOTICE file only include *required* notices.

If the binary builds include additional software, then their NL files
need to include any required references.

I think the NOTICE problems are serious enough to warrant a respin.

 The vote starts now and will be open until:

 Tuesday, August 21st: 2012-08-21 15pm UTC+2.

 The PPMC vote took already place on the public ooo-dev mailing list.
 There where 11 +1 votes including
one IPMC member binding +1,
10 +1 votes fro PPMC members (this includes the one IPMC member),
one +1 vote from a community member.
 No abstinations, no -1 votes.

 Vote thread:
 http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E


 The vote will be open for 3 days.

 [ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating)
 [ ]  0 Don't care
 [ ] -1 Do not release this package because...

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On 8/21/12 12:52 PM, sebb wrote:
On 18 August 2012 13:24, Andre Fischer awf@gmail.com wrote:
Hi all,

this is a call for vote on releasing the following candidate as Apache
OpenOffice 3.4.1 (incubating). This will be the second incubator release for
Apache OpenOffice after the 3.4 release with already more than 11 million
downloads.

This release candidate provides the following important key changes
compared to the OpenOffice 3.4 release:

(1) Five more translations: Finnish, British English, Khmer, Slovak, and
Slovenian.

(2) As of 2012/08/16, there were 69 verified issues that have been
resolved. (Complete list at http://s.apache.org/Huv)

(3) Update of the NOTICE file: it now properly mentions CoinMP as numerical
equation solver.

(3) Most external source archives are now downloaded from their project
servers.
For all of them exists a fallback at
http://ooo-extras.apache-extras.org.codespot.com/files/.
The Apache SVN repository is only used as secondary fallback and
is not used in practice.
It will be removed in the next release.

For a detailed feature overview please see the release notes at
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes.

The release candidate artifacts (source release, as well as binary
releases for 20 languages) and further information how to verify and
review Apache OpenOffice 3.4.1 (incubating) can be found on the following
wiki page:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1

Please vote on releasing this package as Apache OpenOffice 3.4.1
(incubating).

I think the NOTICE file included in the source release is wrong.
NOTICE files are for *required* notices only, and should be as short
as possible, and should only relate to software that is actually
included in the particular artifact in which they appear.

There are several repeated instances of

===
This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
===

There should only be one instance at the head of the file.

The Tomcat (Tomcat? is that really included?) section mentions NSIS -
is that really included?

There are lots of other entries which look superfluous.
It's vital that the NOTICE file only include *required* notices.

I can't argue about the exact content and the format how a NOTICE have
to look like. No changes in the NOTICE file for the src release compared
to AOO 3.4

We had many discussion on the NOTICE file for 3.4 and followed the
advices of we got from these discussion

The discussion took place on
ooo-dev
legal-discuss

And you can find comments here on the list.

If the binary builds include additional software, then their NL files
need to include any required references.

The binaries includes an aggregated NOTICE file where other included
external software (category-b) is integrated.

Here we added the COINMP stuff for the 3.4.1 release that was raised as
feedback to 3.4.

I think the NOTICE problems are serious enough to warrant a respin.

mmh, I am unsure, the next time somebody else with a different view and
opinion comes up and we have to change it again?

Again we changed it according the advices we got for the AOO 3.4 release.

Juergen

The vote starts now and will be open until:

Tuesday, August 21st: 2012-08-21 15pm UTC+2.

The PPMC vote took already place on the public ooo-dev mailing list.
There where 11 +1 votes including
one IPMC member binding +1,
10 +1 votes fro PPMC members (this includes the one IPMC member),
one +1 vote from a community member.
No abstinations, no -1 votes.

Vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E

The vote will be open for 3 days.

[ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating)
[ ] 0 Don't care
[ ] -1 Do not release this package because...

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Branko Čibej

On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

This is an unreasonable request. The IPMC voted on the 3.4.0 release.
The notice file has not changed between 3.4.0 and 3.4.1. How then do you
justify this new requirement?

It is not fair to the podling if the IPMC invents new requirements and
reverses its own decisions for no apparent reason. This NOTICE issue
certainly shouldn't be ground for vetoing a release.

By the way, the same holds for binaries being included in the releases.
The 3.4.0 release, with binaries, was approved. If the podling did not
change its release procedures and policies and artefacts in the
meantime, it's not reasonable to hold up what amounts to a security
release solely based on the IPMC having screwed up the previous release
vote.

It is fair to require changes for the next release. It's not fair to use
different criteria for two successive, essentially identical releases.
(N.B.: I use the term essentially identical in the sense that, whilst
some of the sources have changed, the overall structure of the release
artefacts has not.)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Thilo Goetz

On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.
 
 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

Let me offer some advice from somebody who has been where you
are now.  Please keep in mind that the ASF is a large, volunteer
organization.  The backs and forths you are seeing here are
normal and probably can't be avoided in flat organization like
this.  This can be strange and/or frustrating to people who are
either paid to do their Apache work, or who come from smaller
organizations where it was easier to come to a decision.  Try
to keep a positive attitude, go with the flow, and become a part
of the wider Apache community (not just your project).  Help
improve things where you see they are lacking.  This community
aspect is very important at Apache.

As to the issue at hand, this is not a new requirement.  The
issue just wasn't spotted last time.  Yes, that's annoying, but
it can't be helped.  The NOTICE and the LICENSE files are the
most important files in your distribution, and you should make
every effort to get them right.  Sebb raises valid concerns that
need to be addressed.

Just trying to help here, so no flak my way please :-)

BTW, I think AOO is doing an amazing job.  I was not optimistic
when the project came to Apache, and I'm amazed you are where
you are now.  Keep up the good work.

--Thilo


 
 It is not fair to the podling if the IPMC invents new requirements and
 reverses its own decisions for no apparent reason. This NOTICE issue
 certainly shouldn't be ground for vetoing a release.
 
 By the way, the same holds for binaries being included in the releases.
 The 3.4.0 release, with binaries, was approved. If the podling did not
 change its release procedures and policies and artefacts in the
 meantime, it's not reasonable to hold up what amounts to a security
 release solely based on the IPMC having screwed up the previous release
 vote.
 
 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 (N.B.: I use the term essentially identical in the sense that, whilst
 some of the sources have changed, the overall structure of the release
 artefacts has not.)
 
 -- Brane
 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

2012-08-21 Thread Bertrand Delacretaz

On Tue, Aug 21, 2012 at 11:54 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 ...As one of the active developers I would have a serious problem if we as
 project couldn't provide binary releases for our users. And I thought
 the ASF is a serious enough institution that can ensure to deliver
 binaries of these very popular end user oriented software and can of
 course protect the very valuable brand OpenOffice that the ASF now owns
 as well...

As has been repeatedly mentioned in this thread and elsewhere, at the
moment ASF releases consist of source code, not binaries.

OTOH I don't think anybody said the ASF will never allow projects to
distribute binaries - but people who want to do that need to get
together (*) and come up with a proposal that's compatible with the
ASF's goals and constraints, so that a clear policy can be set. A
related discussion is ongoing on infra-dev [1] about signing
artifacts, where we also have suggested that people get together and
express their requirements in a constructive way instead of
complaining.

-Bertrand

(*) Earlier in this thread, I have suggested using legal-discuss +
LEGAL jira issues to manage this cross-project discussion. The pmcs@
alias + this list can be used to invite all projects and podlings to
join such a discussion.

[1] http://s.apache.org/signing_reqs

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.  Please keep in mind that the ASF is a large, volunteer
 organization.  The backs and forths you are seeing here are
 normal and probably can't be avoided in flat organization like
 this.  This can be strange and/or frustrating to people who are
 either paid to do their Apache work, or who come from smaller
 organizations where it was easier to come to a decision.  Try
 to keep a positive attitude, go with the flow, and become a part
 of the wider Apache community (not just your project).  Help
 improve things where you see they are lacking.  This community
 aspect is very important at Apache.

 As to the issue at hand, this is not a new requirement.  The
 issue just wasn't spotted last time.  Yes, that's annoying, but
 it can't be helped.  The NOTICE and the LICENSE files are the
 most important files in your distribution, and you should make
 every effort to get them right.  Sebb raises valid concerns that
 need to be addressed.


A suggested exercise at ApacheCon.  Get a group of 20 Members, break
them into groups of 5.  Give each group an identical list of 3rd party
dependencies and ask them to create a NOTICE file that expresses them.
 Give them 30 minutes.  Compare the results.

I'd bet any amount that all four NOTICE files will differ in
substantive ways, and that there would be disagreement, both within
the groups, and across the groups, on which was correct.

-Rob

 Just trying to help here, so no flak my way please :-)

 BTW, I think AOO is doing an amazing job.  I was not optimistic
 when the project came to Apache, and I'm amazed you are where
 you are now.  Keep up the good work.

 --Thilo



 It is not fair to the podling if the IPMC invents new requirements and
 reverses its own decisions for no apparent reason. This NOTICE issue
 certainly shouldn't be ground for vetoing a release.

 By the way, the same holds for binaries being included in the releases.
 The 3.4.0 release, with binaries, was approved. If the podling did not
 change its release procedures and policies and artefacts in the
 meantime, it's not reasonable to hold up what amounts to a security
 release solely based on the IPMC having screwed up the previous release
 vote.

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 (N.B.: I use the term essentially identical in the sense that, whilst
 some of the sources have changed, the overall structure of the release
 artefacts has not.)

 -- Brane


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

2012-08-21 Thread Benson Margulies

I would like to offer a very loud +1 to Bertrand's email.

Here we are on a community graduation vote thread. This sub-discussion
would seem to lead to one of three outcomes:

1) No place new. AOO proceeds out of the incubator operating under the
current regime, and those AOO community members who are already
engaged in discussions with infra and others about the preconditions
for formal binary releases continue -- taking Bertrand's suggestion.

2) The community votes to stay in the incubator until a binary release
plan exists. I can't see why this has any attraction for the
community.

3) The community, or a subset thereof, takes their marbles and sets up
shop in some other environment where binary releases are
well-established.

Before people start throwing things at me, I want to emphasize that
(3) is offered only for completeness. If (1) is the order of the day,
and an IPMC vote comes around soon, I'll be voting in favor of
graduation.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Benson Margulies

On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote:
 On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.  Please keep in mind that the ASF is a large, volunteer
 organization.  The backs and forths you are seeing here are
 normal and probably can't be avoided in flat organization like
 this.  This can be strange and/or frustrating to people who are
 either paid to do their Apache work, or who come from smaller
 organizations where it was easier to come to a decision.  Try
 to keep a positive attitude, go with the flow, and become a part
 of the wider Apache community (not just your project).  Help
 improve things where you see they are lacking.  This community
 aspect is very important at Apache.

 As to the issue at hand, this is not a new requirement.  The
 issue just wasn't spotted last time.  Yes, that's annoying, but
 it can't be helped.  The NOTICE and the LICENSE files are the
 most important files in your distribution, and you should make
 every effort to get them right.  Sebb raises valid concerns that
 need to be addressed.

this point has, in fact, been the subject of a long-standing debate in
the IPMC. While I have the greatest respect for sebb, there are other
members of this PMC for whom I also have great respect who have taken
the opposite view -- that - within reason - flaws in these files can
be noted and repaired for the next release.

The situation at hand is complicated by the running graduation thread
for AOO, since it seems to me to be reasonable to expect that these
files have achieved a consensus state before graduation. However,
that's just a thought on my part.






 A suggested exercise at ApacheCon.  Get a group of 20 Members, break
 them into groups of 5.  Give each group an identical list of 3rd party
 dependencies and ask them to create a NOTICE file that expresses them.
  Give them 30 minutes.  Compare the results.

 I'd bet any amount that all four NOTICE files will differ in
 substantive ways, and that there would be disagreement, both within
 the groups, and across the groups, on which was correct.

 -Rob

 Just trying to help here, so no flak my way please :-)

 BTW, I think AOO is doing an amazing job.  I was not optimistic
 when the project came to Apache, and I'm amazed you are where
 you are now.  Keep up the good work.

 --Thilo



 It is not fair to the podling if the IPMC invents new requirements and
 reverses its own decisions for no apparent reason. This NOTICE issue
 certainly shouldn't be ground for vetoing a release.

 By the way, the same holds for binaries being included in the releases.
 The 3.4.0 release, with binaries, was approved. If the podling did not
 change its release procedures and policies and artefacts in the
 meantime, it's not reasonable to hold up what amounts to a security
 release solely based on the IPMC having screwed up the previous release
 vote.

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 (N.B.: I use the term essentially identical in the sense that, whilst
 some of the sources have changed, the overall structure of the release
 artefacts has not.)

 -- Brane


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 9:38 AM, Benson Margulies bimargul...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote:
 On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.  Please keep in mind that the ASF is a large, volunteer
 organization.  The backs and forths you are seeing here are
 normal and probably can't be avoided in flat organization like
 this.  This can be strange and/or frustrating to people who are
 either paid to do their Apache work, or who come from smaller
 organizations where it was easier to come to a decision.  Try
 to keep a positive attitude, go with the flow, and become a part
 of the wider Apache community (not just your project).  Help
 improve things where you see they are lacking.  This community
 aspect is very important at Apache.

 As to the issue at hand, this is not a new requirement.  The
 issue just wasn't spotted last time.  Yes, that's annoying, but
 it can't be helped.  The NOTICE and the LICENSE files are the
 most important files in your distribution, and you should make
 every effort to get them right.  Sebb raises valid concerns that
 need to be addressed.

 this point has, in fact, been the subject of a long-standing debate in
 the IPMC. While I have the greatest respect for sebb, there are other
 members of this PMC for whom I also have great respect who have taken
 the opposite view -- that - within reason - flaws in these files can
 be noted and repaired for the next release.

 The situation at hand is complicated by the running graduation thread
 for AOO, since it seems to me to be reasonable to expect that these
 files have achieved a consensus state before graduation. However,
 that's just a thought on my part.


We're just running the community readiness graduation vote on
ooo-dev right now.  We're also discussing the composition of the PMC,
drafting the charter on our wiki, looking toward nominating a Chair,
etc.  But no formal IPMC vote on graduation is underway.  That will
happen in due course.

One option might be to agree that the NOTICE issues are not fatal to
the purpose of a NOTICE file, and approve the release.  But then have
further discussion on it leading to changes in our trunk, and that
could be a condition of graduation.

-Rob






 A suggested exercise at ApacheCon.  Get a group of 20 Members, break
 them into groups of 5.  Give each group an identical list of 3rd party
 dependencies and ask them to create a NOTICE file that expresses them.
  Give them 30 minutes.  Compare the results.

 I'd bet any amount that all four NOTICE files will differ in
 substantive ways, and that there would be disagreement, both within
 the groups, and across the groups, on which was correct.

 -Rob

 Just trying to help here, so no flak my way please :-)

 BTW, I think AOO is doing an amazing job.  I was not optimistic
 when the project came to Apache, and I'm amazed you are where
 you are now.  Keep up the good work.

 --Thilo



 It is not fair to the podling if the IPMC invents new requirements and
 reverses its own decisions for no apparent reason. This NOTICE issue
 certainly shouldn't be ground for vetoing a release.

 By the way, the same holds for binaries being included in the releases.
 The 3.4.0 release, with binaries, was approved. If the podling did not
 change its release procedures and policies and artefacts in the
 meantime, it's not reasonable to hold up what amounts to a security
 release solely based on the IPMC having screwed up the previous release
 vote.

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 (N.B.: I use the term essentially identical in the sense that, whilst
 some of the sources have changed, the overall structure of the release
 artefacts has not.)

 -- Brane


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 -
 To unsubscribe, e-mail:

[jira] [Commented] (PODLINGNAMESEARCH-12) Establish whether Apache Amber is a suitable name

2012-08-21 Thread Antonio Sanso (JIRA)


[ 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13438756#comment-13438756
 ] 

Antonio Sanso commented on PODLINGNAMESEARCH-12:


US Trademark Search 

http://www.trademarkia.com/trademarks-search.aspx?tn=amber

Results include mainly chemical stuff, nothing seems to be software/computer 
related

 Establish whether Apache Amber is a suitable name
 ---

 Key: PODLINGNAMESEARCH-12
 URL: 
 https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-12
 Project: Podling Suitable Names Search
  Issue Type: Suitable Name Search
Reporter: Antonio Sanso

 We have to do some investigations to ensure that Apache Amber is a suitable 
 name for a TLP. 
 Here are some resources related to this issue: 
 http://incubator.apache.org/guides/names.html 
 http://www.apache.org/foundation/marks/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Thilo Goetz

On 21/08/12 15:24, Rob Weir wrote:
[...]
 A suggested exercise at ApacheCon.  Get a group of 20 Members, break
 them into groups of 5.  Give each group an identical list of 3rd party
 dependencies and ask them to create a NOTICE file that expresses them.
  Give them 30 minutes.  Compare the results.
 
 I'd bet any amount that all four NOTICE files will differ in
 substantive ways, and that there would be disagreement, both within
 the groups, and across the groups, on which was correct.
 
 -Rob

Sure.  You can do the same exercise with 20 IBM lawyers with
similar results.  And still you need to get the approval of
IBM legal.

--Thilo



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread sebb

On 21 August 2012 14:38, Benson Margulies bimargul...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 9:24 AM, Rob Weir robw...@apache.org wrote:
 On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.  Please keep in mind that the ASF is a large, volunteer
 organization.  The backs and forths you are seeing here are
 normal and probably can't be avoided in flat organization like
 this.  This can be strange and/or frustrating to people who are
 either paid to do their Apache work, or who come from smaller
 organizations where it was easier to come to a decision.  Try
 to keep a positive attitude, go with the flow, and become a part
 of the wider Apache community (not just your project).  Help
 improve things where you see they are lacking.  This community
 aspect is very important at Apache.

 As to the issue at hand, this is not a new requirement.  The
 issue just wasn't spotted last time.  Yes, that's annoying, but
 it can't be helped.  The NOTICE and the LICENSE files are the
 most important files in your distribution, and you should make
 every effort to get them right.  Sebb raises valid concerns that
 need to be addressed.

 this point has, in fact, been the subject of a long-standing debate in
 the IPMC. While I have the greatest respect for sebb, there are other
 members of this PMC for whom I also have great respect who have taken
 the opposite view -- that - within reason - flaws in these files can
 be noted and repaired for the next release.

There are two issues here:
1) whether the NOTICE file is correct
2) if not, whether the problems are such as to require a respin.

I hope we are agreed that the NOTICE file is not correct.

The reason I think that problems in NOTICE files are to be taken
seriously is that the N (L) files are vital for our licensing.

 The situation at hand is complicated by the running graduation thread
 for AOO, since it seems to me to be reasonable to expect that these
 files have achieved a consensus state before graduation. However,
 that's just a thought on my part.






 A suggested exercise at ApacheCon.  Get a group of 20 Members, break
 them into groups of 5.  Give each group an identical list of 3rd party
 dependencies and ask them to create a NOTICE file that expresses them.
  Give them 30 minutes.  Compare the results.

 I'd bet any amount that all four NOTICE files will differ in
 substantive ways, and that there would be disagreement, both within
 the groups, and across the groups, on which was correct.

 -Rob

 Just trying to help here, so no flak my way please :-)

 BTW, I think AOO is doing an amazing job.  I was not optimistic
 when the project came to Apache, and I'm amazed you are where
 you are now.  Keep up the good work.

 --Thilo



 It is not fair to the podling if the IPMC invents new requirements and
 reverses its own decisions for no apparent reason. This NOTICE issue
 certainly shouldn't be ground for vetoing a release.

 By the way, the same holds for binaries being included in the releases.
 The 3.4.0 release, with binaries, was approved. If the podling did not
 change its release procedures and policies and artefacts in the
 meantime, it's not reasonable to hold up what amounts to a security
 release solely based on the IPMC having screwed up the previous release
 vote.

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 (N.B.: I use the term essentially identical in the sense that, whilst
 some of the sources have changed, the overall structure of the release
 artefacts has not.)

 -- Brane


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Marvin Humphrey

On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote:

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.

When the option to be fair exists, fair is great!

With regards to my own vote, I'm going to try to apply Jukka's criteria on
rights:

http://markmail.org/message/jtj27kdlhvgocexg

Personally I'm fine with things like missing license headers or partially
incomplete license metadata (which sounds like is the case here), as long
as those are just omissions that don't fundamentally affect our rights (or
those of downstream users) to distribute the releases and as long as
there's a commitment to fix such issues in time for the next release.

Extraneous information in the NOTICE file imposes a burden on some downstream
distributors and consumers.  Thee is almost certainly room for improvement in
the AOO NOTICE file, and we have made some progress towards a consensus on
exactly what ought to be in NOTICE since the first incubating release of AOO
-- though there is also considerable room for improvement in the ASF
documentation with regards to NOTICE.  :)

However, is there anything about the NOTICE file in this AOO release candidate
which affects _rights_, either our own or those of downstream users?  I've
looked through the file, and if that's the case, I don't see it.  If sebb
thinks a respin is merited, that's his call, and his review is a welcome
contribution.  However, considering how much effort it takes to spin up an AOO
release, the good faith and substantial effort invested by the podling in
assembling the NOTICE file in the first place, and the good record of the AOO
podling in incorporating suggestions, my opinion is that a promise to
incorporate any NOTICE revisions into trunk suffices and that a new RC is not
required.

In contrast, I am more concerned about extra files that were apparently
inadvertently committed and were not caught by either the primary mechanism of
PPMC members watching the commits list or by the last line of defense of
running a RAT report prior to rolling the release.  If files which are
incompatible with our licensing end up in a distribution, that has the
potential to affect _rights_.  And what with AOO's history, there is a big
target painted on the project and there is a conspicuous need to maintain
absolute control over what ends up in releases.

It looks like the late audit has revealed that those files are OK, but it
feels like we might have dodged a bullet.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Marvin Humphrey

On Tue, Aug 21, 2012 at 1:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 8/21/12 8:14 AM, Marvin Humphrey wrote:
 *   I could not find a version control tag for 3.4.1-rc2, but I was
 able to obtain the AOO34 branch at the specified revision 1372282; it was
 close, though seemingly not exact.  The discrepancies are shown below.
 I don't believe this should block, but it would be nice to know why the

 I can explain this because I prepared the source release. The binaries
 (MacOS) and the first build of the src release were made on clean source
 tree based on revision r1372282.

 After this I analyzed a potential further bugfix on the same tree. I
 made some debug output in 3 cxx files. But after deeper analysis we
 decided that we don't want include this fix in 3.4.1. The risk to break
 something else was to high and we postponed the fix to the next release.

 After this we recognize some problems with the RAT output. I deleted
 some svn generated *.rej files and built the src package again to clean
 up the RAT output. It seems that I have overseen the debug messages in
 the changed cxx files.

 I can easy repackage the src release on the same tree where I revert the
 local changes to revision 1372282.

 If we all agree I can easy exchange the src release packages with the
 new ones.

Thank you for the thorough explanation.  If I have understood you correctly,
all files flagged by either RAT or by the check against the svn export of
revision 1372282 have been accounted for and we have sufficient rights to
distribute them.  That being the case, in my view it is not necessary to roll
a new RC.

+1 to release.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 11:01 AM, Marvin Humphrey
mar...@rectangular.com wrote:
 On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote:

 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.

 When the option to be fair exists, fair is great!

 With regards to my own vote, I'm going to try to apply Jukka's criteria on
 rights:

 http://markmail.org/message/jtj27kdlhvgocexg

 Personally I'm fine with things like missing license headers or partially
 incomplete license metadata (which sounds like is the case here), as long
 as those are just omissions that don't fundamentally affect our rights (or
 those of downstream users) to distribute the releases and as long as
 there's a commitment to fix such issues in time for the next release.

 Extraneous information in the NOTICE file imposes a burden on some downstream
 distributors and consumers.  Thee is almost certainly room for improvement in
 the AOO NOTICE file, and we have made some progress towards a consensus on
 exactly what ought to be in NOTICE since the first incubating release of AOO
 -- though there is also considerable room for improvement in the ASF
 documentation with regards to NOTICE.  :)

 However, is there anything about the NOTICE file in this AOO release candidate
 which affects _rights_, either our own or those of downstream users?  I've
 looked through the file, and if that's the case, I don't see it.  If sebb
 thinks a respin is merited, that's his call, and his review is a welcome
 contribution.  However, considering how much effort it takes to spin up an AOO
 release, the good faith and substantial effort invested by the podling in
 assembling the NOTICE file in the first place, and the good record of the AOO
 podling in incorporating suggestions, my opinion is that a promise to
 incorporate any NOTICE revisions into trunk suffices and that a new RC is not
 required.

 In contrast, I am more concerned about extra files that were apparently
 inadvertently committed and were not caught by either the primary mechanism of
 PPMC members watching the commits list or by the last line of defense of
 running a RAT report prior to rolling the release.  If files which are

I did check on these JAR files, to see how they got into Subversion in
the first place.  They were checked in as part of the legacy project
and brought over when we did the original svndump import of the
project last June.  So it would not have been found looking at commit
logs.

But you are right that this should have been found during the IP
review and preparation of the AOO 3.4.0 release.

I think the main error was in believing that since this was a minor
maintenance release, with only a handful of carefully reviewed
patches, and that since AOO 3.4.0 was thoroughly reviewed and
approved, that we could concentrate our effort on reviewing the delta
between the two releases.  Of course, if we do this we'll never find
pre-existing errors, and it is clear now that they can exist as well.

What's the old saying?  Every new class of users finds a new class of bugs.

Regards,

-Rob

 incompatible with our licensing end up in a distribution, that has the
 potential to affect _rights_.  And what with AOO's history, there is a big
 target painted on the project and there is a conspicuous need to maintain
 absolute control over what ends up in releases.

 It looks like the late audit has revealed that those files are OK, but it
 feels like we might have dodged a bullet.

 Marvin Humphrey

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On 8/21/12 5:10 PM, Marvin Humphrey wrote:
 On Tue, Aug 21, 2012 at 1:11 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 8/21/12 8:14 AM, Marvin Humphrey wrote:
 *   I could not find a version control tag for 3.4.1-rc2, but I was
 able to obtain the AOO34 branch at the specified revision 1372282; it 
 was
 close, though seemingly not exact.  The discrepancies are shown below.
 I don't believe this should block, but it would be nice to know why the

 I can explain this because I prepared the source release. The binaries
 (MacOS) and the first build of the src release were made on clean source
 tree based on revision r1372282.

 After this I analyzed a potential further bugfix on the same tree. I
 made some debug output in 3 cxx files. But after deeper analysis we
 decided that we don't want include this fix in 3.4.1. The risk to break
 something else was to high and we postponed the fix to the next release.

 After this we recognize some problems with the RAT output. I deleted
 some svn generated *.rej files and built the src package again to clean
 up the RAT output. It seems that I have overseen the debug messages in
 the changed cxx files.

 I can easy repackage the src release on the same tree where I revert the
 local changes to revision 1372282.

 If we all agree I can easy exchange the src release packages with the
 new ones.
 
 Thank you for the thorough explanation.  If I have understood you correctly,
 all files flagged by either RAT or by the check against the svn export of
 revision 1372282 have been accounted for and we have sufficient rights to
 distribute them.  That being the case, in my view it is not necessary to roll
 a new RC.

exactly that is my understanding when I checked the sources. We always
try to address concerns immediately. But we are also humans and no
machines and can make errors or can oversee things. But as mentioned
before we are happy to incorporate any kind of valuable feedback.

The more detaield the feedback is and potential concerns are the better
it is. And of course it is much easier to change things accordingly. We
are still learning.

 
 +1 to release.

Thanks

Juergen


 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.

To be clear: Branko is an IPMC mentor, and not part of the AOO community.

And I do happen to agree with Benson (else-thread) that any NOTICE
problems here do not require a respin.

Cheers,
-g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

2012-08-21 Thread Dave Fisher


On Aug 21, 2012, at 8:01 AM, Marvin Humphrey wrote:

 On Tue, Aug 21, 2012 at 4:59 AM, Branko Čibej br...@apache.org wrote:
 
 It is fair to require changes for the next release. It's not fair to use
 different criteria for two successive, essentially identical releases.
 
 When the option to be fair exists, fair is great!
 
 With regards to my own vote, I'm going to try to apply Jukka's criteria on
 rights:
 
http://markmail.org/message/jtj27kdlhvgocexg
 
Personally I'm fine with things like missing license headers or partially
incomplete license metadata (which sounds like is the case here), as long
as those are just omissions that don't fundamentally affect our rights (or
those of downstream users) to distribute the releases and as long as
there's a commitment to fix such issues in time for the next release.
 
 Extraneous information in the NOTICE file imposes a burden on some downstream
 distributors and consumers.  Thee is almost certainly room for improvement in
 the AOO NOTICE file, and we have made some progress towards a consensus on
 exactly what ought to be in NOTICE since the first incubating release of AOO
 -- though there is also considerable room for improvement in the ASF
 documentation with regards to NOTICE.  :)
 
 However, is there anything about the NOTICE file in this AOO release candidate
 which affects _rights_, either our own or those of downstream users?  I've
 looked through the file, and if that's the case, I don't see it.  If sebb
 thinks a respin is merited, that's his call, and his review is a welcome
 contribution.  However, considering how much effort it takes to spin up an AOO
 release, the good faith and substantial effort invested by the podling in
 assembling the NOTICE file in the first place, and the good record of the AOO
 podling in incorporating suggestions, my opinion is that a promise to
 incorporate any NOTICE revisions into trunk suffices and that a new RC is not
 required.

Thanks.

 In contrast, I am more concerned about extra files that were apparently
 inadvertently committed and were not caught by either the primary mechanism of
 PPMC members watching the commits list

Checking three of these jars - there were all part of the initial svn commit - 
r1162288 - Initial import of the old OOo hg repository tip revision.

 or by the last line of defense of
 running a RAT report prior to rolling the release.  If files which are
 incompatible with our licensing end up in a distribution, that has the
 potential to affect _rights_.  And what with AOO's history, there is a big
 target painted on the project and there is a conspicuous need to maintain
 absolute control over what ends up in releases.

Thanks for your answer to Jürgen and your +1 to release.

 It looks like the late audit has revealed that those files are OK, but it
 feels like we might have dodged a bullet.

Yes, but the shotgun was loaded with salt, so it just stings a little ;-)

Regards,
Dave

 
 Marvin Humphrey
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

On Tue, Aug 21, 2012 at 11:26 AM, Greg Stein gst...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz twgo...@gmx.de wrote:
 On 21/08/12 13:59, Branko Čibej wrote:
 On 21.08.2012 12:52, sebb wrote:
 I think the NOTICE problems are serious enough to warrant a respin.

 This is an unreasonable request. The IPMC voted on the 3.4.0 release.
 The notice file has not changed between 3.4.0 and 3.4.1. How then do you
 justify this new requirement?

 Let me offer some advice from somebody who has been where you
 are now.

 To be clear: Branko is an IPMC mentor, and not part of the AOO community.

Oops. I meant IPMC *member*. (and an ASF Member for a couple years)


 And I do happen to agree with Benson (else-thread) that any NOTICE
 problems here do not require a respin.

 Cheers,
 -g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

The vote period for releasing Apache OpenOffice 3.4.1 (incubating) RC2
has concluded.

The ballot passed.

VOTE TALLY

+1:

IPMC members:

+1 Marvin Humphrey
+1 Dave Fisher
+1 Jim Jagielski

For reference see also the vote thread on ooo-dev

http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C5031F593.9010801%40gmail.com%3E

Thank you for your support

Juergen



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT][VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2