Re: Shepherd notes for ODF Toolkit

[Rob Weir]

On Wednesday, September 2, 2015, John D. Ament <johndam...@apache.org>
wrote:

> All,
>
> I'm adding some shepherd notes for ODF Toolkit.  I think my main concern is
> lack of mentor participation on the project.  Rob Weir (I swear every time
> I type his name I type the d) has taken a mentor role on the project, but
> doesn't seem to be in podlings.xml.  I'm not too worried about this, but
> can we add him to podlings.xml (if so, I'll add him)?
>

I added this yesterday. Thanks for pointing it out.



> It may help the project to bring in an extra mentor, I'd like to volunteer
> to help out to get things moving but wanted to get input from the incubator
> and the podling on their thoughts.  If there are others who are interested
> it may help to look at all options.


Having more than one active mentor is always a good idea, so there is
coverage in case one is temporarily unavailable due to travel or whatever.


Regards,

-Rob


>
> John
>

Re: ODF Toolkit may need help

[Rob Weir]

On Wed, Sep 2, 2015 at 6:25 AM, John D. Ament  wrote:
> All,
>
> I'd like to bring to your attention the ODF Toolkit podling.
>
> This podling has been incubating for over 4 years now.  Last month they
> filed a report without mentor sign off, without any feedback on the mailing
> list.  They have remained partially active throughout the 4 years, but from
> what I can tell suffering a bit in community growth.  I'd like to seek
> input from the incubator on how to potentially resolve this and maybe get
> help for this podling.
>
> John


I am the mentor who did not sign off last month.  You may have noticed
that the podling has been filing nearly identical reports for some
time now.   I'd sum up accomplishments to date as:

1) We've done a few podling releases.

2) IP review is in good shape

3) Community gets along well, no significant frictions

4) Community has added new committers outside the original PPMC, but
has also lost its original corporate-sponsored developers.

5) The code is being used, as seen by incoming traffic on users list
and occasional patch submissions

These are all good steps towards graduation.  However, the community
thinks, and I tend to agree, that the activity level is too low to
sustain a TLP.   If we were able to attract another 2 or 3 active
developers we would be in great shape.  As mentor I've given advice
when asked, and when I thought needed.  But I'm not standing there
with a whip and a megaphone telling them what to do.   I don't think
that makes a sustainable community.

I don't think shuffling the code around within Apache, to another
project (or Podling) really solves anything.  The Attic is one option,
but my guess is that would end the podling but not the (albeit small)
community.  They would probably just set up on github and continue
with the same pace of activity, with a lighterweight process, outside
of Apache.  So, personally, I don't think the Attic would be the death
of the ODF Toolkit.

Regards,

-Rob

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

Re: [VOTE] accept corinthia into incubator

[Rob Weir]

 Please vote
 +1 for accepting corinthia into incubator
 0 for dont care
 -1 for not accepting corinthia into incubator (please add a reason).


+1 (binding)

.
.
.
 == Initial Goals ==

 The initial and most important goal is to enlarge the community consisting
 of developers, testers, and people who know the standards in depth.


That sounds about right.   I think that attracting more users of the
code could help with this as well.

Regards,

-Rob

.
.
.
 The project is aware that this is work in progress and there is special

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

Re: Wiki Access

[Rob Weir]

On Tue, Jul 8, 2014 at 5:11 AM, Svante Schubert
svante.schub...@gmail.com wrote:
 Hi,

 I'm a developer and an incubator PMC member and desire access to the 
 incubator Wiki.

 Can somebody please give me (user svanteschubert) access to the Wiki (in 
 particular the incubator report [1]) so I am able to fill in the Apache ODF 
 Toolkit project podling report?


Anyone?

Thanks!

-Rob


 Thanks,
 Svante

 1. https://wiki.apache.org/incubator/July2014


 -
 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 ODF Toolkit 0.6.1-incubating

[Rob Weir]

On Wed, Jun 25, 2014 at 10:42 AM, Nick Burch apa...@gagravarr.org wrote:
 On Thu, 26 Jun 2014, Justin Mclean wrote:

 This VOTE has now been going on for more than a month. Anyone able to help
 out here?


 I thought the vote had passed?


Yes.  The [VOTE][RESULT] post is here:

http://markmail.org/message/yuentl3tzc3o3i3v

Regards,

-Rob

 Only there was a release announcement about 3 weeks ago for
 0.6.1-incubating:
 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201406.mbox/%3CCAP-ksogYbfCPx%2B7cfp6GEM%2BkOXa-xeT3rE6cdqnc7NzNjNmSkQ%40mail.gmail.com%3E

 Nick


 -
 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: [DISCUSS] Incubator exit criteria

[Rob Weir]

On Tue, Jun 24, 2014 at 9:57 AM, Upayavira u...@odoko.co.uk wrote:


 On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote:
 On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote:

  On Thu, Jun 19, 2014 at 6:22 AM, Christian Grobmeier
  grobme...@gmail.com wrote:
  I think its not enough to just look at release / committer additions.
 
  In the case of Wave, there was a committer addition in the past year.
  Still
  no commits, nor a release. Looking closer you would find that
  committer was
  added because there was some excitement around at that time, with a
  lot of
  plans.
  But then people were facing simply too much work for a small team,
  and
  the motivation then stopped. A deadline wouldn't not help to get out
  a
  release.
 
  That being said, I would like to re-suggest my initial thought with
  one
  modification:
 
  - no new committer for a year
  - AND no release for a year
  - AND less than 20 emails in a month on dev@
  - AND less than 10 commits/jira modifications in a month
  - AND no way to change this in the next three months (in example:
  hackathon
  on horizon)
 
  Here's my personal struggle with two of the items on this list:
  - AND less than 20 emails in a month on dev@
  - AND less than 10 commits/jira modifications in a month
  I can't fathom how a community that is that active can't put
  itself to a task of making a release.

 Let's assume the Wave project would have more activity. Maybe lets say
 they are operating with around 20 commits a month. It would be still
 difficult to release the code base within one year, because its really
 complex and
 needs a full refactoring. If we do not weight activity in general in, we
 reduce
 the exit criteria to: how fast can you do a release?

 And: if you don't manage to make a release in the first year - no matter
 how your
 product looks like - you might be thrown out.


  At the ends of the day, the release of an incubating project
  is NOT a glorious exercise in putting the final coat of paint
  on a flawless product. It is rather a very mundane way sharing
  technology with its users community. And after all, growing the
  user community is as important as growing the contributing
  community. It is only fair that IPMC gently reminds PPMC of that.

 I agree, but sometimes it's simply not possible to release.
 Actually, Wave *could* have released something, but nobody wants
 it to look like that.

 Let's assume they would release it now, which would be possible in
 theory.
 Let's say they would get 3 +1 from the PMC, which will be hard already.
 Then you have a released project, but the community is almost inactive.

  Heck, our TLPs practice it (where expectations are arguably
  higher) let alone Incubating projects. Take Hadoop as an
  example -- in order to make Hadoop 2.x successful the
  community decided to put an early alpha releases of
  Hadoop 2.0.x out to share the technology with its users.
  It was exactly the right decisions and ultimately it resulted
  in a much smoother 2.x.y series.

 As to my knowledge, some Hadoop-devs get financial support from
 companies.
 Projects like Ripple, Wave or Log4cxx do not have that financial
 support.
 In most cases, people work on these codebases in their prime time.
 For that reason I don't want to compare company-backed projects with
 prime-time projects.

  In short -- you don't have to make your releases GA. Alpha
  releases are just fine. Still you have to demonstrate that
  you are capable of sharing your work with the user
  community and doing an alpha/beta/gamma/YNH release
  is the only way to do it.

 I know what you mean, but I doubt this alone is a factor we should
 weight for an exit.

 People might struggle with a release but be healthy otherwise.
 People might get a release done, but have no community otherwise.

 That said, reminding people of the release often and early thing is
 good to do,
 but also have in mind that incubator releases are very difficult to
 make.

 Unlike Christian (another Wave mentor :-) ), I am generally in support
 of this proposal. If a project cannot get a release out, then it
 suggests insufficient weight behind it. Releasing software is what the
 ASF is about. It is acceptable that a mature ASF project, one that is
 code-complete, doesn't release regularly, but an incubator project would
 not fall into that camp, therefore being able to say we can muster the
 resources to make a 'legally valid release' within a year seems
 eminently reasonable to me.


I'll offer OpenOffice as an example of how long an initial podling
release can take in some cases, due to a number of factors:

1) Getting the code repository migrated from Mercurial to Subversion
was time consuming

2) The code that was SGA'ed was for a beta release.  It required a lot
of bug fixing before it was ready for GA.

3) The SGA'ed code had a good number of copyleft dependencies that had
to be replaced, as well as other unique things (at the time) that
required review on 

Re: [VOTE][RESULTS] Release Apache ODF Toolkit 0.6.1-incubating

[Rob Weir]

On Thu, May 29, 2014 at 11:51 AM, Marvin Humphrey
mar...@rectangular.com wrote:
 On Thu, May 29, 2014 at 8:29 AM, Rob Weir robw...@apache.org wrote:

 No other votes were received so the release is approved.

 Congratulations, and many thanks to the Apache ODF Toolkit podling for
 sticking it out through this extended cycle.


And thank you for helping us navigate the new alternative release process!

-Rob

 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

[VOTE] Release Apache ODF Toolkit 0.6.1-incubating

[Rob Weir]

RC4 for the ODF Toolkit 0.6.1-incubating release is available at:

http://people.apache.org/~robweir/odftoolkit-release/odftoolkit-0.6.1-incubating/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.1-incubating-RC4/

We're voting on the odftoolkit-0.6.1-incubating-src.zip.

If the vote passes we'll also distribute pre-built binaries and
JavaDoc as a convenience to users.

NOTE:  We're using the alternative voting process, with review check list here:

https://svn.apache.org/repos/asf/incubator/public/trunk/votes/odftoolkit/0.6.1-manifest.txt

The vote is open for at least the next 72 hours and per the
alternative release process both IPMC and PPMC votes are binding:

http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

[ ] +1 Release this package as Apache ODF Toolkit 0.6.1-incubating
[ ] -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

[Proposal] Add me as Mentor for ODF Toolkit Podling

[Rob Weir]

I looked around and did not see a process defined for adding a Mentor
to a podling.  I see how they are added at podling initiation, but not
after.  So apologies if I'm missing something.

It appears that we have at present zero active Mentors, so even with
the experimental release process we're unable to move forward, since
that requires Mentor sign off on the release manifest/checklist.

I am able and willing to help here.

Regards,

-Rob

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

[VOTE][RESULTS] Pre-clear ODF Toolkit Podling to use Alternate Release Voting Process

[Rob Weir]

On Mon, Apr 21, 2014 at 9:15 AM, Rob Weir robw...@apache.org wrote:
 The process is described here:

 http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

 Please vote:

 [ ] +1 Yes, to pre-clear the ODF Toolkit Polding to use the Alternate
 Release Voting Process

 [ ] -1 No, do not pre-clear the ODF Toolkit Polding to use the
 Alternate Release Voting Process


And +1 from me gives:

+1 Rob Weir
+1 Marvin Humphrey
+1 Chip Childers
+1 Jake Farrell
+1 Nick Burch
+1 Dave Brondsema

 5 +1s, and no other votes.  The vote passes.

Thanks!

-Rob


 This majority vote will run for 72 hours.  Votes cast by members of
 the Incubator PMC are binding.

 Regards,

 -Rob

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

[VOTE] Pre-clear ODF Toolkit Podling to use Alternate Release Voting Process

[Rob Weir]

The process is described here:

http://incubator.apache.org/incubation/Incubation_Policy.html#Releases

Please vote:

[ ] +1 Yes, to pre-clear the ODF Toolkit Polding to use the Alternate
Release Voting Process

[ ] -1 No, do not pre-clear the ODF Toolkit Polding to use the
Alternate Release Voting Process

This majority vote will run for 72 hours.  Votes cast by members of
the Incubator PMC are binding.

Regards,

-Rob

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

Re: [DISCUSS] Apache ODF Release situation

[Rob Weir]

On Thu, Apr 3, 2014 at 9:20 PM, Marvin Humphrey mar...@rectangular.com wrote:
 On Mon, Mar 24, 2014 at 7:51 AM, Rob Weir robw...@apache.org wrote:

 I'll upgrade my vote to +1 (binding)

 That gives us two +1's from the IPMC.  Need one more to release.

 I realize many are busy (including me) finishing up ApacheCon slides.
 But if someone else can take a look I'd appreciate it greatly.

 The release vote situation has now also been mentioned in this month's report,
 under Issues for the Board/IPMC.

 Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
 aware of?

   We've been struggling to get 3 +1 IPMC votes for our latest release
   candidate.  We're stuck at two +1 votes.

 How has the community developed since the last report?

   We issued a call for volunteers to our users list and got a good
   response: http://s.apache.org/4Vx

   Of course, it will be easier to grow the community if we can reliably
   conduct a release vote.

 The 2013 Alternative Release Voting Process was drawn up for scenarios like
 this one, allowing podlings to seize control of their destiny rather than
 being locked in to waiting on IPMC members.

 http://incubator.apache.org/guides/release.html
 http://incubator.apache.org/incubation/Incubation_Policy.html#Releases


Thanks.  This looks like a good fit.

One question on interpreting this alternative process.  It says, For
all releases after the first, votes cast by members of the PPMC are
binding if a Mentor approves the Release Manifest.

Do we mean all releases after the first using the alternative process
specifically?  Or after the first release, even if that release was
using the mainline podling release procedure?

(We've already had two podling releases via the normal procedure.)

We (the PPMC) have already discussed proposing me as an additional
Mentor for the Podling, now that I'm on IPMC.  That could help enable
us using the Alternative Release Voting Process.

Regards,

-Rob

 In my estimation, the ODF Toolkit podling has sufficient expertise to
 participate.

 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 ODF Toolkit 0.6.1-incubating

[Rob Weir]

On Wed, Feb 19, 2014 at 9:07 AM, Rob Weir robw...@apache.org wrote:
 We've had a vote within the PPMC which passed:

 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E


 We're now looking for review and approval by the IPMC.

 Regards,

 -Rob

 --

 RC4 for the ODF Toolkit 0.6.1-incubating release is available at:

 http://people.apache.org/~robweir/odftoolkit-release/odftoolkit-0.6.1-incubating/

 The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.1-incubating-RC4/

 We're voting on the odftoolkit-0.6.1-incubating-src.zip.

 Please vote on releasing this package as Apache ODF Toolkit 0.6.1-incubating.

 If the vote passes we'll also distribute pre-built binaries and
 JavaDoc as a convenience to users, as well as publish to Maven.

 The vote is open for the next 72 hours and passes if a majority
 of at least three +1 PMC votes are cast.

 [ ] +1 Release this package as Apache ODF Toolkit 0.6.1-incubating
 [ ] -1 Do not release this package because...

I'll upgrade my vote to +1 (binding)

That gives us two +1's from the IPMC.  Need one more to release.

I realize many are busy (including me) finishing up ApacheCon slides.
But if someone else can take a look I'd appreciate it greatly.

Regards,

-Rob

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

Re: [VOTE] Release Apache ODF Toolkit 0.6.1-incubating

[Rob Weir]

On Wed, Mar 12, 2014 at 1:07 AM, Dave Fisher dave2w...@comcast.net wrote:
 Hi -

 Small nonblocking issues with this release candidate:

 (1) The source should not include the KEYS file.


OK.  Hopefully you saw that we also have the file on the dist server:

https://dist.apache.org/repos/dist/release/incubator/odftoolkit/KEYS


 (2) I have trouble with the build so I could not judge the build. A maven 3 
 build would be nice and it is beiung discussed by the podling.


Right.  We built with Maven 2.  We have an ornery dependency that
doesn't seem to like Maven 3.  Work-in-progress on that.

 (3) I ran manual rat scans using Apache RAT 0.10 without excludes files.
 (a) It would be good to be able to incorporate ODF files into the Apache RAT 
 process

In theory RAT/Creadur could call the ODF Toolkit to search for the
license header.

 (b) nbproject property and xml files in these two directories:
 ./odftoolkit-0.6.1-incubating/xslt-runner/nbproject
 ./odftoolkit-0.6.1-incubating/xslt-runner-task/nbproject


Those are NetBeans IDE files.  We'd need to see if there is a place to
put the license info that would not be over-written each time NetBeans
saves.

If it is the case that these files cannot preserve a license header,
is there another solution, like adding a nbproject-LICENSE file in
the same directory, or something like that?


 These 6 files could have Apache License headers.

 Nothing to block this release.

 +1 (binding IPMC)


Great, thanks!

-Rob

 Regards,
 Dave


 On Mar 5, 2014, at 10:53 AM, Rob Weir wrote:

 On Wed, Mar 5, 2014 at 1:35 PM, Henry Saputra henry.sapu...@gmail.com 
 wrote:
 Hi Rob, the result Vote within PPMC [1] did not indicate mentor Vote.

 Is there any mentor Vote in favor within ODF dev list Vote thread?


 No, there were no votes from mentors.   That's one of our problems,
 lack of active mentors.  We would benefit greatly from one or two.

 We're a small, but diverse, podling with no drama.  We recently did a
 pitch for new developer volunteers and got a good amount of interest.
 But it is hard to follow up on that without the ability to get a
 release examined.

 If any one has been following the recent news in the UK, the
 government there appears close to expressing a mandate for the use of
 OpenDocument Format.  Libraries that can process ODF documents, like
 the ODF Toolkit, will be an important part of supporting widespread
 use of ODF there and in other places.

 If anyone is interested, pleased let us know at odf-...@incubator.apache.org

 Regards,

 -Rob

 Thx,

 - Henry

 [1] 
 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E

 On Wed, Feb 19, 2014 at 6:07 AM, Rob Weir robw...@apache.org wrote:
 We've had a vote within the PPMC which passed:

 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E


 We're now looking for review and approval by the IPMC.

 Regards,

 -Rob

 --

 RC4 for the ODF Toolkit 0.6.1-incubating release is available at:

 http://people.apache.org/~robweir/odftoolkit-release/odftoolkit-0.6.1-incubating/

 The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.1-incubating-RC4/

 We're voting on the odftoolkit-0.6.1-incubating-src.zip.

 Please vote on releasing this package as Apache ODF Toolkit 
 0.6.1-incubating.

 If the vote passes we'll also distribute pre-built binaries and
 JavaDoc as a convenience to users, as well as publish to Maven.

 The vote is open for the next 72 hours and passes if a majority
 of at least three +1 PMC votes are cast.

 [ ] +1 Release this package as Apache ODF Toolkit 0.6.1-incubating
 [ ] -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


 -
 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 ODF Toolkit 0.6.1-incubating

[Rob Weir]

On Wed, Mar 5, 2014 at 1:35 PM, Henry Saputra henry.sapu...@gmail.com wrote:
 Hi Rob, the result Vote within PPMC [1] did not indicate mentor Vote.

 Is there any mentor Vote in favor within ODF dev list Vote thread?


No, there were no votes from mentors.   That's one of our problems,
lack of active mentors.  We would benefit greatly from one or two.

We're a small, but diverse, podling with no drama.  We recently did a
pitch for new developer volunteers and got a good amount of interest.
But it is hard to follow up on that without the ability to get a
release examined.

If any one has been following the recent news in the UK, the
government there appears close to expressing a mandate for the use of
OpenDocument Format.  Libraries that can process ODF documents, like
the ODF Toolkit, will be an important part of supporting widespread
use of ODF there and in other places.

If anyone is interested, pleased let us know at odf-...@incubator.apache.org

Regards,

-Rob

 Thx,

 - Henry

 [1] 
 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E

 On Wed, Feb 19, 2014 at 6:07 AM, Rob Weir robw...@apache.org wrote:
 We've had a vote within the PPMC which passed:

 http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E


 We're now looking for review and approval by the IPMC.

 Regards,

 -Rob

 --

 RC4 for the ODF Toolkit 0.6.1-incubating release is available at:

 http://people.apache.org/~robweir/odftoolkit-release/odftoolkit-0.6.1-incubating/

 The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.1-incubating-RC4/

 We're voting on the odftoolkit-0.6.1-incubating-src.zip.

 Please vote on releasing this package as Apache ODF Toolkit 0.6.1-incubating.

 If the vote passes we'll also distribute pre-built binaries and
 JavaDoc as a convenience to users, as well as publish to Maven.

 The vote is open for the next 72 hours and passes if a majority
 of at least three +1 PMC votes are cast.

 [ ] +1 Release this package as Apache ODF Toolkit 0.6.1-incubating
 [ ] -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


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

[VOTE] Release Apache ODF Toolkit 0.6.1-incubating

[Rob Weir]

We've had a vote within the PPMC which passed:

http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201402.mbox/%3CCAP-ksogUFy-OkDkdJcNYDjnn8wUf%3DxcJX%2BG2xxQLKzp5PGKEgA%40mail.gmail.com%3E


We're now looking for review and approval by the IPMC.

Regards,

-Rob

--

RC4 for the ODF Toolkit 0.6.1-incubating release is available at:

http://people.apache.org/~robweir/odftoolkit-release/odftoolkit-0.6.1-incubating/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.6.1-incubating-RC4/

We're voting on the odftoolkit-0.6.1-incubating-src.zip.

Please vote on releasing this package as Apache ODF Toolkit 0.6.1-incubating.

If the vote passes we'll also distribute pre-built binaries and
JavaDoc as a convenience to users, as well as publish to Maven.

The vote is open for the next 72 hours and passes if a majority
of at least three +1 PMC votes are cast.

[ ] +1 Release this package as Apache ODF Toolkit 0.6.1-incubating
[ ] -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 ODF Toolkit 0.6-incubating(RC5)

[Rob Weir]

On Tue, May 21, 2013 at 1:56 AM, Florian Hopf
mailingli...@florian-hopf.de wrote:
 Hi Joe,

 thanks for your feedback. This is my first release and only the second
 release of the Odftoolkit so I am glad to get some guidance on things we
 missed so far.


 On 18.05.2013 20:41, Joe Brockmeier wrote:

 On Sun, May 12, 2013, at 09:17 AM, Florian Hopf wrote:

 RC 5 of the ODF Toolkit 0.6-incubating is ready for release. This
 release candidate addresses missing licenses and the disclaimer that
 have been identified during the last IPMC vote.


 Which of the artifacts are we meant to be voting on? We have three
 source choices (tar.bz2, tar.gz, zip) - and ideally we'd be testing
 *all* of these to verify that they're the same. Why not distribute just
 one tarball?

 I'm OK with convenience binaries, but I really don't think it's a good
 idea to put them in the same directory as the source artifacts you want
 voted on.


 Ok, I will put the binaries separately and only add the source zip.


I wonder if it would be good to publish just three files:  one each of
source, doc and binaries?  Just do them all as .zip (which is
available on all platforms).  It would make release verification a
little easier.



 Also, I can't +1 this because the signature of the distributed artifact
 does not match the KEYS file in your dist directory.

 Your dist directory has this KEYS file:

 http://www.apache.org/dist/incubator/odftoolkit/KEYS

 Which only has Devin Han's key. You're distributing a KEYS file with
 your own key, but obviously we're not going to trust a KEYS file that is
 distributed with the source tarball itself.

 You need to upload your new KEYS file and point to it in your email
 asking for votes. Could you please re-roll this and start a new VOTE?


 Thanks, so far I got the impression that the most important place to put my
 key is at https://people.apache.org/keys/committer/
 I am not sure yet how to upload files to the dist folder but I'll figure
 that out.

 As those changes don't require any changes to the source tree I think we
 don't need to vote on the dev-list again but only on the incubator list?


Maybe have the votes in parallel, at the same time?

-Rob

 Thanks

 Florian


 --
 Florian Hopf
 Freelance Software Developer

 http://blog.florian-hopf.de

 -
 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 ODF Toolkit 0.6-incubating(RC4)

[Rob Weir]

On Thu, May 2, 2013 at 4:41 AM, sebb seb...@gmail.com wrote:
 On 2 May 2013 07:04, Florian Hopf mailingli...@florian-hopf.de wrote:

 Hi all,

 The ODF Toolkit 0.6 is ready for release.

 We had a successful vote in the PPMC. The PPMC vote result is here:
 http://markmail.org/message/**fqikz72pys4qr7pahttp://markmail.org/message/fqikz72pys4qr7pa

 We need three more IPMC votes to pass.

 Please vote on releasing the following candidate as Apache ODF Toolkit
 (incubating) version 0.6.

 http://people.apache.org/~**fhopf/odftoolkit-release/0.6-**incubating-rc4/http://people.apache.org/~fhopf/odftoolkit-release/0.6-incubating-rc4/

 The SHA1 checksum of the archive zip source is
 000e25c3b6baf4099e067c8d93cea3**636a24ddfd

 The SHA1 checksum of the archive zip binary is
 f505f7c607098cdd77797417485584**49918b0b45

 The changes can be found at here:

 https://svn.apache.org/repos/**asf/incubator/odf/tags/0.6-**
 incubating-rc4/CHANGES.txthttps://svn.apache.org/repos/asf/incubator/odf/tags/0.6-incubating-rc4/CHANGES.txt


 Where is the SVN/GIT tag?


https://svn.apache.org/repos/asf/incubator/odf/tags/0.6-incubating-rc4/

-Rob

 The source code repo is needed to check provenance.



 The vote is open for 72 hours, or until we get the needed number of votes
 (3 +1).

   [ ] +1 Release this package as Apache ODF Toolkit 0.5-incubating
   [ ] -1 Do not release this package because...

 To learn more about Apache ODF Toolkit, please visit
 http://incubator.apache.org/**odftoolkit/http://incubator.apache.org/odftoolkit/
 .

 Regards
 Florian

 --**--**-
 To unsubscribe, e-mail: 
 general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org
 For additional commands, e-mail: 
 general-help@incubator.apache.**orggeneral-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 cTAKES 3.0.0-incubating RC5 release

[Rob Weir]

On Sat, Jan 26, 2013 at 4:23 AM, Andrea Pescetti pesce...@apache.org wrote:
 On 25/01/2013 Benson Margulies wrote:

 On Fri, Jan 25, 2013 at 3:04 AM, Mattmann, Chris A (388J)

 What about Apache OpenOffice?

 I asked this question about Open Office, and I got, more or less, what
 I typed in above. I was puzzled, but there you have it. As I recall,
 Roy made a remark like 'our real users are people who will take the
 source of Open Office ...'.


 This is not exactly the way the OpenOffice project sees this. We are voting
 on a release right now, and of course we put great care in ensuring that the
 source code is clean and that it can be used by our downstream projects to
 build upon; but we also make extensive tests on the convenience binaries,
 since we know that our largest group of users is the 35 millions and
 counting who already downloaded the approved binaries.


Who the real users are is an empirical question, and it does a
disservice to introduce a false dichotomy between end users of the
convenience binaries and developers who work on the core C++ code.
We have in OpenOffice a large group of developers who use the SDK to
develop extensions 3rd party extensions to OpenOffice.  They've
created around 700 such extensions.  The most popular ones have
thousands of downloads per week.   That is a thriving part of the
ecosystem.

This might not fit a 1999 view of how open source is consumed by an
ecosystem, but in 2013 any product that can only be enhanced by
modifying 20 year old C++ code is stunting its own ecosystem  The fact
that 3rd party value is created more in extensions than core C++ code
modifications is a very good thing from an engineering perspective.
For example it allows end-users to mix and match extensions from
different vendors.  This did not happen by accident.  This was a
design goal.  In any case, I think it is deserving of more recognition
at Apache that ecosystems do not always require compiled code and core
code modifications to exist, and there are indeed real users in this
ecosystem who thrive on such extensions.

Regards,

-Rob


 Regards,
   Andrea.


 -
 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: Preparing for the October reports

[Rob Weir]

On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 Thanks for the reviews, Benson! I added you as a signer-off on these reports.

 As reported and discussed, Kafka remains ready to graduate and will
 hopefully complete that transition shortly.

 On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 ODFToolkit, on the other hand, seems to have a metadata problem. It
 shows no total committers and one new committer. Does anyone
 understand that? Otherwise, all their boxes are green.

 Any thoughts on this from mentors or committers of the project?


Well, here is our status page:

http://incubator.apache.org/projects/odftoolkit.html

It lists both committers and mentors, including new committers.   It
needs an update, since we just voted in a new committer/PPMC member
last week, but I don't see what a problem here.

Where are you seeing no total committers ???

 How should we categorize the status of ODF Toolkit? In June we
 classified the podling under low activty due to the low commit counts.
 That figure and those of list activity look a bit better now, though
 it's hard to tell how much of that is just temporary improvement from
 the GSoC work.


GSoC did not bring any lasting contributors.  But we've had a step up
in recent activity from other contributors, not related to the GSoC
work. So I think that part is looking good, and we're successfully
overcoming the loss of one of the main contributors earlier in the
year, the source of our low activity rate at the time.

As we say in the report, if we can bring a couple more committers on
board, and get out a 2nd release, we think we'll be ready to graduate.

 Like in June, there were no mentor sign-offs on the ODF Toolkit report
 and I see little mentor activity on odf-dev@. Do we need more/new
 mentors for the project?


An additional pair of eyes on the podling is always welcome.

Regards,

-Rob

 BR,

 Jukka Zitting

 -
 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: Preparing for the October reports

[Rob Weir]

On Thu, Oct 11, 2012 at 3:53 PM, Benson Margulies bimargul...@gmail.com wrote:
 On Thu, Oct 11, 2012 at 3:38 PM, Rob Weir robw...@apache.org wrote:
 On Wed, Oct 10, 2012 at 7:21 PM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 Hi,

 Thanks for the reviews, Benson! I added you as a signer-off on these 
 reports.

 As reported and discussed, Kafka remains ready to graduate and will
 hopefully complete that transition shortly.

 On Fri, Oct 5, 2012 at 3:19 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
 ODFToolkit, on the other hand, seems to have a metadata problem. It
 shows no total committers and one new committer. Does anyone
 understand that? Otherwise, all their boxes are green.

 Any thoughts on this from mentors or committers of the project?


 Well, here is our status page:

 http://incubator.apache.org/projects/odftoolkit.html

 It lists both committers and mentors, including new committers.   It
 needs an update, since we just voted in a new committer/PPMC member
 last week, but I don't see what a problem here.

 Where are you seeing no total committers ???

 incubator.apache.org/clutch


Hmmm. another clue is here:  http://people.apache.org/committer-index.html

We don't seem to exist.  Our committers are listed as being in
incubator not there is no odf project here.  But we obviously have
karma for SVN.  But something is not right.

-Rob




 How should we categorize the status of ODF Toolkit? In June we
 classified the podling under low activty due to the low commit counts.
 That figure and those of list activity look a bit better now, though
 it's hard to tell how much of that is just temporary improvement from
 the GSoC work.


 GSoC did not bring any lasting contributors.  But we've had a step up
 in recent activity from other contributors, not related to the GSoC
 work. So I think that part is looking good, and we're successfully
 overcoming the loss of one of the main contributors earlier in the
 year, the source of our low activity rate at the time.

 As we say in the report, if we can bring a couple more committers on
 board, and get out a 2nd release, we think we'll be ready to graduate.

 Like in June, there were no mentor sign-offs on the ODF Toolkit report
 and I see little mentor activity on odf-dev@. Do we need more/new
 mentors for the project?


 An additional pair of eyes on the podling is always welcome.

 Regards,

 -Rob

 BR,

 Jukka Zitting

 -
 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] [PMC] Starting Membership for Apache OpenOffice PMC

[Rob Weir]

On Mon, Oct 1, 2012 at 8:00 PM, Benson Margulies bimargul...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 7:58 PM, Dave Fisher dave2w...@comcast.net wrote:
 FYI - This is being done in public!


 Who or what is an RGB.ES? Don't PMC members have to disclose an identity?


All committers must disclosure their identity, in their iCLA [1].  But
the form also allows them (optionally) to indicate an additional
public name,  essentially a pseudonym they use on the mailing lists,
etc.

-Rob


[1] http://www.apache.org/licenses/icla.txt

 Regards,
 Dave

 Begin forwarded message:

 From: Andrew Rist andrew.r...@oracle.com
 Date: October 1, 2012 3:38:03 PM PDT
 To: ooo-...@incubator.apache.org
 Subject: [VOTE] [PMC] Starting Membership for Apache OpenOffice PMC
 Reply-To: ooo-...@incubator.apache.org
 delivered-to: mailing list ooo-...@incubator.apache.org

 This is a call for vote on selecting the following list as the starting 
 membership for the Apache OpenOffice PMC, to be listed in the TLP 
 resolution.  The voting is for the entire slate as listed.

   Apache OpenOffice PMC Starting Membership:
   Andre Fischer (af)
   Andrea Pescetti (pescetti)
   Andrew Rist (arist)
   Ariel Constenla-Haile (arielch)
   Armin Le Grand (alg)
   Dave Fisher (wave)
   Donald Harbison (dpharbison)
   Drew Jensen (atjensen)
   Ian Lynch (ingotian)
   Jürgen Schmidt (jsc)
   Kay Schenk (kschenk)
   Kazunari Hirano (khirano)
   Louis Suarez-Potts (louis)
   Marcus Lange (marcus)
   Oliver-Rainer Wittmann (orw)
   Pedro Giffuni (pfg)
   Peter Junge (pj)
   Raphael Bircher (rbircher)
   Regina Henschel (regina)
   RGB.ES (rgb-es)
   Roberto Galoppini (galoppini)
   Yang Shih-Ching (imacat)
   Yong Lin Ma (mayongl)


 The balloting will be until UTC midnight Thursday,
   4 October: 2012-10-04T24:00Z.

   Approval requires a majority of +1 over -1 votes cast by members of the 
 PPMC.

[  ] +1 approve
[  ]  0 abstain
[  ] -1 disapprove, for the following reasons:


   The [DISCUSS] for this vote was enthusiastically in favor. There were no 
 concerns expressed other than issues with the timeframe of discussions, 
 which were suitably extended.  (note: All members of this list, except for 
 Drew and Raphael, accepted their nomination to this list.  I have left Drew 
 and Raphael on the list as neither declined, and they still have the 
 ability to decline later)





 -
 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

[Rob Weir]

On Mon, Aug 27, 2012 at 8:59 AM, Jim Jagielski j...@jagunet.com wrote:

 On Aug 27, 2012, at 8:56 AM, donald_harbi...@us.ibm.com wrote:

 Yes, that's what end users care about. But it's not sufficient for AOO
 since we are seeking alternative distribution channels.

 What does that mean? Can I grok alternative distribution channels
 as more mirrors or something else?


You probably don't see this on the server yet, but end-user operating
systems, both desktop and devices, both at OS level as well as in
browsers and with antivirus software, are shifting over to excluding
non-signed executable by default.  This is equally true of software
distributed on CD's, via downloads, or listed in OS-vendor stores.
 That is the direction that the industry is going.  Any desktop
application that ignores this trend will become unusable by most
users.  Instead of detached digital signatures that Apache releases
already carry, the OS vendors expect integrated signatures via code
signing.

Where I hear the churning is over whether the technological change -
code signing rather than detached PGP/GPG signatures -- means anything
different from a liability standpoint.  One could argue that a
signatures merely vouches for authentication, integrity and
non-repudiation -- the classic guarantees of a digital signature.  But
I'm hearing others suggest that the move from one technology to
another technology for signing suggests additional guarantees about
the content of the signed artifact, above and beyond what the ASF
normally offers.  But of course, any additional liability is
explicitly disclaimed by the Apache License.

So given that other Apache projects distribute binaries that are

1) approved by the PMC's

2) distributed on Apache mirrors

3) linked to as ASF products by project websites

4) accompanied by PGP/GPG detached signatures

...what additional liability do we believe comes from the
technological change from one signature mechanism to another?   Or
specifically, what liability is added that is not already explicitly
disclaimed by ALv2?

-Rob

 -
 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

[Rob Weir]

On Mon, Aug 27, 2012 at 8:56 AM,  donald_harbi...@us.ibm.com wrote:
 Jim Jagielski j...@jagunet.com wrote on 08/27/2012 08:43:35 AM:

 From: Jim Jagielski j...@jagunet.com
 To: general@incubator.apache.org, Joe Schaefer
 joe_schae...@yahoo.com, Rob Weir robw...@apache.org,
 Cc: ooo-...@incubator.apache.org ooo-...@incubator.apache.org
 Date: 08/27/2012 08:44 AM
 Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote


 On Aug 26, 2012, at 10:26 AM, Joe Schaefer joe_schae...@yahoo.com
 wrote:

  No.  There is NO WAY IN HELL the org can indemnify
  a volunteer who produces a binary build themselves.
 
  Please don't bother asking legal-discuss to tackle this.
 

 Here's an analogy: for a long, long time Bill Rowe has taken
 it upon himself to create binary builds of Apache httpd for
 the large Windows community. Netware binary builds are also
 occasionally released (see http://httpd.apache.org/download.cgi).

 These are available right from the official httpd download
 page and located right next to the official source code,
 yet they are artifacts NOT released (officially) by the
 ASF or the httpd PMC, but are available from a trusted
 source.

 Isn't that all the end-user cares about? And isn't that
 sufficient for AOO?

 Yes, that's what end users care about. But it's not sufficient for AOO
 since we are seeking alternative distribution channels. Effort to
 exponentially expand distribution channels require code signing. These
 discussions were started on legal@ with no resolution. Sorry I don't have
 the reference for that handy.


Can't we just get a signing certificate that says ASF unofficial
convenience binary or similar language?  This gives us (and more
importantly our users) the desired authentication and integrity
protections of a digital signature, without implying any additional
status.

-Rob



 -
 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

[Rob Weir]

On Mon, Aug 27, 2012 at 7:10 AM, Greg Stein gst...@gmail.com wrote:
 On Aug 27, 2012 6:15 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:

 Hi,

 I'm jumping in late to this discussion after returning from vacation.
 To summarize my understanding:

 * As Joe says, there's no problem with current OpenOffice releases.

 Agreed.

 * The project is looking for ways to produce blessed binaries as a
 part of future releases, and has been working with the relevant
 parties (infra, legal, etc.) on the implications.

 I have not seen this, especially in regards to this thread. Argument is
 occurring on this list instead.


You should take a look at infra-dev@ where Infra, AOO members as well
as members of other Apache projects interested in digital signatures,
have been discussing code signing requirements and ways of providing a
code signing capability.

 * I trust that the project is capable of continuing that work and
 abiding with whatever conclusion also as after graduation.

 Fair enough, but I do not share that trust. I fear the project claiming
 unique difference, and damaging the Foundation, rather than an
 understanding of how we can solve our mission together. I believe AOO has
 unique characteristics and that the ASF needs to adapt, but I do not
 believe the community cares to properly see through those changes. I see
 self-righteous bullying instead.


I agree that this thread has not been productive.  But you really
should check the discussions on infra-dev@ before making statements on
whether we know how to work with other parts of the ASF.

 The ASF and the people that make us what we are, are not perfect. We don't
 know everything. But we *do* deserve consideration to make things Right.
 AOO is an awesome opportunity or us all, and we should do what we can for
 their success. It must happen with an old, and with a new, community
 working together.


Again, look at the discussions on infra-dev.  Your constructive input
is most welcome on those threads.  Ditto for any one else.

-Rob

 Cheers,
 -g

-
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

[Rob Weir]

On Mon, Aug 27, 2012 at 9:57 AM, Jim Jagielski j...@jagunet.com wrote:
 Re adding ooo-dev@ since this is STILL an AOO issue.

 On Aug 27, 2012, at 9:38 AM, Rob Weir robw...@apache.org wrote:

 On Mon, Aug 27, 2012 at 8:59 AM, Jim Jagielski j...@jagunet.com wrote:

 On Aug 27, 2012, at 8:56 AM, donald_harbi...@us.ibm.com wrote:

 Yes, that's what end users care about. But it's not sufficient for AOO
 since we are seeking alternative distribution channels.

 What does that mean? Can I grok alternative distribution channels
 as more mirrors or something else?


 You probably don't see this on the server yet, but end-user operating
 systems, both desktop and devices, both at OS level as well as in
 browsers and with antivirus software, are shifting over to excluding
 non-signed executable by default.

 Believe it or not, I actually use end-user OSs. I am right now! Wow!


I did not mean to imply otherwise.  But I am quite confident that few,
if any other Apache projects are developing end-user software, so they
might not be aware of this trend from the software development
perspective.

  This is equally true of software
 distributed on CD's, via downloads, or listed in OS-vendor stores.
 That is the direction that the industry is going.  Any desktop
 application that ignores this trend will become unusable by most
 users.  Instead of detached digital signatures that Apache releases
 already carry, the OS vendors expect integrated signatures via code
 signing.

 Where I hear the churning is over whether the technological change -
 code signing rather than detached PGP/GPG signatures -- means anything
 different from a liability standpoint.  One could argue that a
 signatures merely vouches for authentication, integrity and
 non-repudiation -- the classic guarantees of a digital signature.  But
 I'm hearing others suggest that the move from one technology to
 another technology for signing suggests additional guarantees about
 the content of the signed artifact, above and beyond what the ASF
 normally offers.  But of course, any additional liability is
 explicitly disclaimed by the Apache License.

 So given that other Apache projects distribute binaries that are

 1) approved by the PMC's

 2) distributed on Apache mirrors

 3) linked to as ASF products by project websites

 4) accompanied by PGP/GPG detached signatures

 ...what additional liability do we believe comes from the
 technological change from one signature mechanism to another?   Or
 specifically, what liability is added that is not already explicitly
 disclaimed by ALv2?


 A signature does 2 things:

   1. Ensures that no bits have been changed
   2. That the bits come from a known (and trusted) entity.


Almost.  It doesn't guarantee trust.  CA's don't require any specific
level of software quality assurance before they issue a certificate.
Any trust is implied by association with the identity of the signer.
So it is a brand association.  This is similar to the association that
comes with association with a project's release announcement, or from
distribution via Apache mirrors, or links from Apache websites.  These
all imply -- in one degree or another -- an association with Apache,
and the trust that flows from that.

But what code signing does do is help protect ASF reputation.  By
having the binaries signed we can distance ourselves from those who
distribute versions of AOO with virus and malware attached.  Again,
this is something you probably don't see in the server world, but it
is quite common with popular end-user open source software.

So trust (reputation) is important.  But we're already seeing that
trust and reputation can be hurt by lack of code signing.

 The fact that we've used GPG-signed artifacts is immaterial, imo.


To a savvy user the use of the detached digital signature can provide
exactly the same assurances that code signing would do.  Exactly the
same thing.  It just happens to be that the industry has moved toward
a CA model rather than a web of trust model.


 But recall in all this that even when the PMC releases code, it is
 signed by the individual RM, and not by the PMC itself.


Correct.  But the concerns in the thread were about individual
liability.  Having an individual signature (whether GPG/PGP or
Authenticode) certainly doesn't make the story any better.

So I wonder if the best solution here is to make it clear in the
language of the certificate that it is an unofficial, convenience
binary?

-Rob

-
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

[Rob Weir]

On Sun, Aug 26, 2012 at 7:26 AM, Branko Čibej br...@apache.org wrote:
 On 26.08.2012 13:15, Tim Williams wrote:
 Marvin gave the link earlier in this thread. 4th para is the relevant bit.

 http://www.apache.org/dev/release.html#what

 The relevant part is in the last paragraph. However, that says
 convenience and defines version numbering requirements, but it does
 /not/ state that the binaries are not sanctioned by the ASF and are not
 part of the official ASF release.


And again, as I and others have stated, this is merely a label with no
content to it.  What does sanctioned (or not sanctioned) by the ASF
mean?  Anything specific?

Remember, the binaries (or Object form in the words of the license)
are also covered by the Apache License 2.0, and sections 7 and 8 of
that license already say that it is provided as-is, and disclaims
warranty and liability.

In other words, the same license and the same disclaimers apply to
source (which we seem to agree is part of the ASF release) and to
binaries.

So again I urge the IPMC to mind the seductive appeal of mere labeling
and instead consider whether there is any actual constraints on
activities and behavior for Podlings (or TLP's for that matter) based
on whether something is a source or binary, e.g.:

1) Is there some required (or forbidden) way in which a distinction
must be acknowledged in a release vote?

2) Is there some required (or forbidden) language on the download webpage?

3) Any required (or forbidden) language on release announcements?

4) Is there some required (or forbidden) constraint with distribution?

So far I have heard some on this list suggest the AOO podling is doing
something incorrect, something against ASF policy.  But dispute
repeated queries, no one has stated what exactly this is.  This is
extremely unfair to the podling, to any podling.  It denies us the
opportunity of addressing issues.  Is this really how the IPMC
operates?  It reminds me of tactics practiced by Microsoft against
open source -- intimate that something is wrong, but never offer
specifics.  We call it FUD there.  What do we call it at the ASF?

 It would be very useful if that paragraph were amended to say so
 explicitly. I've had no end of trouble trying to explain to managers and
 customers that any binaries that come from the ASF are not official.

That may be true for your users, but for mine they would just come
back with, What does that mean in practice?

 Regardless of the policy stated numerous times in this thread and on
 this list, this is not clear anywhere in the bylaws or other online
 documentation (that I can find).


I agree.

 -- Brane

 P.S.: I asked this same question on legal-discuss a week ago. My post
 has not even been moderated through as of today, so referring people to
 that list doesn't appear to be too helpful.


 -
 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

[Rob Weir]

On Sun, Aug 26, 2012 at 1:08 PM, Dave Fisher dave2w...@comcast.net wrote:

 On Aug 26, 2012, at 7:46 AM, Joe Schaefer wrote:

 AOO doesn't need to change anything to their current release processes
 other than to stop pointing source downloads at svn (which is the sole
 reason I won't vote for AOO candidates).

 Well this is worth discussion.

 On this page [1]:

 The source downloads go through aoo-closer.cgi, but all of the hashes and 
 signatures go through www.a.o/dist/. Is that your issue?

 Or is it this page [2]?

 Please help me understand what is wrong and it will be fixed.


This is the old bootstrap.sh issue, where build dependencies where
being downloaded from svn, from out ext-sources directory.   This is a
superset of the issues Pedro had with the cat-b dependencies.  We need
to make it so the dependencies are all downloaded from somewhere else.
 Otherwise we're sucking ASF bandwidth.

 Best Regards,
 Dave

 [1] http://incubator.apache.org/openofficeorg/downloads.html
 [2] http://www.openoffice.org/download/other.html#tested-sdk
 -
 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

[Rob Weir]

On Fri, Aug 24, 2012 at 7:42 PM, Marvin Humphrey mar...@rectangular.com wrote:
 On Fri, Aug 24, 2012 at 1:00 PM, Rob Weir robw...@apache.org wrote:
 Or if someone who cared sufficiently about this policy area took
 ownership and proposed a wording of the policy, either as a Board
 resolution, or on legal-discuss, and had that policy approved and
 recorded via the ordinary means.

 As a member of the Incubator PMC, I am willing to submit the following
 question via https://issues.apache.org/jira/browse/LEGAL:

 AOO official binary artifacts

 May the Apache Open Office podling consider binary artifacts prepared as
 described in this passage official, in the sense that their sense that
 their release is an act of the corporation and their contributors are
 indemnified?


The correct reference is to Bylaws 12.1.  That clause does not use the
undefined term official or unofficial or binary or source or
or act of the corporation indeed any mention of releases at all.  It
refers to all acts done by covered persons , ...in good faith and in
a manner that such person reasonably believed to be in or not be
opposed to the best interests of the corporation.

This would be a question not only of AOO, but of any project that
currently distributes binaries.

Are PMC's when distributing binaries acting ...in good faith and in a
manner that such person reasonably believed to be in or not be opposed
to the best interests of the corporation ?

IMHO, the best interests of the corporation is best determined by
the Board, not Legal Affairs.  Of course, they could choose to punt
the question to anywhere, including Legal Affairs.  But it should
start with them.

At that point we could also ask about all other non-source things that
PMCs do, including maintaining website, where there is always risk of
copyright infringements, data privacy laws, etc, or charges of
discrimination in selection or rating of student performance in Google
Summer of Code, or any of a number of risks that occur in the
operation of any corporate entity.   I think once we start poking we
find that there are many things a PMC does today, beyond the direct
distribution of source code, that brings risk.I don't think the
Board has ever enumerated which of these other activities are covered
by 12.1 and which are not.  I have no opinion on whether doing this is
a good use of their time.  It seems doing so would tie their arms
somewhat, and it might be better to leave these questions unanswered
until such time as they arise in context.  That preserves flexibility.

-Rob

 http://www.apache.org/dev/release.html#what

 The Apache Software Foundation produces open source software. All
 releases are in the form of the source materials needed to make
 changes to the software being released. In some cases, binary/bytecode
 packages are also produced as a convenience to users that might not
 have the appropriate tools to build a compiled version of the source.
 In all such cases, the binary/bytecode package must have the same
 version number as the source release and may only add binary/bytecode
 files that are the result of compiling that version of the source code
 release.

 My preference would be to have someone more invested in AOO serve as advocate,
 but I will do it if no one else steps forward.

 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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Fri, Aug 24, 2012 at 4:35 PM, Greg Stein gst...@gmail.com wrote:
 On Fri, Aug 24, 2012 at 4:00 PM, Rob Weir robw...@apache.org wrote:

snip

 I can give the IPMC a hand here, if my point is too obscure.  A policy
 might look like this:

 Resolved:   An Apache project's release consists of a canonical source
 artifact, voted on and approved by the PMC.  A PMC can also distribute
 additional, non-source artifacts, including documentation, binaries,
 samples, etc., that are provided for the convenience of the user.
 These non-source artifacts must must be buildable from the canonical
 source artifact.  Additional 3rd party libraries may be included
 solely in compliance with license policies defined by Apache Legal
 Affairs.  Additionally the non-source artifacts (or the PMC) must
 and must not _.

 That's existing policy. As people keep saying (most recently, Joe, in
 no uncertain terms).


Hi Greg,

And Joe, as I'm sure you noticed, also said:

THERE IS NO PROBLEM HERE,
CURRENT POLICY FULLY COVERS WHAT AOO ACTUALLY
DOES.  END OF DISCUSSION.

This is my understanding as well.

In any case, you seem to agree with the wording that I gave above,
since you say it represents existing policy.  Since I can find no
place on the IPMC or ASF website where this policy is actually stated
(and please correct me if I missed it), it might be good if we took my
summary from above and put it into the Podling Release Guide.  I know
there is an ongoing effort to clean up the IPMC website.  I'd be happy
to submit a patch.

Regards,

-Rob


 -g

 -
 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

[Rob Weir]

On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey
mar...@rectangular.com wrote:
 Returning to this topic after an intermission...

 On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 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.

 My impression from this discussion is that many podling contributors are
 dismayed by this policy, and that there is an element within the PPMC which
 remains convinced that it is actually up to individual PMCs within the ASF to
 set policy as to whether binaries are official or not.


If there actually is an ASF-wide Policy concerning binaries then I
would expect that:

1) It would come from the ASF Board, or from a Legal Affairs, not as
individual opinions on the IPMC list

2) It would be documented someplace, as other important ASF policies
are documented

3) That the policies is applied not only to AOO, but to other podlings
and to TLP's as well.

Until that happens, I hear only opinions.  But opinions, even widely
held opinions, even Roy opinions, are not the same as policy.

-Rob

 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.

 I'm concerned that such an effort may not be completed, and that once the
 podling graduates, AOO binaries will once again be advertised as official,
 placing the project in conflict with ASF-wide policy.  It may be that some
 within the newly formed PMC will speak out in favor of the ASF status quo, but
 as their position will likely be inexpedient and unpopular, it may be
 difficult to prevail.

 Of course I don't know how things will play out, but it seems to me that
 reactions from podling contributors have ranged from discouraged to skeptical
 to antagonistic and that there is limited enthusisasm for working within the 
 ASF
 on this matter.

 Gaming out this pessimistic scenario, what would it look like if the Board
 were forced to clamp down on a rebellious AOO PMC to enforce ASF policy
 regarding binary releases?

 If we believe that we are adequately prepared for such circumstances, then I
 think that's good enough and that fully resolving the issue of binary
 releases prior to AOO's graduation is not required.

 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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Fri, Aug 24, 2012 at 12:45 PM, Rob Weir robw...@apache.org wrote:
 On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey
 mar...@rectangular.com wrote:
 Returning to this topic after an intermission...

 On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 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.

 My impression from this discussion is that many podling contributors are
 dismayed by this policy, and that there is an element within the PPMC which
 remains convinced that it is actually up to individual PMCs within the ASF to
 set policy as to whether binaries are official or not.


 If there actually is an ASF-wide Policy concerning binaries then I
 would expect that:

 1) It would come from the ASF Board, or from a Legal Affairs, not as
 individual opinions on the IPMC list

 2) It would be documented someplace, as other important ASF policies
 are documented


And 2a)  Actually state the constraints of the policy, i.e., what is
allowed or disallowed by the policy.  Merely inventing a label like
convenience or unofficial gives absolutely zero direction to
PMC's.  It is just a label.  Consider what the IPMC's Release Guide
gives with regards to the source artifact.  It is labeled canonical,
but that level is backed up with requirements, e.g., that every
release must include it, that it must be signed, etc.  Similarly,
podling releases are not merely labeled podling releases, but policy
defines requirements, e.g., a disclaimer, a required IPMC vote, etc.

I hope I am not being too pedantic here.  But I would like to have a
policy defined here so any PMC can determine whether they are in
compliance.  But so far I just hear strongly held opinions that amount
to applying labels, but not mandating or forbidden any actions with
regards to artifacts that bear these labels.

Consider:  If some IPMC members declared loudly that It is ASF policy
that binary artifacts are 'Umbabuga', what exactly would you expect a
Podling to do, given that Umbabuga is an undefined term with no policy
mandated or forbidden actions?

There is a seductive appeal to reaching consensus on a label. But it
avoids the hard part of policy development, the useful part:  reaching
consensus on constraints to actions.


 3) That the policies is applied not only to AOO, but to other podlings
 and to TLP's as well.

 Until that happens, I hear only opinions.  But opinions, even widely
 held opinions, even Roy opinions, are not the same as policy.

 -Rob

 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.

 I'm concerned that such an effort may not be completed, and that once the
 podling graduates, AOO binaries will once again be advertised as official,
 placing the project in conflict with ASF-wide policy.  It may be that some
 within the newly formed PMC will speak out in favor of the ASF status quo, 
 but
 as their position will likely be inexpedient and unpopular, it may be
 difficult to prevail.

 Of course I don't know how things will play out, but it seems to me that
 reactions from podling contributors have ranged from discouraged to skeptical
 to antagonistic and that there is limited enthusisasm for working within the 
 ASF
 on this matter.

 Gaming out this pessimistic scenario, what would it look like if the Board
 were forced to clamp down on a rebellious AOO PMC to enforce ASF policy
 regarding binary releases?

 If we believe that we are adequately prepared for such circumstances, then I
 think that's good enough and that fully resolving the issue of binary
 releases prior to AOO's graduation is not required.

 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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Fri, Aug 24, 2012 at 2:11 PM, Dave Fisher dave2w...@comcast.net wrote:

 On Aug 24, 2012, at 9:32 AM, Marvin Humphrey wrote:

 Returning to this topic after an intermission...

 On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 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.

 My impression from this discussion is that many podling contributors are
 dismayed by this policy, and that there is an element within the PPMC which
 remains convinced that it is actually up to individual PMCs within the ASF to
 set policy as to whether binaries are official or not.

 It is a consequence of 10 years of official openoffice.org binary releases 
 from both Sun and Oracle.

 It is a consequence of a large market share.


Or stated in less commercial terms, the vast amount of public good
that comes from this project.

See:  http://incubator.apache.org/openofficeorg/mission.html


 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.

 I'm concerned that such an effort may not be completed, and that once the
 podling graduates, AOO binaries will once again be advertised as official,
 placing the project in conflict with ASF-wide policy.  It may be that some
 within the newly formed PMC will speak out in favor of the ASF status quo, 
 but
 as their position will likely be inexpedient and unpopular, it may be
 difficult to prevail.

 Of course I don't know how things will play out, but it seems to me that
 reactions from podling contributors have ranged from discouraged to skeptical
 to antagonistic and that there is limited enthusisasm for working within the 
 ASF
 on this matter.

 Gaming out this pessimistic scenario, what would it look like if the Board
 were forced to clamp down on a rebellious AOO PMC to enforce ASF policy
 regarding binary releases?

 If we believe that we are adequately prepared for such circumstances, then I
 think that's good enough and that fully resolving the issue of binary
 releases prior to AOO's graduation is not required.

 One way to help assure proper policy would be to insist that there are 
 several Apache Members on the future PMC.


Or if someone who cared sufficiently about this policy area took
ownership and proposed a wording of the policy, either as a Board
resolution, or on legal-discuss, and had that policy approved and
recorded via the ordinary means.

Right now is is unfair to say that I, or anyone else in the podling,
is rebellious or opposes ASF Policy in this area, since no one seems
to be able to say what the policy actually is, in specific and
actionable terms, and why they think AOO podling is or is not in
compliance.

I can give the IPMC a hand here, if my point is too obscure.  A policy
might look like this:

Resolved:   An Apache project's release consists of a canonical source
artifact, voted on and approved by the PMC.  A PMC can also distribute
additional, non-source artifacts, including documentation, binaries,
samples, etc., that are provided for the convenience of the user.
These non-source artifacts must must be buildable from the canonical
source artifact.  Additional 3rd party libraries may be included
solely in compliance with license policies defined by Apache Legal
Affairs.  Additionally the non-source artifacts (or the PMC) must
and must not _.

Fill in the blanks, get approval via normal procedures, and you have
something resembling a policy.

Regards,

-Rob


 As of now it looks like Jim and I are the only ones on the prospective PMC. 
 That's not enough. I'm going to need a vacation from AOO soon.

 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


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

[VOTE][RESULTS] Apache OpenOffice Community Graduation Vote

[Rob Weir]

The community vote has passed.

Vote reference:  http://s.apache.org/5GA

+1

RGB-ES
Rory O'Farrell
Carl Marcum
Reizinger Zoltan
Keith N. McKenna
Kay Schenk
Roberto Galoppini
Imacat
Andrea Pescetti
Regina Henschel
Graham Lauder
Jürgen Lange
T.J. Frazier
Rob Weir
Dave Fisher
Peter Junge
Christian Grobmeier
Yong Lin Ma
Raphael Bircher
Larry Gusaas
Yan Ji
David McKay
Andre Fischer
Oliver-Rainer Wittmann
Shenfeng Liu
Kevin Grignon
Linyi Li
Liu Da Li
Armin Le Grand
Lei Wang
Ying Zhang
Jörg Schmidt
Tan Li
Joost Andrae
ZuoJun Chen
Ian Lynch
Ariel Constenla-Haile
Dave Barton
Albino B. Neto
Herbert Duerr
Marcus Lange
Phillip Rhodes
Juan C. Sanz
DongJun Zong
Bingbing Ma
B.J. Cheny
Jianyuan Li
Olaf Felka
Wang Zhe
Anton Meixome
Andrew Rist
Claudio Filho
Ian C.
Shzh Zhao
Risto Jääskeläinen
Pedro Giffuni
Helen Yue
Steve Yin
Kazunari Hirano


+0

Dennis E. Hamilton
Michal Hriň

-
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

[Rob Weir]

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

[Rob Weir]

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] Release Apache OpenOffice 3.4.1 (incubating) RC2

[Rob Weir]

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: general-unsubscr

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

[Rob Weir]

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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Mon, Aug 20, 2012 at 4:32 PM, Marvin Humphrey mar...@rectangular.com 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.


Let's look at the the TLP's that the IPMC has recommended, and the ASF
Board has approved in recent months.  Notice that a fair number of
them releae source and binaries, as does the OpenOffice podling:

Apache Lucene.Net -- releases source and binaries

Apache DirectMemory -- releases source only

Apache VCL -- releases  source only

Apache Hama --  releases source and binaries

Apache MRUnit --  releases source only

Apache Giraph -- releases source only

Apache ManifoldCF -- releases source and binaries

So I'm not quite sure in what way the ASF is not ready for a TLP
that releases binaries, or what additional legal or procedural work
needs to be done to enable this.  As far as I can tell ASF projects
release binaries today.

I agree, sterile buildbots and code signing are good things to have,
and we are working with Infra on this today, and would continue to
peruse these avenues as a TLP.

In any case, shouldn't the question be whether the podling is ready
for the ASF rather than whether the ASF is ready for the poding? ;-)

-Rob


 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

[Rob Weir]

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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Mon, Aug 20, 2012 at 5:04 PM, Rob Weir robw...@apache.org wrote:
 On Mon, Aug 20, 2012 at 4:32 PM, Marvin Humphrey mar...@rectangular.com 
 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.


 Let's look at the the TLP's that the IPMC has recommended, and the ASF
 Board has approved in recent months.  Notice that a fair number of
 them releae source and binaries, as does the OpenOffice podling:


Some further documentation of IPMC practice in this regard:

 Apache Lucene.Net -- releases source and binaries


IPMC voted to approve release, and vote post pointed to both source
and binary artifacts:

http://markmail.org/message/mt3xthcqqng7ftnw

 Apache DirectMemory -- releases source only

 Apache VCL -- releases  source only

 Apache Hama --  releases source and binaries


The people.a.o directory that was voted on by the IPMC is gone now.  I
suspect it included binaries as well. Certainly now that the podling
has graduated their release candidates include binaries:

http://people.apache.org/~edwardyoon/dist/0.5-RC4/

 Apache MRUnit --  releases source only

 Apache Giraph -- releases source only

 Apache ManifoldCF -- releases source and binaries


Their most recent vote was withdrawn because they graduated before the
vote completed, but that IPMC vote post also pointed to both source
and binary artifacts:

http://markmail.org/message/op7ofi2gudwfov3z

So the recent practice of the IPMC has been to approve releases with
source and binaries, but also to graduate podlings that do so.

Regards,

-Rob


 So I'm not quite sure in what way the ASF is not ready for a TLP
 that releases binaries, or what additional legal or procedural work
 needs to be done to enable this.  As far as I can tell ASF projects
 release binaries today.

 I agree, sterile buildbots and code signing are good things to have,
 and we are working with Infra on this today, and would continue to
 peruse these avenues as a TLP.

 In any case, shouldn't the question be whether the podling is ready
 for the ASF rather than whether the ASF is ready for the poding? ;-)

 -Rob


 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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Mon, Aug 20, 2012 at 8:01 PM, Marvin Humphrey mar...@rectangular.com wrote:
 On Mon, Aug 20, 2012 at 3:03 PM, drew d...@baseanswers.com wrote:
 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.

 I wonder who might step into the breach to provide binaries for such a
 package...

 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.

 At the ASF, the source release is canonical.  I have never seen anyone assert
 that the source release is not offical and endorsed by the ASF.


What would suggest is the concrete distinction between an official
binary and an unofficial' binary?

I'd assert all binaries that I've seen a project release have these qualities:

1) Have LICENSE and NOTICE

2) Are build from the canonical source

3) Can use other 3rd party components per policy

4) Are voted on by the PMC's

5) Have hashes and detached digital signatures

6) Are distributed via the Apache mirrors

7) Are linked to on websites and announcements

8) Are used by and appreciated by users

9) Are for the public good

Which of these do would you say are not qualities of an unofficial
binary?  Or would you suggest another?

Unless ASF or IPMC policy defines a distinction here, I think we're
just arguing about what color the bike shed is for angels dancing on a
head of pin.  It is a distinction without a difference, or at least
not one that has been stated,

-Rob

 There has been disagreement about whether binaries should be official or not.
 To the best of my knowledge, every time the matter has come up, the debate has
 been resolved with a compromise: that while binary releases are not endorsed
 by the ASF, they may be provided in addition to the source release for the
 convenience of users.

 What is different with AOO is that the compromise does not seem to satisfy
 an element within the PPMC and thus the matter is being forced.

 It would be a lot of hard, time-consuming work for the ASF to build the
 institutions necessary to provide binary releases that approach the standards
 our source releases set.  (As illustrated by e.g. the challenges of setting up
 the code signing service.)  Not all of us are convinced that it is for the
 best, either.

 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] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Mon, Aug 20, 2012 at 8:11 PM, Greg Stein gst...@gmail.com wrote:
 Just because some other podlings have released binary artifacts does
 not mean AOO can base their entire release strategy on binaries.


True,  But we have not based our entire release strategy on binaries.
If you recall we spent a great deal of time preparing the AOO 3.4.0
release, with the vast majority of the work dedicated entirely to the
source code aspects of the release.  There were very few feature
enhancements in that initial release.  Our work was highly centered on
meeting ASF requirements with respect to pedigree review, license
headers, treatment of 3rd party components, LICENSE and NOTICE
requirements, etc.

 As Marvin has said: source releases are the primary release mechanism.

 Binaries are and should be a distant second.


And that is why we put so much effort ensuring that the source code
for OpenOffice met ASF requirements.  But we are also releasing
binaries, as we did for Apache OpenOffice 3.4.0, and as this project
has done for the past 10 years.

If you look at our release artifacts, you see that the source tar
balls are listed first, followed by binaries:

https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds

Is there some specific method by which the IPMC wishes podlings to
make this distinction between the canonical source release and
binaries more clear?  I've looked at recent podling release approved
by the IPMC and I can discern no such distinction.

 I would also state that continuing to argue is symptomatic of a
 failure to understand and integrate with the Foundation's thoughts on
 the matter. Or to at least politely discuss the situation on
 legal-discuss.


I would say the lack of understanding could be in both directions, and
some greater tolerance  would be mutually beneficial.

Remember, OpenOffice is unlike anything else previously at Apache.  It
is an end user product. and a very famous and well adopted one.  This
does not diminish the importance of the source code artifacts.  But it
does increase the importance of the binary ones.  This is something
the PPMC is generally happy with and matches our decade plus
experience with the project and the ecosystem.

Note also that although we take pride in the 12 million downloads of
the binaries, we take even more pride in seeing successful reuses of
the code, as we are seeing with non-Apache ports for BSD, OS/2 and
Solaris, and work on other non-ASF products based on Apache
OpenOffice, including portableApps and WinPenpack.  We have PPMC
members employed in producing products based on our source code, by
three different companies.  So we understand the value of the source
to the overall ecosystem.  But it still remains true that this is an
end user application, used by millions of users, and as a project we
will need to (and desire) to give it the attention it deserves as
well.  These two work together, of course, as additional interest in
the source drives more investment into the ecosyste,

Regards,

-Rob

Regards,

-Rob

 Cheers,
 -g

 On Mon, Aug 20, 2012 at 7:33 PM, Rob Weir robw...@apache.org wrote:
 On Mon, Aug 20, 2012 at 5:04 PM, Rob Weir robw...@apache.org wrote:
 On Mon, Aug 20, 2012 at 4:32 PM, Marvin Humphrey mar...@rectangular.com 
 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.


 Let's look at the the TLP's that the IPMC has recommended, and the ASF
 Board has approved in recent months.  Notice that a fair number of
 them

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Mon, Aug 20, 2012 at 8:59 PM, drew d...@baseanswers.com wrote:
 On Mon, 2012-08-20 at 17:01 -0700, Marvin Humphrey wrote:
 On Mon, Aug 20, 2012 at 3:03 PM, drew d...@baseanswers.com wrote:
  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.

 I wonder who might step into the breach to provide binaries for such a
 package...

 Hi,

 Well, for a start:

 IBM stated it will release a free binary version at some point, after
 shutting down the Symphony product.


This is incorrect.  Wearing my IBM hat I can say that our plan is not
to ship our own binary version at all, but to ship the Apache version
bundled with some proprietary extension modules that would help our
customers work with our server stack.  I don't think we've ever said
otherwise.

 CS2C, a Chinese firm working in cooperation with Ernest and Young IIRC,
 releases a binary based on the source code - in fact I'm not even sure
 AOO supplied binaries are available to most folks in China.

 Multiracio releases a closed source version of the application for sale
 in Europe and the US.

 In the past quite a few Linux distributors included binary releases in
 their offerings, they consume source not binaries.

 The current BSD, OS/2 and Solaris ports will go out as source only from
 AOO, but come to end users from a third party repository, unless I
 totally missed what was happening there (and I might off ;)

 There are currently two groups which offer binary versions packaged to
 run off USB drives, as far as I understand it, they work from source and
 don't require binaries.


My understanding is the portable versions work from the binaries, not
the source.  They rebuild the install portions only.   This is similar
to a variety of distributions (not ports) in the ecosystem.  There is
a lot you can do by taking the OpenOffice binaries and rebuilding the
install set with different extensions, templates, etc.  This is far
easier than rebuilding from source.

 Finally this is a well known brand now, it would be hard to believe that
 if AOO did not release binaries the void would not be filled by others.


Indeed.  Also, if we didn't release source either then someone else
would fill the void, probably Microsoft.

-Rob

 //drew

 ps - sorry if this double posts...


  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.

 At the ASF, the source release is canonical.  I have never seen anyone assert
 that the source release is not offical and endorsed by the ASF.

 There has been disagreement about whether binaries should be official or not.
 To the best of my knowledge, every time the matter has come up, the debate 
 has
 been resolved with a compromise: that while binary releases are not endorsed
 by the ASF, they may be provided in addition to the source release for the
 convenience of users.

 What is different with AOO is that the compromise does not seem to satisfy
 an element within the PPMC and thus the matter is being forced.

 It would be a lot of hard, time-consuming work for the ASF to build the
 institutions necessary to provide binary releases that approach the standards
 our source releases set.  (As illustrated by e.g. the challenges of setting 
 up
 the code signing service.)  Not all of us are convinced that it is for the
 best, either.

 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


-
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

[Rob Weir]

On Mon, Aug 20, 2012 at 10:33 PM, Greg Stein gst...@gmail.com wrote:
 On Aug 20, 2012 8:33 PM, Rob Weir robw...@apache.org wrote:

 On Mon, Aug 20, 2012 at 8:11 PM, Greg Stein gst...@gmail.com wrote:
...
  I would also state that continuing to argue is symptomatic of a
  failure to understand and integrate with the Foundation's thoughts on
  the matter. Or to at least politely discuss the situation on
  legal-discuss.

 I would say the lack of understanding could be in both directions, and
 some greater tolerance  would be mutually beneficial.

 I *am* being tolerant (you should see my intolerant emails). And what makes
 you believe that I don't understand? I get to offer my thoughts, and you do
 not get to say that I have a lack of understanding simply because you
 disagree.

 Remember, OpenOffice is unlike anything else previously at Apache.

 Duh. Don't be so patronizing.


Greg,  I am certain that you are well-informed of the details about
OpenOffice and its history.  But for the benefit of IPMC members and
observers who may have followed this less closely I thought that a
brief summary would be welcome.  I apologize if you thought it was
unnecessary.

 Again: I suggest the discussion about making authorized/authenticated
 binaries be moved to legal-discuss. Not here. Infrastructure may need to
 provide some input, too.


Do you have a specific question we should be asking legal affairs
and/or infrastructure?

We have already had extensive discussions on legal-discuss, including
discussions about specific dependencies that are only included in
binary form in our binary artifacts, per ASF policy.  These
discussions were in the context of releases that included source and
binaries.  I don't recall hearing any concerns raised in principle
about releasing binaries along with source.   The guidance from Legal
Affairs was focused more on the permissible dependencies and required
form for LICENSE and NOTICE and copyright statement in the binaries.

But if you have a specific license-related question we should resolve
with them, please let me know what it is.  I'd be more than happy to
check with them.

As for Infrastructure, we've also had extensive discussions with them
on the specific topic of distributing the binaries. There was an
initial sizing, a poll of the mirror operators and a determination
that the storage and bandwidth would be too great for many of the
mirror operators.  So a separate list of mirror operators was created
who could handle our dist, and this subset rsync's with the OpenOffice
dist.

Also, SourceForge volunteered to provide us access to their
distribution network.  This was approved by VP, Infrastructure.  As of
our AOO 3.4.0 release the majority of the downloads for the binaries
does not involve Apache Infra at all, but goes through SourceForge.
But the source downloads, as well as the downloads of the hashes and
detached signatures does go through the normal ASF mirror network.

Again, I'm not aware of an open question we have for Infra related to
the proposed AOO 3.4.1 podling release.  If they had an issue I know
they would not be shy about raising it with us.  But if you have
something specific that you think we should ask them, please let me
know.  I would be delighted to check with them.

 I might also point you to Sam's recommendation to avoid over-posting to a
 thread as a way to dominate / get your way. How many emails are you up to
 so far?

I'm trying to determine what your substantive issues are and to
resolve them to your satisfaction. If you want to hear less of me,
then please get to the point and say what your concerns are and what
exactly would resolve it.

Regards,

-Rob

 -g

-
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

[Rob Weir]

On Mon, Aug 20, 2012 at 10:58 PM, Rob Weir robw...@apache.org wrote:
 On Mon, Aug 20, 2012 at 10:33 PM, Greg Stein gst...@gmail.com wrote:
 On Aug 20, 2012 8:33 PM, Rob Weir robw...@apache.org wrote:

 On Mon, Aug 20, 2012 at 8:11 PM, Greg Stein gst...@gmail.com wrote:
...
  I would also state that continuing to argue is symptomatic of a
  failure to understand and integrate with the Foundation's thoughts on
  the matter. Or to at least politely discuss the situation on
  legal-discuss.

 I would say the lack of understanding could be in both directions, and
 some greater tolerance  would be mutually beneficial.

 I *am* being tolerant (you should see my intolerant emails). And what makes
 you believe that I don't understand? I get to offer my thoughts, and you do
 not get to say that I have a lack of understanding simply because you
 disagree.

 Remember, OpenOffice is unlike anything else previously at Apache.

 Duh. Don't be so patronizing.


 Greg,  I am certain that you are well-informed of the details about
 OpenOffice and its history.  But for the benefit of IPMC members and
 observers who may have followed this less closely I thought that a
 brief summary would be welcome.  I apologize if you thought it was
 unnecessary.

 Again: I suggest the discussion about making authorized/authenticated
 binaries be moved to legal-discuss. Not here. Infrastructure may need to
 provide some input, too.


 Do you have a specific question we should be asking legal affairs
 and/or infrastructure?

 We have already had extensive discussions on legal-discuss, including
 discussions about specific dependencies that are only included in
 binary form in our binary artifacts, per ASF policy.  These
 discussions were in the context of releases that included source and
 binaries.  I don't recall hearing any concerns raised in principle
 about releasing binaries along with source.   The guidance from Legal
 Affairs was focused more on the permissible dependencies and required
 form for LICENSE and NOTICE and copyright statement in the binaries.

 But if you have a specific license-related question we should resolve
 with them, please let me know what it is.  I'd be more than happy to
 check with them.

 As for Infrastructure, we've also had extensive discussions with them
 on the specific topic of distributing the binaries. There was an
 initial sizing, a poll of the mirror operators and a determination
 that the storage and bandwidth would be too great for many of the
 mirror operators.  So a separate list of mirror operators was created
 who could handle our dist, and this subset rsync's with the OpenOffice
 dist.

 Also, SourceForge volunteered to provide us access to their
 distribution network.  This was approved by VP, Infrastructure.  As of

A slight correction.  We collaborated with SourceForge on two
projects:  hosting the extensions and templates websites as well as
mirror the distributions.

The records show that Sam OK'ed handing over the templates and
extensions to SourceForge [1], but for the mirroring this go-head we
received was from Joe.

[1] http://markmail.org/message/oveyethdmsxnykfj

[2] http://markmail.org/message/ioxowodlwsqoba5i


 our AOO 3.4.0 release the majority of the downloads for the binaries
 does not involve Apache Infra at all, but goes through SourceForge.
 But the source downloads, as well as the downloads of the hashes and
 detached signatures does go through the normal ASF mirror network.

 Again, I'm not aware of an open question we have for Infra related to
 the proposed AOO 3.4.1 podling release.  If they had an issue I know
 they would not be shy about raising it with us.  But if you have
 something specific that you think we should ask them, please let me
 know.  I would be delighted to check with them.

 I might also point you to Sam's recommendation to avoid over-posting to a
 thread as a way to dominate / get your way. How many emails are you up to
 so far?

 I'm trying to determine what your substantive issues are and to
 resolve them to your satisfaction. If you want to hear less of me,
 then please get to the point and say what your concerns are and what
 exactly would resolve it.

 Regards,

 -Rob

 -g

-
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

[Rob Weir]

On Mon, Aug 20, 2012 at 11:05 PM, Greg Stein gst...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 10:55 PM, Prescott Nasser geobmx...@hotmail.com 
 wrote:
 I'm sorry, I'm playing catch-up and I'm a bit unclear on the argument - 
 Marvin said:  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. Is AOO not able to determine 
 that for them a binary is a hard requirement for their releases (along with 
 source code)? I would think that ASF puts a minimum requirement on what an 
 official release is, not a limit.  Why is there a requirement for special 
 infrustructure? (perhaps that is due to the size of AOO?) Speaking just from 
 the Lucene.Net persective, I would consider our binaries (and nuget 
 packages) as official - even if ASF does not specifically allow for 
 official releases or officially endourced binaries - what else would they 
 be? They were built and put up by the same guys releasing the source code.

 The simplest response is that source releases can be audited by (P)PMC
 members. Binary releases cannot. If they cannot be audited, then how
 can the ASF stand behind those releases? How can they state that the
 releases are free of viruses/trojans/etc, and that the binary
 precisely matches the compiled/built output of the audited source
 release?


You ask a serious question it deserves a serious answer.  This issue
faces every software distributor, not just Apache.   We verify
binaries releases in several ways:

1)  As part of the release approval process project members ensure
that they can build from the source artifact.

2) I install the RC on an isolated system and check for viruses and
other malware, and then wait for a few days, refresh the virus
signatures, and test again before releasing, to ensure that we're not
caught by a zero-day attack.

3) We would like to do code signing, as do several other projects.
The discussions with Infra on how this could be accomplished are
ongoing.

Of course, the same questions could be asked of each of the large
number of ASF projects that release binaries today.  I wonder how many
of them even take the precautions of #2?

Maybe my turn for a question?  How many Apache projects have released
a binary in the past 10 years?  And how many have released a binary
containing a virus or a trojan?  And how many users have downloaded
Apache source and built it?  And how many of those users then found
that their servers were compromised due to a security flaw in the
Apache  source?  In theory source code can be inspected.  In practice,
stuff happens.  Ditto for binaries.

-Rob

 That is the first and hardest issue about having the ASF provide
 authenticated binaries.

 Cheers,
 -g

 -
 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

[Rob Weir]

On Mon, Aug 20, 2012 at 11:30 PM, 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.


Maybe you can help clarify this for me then. What exactly about the
proposed AOO 3.4.1 ballot suggests that the AOO binaries are any
different than published convenience binaries to accompany their
releases that you believe are permitted?

Or equivalently, can you point to something, say, in the Lucerne.Net
ballot that distinguishes their binaries as different from ours in
status?

I'm honestly trying to find out what, if anything, we need to change.
Or whether we're just arguing semantics rather than code and bits.

-Rob

 -
 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

Fwd: [VOTE] Apache OpenOffice Community Graduation Vote

[Rob Weir]

-- Forwarded message --
From: Rob Weir robw...@apache.org
Date: Sun, Aug 19, 2012 at 11:52 AM
Subject: [VOTE] Apache OpenOffice Community Graduation Vote
To: ooo-...@incubator.apache.org


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...


Regards,

-Rob

[1] http://incubator.apache.org/guides/graduation.html#tlp-community-vote

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

Re: References to Apache OpenOffice

[Rob Weir]

On Sat, Jun 23, 2012 at 2:59 PM, drew d...@baseanswers.com wrote:
 On Sat, 2012-06-23 at 19:43 +0100, Nick Kew wrote:
 On 23 Jun 2012, at 19:37, Nick Kew wrote:

  Nor what appears on planet.apache.org, featuring the article that first 
  struck me
  as using the name in a way I wouldn't expect when I read it in my feed 
  reader:
  http://www.robweir.com/blog/2012/06/pache-openoffice-34-downloads.html

 Following that link in a browser I see there's also a nice but questionable 
 logo:
 http://www.robweir.com/blog/images/get-aoo-300x100-cf.png
 If PR are OK with that then fine, but I find it surprising.



With reference to the Podling Branding Guide [1] , the requirement is
that the product be called Apache OpenOffice.  That is the name.
Nothing else.  But we're also required to mention that the project is
under Incubation.  There is more than one way of doing that.  Also,
These statements only need to be disclosed upon the first reference
in a document.  IMHO, we've done that for the blog posts as hosted on
ASF servers.  But it is not clear if or how we control other parties
tweeting links.  But I assume if someone feels strongly about
controlling things at that level they will propose a way.

[1] http://incubator.apache.org/guides/branding.html


 hmm - I suppose you are correct, it shouldn't have the feather and
 should have the incubator tab - right?


Actually, we did approve that logo as a PPMC as part of a download
promotion program:

http://incubator.apache.org/openofficeorg/get-it-here.html

We ran that by VP Branding as well.  I could be wrong, but my
impression was he approved as well.

The PPMC does not control the Apache.org home page.  If the ASF
decides to aggregate posts from the committers planet, then maybe that
should come with a disclaimer?  Or bring in just the project blogs,
not the committer blogs?  I could be talking about anything on my
blog: OpenOffice, beer. satantic rituals, bagpipes, perhaps all at
once.   It probably should not automatically all be promoted to the
ASF home page.

As for the project blogs, maybe we should just enhance the aggregator
logic on the ASF home page?  For example, Google+ gets does it well,
pulling in the blog title along with the post title.  Se here:
https://plus.google.com/u/0/114598373874764163668/posts/ZiRcwog5cDJ  .

If you try to fix it in the content itself, then you end up with
suboptimal results for Google+ and other places that do bring the blog
title along, ending up with something like 5 Million Downloads of
Apache OpenOffice (incubating) : Apache OpenOffice (incubating) which
looks sloppy.

-Rob

 //drew



 -
 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: References to Apache OpenOffice

[Rob Weir]

On Sat, Jun 23, 2012 at 3:55 PM, drew d...@baseanswers.com wrote:
 On Sat, 2012-06-23 at 15:42 -0400, Rob Weir wrote:
 On Sat, Jun 23, 2012 at 2:59 PM, drew d...@baseanswers.com wrote:
  On Sat, 2012-06-23 at 19:43 +0100, Nick Kew wrote:
  On 23 Jun 2012, at 19:37, Nick Kew wrote:
 
   Nor what appears on planet.apache.org, featuring the article that first 
   struck me
   as using the name in a way I wouldn't expect when I read it in my feed 
   reader:
   http://www.robweir.com/blog/2012/06/pache-openoffice-34-downloads.html
 
  Following that link in a browser I see there's also a nice but 
  questionable logo:
  http://www.robweir.com/blog/images/get-aoo-300x100-cf.png
  If PR are OK with that then fine, but I find it surprising.
 
 

 With reference to the Podling Branding Guide [1] , the requirement is
 that the product be called Apache OpenOffice.  That is the name.
 Nothing else.  But we're also required to mention that the project is
 under Incubation.  There is more than one way of doing that.  Also,
 These statements only need to be disclosed upon the first reference
 in a document.  IMHO, we've done that for the blog posts as hosted on
 ASF servers.  But it is not clear if or how we control other parties
 tweeting links.  But I assume if someone feels strongly about
 controlling things at that level they will propose a way.

 [1] http://incubator.apache.org/guides/branding.html


  hmm - I suppose you are correct, it shouldn't have the feather and
  should have the incubator tab - right?
 

 Actually, we did approve that logo as a PPMC as part of a download
 promotion program:

 http://incubator.apache.org/openofficeorg/get-it-here.html

 We ran that by VP Branding as well.  I could be wrong, but my
 impression was he approved as well.

 So what, it is still wrong and I can fix it easy enough.


There is more than one way to make it right, so it might be worth a
quick discuss on ooo-dev.

Or if you are in a JFDI mood, the live copy is here:

https://svn.apache.org/repos/asf/incubator/ooo/site/trunk/content/openofficeorg/images/get-it-here/en.png

Regards,

-Rob



 The PPMC does not control the Apache.org home page.  If the ASF
 decides to aggregate posts from the committers planet, then maybe that
 should come with a disclaimer?  Or bring in just the project blogs,
 not the committer blogs?  I could be talking about anything on my
 blog: OpenOffice, beer. satantic rituals, bagpipes, perhaps all at
 once.   It probably should not automatically all be promoted to the
 ASF home page.

 As for the project blogs, maybe we should just enhance the aggregator
 logic on the ASF home page?  For example, Google+ gets does it well,
 pulling in the blog title along with the post title.  Se here:
 https://plus.google.com/u/0/114598373874764163668/posts/ZiRcwog5cDJ  .

 If you try to fix it in the content itself, then you end up with
 suboptimal results for Google+ and other places that do bring the blog
 title along, ending up with something like 5 Million Downloads of
 Apache OpenOffice (incubating) : Apache OpenOffice (incubating) which
 looks sloppy.

 -Rob

  //drew
 
 
 
  -
  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

[ANNOUNCE] Apache OpenOffice 3.4 Released

[Rob Weir]

The Apache OpenOffice Podling Project Management Committee is pleased
to announce the release of Apache OpenOffice 3.4, available on
Windows, MacOS and Linux.

Downloads are available at: http://download.openoffice.org

The full release announcement can be read here:
http://www.openoffice.org/news/aoo34.html

Regards,

- The Apache OpenOffice PPMC

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

Re: Legal question about (re)licensing

[Rob Weir]

On Tue, May 1, 2012 at 10:42 PM, Norbert Thiebaud nthieb...@gmail.com wrote:

snip

 PS: the specific svn revisions here are not the central point, the
 point is the lack of any discussion/scrutiny on any of these followed
 by the self-fulfilling prophecy: To be released the code must be
 clean. Releasing imply a detailed IP review (RAT was run), so surely
 if the release was approved by a vote then the release _is_ IP clean,
 and therefore if it is released then it is clean.
 Rob's 'holier than thou' public attitude on the topic remind me of the
 old saying:  People who live in glass houses shouldn't throw stones.


Your argument is a form of the logical fallacy known as the fallacy
of the false dilemma, also called false either/or or
black-and-white thinking.  You argue that either the code review
must reach some absolute level of complete perfection or that it is no
better than doing no review at all.

Let's recast that argument.   We are not able to test 100% of
OpenOffice, from a path perspective with our current test cases.
Although we do have a practice of recording bugs and fixing them, we
have no practical way of achieving 100% perfection on defect detection
and removal. Therefore (your argument would go) it is not worth
testing at all, and we should not be allowed to tout the user benefits
of what testing that we do perform.

Now, you wouldn't make such an argument about testing, would you?

Similarly, the Apache emphasis on IP review is not less important
because of possible human error.  In fact the multiple stages of
review and approval are designed to give maximal opportunity to
identify and fix such issues.  This has worked very well for this
project, and the reviews we've done have found and addressed many
issues.   It is far better than doing nothing.   In the end, I'll take
diligence over negligence any day.

-Rob

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

Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[Rob Weir]

On Thu, Apr 12, 2012 at 9:07 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Thu, Apr 12, 2012 at 7:43 AM, William A. Rowe Jr.
 wr...@rowe-clan.net wrote:
 Short of people.a.o/~luser/my-patch.tgz, I'm fairly certain that
 can't happen with an incubating podling.  Everything under the space
 /dist/ must exist under a PMC.

 I totally agree for proper releases (with a source archive) blessed by
 the PMC (on private@ if needed). However, this was neither, so I find
 using the same location a bit troublesome.

 Anyway, it sounds like the case was handled reasonably well under some
 fairly challenging constraints, so I'm not too worried about  details
 like this as long as this remains a one-off special case. I only
 wanted to bring this up to make sure this doesn't become a standard
 procedure without a broader discussion of how cases like this should
 be handled.


If there is anything worth additional consideration, it would be how
to handle large incubation projects, where the time to initial Apache
release is long enough that there is a possibility or even likelihood
of needing to release a security patch for a legacy version of the
product.  In some cases the original sponsors of the project are still
around and can continue to do this kind of maintenance. In other
cases, as with OpenOffice, this is not true.

I'd recommend that future podlings, and the IPMC, consider this aspect
when reviewing new podling applications.  It should probably be
treated explicitly in the wiki proposal for podlings that expect to
take more than 3 or 4 months to get to their first release.

Regards,

-Rob

 BR,

 Jukka Zitting

 -
 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: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[Rob Weir]

On Thu, Apr 12, 2012 at 12:32 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 I don't think the problem is with the size of the ooo-security list 
 membership.  I think it is in the assumption that the [P]PMC has somehow 
 delegated the ability to make a release of any kind to the ooo-security team. 
  I don't mean slip-streaming fixes and working off the public SVN until that 
 happens.  I mean developing and deploying all the rest of what accompanies an 
 advisory along with provision of a mitigation.

 The breakdowns were not in analyzing the reported vulnerability and the 
 proof-of-exploit that accompanied it.  I assume that ooo-security acquitted 
 itself well in that regard as well as with the coordination with other 
 parties, including ones external to Apache, having common concerns.  The 
 breakdown was in all of the non-security considerations and assumptions, even 
 though they needed to be developed in confidence.  The PPMC would have 
 provided a proper arena for working that out.

 The PPMC has much to offer concerning the announcement of CVEs and the 
 appropriate coordination and form of patch releases/updates.  Those with 
 valuable perspective on the deployment strategy and its support might have no 
 sense of the technical work that ooo-security members undertake.


Dennis, if the PPMC wishes to make any changes to the patch, or the
documentation, or the announcement, or the website related this patch,
they have had that ability for nearly a month now.  But no one,
including yourself, has offered one change.  A lot of criticism,
certainly, but no patches. The actions (or inaction) of the PPMC since
this patch was announced proves the point.  It was good enough, and no
one -- including you -- has ventured to raise a finger to improve any
of the patch materials.

-Rob

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

Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[Rob Weir]

On Thu, Apr 12, 2012 at 2:54 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 @Rob,

 In fact, I posted to ooo-dev and ooo-users information on the significance of 
 the vulnerability and ways to mitigate it.


Yes, after the official security bulletin went out to those same lists.  Thanks.

 I was unsuccessful in posting instructions, after several failed attempts, 
 for applying the patch on Windows XP where the dialogs are different and have 
 different consequences than described in the Windows-patch PDF, which gives 
 instructions for Windows 7.  (This has to do with an over-zealous spam filter 
 on our lists and I could not get around it.)  I have however put what I could 
 on the Media Wiki as the basis for a possible FAQ, using
 http://wiki.services.openoffice.org/wiki/Talk:Documentation/FAQ/Installation/How_Can_I_Install_the_Security_Patch_(CVE-2012-0037).


The security bulletin is in SVN.  You can use the CMS or check in the
fix directly.  Or post to BZ as a patch.  There is no need for a spam
filter on the lists to get in your way.


 I can't do anything about the fact that the need for a Linux patch has not 
 been resolved.  I can't do anything about the fact that the patch requires 
 the confidence and experience of a power user to apply on any platform.  I 
 understand why that is; I can't do anything about it myself beyond attempt to 
 provide supporting information and supplementary instructions.


There are others in the PPMC who could do these things if they thought
it was important to do so.  In fact, the definition of important is
pretty much synonymous with it gets someone to take action.

 And I, am, of course, a volunteer here.

 I also don't see what that has to do with the relationship between the PPMC 
 and ooo-security.  That's about getting many eyes, not about where orcmid 
 might exercise his heroic super powers.


But I hope you see my point.  If neither you nor anyone else on the
PPMC has thought it important to address these issues in the month
since the patch has been public, then I do not think that the same
PPMC members would have addressed these concerns if the security team
gave them a heads up a day or two earlier.  Or a week earlier.
Evidently even a month is not even enough.

-Rob

  - Dennis

 -Original Message-
 From: Rob Weir [mailto:robw...@apache.org]
 Sent: Thursday, April 12, 2012 09:46
 To: general@incubator.apache.org
 Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
 Update of April2012 by robweir)

 On Thu, Apr 12, 2012 at 12:32 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 I don't think the problem is with the size of the ooo-security list 
 membership.  I think it is in the assumption that the [P]PMC has somehow 
 delegated the ability to make a release of any kind to the ooo-security 
 team.  I don't mean slip-streaming fixes and working off the public SVN 
 until that happens.  I mean developing and deploying all the rest of what 
 accompanies an advisory along with provision of a mitigation.

 The breakdowns were not in analyzing the reported vulnerability and the 
 proof-of-exploit that accompanied it.  I assume that ooo-security acquitted 
 itself well in that regard as well as with the coordination with other 
 parties, including ones external to Apache, having common concerns.  The 
 breakdown was in all of the non-security considerations and assumptions, 
 even though they needed to be developed in confidence.  The PPMC would have 
 provided a proper arena for working that out.

 The PPMC has much to offer concerning the announcement of CVEs and the 
 appropriate coordination and form of patch releases/updates.  Those with 
 valuable perspective on the deployment strategy and its support might have 
 no sense of the technical work that ooo-security members undertake.


 Dennis, if the PPMC wishes to make any changes to the patch, or the
 documentation, or the announcement, or the website related this patch,
 they have had that ability for nearly a month now.  But no one,
 including yourself, has offered one change.  A lot of criticism,
 certainly, but no patches. The actions (or inaction) of the PPMC since
 this patch was announced proves the point.  It was good enough, and no
 one -- including you -- has ventured to raise a finger to improve any
 of the patch materials.

 -Rob

 -
 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: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of April2012 by robweir)

[Rob Weir]

On Thu, Apr 12, 2012 at 5:08 PM, Dave Fisher dave2w...@comcast.net wrote:

 On Apr 12, 2012, at 1:00 PM, Dennis E. Hamilton wrote:

 Yes, this was already raised on the PPMC (on March 22) as you know.  It 
 seems to me that the PPMC is not concerned.

 It is interesting that it is thought, here, that the remedy is to add more 
 ooo-security subscribers from the PPMC.  That had not come up before.

 Well I did raise it on ooo-private. My suggestion was to add someone who 
 understood Linux distributions to ooo-security ASAP. I got blowback. This  
 was unfortunate. Since then we've had discussions about culture, politeness 
 and apologies. There was some discussion about OpenOffice and Linux distro on 
 ooo-dev, but more in context of the AOO release plans.

 My frustration about not being informed was that no one gave even the 
 slightest notice OFFLIST that there was a reason that certain people were 
 asking the project questions and that things were not as I thought and I 
 should move on and let the world revolve. This is particularly true since I 
 responding with what I had every reason to believe was the project policy.

 Emotions pass. What's the root cause? It's a communication problem, why was 
 communication blocked?

 If there are individuals on a PPMC that the podling security team and Mentors 
 feel are not trustworthy enough that it is decided to forgo the minimal 
 courtesy of keeping the PPMC informed to manage the process as Dennis 
 described then perhaps the problem is with the PPMC membership itself.

 Normally a podling will set the PMC as part the graduation resolution. 
 Perhaps the AOO PPMC membership needs to be revised sooner. Any advice?


So step back, to when the podling received notice of our first
security report.  The Apache Security Team would not give it to the
PPMC, not even on ooo-private.  The issue was not the size of the PPMC
per se, or even its status as a podling.  The issue was the way in
which the initial committers were selected, that anyone could just
walk in off the street in essence, put their name down and be an
instant PPMC number.  Needless to say, a group of nearly 100 initial
committers formed that way is not the best way to have a secure
discussion.

So the request, at that time, was to make a smaller list ---
ooo-security -- and to share such sensitive information only on that
list.  Of course, Mentors and other Apache Members can view that list,
as can Apache Security Team members.


I have no doubts that as a TLP the AOO PMC will shed 30%+ of the
current membership.  That would take care of the names of people who
signed up, returned the ICLA but then have not been heard of since.  I
think we can reach the point where matters of some sensitivity can be
shared more broadly on ooo-private.

But you also need to understand that this is not only about trust.  It
is about security.  If if I personally trusted you like a brother, and
trusted every PPMC member like a brother (or sister) it would not make
sense to share all security information with a list of 90 trusted
siblings..  Why?  Because of human error.  Because of stolen iPhones.
Because of accidentally forwarded emails.  Because  of accidentally
typed recipients.Because of 4am's and because shit happens.  It
will never make sense to share such sensitive information more broadly
than needed to deal with the actual security issue.  This is not about
trust.  It is about compartmentalization,  In other words, the
security list is about security.

-Rob

 Regards,
 Dave



 - Dennis

 -Original Message-
 From: Ross Gardler [mailto:rgard...@opendirective.com]
 Sent: Thursday, April 12, 2012 12:41
 To: general@incubator.apache.org; dennis.hamil...@acm.org
 Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
 Update of April2012 by robweir)

 On 12 April 2012 17:32, Dennis E. Hamilton dennis.hamil...@acm.org wrote:
 I don't think the problem is with the size of the ooo-security list 
 membership.  I think it is in the assumption that the [P]PMC has somehow 
 delegated the ability to make a release of any kind to the ooo-security 
 team.  I don't mean slip-streaming fixes and working off the public SVN 
 until that happens.  I mean developing and deploying all the rest of what 
 accompanies an advisory along with provision of a mitigation.


 Whether this is the case or not should be discussed on the ooo-dev
 lists rather than the IPMC general list. This is not an IPMC issue.
 All IPMC members are free to join that list or read its archives if
 they so desire.

 Ross

 -
 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: 

Re: Is there an ASF license for Apple's Apple Developer Program ?

[Rob Weir]

On Tue, Apr 3, 2012 at 1:43 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 3/31/2012 8:43 AM, Rob Weir wrote:
 On Fri, Mar 30, 2012 at 7:20 AM, Ross Gardler 
 rgard...@opendirective.comwrote:

 There isn't (to my knowledge), I can imagine an increasing number of
 projects wanting such a thing though. Unless someone tells me I'm
 wrong and we already have one would you be interested in seeing if
 Apple are open to such an arrangement?



 I'd recommend first very careful review of the licensing terms first, on
 legal-discuss, to ensure that we're comfortable with any restrictions use
 of their SDK brings.  This would also help with other potential
 contributors who might have iOS apps they would like to contribute, but
 whose current analysis suggests that the Apple terms are incompatible.

 nonsense

 These are the very same SDK tools that these very same Apache Committers 
 already
 use on a daily basis.


The issue, of course, is not what you do with the Apple SDK in the
privacy of your own bedroom.  The question is about creating
dependencies for releases and the restrictions these bring to
downstream consumers.If you want to just say those are questions
for the individual PMC's to resolve, then I'd agree, but I then note
that the IPMC is the PMC for podlings, so my point is in order.

 The only modulo here is that some have access through work.  Some purchase 
 their
 own access.  Some have been comp'ed subscriptions individually or through 
 other
 organizations.

 This simply makes the same tool for a committer free or discounted from what
 they already paid.  For example, I was an MSDN subscriber through work for 
 some
 years, as a consultant for some years, took a break from my subscription on 
 some
 other years.  Now, I'm using a subscription donated for ASF committers.  
 Nothing
 changed.

 Sure, you can have a discussion about whether some WizBang API introduces new
 licensing restrictions, platform lock-in, etc.  But we are NOT GOING TO BEGIN
 auditing the Oracle Developer Suite, the Microsoft Developer Network, the 
 Apple
 Developer Network, the IBM HP VMware Google RedHat Citrix Adobe Amazon (OH GOD
 MAKE IT STOP!!!) developer tool program for every possible future quirk.

 There are real questions to be asked about specific tools and specific api's 
 in
 the open source and closed source world and the projects which are affected 
 need
 to do their homework and work with ASF legal to resolve ambiguity.  But any of
 these examples includes hundreds of tools and api's and sdk's which have no
 intersection with an ASF code base.

 If Jim works out some connections for ASF  Apple and you use Apple then 
 enjoy
 that perk, and otherwise, please EIGNORE?  Thanks :)


 -
 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: Multi-licensed dependencies

[Rob Weir]

On Fri, Mar 30, 2012 at 2:08 PM, sebb seb...@gmail.com wrote:

 On 30 March 2012 17:38, Leo Simons m...@leosimons.com wrote:
  On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote:
  On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote:
  On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
  Personally, I agree with Roy.  Perhaps it might seem a little odd to
 include
  the text of e.g. the GPLv2 in one of our LICENSE files (alongside a
 more
  permissive license), but the key here is that it is both legally OK
 for us to
  distribute a product bundling such a dependency without explicitly
 justifying
  our usage, and legally OK for a downstream consumer to distribute a
 product
  bundling ours which asserts usage of the dependency under a different
  rationale.
 
  I prefer to put our license in the file and then, at the bottom, refer
  to a list of other licenses per dependency (if included in this
 package),
  wherein the dependency licenses are in separate files near the
 dependency.
 
  However, this does not agree with the following [1]:
 
 
  ...
  When an artifact contains code under several licenses, the LICENSE
  file should contain details of all these licenses. For each component
  which is not Apache licensed, details of the component and the license
  under which the component is distributed should be appended to the
  LICENSE file.
  
 
  [1]
 http://www.apache.org/dev/release.html#distributing-code-under-several-licenses
 
  ...the license file SHOULD contain ...
 
  I believe at least some of these
  how-to-put-the-license(s)-into-the-file(s) statements are not
  necessarily backed up by it must be this way legally or this is
  unambiguously always the best way kind of thoughts, but more by this
  is a good standard way to do it, that is easy to do and
  (automatically) verify. So Roy saying I prefer does not necessarily
  conflict with the SHOULD in the policy.
 
  I very much like the approach where the Incubator teaches the
  documented policies that have been defined by Legal. While it's
  probably good to have Roy's preferences (which I trust are good ones)
  reflected in our policy docs, that should happen via legal-discuss in
  this case, and even after that,
  we should not change what we teach our podlings

 This is precisely the issue - there is no single unified message at
 present.
 The approach depends a lot on who happens to be mentoring/reviewing
 releases.

  until the docs have changed. It gets way too confusing way
  too quickly, otherwise.

 It's already confusing.

 Nor do the documents have a single - or even consistent - approach.

 I think a lot of this stems from the fact that the documents tend to
 describe processes and procedures without providing the underlying
 rationale.


+1   That is the key observation.  We need more principles, agreed on and
documented, than we need more policies and rules.

For example, the core licensing criteria makes a simple but solid statement
that has allowed us to adapt to the changing licensing landscape by
applying these principles to new situations:

http://www.apache.org/legal/resolved.html#criteria

It would be great if we had similar compact statement on the intent of
LICENSE and NOTICE.

-Rob



 The statement from Roy about open source and the ASF incorporation was
 very useful in understanding the existing doumentation.

 I think the foundation assumptions need to be clearly documented so
 the derived processes and rules can be better understood.

 
  cheerio,
 
 
  Leo
 
  -
  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: Is there an ASF license for Apple's Apple Developer Program ?

[Rob Weir]

On Fri, Mar 30, 2012 at 7:20 AM, Ross Gardler rgard...@opendirective.comwrote:

 There isn't (to my knowledge), I can imagine an increasing number of
 projects wanting such a thing though. Unless someone tells me I'm
 wrong and we already have one would you be interested in seeing if
 Apple are open to such an arrangement?



I'd recommend first very careful review of the licensing terms first, on
legal-discuss, to ensure that we're comfortable with any restrictions use
of their SDK brings.  This would also help with other potential
contributors who might have iOS apps they would like to contribute, but
whose current analysis suggests that the Apple terms are incompatible.

-Rob


 Ross

 On 30 March 2012 12:10, seba.wag...@gmail.com seba.wag...@gmail.com
 wrote:
  Hi,
 
  we would like to build a client prototype for Apache OpenMeetings for the
  iOS platform.
 
  But you have to pay a fee to get a developer certificate.
 
  Is there an ASF license program with Apple so that committers can access
  Apple's Developer Program for free for their projects?
 
  Thanks!
  Sebastian
  --
  Sebastian Wagner
  https://twitter.com/#!/dead_lock
  http://www.openmeetings.de http://incubator.apache.org/openmeetings/
  http://www.webbase-design.de
  http://www.wagner-sebastian.com
  seba.wag...@gmail.com



 --
 Ross Gardler (@rgardler)
 Programme Leader (Open Development)
 OpenDirective http://opendirective.com

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

Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)

[Rob Weir]

On Tue, Mar 27, 2012 at 1:16 PM, Roy T. Fielding field...@gbiv.com wrote:

 On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote:

  Hi,
 
  [dropped infra@, I believe most interested people are already on
 general@]
 
  Let's decouple this thread from the specific issue of the ManifoldCF
  release. There's a long tradition of Apache releases like the ones
  ManifoldCF is producing, so turning this suddenly into a blocker is
  IMHO bad business, especially since no legal issues are involved (this
  is about Apache policy). If we do come to the consensus that releases
  like this are contrary to Apache policy, then affected projects should
  be given a reasonable amount of time to adapt.

 I don't see where you get the idea that there is a long tradition of
 including binary artifacts within the source package releases at Apache.
 There may be specific groups who are apparently lacking the appropriate
 clue and stubbornly refuse to read the messages I have sent multiple
 times to this mailing list, legal-discuss, and members, but there is
 no question whatsoever that a source package cannot include binaries.
 It would not be a source package otherwise.


I think this may be overstating things. The issue should be lack of source
code, not presence of binary code.

For example, I could have a Java code that relies on a native method
implemented in C code.  I could have a source package that contains the
complete Java and the complete C code, all under ALv2.  But do we really
want to say that we cannot also include, in the source page, the native
code, pre-compiled as a convenience for the developer?

The alternative would be that a downstream developer who is modifying only
unrelated Java portions of the source code would be required to compile the
native code on all platforms in order to create a package.  (It would also
require the PMC to have rather elaborate build rituals to create that JAR,
since it would require that we shuffle libraries across multiple buildbots)

-Rob

Re: Request for an early review of an potential Apache OpenOffice release

[Rob Weir]

On Wed, Mar 14, 2012 at 11:23 PM, Marvin Humphrey
mar...@rectangular.com wrote:
 2012/3/13 Jürgen Schmidt jogischm...@googlemail.com:
 we have prepared a new developer snapshot on the way to our first release.

 Congratulations on your progress so far!


And thanks for reviewing out dev snapshot build.

 We would very much appreciate some early feedback if possible.

 I can do a little bit of surface level checking.  Ordinarily, I would probe
 deeper into source code provenance, but in this case I will have to trust the
 AOO PPMC and the AOO Mentors that proper diligence has been exercised.


We've tried to publicly document what we did to clean up the code on our wiki:

https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance

By clean up we mean that OpenOffice.org consisted of code that we
received under SGA, but it also had some dependencies on 3rd party
open source libraries.  We've gone through each one, and removed the
ones that had incompatible licenses.  In almost every case we were
fortunate to find a good substitute with a compatible license.


 The PGP signature and the checksums on the tar.gz archive all looked good.
 FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS and
 some of the checksum files, and the format of the checksum files will not work
 with md5sum --check and shasum --check -- but that's all nitpicking.


Good to know.

 I was a little surprised that the LICENSE file contained only the ALv2, and
 that NOTICE points at the websites for dependencies and their licensing.
 Ordinarily, I would expect to see entire verbatim licenses for all bundled
 dependencies in LICENSE.


OK.

 The README starts with a UTF-8-encoded BOM.  Just FYI.

 I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file or
 the README.  Also, the word incubating is not in the archive filename.


OK.

 Hope this helps as a start at least,


Yes, thanks.

-Rob

 Marvin Humphrey

 marvin@smokey:~/Desktop $ gpg --verify aoo-3.4-src.tar.gz.asc
 gpg: Signature made Tue Mar 13 00:52:11 2012 PDT using RSA key ID 51B5FDE8
 gpg: Good signature from Juergen Schnmidt j...@apache.org
 gpg:                 aka Juergen Schmidt jogischm...@googlemail.com
 gpg:                 aka Juergen Schmidt jogischm...@gmail.com
 gpg: WARNING: This key is not certified with a trusted signature!
 gpg:          There is no indication that the signature belongs to the owner.
 Primary key fingerprint: D09F B15F 1A24 768D DF1F  A29C CFEE F316 51B5 FDE8
 marvin@smokey:~/Desktop $ gpg --print-md MD5 aoo-3.4-src.tar.gz
 aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2  54 DC 6C E2 3C 32 5F 17
 marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.md5.txt
 aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2  54 DC 6C E2 3C 32 5F 17
 marvin@smokey:~/Desktop $ gpg --print-md SHA1 aoo-3.4-src.tar.gz
 aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468  24CC D245 2DEB 9171 6689
 marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha1.txt
 aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468  24CC D245 2DEB 9171 6689
 marvin@smokey:~/Desktop $ gpg --print-md SHA512 aoo-3.4-src.tar.gz
 aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
                    CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
                    C62161B5 F16FE64B 5CD144FF ED043D33
 marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha512
 aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
                    CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
                    C62161B5 F16FE64B 5CD144FF ED043D33

 -
 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: [SITE] CMS cutover for incubator site on Monday

[Rob Weir]

On Sat, Mar 3, 2012 at 10:39 AM, Joe Schaefer joe_schae...@yahoo.com wrote:
 I'll be cutting over the incubator site to
 svnpubsub based on the CMS this coming Monday.
 Please be advised this will impact the workflow
 for publishing stuff: instead of committing build
 output to site-publish and svn upping the tree
 on people.apache.org, you will instead publish
 your changes by either visiting

     https://cms.apache.org/incubator/publish

 or by using the publish.pl script on people.apache.org.

So for the podling status files, we currently do this:

http://incubator.apache.org/openofficeorg/ppmc-faqs.html#status

So, we edit the XML, ant, svn commit the changed XML and generated
HTML, then go to people.apache.org and svn update.

Does this just change the last step, so instead of an svn update on
people.apache.org we do the publish script?  Or something else?

-Rob


 Please read up on CMS usage at

     http://www.apache.org/dev/cms
     http://www.apache.org/dev/cmsref

 Thanks for your attention!

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

Re: [VOTE] Release Apache ODF Toolkit 0.5-incubating(RC7)

[Rob Weir]

On Sun, Jan 1, 2012 at 5:27 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 =0 (abstain, non-binding [;) from me.

 With a different build configuration, I have matching results to the
 successful builds reported by others.  I don't know enough to interpret the
 outcome or the console-message details that occurred during the build.  I
 presume that it is desirable to eliminate [ERROR] and [WARNING] messages at
 some future opportunity; there does not appear to be any impact on the
 results.


Some quick comments.  The build output is rather verbose.  It has
always been that way, including in the legacy releases pre-Apache.   I
don't see anything new.

Our goal with this first podling release has been modest.  We wanted
to take the most-recent release from the ODF Toolkit Union, migrate
the website and combine what was previously separately released
modules (ODFDOM, Simple API, Validator, etc.) into a single ODF
Toolkit release.  We didn't set a goal of being bug free.   After
all, we did make some effort to migrate over the legacy Bugzilla
database as well.  We fixed a few bugs, of course.  But generally this
releases is functionally equivalent to the prior release at the ODF
Toolkit Union.

I'm hoping that we can use the buzz from our initial release to
attract more attention to this project, get in a few new contributors
to increase the diversity of the project, and build upon this for more
exciting 2nd release.  The fact that ODF 1.2 was approved as an OASIS
Standard since our last legacy release is also important.

-Rob

  - Dennis

 ANALYSIS AND SUMMARY

 Console Session (line breaks added for readability):
 ---

    * MyMaven64.bat 0.02 64-BIT APACHE MAVEN PROJECT-OBJECT ENVIRONMENT
    ** MyJDK64.bat 0.02 orcmid's ASTRAENDO 64-BIT JDK ENVIRONMENT
             JDK C:\Program Files\Java\jdk1.6.0_30
             %myJavaClasses% path C:\Users\orcmid\Documents\MyProjects\java
             No %MAVEN_OPTS% for C:\Program Files\Apache\Maven\3.0.3


    C:\Users\orcmid\Downloads\odf-toolkit-rcmvn --version
    Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800)
    Maven home: C:\Program Files\Apache\Maven\3.0.3
    Java version: 1.6.0_30, vendor: Sun Microsystems Inc.
    Java home: C:\Program Files\Java\jdk1.6.0_30\jre
    Default locale: en_US, platform encoding: Cp1252
    OS name: windows 7, version: 6.1, arch: amd64, family: windows

    C:\Users\orcmid\Downloads\odf-toolkit-rccd odftoolkit-0.5-incubating

    C:\Users\orcmid\Downloads\odf-toolkit-rc\odftoolkit-0.5-incubating
       mvn clean install 2012-01-01-1204-install.log

    C:\Users\orcmid\Downloads\odf-toolkit-rc\odftoolkit-0.5-incubatingexit

 Maven Log
 -

 There is a 1.2 MB console log produced from the clean install.  The summary on
 the end agrees with other successful reports ([INFO] prefixes deleted to avoid
 line-wrap):

 -
 Reactor Summary:

 Apache ODF Toolkit  SUCCESS [1.061s]
 ODF Custom Javadoc Taglets  SUCCESS [7.308s]
 XML Schema to Template Mapping Tool: Parent POM ... SUCCESS [0.031s]
 XML Schema to Template Mapping Tool: Library .. SUCCESS [35.771s]
 XML Schema to Template Mapping Tool: Maven2 Plugin  SUCCESS [4.852s]
 ODFDOM  SUCCESS [3:32.479s]
 ODF XSLT-Runner ... SUCCESS [4.680s]
 ODF XSLT-Runner Ant Task .. SUCCESS [4.555s]
 ODF Validator . SUCCESS [51.741s]
 Simple Java API for ODF (Simple ODF) .. SUCCESS [1:25.020s]
 ---
 BUILD SUCCESS
 ---
 Total time: 6:47.919s
 Finished at: Sun Jan 01 12:11:29 PST 2012
 Final Memory: 26M/270M
 ---

 Note: This is not a first-time clean install.  That one took longer because of
 dependency downloads.  I didn't have the foresight to redirect the voluminous
 console output.


 Summary Log
 ---

 The attachment, 2012-01-01-1313-logsummary.txt (110 kb), is a distillation of
 the 1.2 MB console log to retain only headings, the summaries, and any Error
 and Warning messages.  None of these appear to impact achievement of a
 successful result.

 This is an eyeball analysis of the summary:

 Some tests are reported as skipped.  No run tests are reported to have failed
 or had errors.

 Three recurring [ERROR] reports involve inability to fetch a link.  Those are
 ignored.

 There are recurring [WARNING] messages from JavaDoc with regard to unknown
 tags.

 There are a substantial number of [WARNING] messages concerning deprecated
 org.odftoolkit.odfdom.doc.* and org.odftoolkit.odfdom.incubator.* types.

 There are also some deprecated members in some classes.

 These different 

Re: [VOTE] Release Apache ODF Toolkit 0.5-incubating(RC7)

[Rob Weir]

2011/12/27 Devin Han devin...@apache.org:
 Hi all,

 Please vote on releasing the following candidate as Apache ODF Toolkit
 (incubating) version 0.5. This will be the first incubator release for
 ODF Toolkit in Apache.

 This release candidate fixes the pom.xml file inconsistant issue found in
 RC6. Thanks Yegor!

 The candidate for the ODF Toolkit 0.5-incubating release is available at:

 http://people.apache.org/~devinhan/odftoolkit-release/odftoolkit-0.5-incubating-rc7/

 The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/incubator/odf/tags/odftoolkit-0.5-incubating/


Sorry for the delay in responding.  I was traveling over the Christmas holiday.

I downloaded the source tar.gz file for the release candidate.

Here's my environment (mvn --version):

Apache Maven 2.2.1 (rdebian-6)
Java version: 1.6.0_23
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 3.0.0-14-generic arch: i386 Family: unix

I did an mvn clean install and all modules built and tested without error:

[INFO]
[INFO]
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache ODF Toolkit  SUCCESS [27.311s]
[INFO] ODF Custom Javadoc Taglets  SUCCESS
[11:37.233s]
[INFO] XML Schema to Template Mapping Tool: Parent POM ... SUCCESS [0.250s]
[INFO] XML Schema to Template Mapping Tool: Library .. SUCCESS [49.373s]
[INFO] XML Schema to Template Mapping Tool: Maven2 Plugin  SUCCESS [13.649s]
[INFO] ODFDOM  SUCCESS
[9:44.490s]
[INFO] ODF XSLT-Runner ... SUCCESS [11.922s]
[INFO] ODF XSLT-Runner Ant Task .. SUCCESS [3.367s]
[INFO] ODF Validator . SUCCESS
[1:13.174s]
[INFO] Simple Java API for ODF (Simple ODF) .. SUCCESS
[5:04.813s]
[INFO] 
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 29 minutes 34 seconds
[INFO] Finished at: Wed Dec 28 20:33:38 EST 2011
[INFO] Final Memory: 116M/270M
[INFO] 

If someone can try on Windows, that would be great as well.

 The SHA1 checksum of the zip archive is
 4e97a1a79291035d590b5578caf79478dc3f6de8.
 The MD5 checksum of the zip archive is 8883f036ee34282077d3c175329f6257.

 Besides source code, binary packages and javadoc packages are also listed
 in：
 http://people.apache.org/~devinhan/odftoolkit-release/odftoolkit-0.5-incubating-rc7/

 All of the artifacts supply three package formats, tar.gz, tar.bz2 and zip.

 Keys:
    http://www.apache.org/dist/incubator/odftoolkit/KEYS

 Please vote on releasing this package as Apache ODF Toolkit 0.5-incubating.
 The vote is open for the next full week, until Tuesday, Jan 3rd, 2012, 6pm,
 because of the New Year holiday and passes if a majority of at least 3 +1
 IPMC votes are cast.

   [ ] +1 Release this package as Apache ODF Toolkit 0.5-incubating
   [ ] -1 Do not release this package because...


+ 1 from me

-Rob



 To learn more about Apache ODF Toolkit, please access:
 http://incubator.apache.org/odftoolkit/.
 @OOo-Dev, @POI-Dev, @Tika-Dev and @PDFBox-Dev, so sorry for the interrupt.
 CC to you just wish to get your feedback, as your projects have more or
 less interaction with ODFToolkit and we need more votes.


 Thanks,
 Devin

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

Re: Non English Mailing Lists

[Rob Weir]

On Wed, Dec 14, 2011 at 7:34 AM, seba.wag...@gmail.com
seba.wag...@gmail.com wrote:
 Hi,

 I would like to clarify if Non-English Mailing lists are allowed.

 Background: I missed in our Proposal the Mailing List:
 http://groups.google.com/group/openmeetings-en-espanol/about?hl=en_US
 We made now a Vote on our Developer List to add this mailing list and the
 Moderators from the GoogleGroups List have applied to become the Moderator
 of the new list. Everythings fine from my point of view.

 But I've heard that using Non-English List is not allowed on Apache
 Infrastructure. Is that true?
 It makes me wonder as the OpenOffice project has 100++ Mailing lists in a
 lot of different languages. So I guess there is no such restriction and we
 can proceed right?


Aside from the good advice Ross gave, I'd point out one technical
issue we did run into with the OpenOffice podling.  The issue was
related to character encoding and mailing list archives.  The issue is
here:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52195

So depending on what language you are looking at, this may or may not
be an issue for you.

-Rob


 Thanks,
 Sebastian
 --
 Sebastian Wagner
 http://www.openmeetings.de
 http://www.webbase-design.de
 http://www.wagner-sebastian.com
 seba.wag...@gmail.com

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

Re: timeline of Apache Incubator history

[Rob Weir]

On Sat, Oct 22, 2011 at 12:18 AM, Gavin McDonald ga...@16degrees.com.au wrote:


 -Original Message-
 From: Rob Weir [mailto:robw...@apache.org]
 Sent: Saturday, 22 October 2011 8:03 AM
 To: general@incubator.apache.org
 Subject: Re: timeline of Apache Incubator history

 On Fri, Oct 21, 2011 at 2:57 AM, David Crossley cross...@apache.org
 wrote:
  Rob Weir wrote:
  David Crossley wrote:
  
   Please see
   http://incubator.apache.org/history/
  
   This is a Timeplot chart of the number of projects handled by the
   Incubator.
  
   The green line shows the Count podlings entered incubation.
   The yellow line shows the Total podlings currently in incubation.
  
   The growth of the yellow line is showing that we do have more
   podlings entering incubation than graduating/retiring.
   This is not sustainable.
 
  Are there any stats on mentors over time?
 
  Not yet, but we could start now. Perhaps could programatically obtain
  historical data using svn from the old projects/index.xml file.
 
  Clutch has been gathering and showing the mentors list at
  http://incubator.apache.org/clutch.html#mentors
 
  What statistics were you thinking of?
  Perhaps total number of member/project instances.
  Something else?

 With classrooms, the student-to-teacher ratio is something that is often
 looked at.  The equivalent would probably be the mentor:PPMC member
 ratio

  Over-committedness index perhaps? :-)
 

 Exactly.

 So rather than be congratulatory of Mentors you want these stats to call
 them out for doing too much ? What then, tell them to resign if they are doing
 more than how many projects , 3 , 4 , 7 ?


1. Nothing in the stats I proposed would talk about the efforts of any
individual mentor.  It is aggregate information.

2. The natural interpretation would be to highlight when there is an
overall need for more mentors.

3. This could be especially useful as an early warning sign, i.e., a
leading indicator

4. No one can prevent someone from taking statistics and misinterpreting them.

 Far out.


See #4.



  -David
 
  -
  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: timeline of Apache Incubator history

[Rob Weir]

On Fri, Oct 21, 2011 at 2:57 AM, David Crossley cross...@apache.org wrote:
 Rob Weir wrote:
 David Crossley wrote:
 
  Please see
  http://incubator.apache.org/history/
 
  This is a Timeplot chart of the number of projects
  handled by the Incubator.
 
  The green line shows the Count podlings entered incubation.
  The yellow line shows the Total podlings currently in incubation.
 
  The growth of the yellow line is showing that we do have
  more podlings entering incubation than graduating/retiring.
  This is not sustainable.

 Are there any stats on mentors over time?

 Not yet, but we could start now. Perhaps could programatically
 obtain historical data using svn from the old projects/index.xml file.

 Clutch has been gathering and showing the mentors list at
 http://incubator.apache.org/clutch.html#mentors

 What statistics were you thinking of?
 Perhaps total number of member/project instances.
 Something else?

With classrooms, the student-to-teacher ratio is something that is
often looked at.  The equivalent would probably be the mentor:PPMC
member ratio

 Over-committedness index perhaps? :-)


Exactly.

 -David

 -
 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: timeline of Apache Incubator history

[Rob Weir]

On Thu, Oct 20, 2011 at 4:03 AM, David Crossley cross...@apache.org wrote:
 Please see
 http://incubator.apache.org/history/

 This is a Timeplot chart of the number of projects
 handled by the Incubator.

 The green line shows the Count podlings entered incubation.
 The yellow line shows the Total podlings currently in incubation.

 The growth of the yellow line is showing that we do have
 more podlings entering incubation than graduating/retiring.
 This is not sustainable.


Are there any stats on mentors over time?

-Rob

 -David

 -
 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][RESULT] Accept ODF Toolkit for Incubation

[Rob Weir]

2011/8/9 Ying Chun Guo guoyi...@cn.ibm.com:

 Nick Burch nick.bu...@alfresco.com 写于 08/09/2011 06:47:05 PM:

 Nick Burch nick.bu...@alfresco.com
 08/09/2011 06:47 PM

 Please respond to
 general@incubator.apache.org

 To

 general@incubator.apache.org

 cc

 Subject

 Re: [VOTE][RESULT] Accept ODF Toolkit for Incubation

 On Tue, 9 Aug 2011, Mohammad Nour El-Din wrote:
  I would like to help as well if you still need more mentors :).

 If you've got the spare cycles, please feel free to give us a hand!
 Currently we have our minimum of 3 mentors:
     http://incubator.apache.org/projects/odftoolkit.html


 I'd like to raise my hand. You can count me in.


Hi Daisy, In this context a mentor is an experienced Apache member,
from the Incubation Project Management Committee (IPMC) who volunteers
to help the new Podling understand Apache and how it works.

You can read about Mentors (and other roles) here:

http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor

-Rob

 Nick

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



 Regards
 Ying Chun Guo (Daisy)
 Manager, China Standards Growth Team
 Emerging Technology Institute (ETI)
 IBM China Development Lab
 Tel:(86-10)82453491
 Email: guoyi...@cn.ibm.com
 Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park,
 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193

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

Apache ODF Toolkit Podling Status Report (Draft)

[Rob Weir]

Devin noticed that we have our first status report due to the Apache
Board tomorrow (Wed). But we don't have an Apache mailing list to
discuss this yet.

So, I've pasted Devin's draft into the wiki. You can review it here:
http://wiki.apache.org/incubator/August2011Search for
ODFToolkit.

Obviously, we don't have much status yet.  But if you have any
additional changes, either make them directly in the wiki or respond
to all and we can discuss.

We need a mentor to sign off on the status report as well.

I'm sending this note to all the initial committers as well as
general@incubator.a.o, in the interest of transparency.

-Rob

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

Re: [VOTE][RESULT] Accept ODF Toolkit for Incubation

[Rob Weir]

On Mon, Aug 1, 2011 at 7:05 AM, Nick Burch nick.bu...@alfresco.com wrote:
 On Sun, 31 Jul 2011, Sam Ruby wrote:

 On Thu, Jul 28, 2011 at 3:53 PM, Sam Ruby ru...@intertwingly.net wrote:

 As the discussions on the ODF Toolkit threads seem to be winding down,
 I would like to initiate the vote to accept the ODF Toolkit as an
 Apache Incubator project.

 This vote will close 72 hours from now.

 Voting is now closed.  Quorum was achieved, and the vote passes.

 Great. I've gone ahead and added the podling status page:
    http://incubator.apache.org/projects/odftoolkit.html
 (may take an hour or two for the site publish to go live though)


Thanks!


 Next step is probably to get the lists setup, so we can use them to discuss
 importing the code, website etc.

 Can I have a couple of volunteers to be moderators for the lists? (List
 moderators review emails from non members, and approve if appropriate or
 discard if spam). Once we've a few volunteers, I can ask infra to create the
 lists


I can moderate as well.


 I'll contact people needing iCLAs shortly

 Nick

 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Mon, Jul 25, 2011 at 10:38 AM, Sam Ruby ru...@intertwingly.net wrote:
 On Mon, Jul 25, 2011 at 3:27 AM, Yegor Kozlov yegor.koz...@dinom.ru wrote:

 Can we do this for now?  If anyone is committed to the project and
 able to contribute, please respond to this note with some indication
 of your interest.  The proposers can then review this information and
 add names to the wiki accordingly.  There is a  checks and balances
 aspect to this as well.  If the proposers are seen as rejecting
 earnest offers of help from the community, then that could clearly be
 a factor in how the proposal is voted on.


 Shall we cc the proposal to the Tika and PDFBox dev lists? These
 projects are listed in the Relationships section and there may be
 interest on their side too.

 Please forward the proposal as you see fit.

 Meanwhile, I'm only seeing positive responses.  If we call for a vote
 in 72 hours (late morning EDT on Thusrday) is that enough time for
 discussion?


Sam, I think we're ready for the vote now.

Thanks,

-Rob

 - Sam Ruby

 -
 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] Accept ODF Toolkit for Incubation

[Rob Weir]

 Please cast your votes:

 [  ] +1 Accept ODF Toolkit for incubation
 [  ] +0 Indifferent to ODF Toolkit incubation
 [  ] -1 Reject ODF Toolkit for incubation


+1

Regards,

-Rob

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

Re: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

http://wiki.apache.org/incubator/ODFToolkitProposal

This proposal was sent to the Apache Incubator list a week ago.  It
was suggested that the PDFBox and Tiki projects should be contacted as
well, to make members aware of this proposal.

If you have comments, please follow up to general@incubator.apache.org.

Regards,

-Rob

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

Re: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Mon, Jul 25, 2011 at 5:26 AM, Mohammad Nour El-Din
nour.moham...@gmail.com wrote:
 +1 on the proposal

 But comment though on the mailing lists you asked for, I updated them,
 so would you please take a look. In brief the changes are:

 1- You missed adding odf-private@ which is for Podling Project
 Management Committee specific discussion which MUST be private.
 2- For issues and CI notifications we use the dev@ for that purpose no
 need to have their own mailing lists.


Thanks.

 One last note, I believe you need to rename your mailing lists to be
 deft-*. I could have done that but wanted to notify you first :).


For this proposal, odf is correct.  But I am open to other names for
the project, since The Apache ODF Toolkit is rather long.  If we
want Dutch towns, maybe Apache Gouda?  That would result in a logo
that even I, with my limited graphics skill, could design ;-)

 On Mon, Jul 25, 2011 at 9:27 AM, Yegor Kozlov yegor.koz...@dinom.ru wrote:

 Can we do this for now?  If anyone is committed to the project and
 able to contribute, please respond to this note with some indication
 of your interest.  The proposers can then review this information and
 add names to the wiki accordingly.  There is a  checks and balances
 aspect to this as well.  If the proposers are seen as rejecting
 earnest offers of help from the community, then that could clearly be
 a factor in how the proposal is voted on.


 Shall we cc the proposal to the Tika and PDFBox dev lists? These
 projects are listed in the Relationships section and there may be
 interest on their side too.

 Yegor

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





 --
 Thanks
 - Mohammad Nour
   Author of (WebSphere Application Server Community Edition 2.0 User Guide)
   http://www.redbooks.ibm.com/abstracts/sg247585.html
 - LinkedIn: http://www.linkedin.com/in/mnour
 - Blog: http://tadabborat.blogspot.com
 
 Life is like riding a bicycle. To keep your balance you must keep moving
 - Albert Einstein

 Writing clean code is what you must do in order to call yourself a
 professional. There is no reasonable excuse for doing anything less
 than your best.
 - Clean Code: A Handbook of Agile Software Craftsmanship

 Stay hungry, stay foolish.
 - Steve Jobs

 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Thu, Jul 21, 2011 at 1:23 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
  1. In the proposal,

 The coders on the existing ODF Toolkit will comprise the initial committers 
 on the Apache project. These committers have varying degrees of experience 
 with Apache-style open source development, ranging from none to being 
 committers on other Apache projects.

 That strikes me as inadequately expansive/inclusive.  It makes me wonder, why 
 doesn't the project simply stay where it is?  You appear to have a definite 
 roadmap for how you want to see this project proceed.


That text is in response to the core developers section of the
proposal. If you look at the Apache Incubation Proposal Guide [1], you
will see that our response is in line with the examples given.

You probably want to review the rationale section for the why question.


[1] http://incubator.apache.org/guides/proposal.html#template-core-developers


  2. Also, the current code carries template Apache ALv2 notices with 
 copyright statements such as

    /
    *
    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER
    *
    * Copyright 2008, 2010 Oracle and/or its affiliates. All rights reserved.
    * Copyright 2009, 2010 IBM. All rights reserved.
    * [... usual ALv2 template text ...]
    */

 Is it intended that there be an SGA or will this code simply be adapted as 
 licensed?  [I am curious because I have been restructuring some projects of 
 mine along these lines and I'd like to see how that works.]


SGA's are for donations of code or documentation.  No one is donating
anything here.  Apache does not typically aggregate copyright and the
code is already under an Apache 2.0 license.  So the copyright
statements in the code are factual, but irrelevant from Apache's
perspective, to the extent that all the code is also properly under
the Apache 2.0 license.

  3. In the code base, there appear to be other committers (e.g., Devin and 
 Michel).  Is there some reason they are not among the initial committers?  
 Are the listed Initial Committers the only current committers on the ODF 
 Toolkit projects?


All existing committers to the ODF Toolkit were contacted and asked
whether they wanted their names added to the proposal.  The ones who
took us up on the offer are listed.  Also, note that some of the
Chinese project members use Western nicknames (like 'Devin'), so
correlating the legal iCLA names to their ID's will require some care.

  4. Can we know the contact e-mail and current iCLA status of the initial 
 committers?


Yes, we can work on that.

  - Dennis

 -Original Message-
 From: Dave Fisher [mailto:dave2w...@comcast.net]
 Sent: Thursday, July 21, 2011 08:03
 To: general@incubator.apache.org
 Subject: Re: [PROPOSAL] ODF Toolkit for Incubation


 On Jul 21, 2011, at 7:10 AM, Andy Brown wrote:

 Rob Weir wrote:
 On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net 
 wrote:
 Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal

 -Rob

 What can I do to help?



 Good question.  Once the project is set up, there will be many areas
 where we would benefit from contributions.  Naturally, this includes
 Java programmers, but also QA, documentation, and of course, users.

 I was referring to get it approved as an incubator project.  I see no
 where to sign up as a committer as we had with OOo.

 I would like to help as well. Are people allowed to add their names to the 
 proposal?

 Regards,
 Dave
 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Thu, Jul 21, 2011 at 11:02 AM, Dave Fisher dave2w...@comcast.net wrote:

 On Jul 21, 2011, at 7:10 AM, Andy Brown wrote:

 Rob Weir wrote:
 On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net 
 wrote:
 Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal

 -Rob

 What can I do to help?



 Good question.  Once the project is set up, there will be many areas
 where we would benefit from contributions.  Naturally, this includes
 Java programmers, but also QA, documentation, and of course, users.

 I was referring to get it approved as an incubator project.  I see no
 where to sign up as a committer as we had with OOo.

 I would like to help as well. Are people allowed to add their names to the 
 proposal?


I've been told that the way we opened things up for initial committers
on the OpenOffice proposal was not the norm.  I was pointed to this
post that explained the danger of extreme approaches in either
direction, piling on versus not letting anyone new in:

http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3c5353a3c4-4ccc-4673-a00f-b9ce3193c...@gbiv.com%3E

So it appears that the decision on initial committers rests with the
proposers, which I count as myself and the other names listed
initially.  Personally, I would welcome anyone who is committed to the
success of the project and is able to contribute in one way or
another.  But I'd like to see what my co-proposers think on this as
well.

Can we do this for now?  If anyone is committed to the project and
able to contribute, please respond to this note with some indication
of your interest.  The proposers can then review this information and
add names to the wiki accordingly.  There is a  checks and balances
aspect to this as well.  If the proposers are seen as rejecting
earnest offers of help from the community, then that could clearly be
a factor in how the proposal is voted on.

-Rob


 Regards,
 Dave
 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

2011/7/22 Jürgen Schmidt jogischm...@googlemail.com:
 Hi Rob,

 On Thu, Jul 21, 2011 at 8:02 PM, Rob Weir apa...@robweir.com wrote:

 On Thu, Jul 21, 2011 at 11:02 AM, Dave Fisher dave2w...@comcast.net
 wrote:
 
  On Jul 21, 2011, at 7:10 AM, Andy Brown wrote:
 
  Rob Weir wrote:
  On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net
 wrote:
  Rob Weir wrote:
  And I've added it to the wiki:
  http://wiki.apache.org/incubator/ODFToolkitProposal
 
  -Rob
 
  What can I do to help?
 
 
 
  Good question.  Once the project is set up, there will be many areas
  where we would benefit from contributions.  Naturally, this includes
  Java programmers, but also QA, documentation, and of course, users.
 
  I was referring to get it approved as an incubator project.  I see no
  where to sign up as a committer as we had with OOo.
 
  I would like to help as well. Are people allowed to add their names to
 the proposal?
 

 I've been told that the way we opened things up for initial committers
 on the OpenOffice proposal was not the norm.  I was pointed to this
 post that explained the danger of extreme approaches in either
 direction, piling on versus not letting anyone new in:


 http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/%3c5353a3c4-4ccc-4673-a00f-b9ce3193c...@gbiv.com%3E

 So it appears that the decision on initial committers rests with the
 proposers, which I count as myself and the other names listed
 initially.  Personally, I would welcome anyone who is committed to the
 success of the project and is able to contribute in one way or
 another.  But I'd like to see what my co-proposers think on this as
 well.

 Can we do this for now?  If anyone is committed to the project and
 able to contribute, please respond to this note with some indication
 of your interest.  The proposers can then review this information and
 add names to the wiki accordingly.  There is a  checks and balances
 aspect to this as well.  If the proposers are seen as rejecting
 earnest offers of help from the community, then that could clearly be
 a factor in how the proposal is voted on.


 i would be interested in this project in the same way as i was as a project
 member of the existing project. Well i was not really active in the past as
 a developer because of some other internal to-dos but this can be changed.


Hello Jürgen ,

I'd like to invite you to sign up as an initial committer on the wiki here:

http://wiki.apache.org/incubator/ODFToolkitProposal

Regards,

-Rob


 Juergen


 -Rob


  Regards,
  Dave
  -
  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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Thu, Jul 21, 2011 at 11:02 AM, Dave Fisher dave2w...@comcast.net wrote:

 On Jul 21, 2011, at 7:10 AM, Andy Brown wrote:

 Rob Weir wrote:
 On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net 
 wrote:
 Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal

 -Rob

 What can I do to help?



 Good question.  Once the project is set up, there will be many areas
 where we would benefit from contributions.  Naturally, this includes
 Java programmers, but also QA, documentation, and of course, users.

 I was referring to get it approved as an incubator project.  I see no
 where to sign up as a committer as we had with OOo.

 I would like to help as well. Are people allowed to add their names to the 
 proposal?


Hi Dave,

I'd like to invite you to sign up as an initial committer on the wiki here:

http://wiki.apache.org/incubator/ODFToolkitProposal

Regards,

-Rob


 Regards,
 Dave
 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Thu, Jul 21, 2011 at 10:10 AM, Andy Brown a...@the-martin-byrd.net wrote:
 Rob Weir wrote:
 On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net wrote:
 Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal

 -Rob

 What can I do to help?



 Good question.  Once the project is set up, there will be many areas
 where we would benefit from contributions.  Naturally, this includes
 Java programmers, but also QA, documentation, and of course, users.

 I was referring to get it approved as an incubator project.  I see no
 where to sign up as a committer as we had with OOo.


Hi Andy,

I'd like to invite you to sign up as an initial committer on the wiki here:

http://wiki.apache.org/incubator/ODFToolkitProposal

Regards,

-Rob

 Andy

 -
 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: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown a...@the-martin-byrd.net wrote:
 Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal

 -Rob

 What can I do to help?



Good question.  Once the project is set up, there will be many areas
where we would benefit from contributions.  Naturally, this includes
Java programmers, but also QA, documentation, and of course, users.

Some specific things that I think would be interesting, if we had more
contributors:

- Work on improving the JavaDoc.  What we have now is thin and would
benefit from editing by someone with English fluency.

- Quantify our unit test test-coverage and write additional targeted
unit tests so that we achieve 100% coverage

- A module that takes an ODF document as input and generates code,
expressed in the ODF Toolkit, that would when executed created the
original ODF document.  It sound weird, but think about it.  This
would allow someone to jump-start a program that produced customized
versions of that document.

- Implement OpenFormula, the spreadsheet formula language of ODF 1.2

- We occasionally get a report of concurrency bugs. These, as you may
know, are notoriously hard to debug and fix.  Is there something we
can be doing to shake out these errors earlier, during test?  What is
the state of the art here in static and dynamic analysis?

- We have a cookbook [1] of sample snippets of code that illustrate
common problem/solution pairs, like how to copy a slide from another
presentation deck.  This cookbook is very useful and popular.  But
there is much room for expansion.

- Performance -- profiling and tuning is needed.

- A more radical way to achieve greater performance would be to have a
streaming-mode API that does not require building a DOM at all.  This
would be limited in what you can do with it -- especially limited to
what can be done within a single pass over the document -- but could
be highly optimized.  For example, suppose you just want to extract
the author's name and creation date from a large number of documents.
This requires only that you scan through the meta.xml in the ODF ZIP
file.  Building a DOM would be highly wasteful.  But if you had a
SAX-like set of listener interfaces and realized that only a
MetadataListener was registered, then you could optimize the
processing of the document.

So, there is no shortage of areas were we could use help.  And there
are probably even more ways of improving/extending this code than I
have even thought of.

[1] http://simple.odftoolkit.org/cookbook/index.html

 Andy

 -
 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

[PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

 on meritocracy.

= Known Risks =
== Orphaned products ==

The risk, as in most projects, is to grow the project and maintain
diversity.  This is a priority that is keenly desired by the
community.

== Inexperience with Open Source ==
The initial developers include experienced open source developers,
including committers from other Apache projects. Although the majority
of proposed committers do not have Apache experience, they do have
open source experience.

== Homogeneous Developers ==
The ODF Toolkit Union was created by IBM and Sun (later Oracle) who
provided the majority of its engineering resources as well as its
direction. Moving this project to Apache enables a new start.  We
intend to engage in strong recruitment efforts in order to further
strengthen and diversify the community.


== Reliance on Salaried Developers ==
When we look at sponsored developers, with the ability to work on this
project full time, IBM currently has more committers.  We believe that
this situation will change, as the project grows in incubation.

== Relationships with Other Apache Products ==
Several potential areas for collaboration with other Apache projects
have been suggested, including:

[[http://poi.apache.org|Apache POI]] which is similar library, focused
on Microsoft Office format documents

[[http://tika.apache.org/|Apache Tika]] is a generic toolkit for
extracting text and metadata from various file formats.

[[http://pdfbox.apache.org/|Apache PDFBox]] is a Java library for
working with PDF documents. If not direct code sharing over the Java /
C++ divide, then at least sharing of PDF know-how and perhaps things
like test cases between these projects would be great.

We are interested in further exploring these options.

==A Excessive Fascination with the Apache Brand==

Our primary interest is in the processes, systems, and framework
Apache has put in place around open source software development more
than any fascination with the brand.

==Documentation==

There is documentation for the Simple Java API for ODF project,
including a Cookbook, and JavaDoc:

http://simple.odftoolkit.org/cookbook/

http://simple.odftoolkit.org/javadoc/index.html

For the ODFDOM, there is a good overview documenting the project here:
http://odftoolkit.org/projects/odfdom/pages/ProjectOverview

A 3rd party introductory tutorial here:
http://www.langintro.com/odfdom_tutorials/

==Initial Source==

Will come from the ODF Toolkit Union, the latest stable source, plus
any work in-progress

==External Dependencies==

We do not believe that we have any external dependencies other than
Apache Xerces, Xalan, Velocity (a build-time dependency), Java 6 and
the ODF schemas (also a build-time dependency)

==Cryptography==

We are currently working on adding support for digital signatures and
encryption of documents. The project will complete any needed export
control paperwork related to these features.

==Required Resources==

The following mailing lists:

 * `odf-...@incubator.apache.org` - for developer discussions

 * `odf-u...@incubator.apache.org` - for user discussions

 * `odf-comm...@incubator.apache.org` - for Subversion commit messages

 * `odf-iss...@incubator.apache.org` - for JIRA change notifications

 * `odf-notificati...@incubator.apache.org` - for continuous
build/test notifications

===Other resources===

A source code repository, preferable git

An issue tracker

A wiki

A website

==Initial Committers==

 Rob Weir
 Biao Han
 Svante Schubert
 Ying Chun Guo

==Sponsors==

===Champion===
Sam Ruby

===Nominated Mentors===
Nick Burch
Yegor Kozlov

===Sponsoring Entity===

The Apache Incubator

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

Re: [PROPOSAL] ODF Toolkit for Incubation

[Rob Weir]

And I've added it to the wiki:
http://wiki.apache.org/incubator/ODFToolkitProposal

-Rob

On Wed, Jul 20, 2011 at 4:29 PM, Rob Weir apa...@robweir.com wrote:
 Apologies to those who have received multiple copies of this message.
 I've cc'ed members of the Apache POI project, the Apache OpenOffice
 podling and the ODF Toolkit Union, due to the prior interest they've
 expressed in this.  I invite them to join the discussion on
 general@incubator.apache.org.  If they want to subscribe to this list
 they can do so by sending an email to
 general-subscr...@incubator.apache.org.

 = The ODF Toolkit =

 == Abstract ==

 The ODF Toolkit is a set of Java modules that allow programmatic
 creation, scanning and manipulation of OpenDocument Format (ISO/IEC
 26300 == ODF) documents. Unlike other approaches which rely on runtime
 manipulation of heavy-weight editors via an automation interface, the
 ODF Toolkit is lightweight and ideal for server use.

 The ODF Toolkit is currently hosted by the ODF Toolkit Union and is
 licensed under the Apache 2.0 license.

 == Proposal ==

 To move the following components from the ODF Toolkit Union to a
 single ODF Toolkit project at Apache:

 Simple Java API for ODF: http://simple.odftoolkit.org/

 ODFDOM: http://odftoolkit.org/projects/odfdom/pages/Home

 ODF Conformance Tools:
 http://odftoolkit.org/projects/conformancetools/pages/Home

 (We'd be open as well to a catchier name.  We've been calling it The
 ODF Toolkit, prefaced always with The.  Or individually by
 component name.  But The Apache ODF Toolkit or Apache ODF Toolkit
 are ponderous.)

 In addition to migrating the code, we would migrate the website,
 tutorials, samples, Bugzilla data, and (if feasible) the mailing list
 archives.  We would also seek to transfer the odftoolkit.org domain
 name to Apache.

 While under incubation we will merge these projects into a single SDK
 with three layers:

 # Package layer, representing the ZIP + Manifest container file of an
 ODF document.  This structure is shared by other document formats,
 such as EPUB
 # DOM Layer, a schema-generated layer that maps 1:1 with the ODF
 schema.  This uses Apache Velocity as the templating engine.
 # Convenience layer: an intuitive, high level API for use by app
 developers who are not familiar with ODF XML, but who have basic
 knowledge at the level of a word processor user.

 == Background ==
 The ODF Toolkit Union was jointly announced by Sun and IBM at the
 OpenOffice.org Conference in Beijing, November 2008. The idea was to
 create a portfolio of tools aimed at accelerating the growth of
 document-centric solutions. The Open Document Format specification is
 large and complex. Most developers simply do not have the time and
 energy to master the 1,000-page specification  By providing
 programming libraries, with high level APIs, the ODF Toolkit offers an
 means to reduce the difficulty level, and encourage development of
 innovative document solutions.

 == Rationale ==

 During the recent OpenOffice incubation proposal discussions, the
 mention of possible moving the ODF Toolkit to Apache was met with
 enthusiasm.

 Apache is emerging as the leading open source community for document
 related projects.  The ODF Toolkit would have a good deal of synergy
 with other Apache projects, including the ODF Toolkit's dependency on
 Apache XML tools like Xerces, to possible multi-format applications
 with POI libraries to pipelining ODF with SVG and PDF rendering with
 Batik, FOP or  PDFBox.  Getting these various document processing
 libraries in one place, under a compatible permissive license would be
 of great value and service to users-developers interested in combining
 these tools for their specific project requirements.

 Last, but not least,  there is obvious synergy with Apache OpenOffice,
 as a prominent office suite supporting the ODF format.

 The ODF Toolkit is already licensed under Apache License, Version 2.0,
 enabling a smooth transition.

 = Current Status =
 == Meritocracy ==
 We understand the intention and value of meritocracy at Apache.  The
 initial committers are familiar with open source development.  A
 diverse developer community is regarded as necessary for a healthy,
 stable, long term ODF Toolkit project.

 == Community ==

 The ODF Toolkit is developed by a small set of core developers, though
 the community extends to include a broad set of application developers
 who use the code and contribute bug reports, patches and feature
 requests.

 Although there are some open source projects that use these components
 directly, such Apache Directory Studio and GNU Octave,  to support ODF
 import/export, it is more typical for these kinds of libraries to be
 used by application developers in small, ad-hoc document automation
 and data wrangling applications.


 == Core Developers ==
 The coders on the existing ODF Toolkit will comprise the initial
 committers on the Apache project.  These committers have varying
 degrees

Re: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

We continue to discuss moving this work to Apache.  Feedback so far
has been to try for an eventual TLP.  We're starting to draft the
Incubation proposal.  We talked to the maintainer of the C#/AODL
component and he confirmed that it is not really active anymore.  He
might move it to bitbucket.  So our plan will be to propose moving
only the Java components over to Apache,

Also, we just announced a new release (more info below) and are
starting work on our next release, which is targeted to add support
for document encryption and digital signatures.

Regards,

-Rob

---

We are pleased to announce the release of the Simple Java API for ODF
version 0.6.5 today. The improvements in this version focus on text
documents.

They are:

-Hard page breaks, including appending page break at the end of a text
document and appending a page break after a referenced paragraph.

-Headings, including appending heading to documents, and changing
plain text as heading;

-Comments, including attaching a comment to a text selection and to a
paragraph;

-Paragraph font, including getting/setting paragraph's font size,
style, color and so on;

-Paragraph alignment, including getting/setting text alignment of a paragraph;

-Hyperlinks, including applying hyperlink to a selection, a paragraph,
an image and a span.

An introduction to the new functions has been added to the Cookbook:

http://simple.odftoolkit.org/cookbook/Text Document.html

An interesting code sample to show how to use these new functions to
format a text document is available in the website:

http://simple.odftoolkit.org/demo/demo10.html

The full release notes, including a list of patches can be found in the wiki:

http://odftoolkit.org/projects/simple/pages/ReleaseNotes

The binary file can be downloaded from:

http://odftoolkit.org/projects/simple/downloads/directory/0.6.5

The Java doc, sample codes and cookbook in the website have been updated:

http://simple.odftoolkit.org/documents.html

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

Re: [PROPOSAL] Oozie for the Apache Incubator

[Rob Weir]

And I was thinking of the Ray Ozzie, the former Microsoft CTO.
Elephant handler is perhaps apt.

-Riob


On Wed, Jun 29, 2011 at 9:32 AM, Marvin Humphrey mar...@rectangular.com wrote:
 On Wed, Jun 29, 2011 at 11:22:39AM +0100, Ross Gardler wrote:
 You might want to reconsider the name.

 In English (British English at least) ooze is an unpleasant thing
 often related to a body wound or a stagnant river. The formal
 definition is not so bad [1], but in common (UK) usage it's
 unpleasant.

 And I thought at first that it was a reference to the Uzi, a submachine gun.

 It's apparently the Burmese term for an elephant handler.

    http://en.wikipedia.org/wiki/Mahout

    In Burma, the profession is called oozie; in Thailand kwan-chang; and in
    Vietnam quản tượng.

 We had a good laugh about all this in the #lucy_dev IRC channel a couple days
 ago.  One of the participants (who free-associated Oozie with sucking chest
 wound) suggested that Hadoop projects might consider referencing stuffed
 animals rather than elephants.  :)

 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

Fwd: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

Passing along, from the ooo-dev list.

-Rob


-- Forwarded message --
From: Jürgen Schmidt jogischm...@googlemail.com
Date: 2011/6/28
Subject: Re: ODF Toolkit Incubation Pre-Proposal
To: ooo-...@incubator.apache.org


Hi Rob,

i support your idea and i think that it make sense to move the ODFToolkit
project to Apache as well.

ODF is a key element in an open standard based world. Probably more
automatically processed  document workflows become available in the future
because of an open standard that everybody can read and write. Fat client
applications like OpenOffice, LibreOffice, Symphony are only one part of the
story. But when we think about the new generation of devices (smartphones,
tablets) it becomes obvious that a smaller library that can handle this
document format really make sense. Simple viewers are necessary to make the
format popular like PDF for easy exchange of documents. Other applications
that generate documents in a backend or again full featured or simplified
editors are altogether necessary to build a working eco-system around ODF.

I would prefer a new project to give them the visibility it needs. Ideally
the project will not only support a Java library but also other languages
(e.g. Python, the existing C#, etc.).

Juergen

On Mon, Jun 27, 2011 at 9:42 PM, Rob Weir apa...@robweir.com wrote:

 I'm cc'ing the POI and OpenOffice projects, inviting them to join this
 discussion on the Incubator general list: general@incubator.apache.org

 When we were discussing the OpenOffice proposal a few weeks ago I
 mentioned that there was another set of technology called the ODF
 Toolkit, that we might want to bring to Apache as well.  I heard some
 enthusiasm for this at the time, but I didn't have the bandwidth to
 put together another proposal.  Now I do.  I'd like to pitch the idea,
 and see if there is still interest in having a formal incubation
 proposal submitted, and if so, identifying a Champion and Sponsor for
 the proposal.

 Note that this would not be a fork.  The ODF Toolkit Union Steering
 Committee met this morning and agreed to propose moving to Apache.

 As you probably know, ODF == Open Document Format, a open standard
 document format for office documents.  The ODF standard is created at
 OASIS and then sent to ISO/IEC JTC1 for transposition into an
 International Standard.  ODF 1.0 was first published in 2005.  ODF 1.1
 came out in 2007.  And ODF 1.2 is Candidate OASIS Standard awaiting
 final approval in OASIS, probably by end of September.  ODF 1.2 is
 what most applications are supporting today.   OpenOffice,
 LibreOffice, Symphony, KOffice/Calligra Suite use ODF as native
 formats.  Other applications, including Microsoft Office, Corel
 Wordperfect and Google Docs offer some degree of import/export
 support.  ODF 1.2 is the version also supported by the ODF Toolkit.

 The ODF Toolkit Union maintains the following toolkits, all of them
 under the Apache 2.0 license:

 1) ODFDOM is Java-based typed DOM API, relatively low level, a 1-to-1
 mapping to the ODF schema.  In fact, much of the code is generated by
 processing the schema.

 http://odftoolkit.org/projects/odfdom/pages/Home

 2) Simple Java API for ODF is a high level wrapper of ODFDOM.  So
 operations that might require several DOM-level operations, like
 deleting a column in a spreadsheet, are a single operation in the
 Simple API.  Search and replace, copying slides from one presentation
 to another, adding hyperlinks to a selection, etc., are top level
 operations.

 http://simple.odftoolkit.org/

 3) The Conformance Tools projects is also in Java, and includes an
 online conformance checker of ODF documents, which can also be run in
 command line mode.

 http://odftoolkit.org/projects/conformancetools/pages/Home

 4) XSLTRunner and XSLT Runner Task allows easy use of XSLT transforms
 with ODF documents.

 http://odftoolkit.org/projects/conformancetools/pages/ODFXSLTRunner

 5) AODL is a C#/.NET library for ODF

 http://odftoolkit.org/projects/aodl/pages/Home

 I think there is natural synergy with Apache, especially with the Java
 components.  For example, I could see publishing pipelines involving
 the ODF Toolkit with PDFBox, Batik, FOP, and POI. Having these tools
 under a common license, in one place, has obvious benefits.

 Moving this project over would not be a large technical effort.
 Mercurial == SVN,  some simple website/wiki migration, 30 or so
 pages, a few mailing lists and bugzilla databases.  It is currently on
 the Kenai infrastructure, so similar to OpenOffice, just much, much
 smaller in scale.

 I'm open as to whether this would be best eventually as a TLP or as
 part of an existing project, like POI or even OpenOffice.  I'm leaning
 a little toward having this as a TLP, but I'm open to other ideas.

 Also, since this is already an open source project with all code under
 Apache 2.0, I assume no SGA is required?

 So please let me know if you agree that Apache would be a good

Re: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

On Tue, Jun 28, 2011 at 6:31 AM, Daniel Shahaf d...@daniel.shahaf.name wrote:
 Rob Weir wrote on Mon, Jun 27, 2011 at 20:51:53 -0400:
 On Mon, Jun 27, 2011 at 8:45 PM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
  Rob Weir wrote on Mon, Jun 27, 2011 at 19:00:50 -0400:
  Hi Dennis,
 
  If I understand correctly, the practice at Apache would be to remove
  these legacy copyright statements and aggregate them into a single
  NOTICE document.  This would be true, even if it says DO NOT ALTER OR
  REMOVE.  I imagine they would even tear off those tags on mattresses.
 
 
  To whom does the pronoun they refer?
 

 Sorry, that is a joke that probably only makes sense in the US.

 You did not answer my question.


You could parse they as being a nominative third person plural
impersonal.  In English, not all pronouns refer to antecedents in the
text.  The exceptions are the impersonals.

The impersonal is used in English to make general statements without
a specified agent. An agent, in the case of the impersonal, is defined
as the persons who perform the action of the verb. Although the
impersonal pronouns in English are officially the one pronouns (one,
someone, no one, anyone), the third person plural pronoun they as well
as the second person pronoun you and the noun people can also be used
in the construction of the impersonal in English. Such impersonal
markers can also be mixed and matched as in the case of mixing one
with their in the example One should always wash their hands before
eating.

Read more: 
http://www.brighthub.com/hubfolio/heather-marie-kosur/articles/38523.aspx#ixzz1QZPmWx68



Regards,

-Rob

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

Re: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

On Mon, Jun 27, 2011 at 4:26 PM, Ross Gardler
rgard...@opendirective.com wrote:
 Thanks Rob,

 Looking I've the Kenai site I notice that there is as good as no visible 
 activity within the project. You mention that the ODF Toolkit Union Steering 
 Committee met and approved the idea of this proposal, but this is not 
 visible so we don't know what this means.


There is activity.  It just is not evenly distributed.  For example,
with the Simple API, we had a release June 1st;

http://odftoolkit.org/projects/simple/pages/ReleaseNotes

(We'll have another release in July)

Forums are dead because the activity occurs on mailing lists, e.g.:

http://odftoolkit.org/projects/simple/lists/dev/archive

Activity on bug reports:

http://odftoolkit.org/projects/simple/lists/issues/archive

Commit logs:

http://odftoolkit.org/projects/simple/lists/commits/archive

User list:

http://odftoolkit.org/projects/simple/lists/users/archive


 What interest is there in reviving the project rather than just moving it 
 here. I'm particularly worried that in just a few minutes of browsing the 
 project website I've found a number of people who seem to want to engage with 
 the project but receive no response. The project seems, for all intents and 
 purposes, to be dead.


We've consistently made monthly releases of the Simple API for almost
a year now:

http://odftoolkit.org/projects/simple/downloads

I wouldn't call that dead.  How many Apache projects have a QA'ed
release every month?

But that is just the simple API.  Other components are more driven by
the ODF specification.  For example, the conformance checking module
gets revised when the ODF specification is updated, when a new
Committee Draft is released, with schema changes.  So that happens at
the pace of standards, which is a bit slower.

Overall, we have a mix of pieces actively worked on and pieces that are not.


 Who is going to kickstart this new community? Who will make sure that it 
 receives the attention it needs in order to graduate from the incubator?


That's what I'm here to find out.  Back when I mentioned the project
before, during the OpenOffice proposal, there were a few people who
seemed interested in it.  I don't remember all the names.  I think
they were from the PO project.  If that interest still exists, I think
that, plus the existing sponsored programmers we already have working
on this code, would be sufficient to bring the ODF Toolkit to the next
level.  This is not a huge piece of code.  If we grew to a dozen
committers, it would be amazing.

Mind you, we're doing fine and achieving some modest success with the
project as it is.  You can see some of the recent demos we've done
here:

http://simple.odftoolkit.org/demo/index.html

The other thing that recommends Apache, in my mind, is the synergy
with OpenOffice, POI and other projects.  There is potential, at
Apache to have an even more amazing collection of document-oriented
toolkits that covers everything from the legacy binary formats of MS
Office, to the latest generation of XML-based formats.  This would be
covered both as head-less pure Java libraries, as well as in the SDK
associated with OpenOffice.  Add in that the PDF, SVG and XSL:FO
libraries from other projects and you have a something that excites
me, at least.

Think of it this way:  If OpenOffice succeeds at Apache, and its
default file format is ODF, then the ODF Toolkit becomes a necessary
part of the successful ecosystem.


 I appreciate this is not yet a proposal, this is a discussion that might 
 answer these questions.


Thanks, I appreciate the questions.

-Rob


 Sent from my mobile device (so please excuse typos)

 On 27 Jun 2011, at 20:42, Rob Weir apa...@robweir.com wrote:

 I'm cc'ing the POI and OpenOffice projects, inviting them to join this
 discussion on the Incubator general list: general@incubator.apache.org

 When we were discussing the OpenOffice proposal a few weeks ago I
 mentioned that there was another set of technology called the ODF
 Toolkit, that we might want to bring to Apache as well.  I heard some
 enthusiasm for this at the time, but I didn't have the bandwidth to
 put together another proposal.  Now I do.  I'd like to pitch the idea,
 and see if there is still interest in having a formal incubation
 proposal submitted, and if so, identifying a Champion and Sponsor for
 the proposal.

 Note that this would not be a fork.  The ODF Toolkit Union Steering
 Committee met this morning and agreed to propose moving to Apache.

 As you probably know, ODF == Open Document Format, a open standard
 document format for office documents.  The ODF standard is created at
 OASIS and then sent to ISO/IEC JTC1 for transposition into an
 International Standard.  ODF 1.0 was first published in 2005.  ODF 1.1
 came out in 2007.  And ODF 1.2 is Candidate OASIS Standard awaiting
 final approval in OASIS, probably by end of September.  ODF 1.2 is
 what most applications are supporting today.   OpenOffice

Re: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

On Mon, Jun 27, 2011 at 6:30 PM, Lee Fisher blib...@gmail.com wrote:
 There is activity.  It just is not evenly distributed.
 [...]

 I presume the activity is more in the Java libraries. :-)


I not asking you to presume anything.  I'm just following up on
interest expressed on this list a few weeks ago.   If you find the
Java libraries to be interesting but not the .NET library, then that
would be good to know.

-Rob

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

Re: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

Hi Dennis,

If I understand correctly, the practice at Apache would be to remove
these legacy copyright statements and aggregate them into a single
NOTICE document.  This would be true, even if it says DO NOT ALTER OR
REMOVE.  I imagine they would even tear off those tags on mattresses.

-Rob

On Mon, Jun 27, 2011 at 4:33 PM, Dennis E. Hamilton orc...@apache.org wrote:
 I support this idea.

 I think with regard to need for an SGA or not, there is the matter of the 
 current headings at the tops of source files.  (I have no idea what is 
 required, I'm simply
 observing what is there.)

  - Dennis

 /
 *
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER
 *
 * Copyright 2008, 2010 Oracle and/or its affiliates. All rights reserved.
 * Copyright 2009, 2010 IBM. All rights reserved.
 *
 * Use is subject to license terms.
 *
 * Licensed under the Apache License, Version 2.0 (the License); you may not
 * use this file except in compliance with the License. You may obtain a copy
 * of the License at http://www.apache.org/licenses/LICENSE-2.0. You can also
 * obtain a copy of the License at http://odftoolkit.org/docs/license.txt
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 /

 -Original Message-
 From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
 Sent: Monday, June 27, 2011 12:43
 To: general@incubator.apache.org
 Cc: d...@poi.apache.org; ooo-...@incubator.apache.org
 Subject: ODF Toolkit Incubation Pre-Proposal

 [ ... ]

 Also, since this is already an open source project with all code under
 Apache 2.0, I assume no SGA is required?

 So please let me know if you agree that Apache would be a good
 location to further develop the ODF Toolkit libraries.

 Regards,

 -Rob


 -
 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: ODF Toolkit Incubation Pre-Proposal

[Rob Weir]

On Mon, Jun 27, 2011 at 8:45 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
 Rob Weir wrote on Mon, Jun 27, 2011 at 19:00:50 -0400:
 Hi Dennis,

 If I understand correctly, the practice at Apache would be to remove
 these legacy copyright statements and aggregate them into a single
 NOTICE document.  This would be true, even if it says DO NOT ALTER OR
 REMOVE.  I imagine they would even tear off those tags on mattresses.


 To whom does the pronoun they refer?


Sorry, that is a joke that probably only makes sense in the US.

More information that you ever wanted to know on mattress sales in the
US can be found here:

http://en.wikipedia.org/wiki/Matress_tag

-Rob

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