Re: Getting buildbots operational again

[Andrea Pescetti]

On 26/03/2016 Andrea Pescetti wrote:

https://bz.apache.org/ooo/show_bug.cgi?id=126892
This will hopefully mean that buildbots get past the "./bootstrap"
phase. It is a temporary fix


All buildbots are indeed now past the "./bootstrap" phase (the one that 
had been failing in the last month) and they are now building, which 
will take several hours.


You can see the nightly ones here:
https://ci.apache.org/builders/aoo-win7
https://ci.apache.org/builders/openoffice-fbsd-nightly
https://ci.apache.org/builders/openoffice-linux32-nightly
https://ci.apache.org/builders/openoffice-linux64-nightly

(the last one was already OK since it is on the system that Infra had 
already updated to support HTTPS).


Regards,
  Andrea.

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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Patricia Shanahan]

On 3/26/2016 10:37 AM, Andrea Pescetti wrote:

On 20/03/2016 Patricia Shanahan wrote:

The issue is whether it is ASF distributed software, for which ASF
trademarks can appropriately be used. I think it is and should continue
to be ASF distributed software.

...

3) We recognize that http://svn.apache.org/viewvc/openoffice/ has
different areas, and that not all of them should be subject to the same
policy. Just like I don't call a release vote when I change a web page
(the full site is hosted under that tree, so technically I am making a
"website release" every time I update a page), we could recognize that
everything in devtools/ is just a set of tools that we can make
available with lazy consensus and no need for a formal release. This is
my favorite option.

...

This option does not appear to me to conform to
http://www.apache.org/dev/release.html.

The policy does say:

"Deviations from this policy may have an adverse effect on the legal
shield's effectiveness, or the insurance premiums Apache pays to protect
officers and directors, so are strongly discouraged without prior,
explicit board approval. Do note however that organizationally we prefer
robust, reviewable decision-making over efficient decision-making, so if
you are thinking of proposing an alternative process for the board to
consider, be sure your targets reflect this."

That suggests that a good enough justification for a deviation could get
"prior, explicit board approval". How about asking the board for approval?

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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Patricia Shanahan]

On 3/26/2016 2:58 PM, Dennis E. Hamilton wrote:




-Original Message- From: Andrea Pescetti
[mailto:pesce...@apache.org] Sent: Saturday, March 26, 2016 10:38
To: dev@openoffice.apache.org Subject: Re: Releasing the Apache
OpenOffice API plugin for NetBeans

On 20/03/2016 Patricia Shanahan wrote:

The issue is whether it is ASF distributed software, for which
ASF trademarks can appropriately be used. I think it is and
should

continue

to be ASF distributed software.



[ ... ]

2) We go for the full release vote, but this is a serious process,
much more than what is needed for this tool. If one really wants to
do it right, you need a release manager, binding votes, sources in
dist/, GPG signing the way the ASF wants it, old sources preserved
in the ASF archives...

[orcmid]

I'm puzzled about one thing.

There are small Apache projects.  I suspect there are more small ones
than large ones.

Yet, making releases does not seem to be that burdensome to those
projects.  They have it work and they satisfy the Apache requirements
for releases and the integrity of Apache-released code.

The UNO Tools work strikes me as a commendable way of spinning out
useful releases on the same cadence as small projects manage.  (It is
also a small case that sort of demonstrates the process and how it is
achievable.)

Now it is a bit of a problem that this has been a one-committer
effort, and it would be great if supported by more contributors.
Having some community building around this component of AOO would be
valuable.

With that, the release process should become systematic and
sustainability would also be addressed.

Isn't that worth looking into?


+1

We need to train release managers, myself included. It makes sense to me
to practice on smaller, simpler releases before doing a full AOO release.

Patricia


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

Re: branches/gbuild-reintegration merge?

[Damjan Jovanovic]

On Sat, Mar 26, 2016 at 12:11 PM, Andrea Pescetti  wrote:
> On 22/03/2016 Damjan Jovanovic wrote:
>>
>> For the past month I've been working on preparing the gbuild branch
>> for merge into trunk, and I believe it to be essentially ready.
>
>
> Thank you Damjan, this is one of the best news about project development
> we've had in recent months! And I won't insist again that these news deserve
> a blog post...
>
>> My work can be found in branches/gbuild-reintegration
>
>
> I've just built it correctly on one of my environments (Linux64). OK to
> merge it from my side, with the aim of ironing out any further issues by
> 4.2.0. For the record, a parallel build (-P4) worked great too.
>
>> * Fixes bugs 117685, 117218, 117340, 116880, 116755, 117350, 117340,
>> 117610, 116959, 117845, 117687, and 117171. Note how at least 116755
>> is a user-visible bug in OOXML parsing.
>
>
> This is really impressive. I've taken a look all of them (117340 is listed
> twice, I don't know if you wanted to list something else). May I know why
> this branch development fixes
> https://bz.apache.org/ooo/show_bug.cgi?id=116880 and
> https://bz.apache.org/ooo/show_bug.cgi?id=116755 ? I mean, you fixed them
> "while at it" or are they side effects of the build system changes? I am
> actually interested in the opposite situation, i.e., can build system
> changes reach so deep within the user experience? Or, in other words, can
> they introduce new bugs at a level this deep?

Thank you. Yes several are repeated, and no I didn't want to list
something else. Those bug fixes were present in the original gbuild
branch - they're not something I developed. I don't know why.

Build changes can't really break code. There were some code changes,
for example controlling function visibility using code instead of
using .map files, but if that broke something, linking would fail and
the build would presumably fail; only run-time dynamic linking can
break at run-time.

> I don't get why
> https://bz.apache.org/ooo/show_bug.cgi?id=117171
> is addressed too.

Me neither.

>> I don't have the ability to test Mac OS and it would be appreciated if
>> someone could or remote access could be given to me so I can.
>
>
> You received access to an ASF-owned Mac back in October 2015. That Mac was
> then taken over by Infra and transformed in an ASF-wide service to optimize
> resources. You can surely get access to it again if it doesn't work for you.
> I can reactivate the discussion with Infra, just ask in case.

Please do. I was told I received access back then, but AFAIK never
given its IP address, login credentials or protocol to access it.

>> Can I merge branches/gbuild-reintegration to trunk now?
>
>
> +1 from me. Marcus' concern about merging trunk into it beforehand was
> correct, but the set of unrelated changes is minimal and under control in
> any merge strategy.

Let's get Mac working first, then see about a merge.

> Regards,
>   Andrea.

Regards
Damjan

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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Carl Marcum]

On 03/26/2016 05:58 PM, Dennis E. Hamilton wrote:



-Original Message-
From: Andrea Pescetti [mailto:pesce...@apache.org]
Sent: Saturday, March 26, 2016 10:38
To: dev@openoffice.apache.org
Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans

On 20/03/2016 Patricia Shanahan wrote:

The issue is whether it is ASF distributed software, for which ASF
trademarks can appropriately be used. I think it is and should

continue

to be ASF distributed software.

[ ... ]

2) We go for the full release vote, but this is a serious process, much
more than what is needed for this tool. If one really wants to do it
right, you need a release manager, binding votes, sources in dist/, GPG
signing the way the ASF wants it, old sources preserved in the ASF
archives...

[orcmid]

I'm puzzled about one thing.

There are small Apache projects.  I suspect there are more small ones than 
large ones.

Yet, making releases does not seem to be that burdensome to those projects.  
They have it work and they satisfy the Apache requirements for releases and the 
integrity of Apache-released code.
I think the biggest issue with these devtools in general for the project 
is that it's not AOO core code.  Almost all of us use AOO or we wouldn't 
be here.  Only a few use this NetBeans tool and fewer still (me) use the 
newer tools I have been working on for Gradle and Groovy which I hope 
will change once people see value in them.


I have no issue going through the release process with these tools as 
long as enough people don't mind the verification process.




The UNO Tools work strikes me as a commendable way of spinning out useful 
releases on the same cadence as small projects manage.  (It is also a small 
case that sort of demonstrates the process and how it is achievable.)

Agreed.



Now it is a bit of a problem that this has been a one-committer effort, and it 
would be great if supported by more contributors.  Having some community 
building around this component of AOO would be valuable.
Actually there have been solid contributions by others as far as the 
NetBeans plugin is concerned. The most resent being the Japanese message 
bundles  for AOO branding which is the purpose of this release 
discussion. Spanish and Italian contributions have also been made.




With that, the release process should become systematic and sustainability 
would also be addressed.

Isn't that worth looking into?



I think there is a strong case for these tools to be properly released 
and will put them forward as I have time.


Providing tools for extension developers only helps our ecosystem. As 
more extension developers use the new tools I think more people will 
find a way to contribute as I did.


On a similar topic I posted a [DISCUSS] email [1] looking for help 
trying out the Groovy UNO API extension and haven't got any takers.

[HELPWANTED] may have been a better subject.
I would like to get a vote ready for that one soon but I was hoping a 
few people would test it first if anybody has a few spare cycles :)


[1] 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201603.mbox/%3C56E60EF7.4040304%40apache.org%3E


Thanks,
Carl

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

Re: Getting buildbots operational again

[Kay Schenk]

On Sun, Mar 27, 2016 at 12:51 AM, Andrea Pescetti 
wrote:

> On 26/03/2016 Andrea Pescetti wrote:
>
>> https://bz.apache.org/ooo/show_bug.cgi?id=126892
>> This will hopefully mean that buildbots get past the "./bootstrap"
>> phase. It is a temporary fix
>>
>
> All buildbots are indeed now past the "./bootstrap" phase (the one that
> had been failing in the last month) and they are now building, which will
> take several hours.
>
> You can see the nightly ones here:
> https://ci.apache.org/builders/aoo-win7
> https://ci.apache.org/builders/openoffice-fbsd-nightly
> https://ci.apache.org/builders/openoffice-linux32-nightly
> https://ci.apache.org/builders/openoffice-linux64-nightly
>
> (the last one was already OK since it is on the system that Infra had
> already updated to support HTTPS).
>
>
> Regards,
>   Andrea.
>

​Thank you SO much for this fix.
​




-- 
--
MzK

"Time spent with cats is never wasted."
-- Sigmund Freud

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Andrea Pescetti]

On 27/03/2016 Patricia Shanahan wrote:

On 3/26/2016 10:37 AM, Andrea Pescetti wrote:

3) We recognize that http://svn.apache.org/viewvc/openoffice/ has
different areas, and that not all of them should be subject to the same
policy. Just like I don't call a release vote when I change a web page
(the full site is hosted under that tree, so technically I am making a
"website release" every time I update a page), we could recognize that
everything in devtools/ is just a set of tools that we can make
available with lazy consensus and no need for a formal release. This is
my favorite option.

This option does not appear to me to conform to
http://www.apache.org/dev/release.html.


Then all of us are violating the policy every time we update the 
website. It's a matter of interpreting things correctly. Trunk, 
branches, tags are for sure subject to the standard release policy. The 
website is for sure not subject to it (no human with a grain of salt can 
imagine a release vote for a typo fix on a web page, right?). The rest 
is... well, in between.



That suggests that a good enough justification for a deviation could get
"prior, explicit board approval". How about asking the board for approval?


We can ask the board for advice, why not. But my recommendation is: get 
three PMC members to commit to voting on this release before we explore 
the "real release" option. Once we know that at least three PMC members 
will vote, then this discussion make sense. There will be quite a few 
arrangements to do since (for example) we don't want to break our 
release tree layout, which was the subject of endless discussions in the 
past, but if three PMC members are available and willing to do a formal 
release we have the basic steps done. And actually... if we have three 
volunteers then we can get it done even without asking the Board!


I thought about examples but I can't find anything similar. Solr is 
released by Lucene, see 
https://dist.apache.org/repos/dist/release/lucene/ but those are real 
end-user software packages in themselves, while here we are discussing a 
development tool.


Regards,
  Andrea.

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

Reporting broken download link

[natedegrate]

Apache quit downloading after I said “download full” program.  No error 
message.  I was using Apache prior to this?

I had previously downloaded Apache but it quit and does not appear to respond 
to restore requests?

I was in the process of opening a docx form I had just updated with Free Editor?

Thank you.

956-423-3154   620-363-1824

nate

Sent from Mail for Windows 10

RE: Releasing the Apache OpenOffice API plugin for NetBeans

[Dennis E. Hamilton]

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 27, 2016 09:46
> To: dev@openoffice.apache.org
> Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans
> 
> On 27/03/2016 Patricia Shanahan wrote:
> > On 3/26/2016 10:37 AM, Andrea Pescetti wrote:
> >> 3) We recognize that http://svn.apache.org/viewvc/openoffice/ has
> >> different areas, and that not all of them should be subject to the
> same
> >> policy. Just like I don't call a release vote when I change a web
> page
> >> (the full site is hosted under that tree, so technically I am making
> a
> >> "website release" every time I update a page), we could recognize
> that
> >> everything in devtools/ is just a set of tools that we can make
> >> available with lazy consensus and no need for a formal release. This
> is
> >> my favorite option.
> > This option does not appear to me to conform to
> > http://www.apache.org/dev/release.html.
> 
> Then all of us are violating the policy every time we update the
> website.
[orcmid] 

That is not the case for *any* Apache Project web site or the web site for 
Apache itself.

The ASF is very clear about open-source software releases and what that means.  

Please.  We are talking about software releases made available to the public 
and the duties the Foundation places on such releases with regard to 
intellectual property, licenses, and notifications.  

It doesn't matter what the domain of use of the software is, it matters that it 
is software made freely available as a public good.

[ ... ]


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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Andrea Pescetti]

Dennis E. Hamilton wrote:

From: Andrea Pescetti
On 27/03/2016 Patricia Shanahan wrote:

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

Then all of us are violating the policy every time we update the
website.

[orcmid]
That is not the case for *any* Apache Project web site or the web site for 
Apache itself.
The ASF is very clear about open-source software releases and what that means.


It was clearly ironic, just to show that reading the words on that page 
("Releases are, by definition, anything that is published beyond the 
group that owns it") without a grain of salt one could conclude that a 
website fix is a release. Of course, a website fix is NOT a release. And 
there is no reason to write it on the Releases page, since people have a 
brain.



It doesn't matter what the domain of use of the software is, it
matters that it is software made freely available as a public good.


When we have three PMC members willing to commit to voting (at due time) 
on the NetBeans plugin, this discussion will make sense. Otherwise we 
are wasting our time.


Note that if we go this way we will have to handle the previous 
"release" by Carl appropriately too. But I don't want to open too many 
discussions. Let's find the three PMC members willing to be involved 
first. Once we have them, everything becomes easier.


Regards,
  Andrea.

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

Re: Release Manager for 4.2.0?

[Andrea Pescetti]

On 29/01/2016 Andrea Pescetti wrote:

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction ...
I am surely available to have a significant role in the 4.2.0 release


A few days after writing this, almost 2 months ago, sudden events left 
me incapacitated to make any significant contributions until very 
recently. I'm still unable to make long-term commitments.


Anyway, there are some issues we need to get done as a team before 
appointing a release manager makes sense:


1) Enough code. Done. The merge of the recent gbuild work totally 
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
fraction of the fixes that (at that time) were available on trunk. So 
here we are already OK, and we've been OK for months.


2) Localization. I got shell access to the Pootle server a few days ago. 
I'm still looking around, and if someone else want to join this is an 
important part. We need to have a solid process for updating 
translations (the full route: new strings in code -> Pootle -> back to 
code -> in localized builds) in place.


3) Buildbots and ASF-owned build machines. Buildbots are not essential 
for a release: 4.1.2 was built (like all previous releases in history) 
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we 
can't use buildbots for it; we need to setup new systems. Those who read 
the infrastructure@ list can see the discussion I started there 
yesterday. Still, having buildbots helps QA and having ASF-owned build 
machines is an important investment for the project: at that point we 
will be able to make a release within days, not months. We should make 
as much progress as we can here. Again, if anybody can help, this is an 
important area.


4) There are several optimizations I have in mind, especially on 
reducing a bit our binary size on Linux (trust me, it is really a pain 
to commit all those binaries to SVN, or to any version control system). 
But they are not essential.


I have just committed to the devtools/ area the scripts we (mainly 
Juergen) used to build the 4.1.2 release, with specs of the build 
machines. I've had them since last October, but I never committed them. 
They are a first step if we want to build our release binaries on ASF 
hardware: they contain build options and config.log to have some more 
information on the environment.


My next priorities will be localization (especially, re-exporting the 
Italian translation to Pootle and re-importing it) and and a 
proof-of-concept VM for building releases on Linux (64 bit) based on the 
above scripts. There is plenty of room for other to jump in (Linux 32, 
Windows, Mac; or localization management) so please do!


Regards,
  Andrea.

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

Re: branches/gbuild-reintegration merge?

[Andrea Pescetti]

Damjan Jovanovic wrote:

On Sat, Mar 26, 2016 at 12:11 PM, Andrea Pescetti wrote:

you fixed them
"while at it" or are they side effects of the build system changes?

Those bug fixes were present in the original gbuild
branch - they're not something I developed. I don't know why.


OK, thanks for the explanation. So the "gbuild" branch comes with some 
bonus bugfixes that were added to it for some unknown reasons. Great 
that you looked into it; and good that they work!



Let's get Mac working first, then see about a merge.


I've opened https://issues.apache.org/jira/browse/INFRA-11553 with the 
full story. You may want to watch the issue to follow up. Note that for 
some reason I don't get notifications of all comments from JIRA, so you 
may want to revisit the page in 48 hours to check if Infra took action.


Regards,
  Andrea.

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

RE: Release Manager for 4.2.0?

[Dennis E. Hamilton]

Great news!

Thanks, Andrea

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 27, 2016 13:13
> To: dev@openoffice.apache.org
> Subject: Re: Release Manager for 4.2.0?
> 
> On 29/01/2016 Andrea Pescetti wrote:
> > For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> > Release Manager for 4.2.0 since I'm finding that in this period I can
> > help more productively with tasks that do not require constant
> > interaction ...
> > I am surely available to have a significant role in the 4.2.0 release
> 
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
> 
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
> 
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
> 
> 2) Localization. I got shell access to the Pootle server a few days ago.
> I'm still looking around, and if someone else want to join this is an
> important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.
> 
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who read
> the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is an
> important area.
> 
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control system).
> But they are not essential.
> 
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed them.
> They are a first step if we want to build our release binaries on ASF
> hardware: they contain build options and config.log to have some more
> information on the environment.
> 
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on the
> above scripts. There is plenty of room for other to jump in (Linux 32,
> Windows, Mac; or localization management) so please do!
> 
> Regards,
>Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


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

RE: Releasing the Apache OpenOffice API plugin for NetBeans

[Dennis E. Hamilton]

+1 on the three PMC members

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 27, 2016 12:26
> To: dev@openoffice.apache.org
> Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans
> 
> Dennis E. Hamilton wrote:
> >> From: Andrea Pescetti
> >> On 27/03/2016 Patricia Shanahan wrote:
> >>> http://www.apache.org/dev/release.html.
> >> Then all of us are violating the policy every time we update the
> >> website.
> > [orcmid]
> > That is not the case for *any* Apache Project web site or the web site
> for Apache itself.
> > The ASF is very clear about open-source software releases and what
> that means.
> 
> It was clearly ironic, just to show that reading the words on that page
> ("Releases are, by definition, anything that is published beyond the
> group that owns it") without a grain of salt one could conclude that a
> website fix is a release. Of course, a website fix is NOT a release. And
> there is no reason to write it on the Releases page, since people have a
> brain.
> 
> > It doesn't matter what the domain of use of the software is, it
> > matters that it is software made freely available as a public good.
> 
> When we have three PMC members willing to commit to voting (at due time)
> on the NetBeans plugin, this discussion will make sense. Otherwise we
> are wasting our time.
> 
> Note that if we go this way we will have to handle the previous
> "release" by Carl appropriately too. But I don't want to open too many
> discussions. Let's find the three PMC members willing to be involved
> first. Once we have them, everything becomes easier.
> 
> Regards,
>Andrea.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Patricia Shanahan]

On 3/27/2016 12:26 PM, Andrea Pescetti wrote:
...

When we have three PMC members willing to commit to voting (at due time)
on the NetBeans plugin, this discussion will make sense. Otherwise we
are wasting our time.


I generally have at least one Windows box with Netbeans installed, so I 
should be able to participate.


Insufficient PMC members is a problem in its own right, but I don't 
think it changes the release policy at all.


One possible solution to consider in the long term to splitting out some 
of this type of thing from the OpenOffice project. As a separate project 
it would be much less scary, and might attract more developers, and PMC 
members, with the specific skills.


Patricia


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

Re: Reporting broken download link

[Marcus]

Am 03/27/2016 06:18 PM, schrieb natedegrate:

Apache quit downloading after I said “download full” program.  No error 
message.  I was using Apache prior to this?

I had previously downloaded Apache but it quit and does not appear to respond 
to restore requests?

I was in the process of opening a docx form I had just updated with Free Editor?


I don't see any problems at the moment with downloading the respective 
file. Please try again.


HTH

Marcus

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

Re: Release Manager for 4.2.0?

[Don Lewis]

On 27 Mar, Andrea Pescetti wrote:
> On 29/01/2016 Andrea Pescetti wrote:
>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>> Release Manager for 4.2.0 since I'm finding that in this period I can
>> help more productively with tasks that do not require constant
>> interaction ...
>> I am surely available to have a significant role in the 4.2.0 release
> 
> A few days after writing this, almost 2 months ago, sudden events left 
> me incapacitated to make any significant contributions until very 
> recently. I'm still unable to make long-term commitments.
> 
> Anyway, there are some issues we need to get done as a team before 
> appointing a release manager makes sense:
> 
> 1) Enough code. Done. The merge of the recent gbuild work totally 
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny 
> fraction of the fixes that (at that time) were available on trunk. So 
> here we are already OK, and we've been OK for months.

Some of the external software that is bundled has security issues.  I
put together a patch for nss here:
.

The version of libxml currently bundled also has a lot of known
vulnerabilities.  I'm currently testing a patch.

These both need review and testing.

The versions of openssl and curl badly need updating for the same
reason, and there is one CVE for serf.

There is a CVE for raptor-1.4.18, but I believe there was a cherry
picked patch commited for that.

There are likely to be vulnerabilites in the bundled version of
silgraphite, but it has been unmaintained upstream for quite some time.
Ideally we would switch to Graphite2, but the API is radically different
and this looks difficult.  The unattractive alternative is to look at
the additional sanity checks added in recent Graphite2 commits and try
to retrofit those into silgraphite.


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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Carl Marcum]

On 03/27/2016 05:01 PM, Patricia Shanahan wrote:

On 3/27/2016 12:26 PM, Andrea Pescetti wrote:
...

When we have three PMC members willing to commit to voting (at due time)
on the NetBeans plugin, this discussion will make sense. Otherwise we
are wasting our time.


I generally have at least one Windows box with Netbeans installed, so 
I should be able to participate.


That great,  You will need v. 8.1



Insufficient PMC members is a problem in its own right, but I don't 
think it changes the release policy at all.


One possible solution to consider in the long term to splitting out 
some of this type of thing from the OpenOffice project. As a separate 
project it would be much less scary, and might attract more 
developers, and PMC members, with the specific skills.
I think this particular plugin belongs here.  Its sole purpose is to 
generate AOO extension code and is dependent on the UNO API's. As a 
separate project it doesn't have the necessary activity to stay at 
Apache nor does it require it as it is fairly mature for what it is 
intended for. However one could argue there is functionality that could 
be added. Bringing it back later if needed would be more difficult due 
to code IP issues.


I would agree my recent efforts on Gradle integration and Groovy UNO 
would be better candidates to spin-off.
However if we ever add Apache Groovy as a macro language (hopefully my 
next endeavor) and want to include that in the code base and not as an 
extension, it would be dependent on an outside project instead of under 
our control.


Thanks,
Carl

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

Re: Releasing the Apache OpenOffice API plugin for NetBeans

[Patricia Shanahan]

On 3/27/2016 3:53 PM, Carl Marcum wrote:

On 03/27/2016 05:01 PM, Patricia Shanahan wrote:

On 3/27/2016 12:26 PM, Andrea Pescetti wrote:
...

When we have three PMC members willing to commit to voting (at due time)
on the NetBeans plugin, this discussion will make sense. Otherwise we
are wasting our time.


I generally have at least one Windows box with Netbeans installed, so
I should be able to participate.


That great,  You will need v. 8.1


Got v. 8.1 installed.

I would like to attempt a build and test from what you now have. Is 
there a Wiki how-to page? If not, should we be constructing one?


Patricia

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