Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1FD856D7F for ; Wed, 22 Jun 2011 06:07:18 +0000 (UTC) Received: (qmail 5381 invoked by uid 500); 22 Jun 2011 06:07:17 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 5230 invoked by uid 500); 22 Jun 2011 06:07:14 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 5210 invoked by uid 99); 22 Jun 2011 06:07:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jun 2011 06:07:13 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dennis.hamilton@acm.org designates 75.98.160.130 as permitted sender) Received: from [75.98.160.130] (HELO a2s15.a2hosting.com) (75.98.160.130) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jun 2011 06:07:05 +0000 Received: from 63-226-210-225.tukw.qwest.net ([63.226.210.225] helo=Astraendo) by a2s15.a2hosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QZGaJ-0000vl-DU; Wed, 22 Jun 2011 02:06:43 -0400 Reply-To: From: "Dennis E. Hamilton" To: Cc: "'Dave Fisher'" , "'Daniel Shahaf'" References: <01f401cc3082$ecef01b0$c6cd0510$@acm.org> <20110622035818.GA25480@daniel3.local> In-Reply-To: Subject: RE: Consequences of Working in Office Documents Here Date: Tue, 21 Jun 2011 23:06:44 -0700 Organization: NuovoDoc Message-ID: <024d01cc30a2$90ad6660$b2083320$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEr/q45biTvjUbGJge9E5IzKWRAZAHKKcCeAhWGEsiV6kWUMA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2s15.a2hosting.com X-AntiAbuse: Original Domain - incubator.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acm.org X-Virus-Checked: Checked by ClamAV on apache.org It's true that we could bring things around and shoe-horn them into the = SVN DIFF model, like using a CSV, or not minding that HTML diffs aren't = that illuminating but we get them for what they are worth, etc. Of course, using a CSV loses a lot of information and anything that was = done in the design of the spreadsheet to facilitate its use, in my = chosen example. Now, in this case, the spreadsheet was from a committer. And other = committers knew how to retrieve it, update it, and resubmit to SVN with = an informative enough commit message. This is not a complex case, it = was just illustrative of the different level. The question I did not answer, because I do not know the answer: What = is a straightforward way for someone who was not raised as a Martian to = contribute without being compelled to commit unnatural (for a Venusian) = acts. What is a way to contribute that does not require an unnatural = change in already-successful ways of working? And what is the cutover = where the contribution is substantial enough that an iCLA is required = anyhow? It seems to me there is an impedance mismatch for non-developer = contributions of content that becomes part of an Apache deliverable. I = don't question policies that are involved. I am wondering about the = logistics and the friction of shoe-horning contributors into a practice = that is designed around submission of patches and requires arcane = Martian technology. Perhaps this is too hypothetical. I would like to hear from non-developer members of ooo-Dev who want to = contribute, and what the nature of the envisioned contribution is. = Maybe some concrete use cases can clear this up for all of us. - Dennis -----Original Message----- From: Dave Fisher [mailto:dave2wave@comcast.net]=20 Sent: Tuesday, June 21, 2011 22:30 To: ooo-dev@incubator.apache.org Cc: Dennis E. Hamilton Subject: Re: Consequences of Working in Office Documents Here On Jun 21, 2011, at 8:58 PM, Daniel Shahaf wrote: > Dennis E. Hamilton wrote on Tue, Jun 21, 2011 at 19:20:13 -0700: >> BACK STORY >>=20 >> On a different list, not just here on ooo-dev, there has been some >> surprise to see us putting binaries (ODF documents) into some SVN >> locations used by the PPMC.=20 >>=20 >> My impression is that the experienced hands here in ASF are expecting >> to see DIFFs in commit messages on SVN, but binaries don't get DIFFed >> since it is usually unintelligible and almost always uninteresting. >> For some, it is new news that ODF packages are not XML files. >>=20 >> Someone suggested that one could unpack the Zip of these documents = and >> then do diffs of the respective XML parts and that could serve as >> a DIFF on what the changes are. They also noticed they'd never seen >> that done. >>=20 >> THE INSIGHT >>=20 >> On seeing that suggestion (clearly the kinds of things developers >> think of, it being what we do), it struck me that we have a geeks are >> from Mars, users are from Venus situation here. >>=20 >> I think the clash of expectations has to do with the differences in >> tools that are applicable at the level we work at, and how we see = what >> it is we are at work on. >>=20 >> We need to understand that we really have different experience sets, >> and they all are important in the context of the OpenOffice.org >> project. >>=20 >> A GEEKY LOOK >>=20 >> Here is a geeky explanation of why it does no good to figure out >> a better way to show DIFFs of the XML inside an ODF package if you >> want to know what an author contributor/committer changed. (You = might >> want that as a forensics tool, but not for knowing what someone >> changed in the course of their work on a document.) >>=20 >> My (updated) explanation: >>=20 >=20 > Long email. In the end, the expectation is for commit mails to = contain > reviewable diffs, I don't think you've addressed how that might be = done? As far as I know binary files are acceptable elsewhere in SVN. >=20 > (as opposed to how it shouldn't be done) Generally ODF files will be documentation and testcases, and generally = consistent., like PNGs, JPEGs, etc. No one complains about PDFs or any = of the MS Office formats in SVN. We haven't seemed to care about that in = the Apache POI project, I can't answer for PDFBox. I unzipped an ODF zip then each part is a huge set of verbose xml on two = lines. Header and data. For example, content.xml.