Re: [PROPOSAL] Admin mailing list
Andrea Pescetti wrote on Mon, Sep 09, 2013 at 09:29:35 +0200: > But I'm really thinking of just an alias that forwards mail, not a > public or private mailing list. For example, how does > aoo-bugzilla-ad...@apache.org work? Maybe that one is a model we could > follow. That one is just an autoreply script. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] Admin mailing list
Rob Weir wrote on Sun, Sep 08, 2013 at 22:14:13 -0400: > On Sep 8, 2013, at 10:06 PM, Daniel Shahaf wrote: > > > Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400: > >> I'd like to propose a new mailing list: ad...@openoffice.apache.org > > > > Public archives or private archives? > > I was assuming it would be public. If something needed to be > discussed privately it could be done on the infra or infra-dev lists. infra-dev@ is public. infra@ is technically private but allows any committer to subscribe, which makes it wider than is suitable for some discussions (such as "Who is going to install that security patch that has just been announced?"). > Does that make sense? Or would you recommend something else? Hard to say: some topics should be public and some topics need to be private, but I don't know what topics you guys are looking for a place to discuss, so I can't say whether a private list or a public list would better meet your needs. HTH Daniel - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] Admin mailing list
Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400: > I'd like to propose a new mailing list: ad...@openoffice.apache.org > Public archives or private archives? > It would serve a few primary purposes: > > 1) A focused mailing list to help our volunteer admins coordinate > maintenance of our project infrastructure, or at least that portion of > it maintained by the project. > > 2) It would give a single point of contact for admin-related > questions, outage reports and requests from project members or the > public. > > 3) It would allow other parties interested in monitoring our admin > discussion, say Infra@ members, to follow a more focused list. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Rob Weir wrote on Sun, Sep 08, 2013 at 18:11:19 -0400: > On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti wrote: > > On 04/09/2013 Rob Weir wrote: > >> > >> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote: > >> > >> I assume we want well-maintained servers that help us get our > >> project-related tasks done, and also help serve our users. > > > > > > Yes we do. And Jan's proposal seems very reasonable and dictated from > > experience (both personal experience and the experience of actually > > maintaining these servers). > > > > > >>> some thoughts on how admins could work, but in general I > >>> believe we should convince infra to take over the vm responsibility and > >>> keep our well functioning forum/wiki admins. > > > > > > Last time we approached Infra on this, their answer was: find resources > > (people) within the OpenOffice project to take care of the non-standard > > tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they > > helped a bit respecting these lines so far. > > > > Handing over to Infra would indeed be "peace of mind" for us, but I still > > think that your proposal makes sense in light of the above: Infra prefers > > that project-specific tools are maintained by the project itself as a > > first/primary contact, and escalate to Infra if needed. > > > > By the way, if you believe that Infra could now be available to support us > > more closely, feel free to investigate. > > > > > >> maybe > >> 3b) Try to evolve systems so users can implement their own wishes, in > >> a way compatible with 1) and 2). For example, if routine logos and > >> footers are synched to resources in the project's SVN tree, then any > >> committer can update things. > > > > > > This is not feasible in the current state. Even ignoring the fact that this > > issue derailed the discussion, I see no benefit in implementing this: if we > > have a real (reasonable active) team maintaining the servers, and the team > > is not a bottleneck for the community, we will be fine with it. I won't feel > > "excluded" if I have to ask someone to change some configuration: this > > routinely happens for Infra-maintained services, or for our Bugzilla, and it > > works. > > > > That does not match my experience at all. From trying to get the > terms and conditions statement on the Forum to integrating Google > Analytic across the websites to rolling out the new logo, my > experience has been that getting simple content changes make to the > VMs has been very frustrating. Some of these changes took months. > > (Note: I'm not talking about "configuration". I'm talking about > website content, things like logos, contact information, terms and > conditions, copyright statements, etc.) > > You say that if we had active admin teams maintaining the servers, > this would be easier. But we don't have such a team So these changes > have been painful. Considering the admins are scarce and their time > is precious, I'd like to find ways that we can allow some degree of > "self- service" for committers, so we don't waste admin time on > trivial content changes. Have the admins focus on things that only > they can do. > I'd also like to point out that allowing any committer to make changes --- when that is easy to implement, does not raise security or privacy issues, and does not lead to abuse --- makes the project more inclusionary, which is a good thing. It's not unlike enabling non-committers to review patches. Daniel > So this is not an either/or question. We should both have an active > admin team as well as move toward allowing committers to maintain the > content of our websites. > > Regards, > > -Rob > > > > >>> A good setup would be, 3 types of admin: > >>> Each server will have an appointed "owner" (anchor-admin) > >>> A number of persons have full sudo on a server (admin) > >>> A number of persons can reboot/restart/work on po files (help-admin) > > > > > > Something that we might discuss (but I guess this is implicit in your > > proposal) is to avoid that the same person is the "anchor-admin" (or > > "contact-admin", i.e., the first point of contact) for all the three > > machines. This might help in sharing the knowledge and mitigate the > > "loneliness" you have experienced so far in maintaining our infrastructure. > > > > It would actually make a lot of sense that you continue to be the > > "main/anchor-admin" for at least one of the machines, so that the other > > machines can be smoothly transitioned and that the whole knowledge, not only > > what's written in the documentation, can be shared. > > > > 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 additi
Re: Problem with PayPal donations to the Apache Software Foundation
On Sat, Sep 07, 2013 at 10:47:20AM +0200, Andrea Pescetti wrote: > To the Apache fundraisers: a user (see below for context) reported a > problem with PayPal donations to the Apache Software Foundation > account, used for Apache OpenOffice donations. > > Indeed the button at > > http://www.apache.org/foundation/contributing.html#Paypal > > leads to the following error message: Thanks for the report. We're looking into the issue and updated the website to note it. We hope it will be fixed in a few days so it would be great if you could retry the donation then. Thanks for your interest in the ASF! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bugzilla is down
It's on status.apache.org so we already know about it. On Tue, Jun 11, 2013 at 07:33:55AM -0400, Karl Wright wrote: > FWIW, JIRA is also down; https://issues.apache.org/jira does not respond, > or takes a very long time. > > Karl > > > On Tue, Jun 11, 2013 at 7:18 AM, Oliver-Rainer Wittmann < > orwittm...@googlemail.com> wrote: > > > Hi, > > > > > > On 11.06.2013 13:16, Oliver-Rainer Wittmann wrote: > > > >> Hi, > >> > >> On 11.06.2013 13:06, Daniel Shahaf wrote: > >> > >>> On Tue, Jun 11, 2013 at 12:42:48PM +0200, Oliver-Rainer Wittmann wrote: > >>> > >>>> Hi, > >>>> > >>>> On 11.06.2013 12:00, RGB ES wrote: > >>>> > >>>>> I'm trying to take some bugs on ES translation (in fact, I just fixed a > >>>>> couple of them), but bugzilla is not responding > >>>>> > >>>>> Error 101 (net::ERR_CONNECTION_RESET) > >>>>> > >>>>> > >>>> I also can not access Bugzilla - https://issues.apache.org/ooo/ > >>>> https://issues.apache.org/ is not accessible, too. > >>>> > >>>> Putting infra@a.o on CC - may be infra knows the reason. > >>>> > >>>> > >>> We knew about this. Did you check status.apache.org? > >>> > >>> > >> After written the post I remember the infrastructure maintance mail. > >> Then I had a look at status.apache.org saw the critical status. > >> A minute or so later the status went back to green. > >> > >> > > Now, the status is back to critical :( > > > > > > Best regards, Oliver. > > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bugzilla is down
On Tue, Jun 11, 2013 at 12:42:48PM +0200, Oliver-Rainer Wittmann wrote: > Hi, > > On 11.06.2013 12:00, RGB ES wrote: > >I'm trying to take some bugs on ES translation (in fact, I just fixed a > >couple of them), but bugzilla is not responding > > > >Error 101 (net::ERR_CONNECTION_RESET) > > > > I also can not access Bugzilla - https://issues.apache.org/ooo/ > https://issues.apache.org/ is not accessible, too. > > Putting infra@a.o on CC - may be infra knows the reason. > We knew about this. Did you check status.apache.org? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
(note CC list) Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 18:56:01 -0700: > @Daniel, > > Right, this is about poisoning the committer keys but not touching the > SVN, instead, counterfeiting a binary release downstream, but faking > the asc, md5, and sha1 too. (These would not be at dist, and depend ASF mirrors do not contain .asc, .md5, .sha1 files. We should probably verify that in our regular checks, if we don't do so already. Assuming "real mirrors have no .md5/.asc files" holds, assuming a user downloads a rogue .md5 means either the user is using a rogue download page or there's a rogue .md5 in https://www.apache.org/dist/openoffice/ --- these are both acceptable risks (the latter because it will have generated a commit mail which the PMC is supposed to catch). > on folks not noticing because the instructions for how to check > correctly are so obscure. It is very far-fetched, since there are > easier exploits that rely on user's not being equipped to verify what > they are getting and not relying on the authentic download location. > > Another way would be to attack the release candidate in the release > manager's ASF FreeBSD account, although someone who checks the > signature might notice that it is by an unexpected committer. Again, > reasonably far-fetched. Two committers would have to be compromised, > or the Release Manager would have to be compromised and not notice > that there is a new fingerprint in the RM's profile. I like that last > one. It has a certain movie-plot plausibility. Who ever looks for > funny business in their profile, or odd materials in their keys entry? Everyone. The PMC is REQUIRED to verify the .asc files in a release before voting on it. That means verifying it's signed by the correct key, too. Daniel > (Note that it is the binaries that are compromised, there is no > messing with the source tarballs.) > > - Dennis > > -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: Monday, April 29, 2013 15:58 > To: Dennis E. Hamilton > Cc: dev@openoffice.apache.org; pesce...@apache.org > Subject: Re: Proposal: Improve security by limiting committer access in SVN > -- KEYS Compromise Exposure > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > > 5. This is sufficient to poison a download mirror site with > > a counterfeit download so long as the ASC, SHA1, and MD5 locations > > can also be spoofed without the user noticing. > > Right. The normal answer here is "They will have to commit to the dist/ > repository which will cause a post-commit mail which someone will > notice". I'd be interested in hearing (on infra-dev@) how you break > this without assuming a mirror gets compromised (if _that_ happens, > it's game over for users who don't verify PGP sigs). > > - > 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 > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Proposal: Improve security by limiting committer access in SVN -- KEYS Compromise Exposure
Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > 5. This is sufficient to poison a download mirror site with > a counterfeit download so long as the ASC, SHA1, and MD5 locations > can also be spoofed without the user noticing. Right. The normal answer here is "They will have to commit to the dist/ repository which will cause a post-commit mail which someone will notice". I'd be interested in hearing (on infra-dev@) how you break this without assuming a mirror gets compromised (if _that_ happens, it's game over for users who don't verify PGP sigs). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Proposal]: Call for donations
You might want to talk to fundraising@ before you do anything --- not as much for permission as for ideas on how to frame the "Please donate" request. (fundraising@ is privately-archived) Joseph Schaefer wrote on Thu, Apr 04, 2013 at 18:38:18 -0400: > FWIW last time I checked there was a huge increase > in paypal donations once OpenOffice adjusted it's > contribution page accordingly. > > > On Apr 4, 2013, at 6:21 PM, Andrea Pescetti wrote: > > > Raphael Bircher wrote: > >> Am 04.04.13 14:22, schrieb Jürgen Schmidt: > >>> And opinions or further ideas how we can improve this? It shouldn't be a > >>> big problem for us to collect the money we need. > >> I disagree. Yes, we can help with foundings for ASF, but please do this > >> on ASF Level. Founding money is not the task of a ASF project, It's the > >> task for the foundation. > > > > The Foundation is made by its projects, so OpenOffice should definitely > > help with fundraising. Consider that OpenOffice (downloads excluded!) > > generates as much web traffic as all the other Apache projects put > > together, or something reasonably close to that. Also, the OpenOffice > > infrastructure requirements (buildbots, management) generates additional > > expenses for the Foundation that only benefit the OpenOffice project. > > > > In short: if OpenOffice can use its web traffic and popularity to drive > > more donations to the Foundation, it will surely directly benefit from most > > of them. So I agree with Juergen that we should solicit donations. > > > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Review Board
Dave Fisher wrote on Fri, Mar 08, 2013 at 15:35:31 -0800: > > On Mar 8, 2013, at 1:47 PM, Rob Weir wrote: > > > On Fri, Mar 8, 2013 at 4:21 PM, janI wrote: > >> On 8 March 2013 22:16, Rob Weir wrote: > >> > >>> On Fri, Mar 8, 2013 at 3:51 PM, Dave Fisher wrote: > Only if we are going to become a Review Then Commit project. > > >>> > >>> I was thinking more of whether it would be useful for working with > >>> patch contributions from contributors. > >>> > >> > >> Just be careful not to set level too high for volunteers, in my opinion the > >> mailing list is more than enough, no need for extra layers to complicate > >> matters. > >> > > > > That's exactly the issue. The mailing list is so busy that new > > volunteers get lost, and their patches as well. And if they toss > > their patches to bugzilla, the patches can easily be lost there was > > well. So the question is whether a dedicated place for patches, with > > no distracting complications, would be preferred. > > If there are volunteers who will do RTC work for new code contributors > then this might be an improvement to bug tracking. FWIW, over at Subversion we (a) have a 'patch' label in the bug tracker, (b) have a volunteer who pings [patch] threads that have petered out without the patch being either applie or rejected. http://subversion.apache.org/docs/community-guide/roles#patch-manager Perhaps one or both of these ideas would be useful here. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New page: Contributing Code
Andrea Pescetti wrote on Wed, Mar 06, 2013 at 10:01:03 +0100: > Rob Weir wrote: >> OK. Feel free to update the language. I think we agree on the facts. >> It is just a matter of making it clear. > > Done at http://openoffice.apache.org/contributing-code.html (first > bullet item). Feel free to review/modify again if further clarifications > are needed. > +1, looks good to me. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: [MediaWiki-announce] MediaWiki security release: 1.20.3 and 1.19.4
janI wrote on Tue, Mar 05, 2013 at 09:08:33 +0100: > On 5 March 2013 08:46, Andrea Pescetti wrote: > > > Daniel Shahaf wrote: > > > >> if somebody replies to your post and says "Hey, > >> false negative", you really want_that_ to happen privately. > >> > > > > That was my concern too. Jan is perfectly right that he merely forwarded a > > public security announcements, and that there is absolutely nothing wrong > > in this in itself, but it's better to avoid the (admittedly remote, in this > > case) possibility that someone exposes a security risk while commenting. > > Take this as a generic practice; we had similar discussions about > > vulnerabilities found in libraries, for example; and the common advice is > > not to discuss security-related practices in public. > > > > I did not take it personally, but I do not understand how we can discuss an > issue on a mailing list where most of the people needed for the discussion > do not have access. Please remember my purpose, we need 2-3 volunteers to > test the update. I am expecting you to discuss security issues privately and recruit volunteers publicly. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: [MediaWiki-announce] MediaWiki security release: 1.20.3 and 1.19.4
janI wrote on Tue, Mar 05, 2013 at 00:41:42 +0100: > On 5 March 2013 00:24, Daniel Shahaf wrote: > > > Andrea Pescetti wrote on Mon, Mar 04, 2013 at 22:05:42 +0100: > > > janI wrote: > > >> As you can read below, mediawiki has just released a security release. > > >> We are currently not hit by the issues noted in the mail. > > >> However I would like to ask the community if we should upgrade or wait > > for > > >> a later release ? > > > > > > Security issues are one of the few cases where we prefer that all > > > conversations happen in private (infrastructure-private, that you CCed, > > > seems right). > > > > Security issues in services running on apache.org hardware should be > > reported to root@, rather than infra-private@. > > > > I dont get itI forwarded a PUBLIC email, about a security relase, NOT a > security issue, just to get an opinion from the community, because if > installed someone has to test it !! > > It is really not easy to something right. Can you please not take this personally? It was just a commit review. To the point: I agree with Andrea: it would have been good if you had been more conservative and discussed the security implications privately. That's because of the a small chance that your assessment that the announced issue does not affect ooo-wiki2-vm will turn out to be a false negative: if somebody replies to your post and says "Hey, false negative", you really want _that_ to happen privately. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fwd: [MediaWiki-announce] MediaWiki security release: 1.20.3 and 1.19.4
Andrea Pescetti wrote on Mon, Mar 04, 2013 at 22:05:42 +0100: > janI wrote: >> As you can read below, mediawiki has just released a security release. >> We are currently not hit by the issues noted in the mail. >> However I would like to ask the community if we should upgrade or wait for >> a later release ? > > Security issues are one of the few cases where we prefer that all > conversations happen in private (infrastructure-private, that you CCed, > seems right). Security issues in services running on apache.org hardware should be reported to root@, rather than infra-private@. See http://www.apache.org/dev/infra-contact#how - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [WEBSITE] Problem with .htm files
Dave Fisher wrote on Mon, Dec 17, 2012 at 10:20:05 -0800:
>
> On Dec 17, 2012, at 9:29 AM, Kay Schenk wrote:
>
> > On Sun, Dec 16, 2012 at 3:54 PM, Dave Fisher wrote:
> >> Hi Andrea,
> >>
> >> On Dec 16, 2012, at 2:44 PM, Andrea Pescetti wrote:
> >>
> >>> Dave Fisher wrote:
> I think that we can purge these *.htm duplicates, but if we do it
> will be a "sledgehammer" build.
> >>>
> >>> It will also be a problem, unless we accompany it with other changes: for
> >>> example, http://www.openoffice.org/pt/ would completely break, and all
> >>> external sites that now link to some of our .htm files would break too.
> >>
> >> Got it.
> >>
> It was intentional. Before doing so we would need to make a group
> decision about how to treat the two types of files.
> >>>
> >>> Regardless of what templates we apply, the best solution should:
> >>> 1) Allow a .htaccess redirect/rewrite from .htm to .html (to preserve
> >>> existing internal and external links)
> >>> 2) Have the SVN file names match the URLs: editing a file named
> >>> "news.htm" in SVN should not result in a change in a page with URL
> >>> ".../news.html". The current handling confuses the CMS too (for example,
> >>> no diff is reported). So either we mass-rename files from .htm to .html
> >>> and rely on 1) above, or we don't change .htm to .html but publish .htm
> >>> URLs.
> >>
> >> We need only do (1) and I would do it within the httpd config like our
> >> existing redirects. Regardless if there are both file1.htm and file1.html
> >> in the source, one of these must be removed from the source svn.
> >
> > Dave, Andrea --
> >
> > Only ONE copy is in source, the "htm" file. The duplicate gets
> > generated from CMS -- but the new "html" is the most recent copy (on
> > the actual web tree) -- generated from "htm".
> >
> > Could we fix our templating to just continue to allow for "htm"
> > instead of combing them as we're doing now?
>
> It can be tried on a local copy. The prospective changes are required in
> lib/view.pm, but exactly what these changes are I am "guessing" at this point.
>
> It will be something about determining which type of page htm vs. html and
> then make the appropriate call here:
>
> I think, but do not know. If someone wants to experiment on a local build
> then I'll give pointers, but I may not have time to check for a day or two.
I think you could define:
sub htm_page {
my (@r) = html_page @_;
$r[1] = 'html' if $r[1] eq 'htm';
@r
}
and then use that in path.pm.
Re: Our SVN moved from "incubator/ooo" to "openoffice"
Marcus (OOo) wrote on Mon, Dec 10, 2012 at 22:56:31 +0100: > Strange, all my "entries" files are still pointing to the incubator URL. > > @Herbert: > Do you have another idea? Or do I have to really checkout all stuff > again? Not a big thing but I would like to avoid this. ;-) The 21st line after a formfeed will contain the incubator URL in new working copies too. Don't worry about implementation details please --- if 'svn info' and 'svnversion' give the right output, you're fine.
Re: promoting svn assets
Dave Fisher wrote on Wed, Nov 21, 2012 at 08:35:39 -0800: > Hi Joe, > > Thanks! > > On Nov 21, 2012, at 8:17 AM, Joe Schaefer wrote: > > > With the holiday weekend coming up, I'd like > > to suggest that that's as good a time as any > > > > to adjust the location of your svn tree to > > top-level. Instead of doing a straight svn mv > > of the tree, I plan to copy it instead and > > set the old location read-only, given that > > past source releases still depend on the old > > svn urls to work. > > You will mark the old svn read-only before you perform the copy, correct? > > > > > Not today, and probably not tomorrow, but before > > Monday, unless there are strong objections listed > > on this thread. > > The implication is that we will ALL need to recheck out our svn source and > cms trees from the new location. We'll find out when try to commit. > 'svn switch' not 'svn checkout' --- uses less bandwidth. > In that case we can svn checkout the new, svn diff the old, apply our changes > to the new, and commit.. > > Correct? > > Best Regards, > Dave > > > > > > > > Thanks. >
Re: Roller account request
Andrea Pescetti wrote on Tue, Nov 06, 2012 at 16:53:11 +0100: > Of course it took me until I got to the ApacheCon to realize that the > best way to share information with the community would be to blog about > what's happening here... > > Could anyone authorize my account "pescetti" to post articles to > https://blogs.apache.org/OOo/ ? If any preliminary steps are to be > taken, I can obviously do it, but so far I only bumped into seemingly > outdated resources like > https://cwiki.apache.org/INFRA/resource-request-faqs.html > What's the problem? Perhaps you missed the one line at the end of the page that points to the new location of the contents? > Thank you, > Andrea.
