> -----Original Message----- > From: Dave Fisher [mailto:dave2w...@comcast.net] > Sent: Monday, 1 August 2011 10:10 AM > To: ooo-dev@incubator.apache.org > Cc: 'Kay Schenk' > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was > re:OpenOffice.org branding) > > Hi Dennis, > > I went for a walk and shopped before replying to Kay. Between the two of us > we certainly have consensus. > > On Jul 31, 2011, at 3:53 PM, Dennis E. Hamilton wrote: > > > Thanks for your follow-up Kay. Keep asking! > > > > No, I was thinking that Apache ooo would be the place for code > developers. > > > > OpenOffice.org for public web, downloads, forums, wikis, etc., and end- > user, power-user support in the ways it has come to be known and loved. > Also the place to hook in the several language communities. That is, they > would be where people already know where to look for them and those who > support them already would also be able to continue doing that. > > > > See the recent conversation with Terry Ellison and Mark Thomas on LAMP, > etc. as well. > > > > Some of the developer-centric content would migrate to apache.org but > we can figure that out. I share your concern about fragmenting the > community. But we know for certain that the code has to move and that the > development on it will be under the Apache Way and the ooo [P]PMP. We > also have to deal with the IP cleanups as part of that. > > > > What I am hoping for is that we can secure, preserve, and continue > OpenOffice.org pretty much as is, with the developer impact being what it > already is. > > > > I don't know what to do about bug-tracking. It really needs to move to > apache.org, I think. More creative thinking required here. > > Yes, definitely. This may now be the biggest unknown to the migration. > Raphael Bircher was investigating ... > > I guess we have three choices - > > (1) Preserve current bugzilla. Requires people to support directly. > > (2) Convert to Apache Bugzilla. > > (3) Convert to Apache JIRA. > > Perhaps we should preserve the old bugzilla in openoffice.org as a read / > comment-only resource on an appropriate VM and redirect to Apache JIRA / > Bugzilla in the project's site for new issues. In many ways this is easier. We'll > just need to assure we can support the infrastructure.
I think the plan is to migrate the current Bugzilla as it is to ASF hardware and then at some stage, over time, it can align itself to be more of a standard Bugzilla install like the other ASF ones are. Initially, anyway we should certainly plan to do the migration and get it running so as to not cause unnecessary interuptions to service. Then if you guys decide you want to move over to Jira, we can do that no problem. Infrastructure folks will look after the Bugzilla instance itself, performing the migration, the upgrades etc. OOo admins can help look after the web faced aspects I expect. If any of the current OOo admins who look after and know Bugzilla want to help maintain the instance on the machine (FreeBSD Jail is earmarked for it) then that's something we can organise. (Some of this is mute if you later want to move to Jira. Note that Jira too is maintained by Infra as a whole, with OOo admins looking after the GUI side of things.) HTH Gav... > > Regards, > Dave > > > > > - Dennis > > > > -----Original Message----- > > From: Kay Schenk [mailto:kay.sch...@gmail.com] > > Sent: Sunday, July 31, 2011 15:18 > > To: ooo-dev@incubator.apache.org > > Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was > > re:OpenOffice.org branding) > > > > > > > > On 07/30/2011 03:28 PM, Rob Weir wrote: > >> On Sat, Jul 30, 2011 at 5:25 PM, Kay Schenk<kay.sch...@gmail.com> > wrote: > >>> > >>> > >>> On 07/30/2011 11:37 AM, Dennis E. Hamilton wrote: > >>>> > >>>> On another list, I saw a comment from Roy Fielding that resonated > >>>> with me. Others have mentioned it, but not here on ooo-dev. > >>>> > >>>> My interpretation is that we could have Apache ooo as the > >>>> identifier of the core Apache project built on what we factor out > >>>> of the Oracle grant, leaving OpenOffice.org as a web site and a > >>>> family of distributions and support for end-user and > >>>> adopter/integrator activities that reach out beyond the development > >>>> of a buildable open-source code base. > >>> > >>> This seems like a GREAT idea to me assuming it can be "done" vis a > >>> vis current conditions -- the Apache way, etc. Also see below > >>> > >> > >> > >> That has been the plan since the start. We eventually have an > >> openoffice.apache.org web site that has the project-facing website > >> and services, like source repositories, dev lists, work by > >> translators, documentation, etc. This is the web site where those > >> who make OOo work, the project community. > > > > Well OK, at some point I got very confused by what this meant I guess. > > Should I take this remark openoffice.apache.org will be primarily the > > stop off for what I'll call "code developers"? > > > >> > >> Then we have http:///www.openoffice.org, which remains the end-user > >> facing portal, the entry way to downloads, to support, to templates > >> and extensions, etc. > > > > Right, OK, but again, where will this and many other ancillary > > openoffice.org sites (like the forums etc.) actually live? > > > >> > >> There are some services that have dual personalities, like bugzilla, > >> which is used by users as well as those on the project development > >> side. > > > > -- more below.... > > > >> > >> This would not be an attempt to create an artificial division between > >> the project community and the users. I'm very sensitive to that. > >> But in this space, we really need an extremely easy-to-use, slee, > >> sexy, consumer-friendly portal for end users. This is the face of the > >> project to millions of current and potential users. We should have > >> hooks to draw them into the project community, for those with further > >> interest. But we can't scare them initially with the bare-bones > >> standard Apache look and feel project site. > >> > >>>> > >>>> I think we should consider that attempting to put OpenOffice.org > >>>> atop all of it is over-constraining and also confusing, even though > >>>> the result may be unrecognizably different at the end-user level. > >>>> > >>>> - Dennis > >>>> > >>>> MORE THOUGHTS BELOW THE QUOTATION > >>>> > >>>> [Disclaimer. This inspired my thinking but any misunderstanding of > >>>> what Roy was thinking is mine and mine alone.] > >>>> > >>>>> -----Original Message----- From: Roy T. Fielding > >>>>> [mailto:field...@gbiv.com] Sent: Wednesday, July 27, 2011 09:51 [ > >>>>> ... quoted by permission ] Subject: Re: OpenOffice.org branding > >>>>> > >>>>> [ ... ] > >>>>> > >>>>> BTW, my personal preference is to call our product Apache OOo and > >>>>> leave the OpenOffice.org website as a joint forum and > >>>>> redistribution site for all variations of the suite, docs, > >>>>> tutorials, etc. However, such decisions are typically made by the > >>>>> people doing the work. > >>>>> > >>>>> Cheers, > >>> > >>> yes... +1 > >>> > >>>>> > >>>>> ....Roy T. Fielding, Director, The Apache Software Foundation > >>>>> (field...@apache.org)<http://www.apache.org/> > >>>>> (field...@gbiv.com)<http://roy.gbiv.com/> > >>>>> > >>>> > >>>> MORE THOUGHTS > >>>> > >>>> I am not invested in the history or passion around OpenOffice.org > >>>> as an ongoing development. My perspective is as someone who works > >>>> from the open standards and architectural perspective. So I beg > >>>> your forbearance if I have been insensitive to the history and the > >>>> familiarity that there is in how things have been done over the > >>>> years. It is not my intention to offend but to see what we can see > >>>> by thinking outside of the box. > >>>> > >>>> I trust it is clear to all of us that it will be unlikely that we > >>>> can somehow revive OpenOffice.org to a place where it is a > >>>> business-as-usual continuation of the now-stalled effort. > >>>> > >> > >> Not business as usual. Business better than usual. But this is not > >> something for arguing. It is for doing. > >> > >>>> Furthermore, my attention is on the suitability of Apache ooo as a > >>>> reference implementation with respect to ODF, with less emphasis on > >>>> what it takes to continue OpenOffice.org a desirable and thriving > >>>> software distribution. I'm in favor of that. It is not what my > >>>> attention is on. So this is not a balanced perspective. > >>>> > >> > >> > >> And why can't we do both? Is there some reason why an application > >> cannot both be a good implementation of ODF and also be a thriving > >> product? There are not mutually exclusive outcomes. > >> > >> > >>>> Here are some loosely-conceived thoughts. I don't have a clear or > >>>> specific picture. But I think the conceptual separation of ooo and > >>>> OpenOffice.org is an opportunity that might unfreeze us from trying > >>>> to move ahead under one giant lump. > >>> > >>> I agree...but... > >>> > >>>> > >>>> I favor the idea of separating the "pure Apache-way" project effort > >>>> and from the OpenOffice.org identity and "brand" as a broader > >>>> umbrella for all of the variations that go into making end-user > >>>> distributions, providing documentation materials, end-user support, > >>>> and especially the various native-language efforts that are part of > >>>> the OpenOffice.org ecosystem. > >>> > >> > >> I've heard this idea put forward by LibreOffice supports as well. > >> The brand name of OpenOffice.org is very strong. The web site gets a > >> lot of traffic. Far more than libreoffice.org. Far more than > >> symphony.lotus.com. I think we'd all love a link from that website. > >> Who wouldn't? If you look at other Apache projects you see that they > >> are quite liberal about providing links to distributions of > >> downstream consumers, including other ports, distros and derived > applications. > >> This comes with a disclaimed that these are not official Apache > >> releases, but it does help give these other projects some greater > >> visibility and "link love". See, for example, this Subversion page: > >> > >> http://subversion.apache.org/packages.html > >> > >> As you can see, there is also some degree of co-branding. So there > >> is TortoiseSVN, uberSVN, visualSVN, etc > >> > >> I've always assumed we'd do something similar for Apache OpenOffice, > >> provide links to other releases. And if someone wants to call their > >> release "SuperDuper OpenOffice" or whatever, then we'd handle that > >> request via the normal process for Apache branding discussions. > >> > >> > >>> HOW to do this? I mean from a practical, pragmatic perspective. How > >>> will continued existence of what we might see as the "end user" > >>> OpenOffice.org architecture (servers, administration architecture) > >>> be carried out? What will we use, where will it be housed, how will > >>> it be administered it and who will finance it? I am QUITE concerned > >>> about the existence of the current site (on kenai). Maybe I missed > >>> it, but I haven't seen a "drop dead" for removal of OpenOffice.org from > this platform. > >>> > >> > >> We've had discussions on the list on migration, some details here > >> (look at the website transfer row of the table): > >> > >> > https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning > > > > Yes, I know about this and have contributed to this but it doesn't > > really answer my question...where do we go? > > > > The "user facing" sites are itemized in > > > > https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap > > > > assuming you exclude development, distribution, and api (maybe others > > related to direct development). > > > > What is the suggestion to place this architecture elsewhere? > > > > > >> > >>>> > >>>> I also see separation as rather easy because at the moment we are > >>>> using "ooo" for these lists, for the podling's SVN repository > >>>> branch, for the two wikis, for the Apache Extras (although that has > >>>> forked already [;<), etc. > >>> > >>> um....see my last comments. Easy from a philosophical standpoint, > >>> but not necessarily from a practical one. > >>> > >>>> > >>>> I favor the idea of a cleaner separation of the development of the > >>>> core ODF reference-implementation aspects from wider variations > >>>> that are typical and appropriate for a production-usable > >>>> productivity suite. A distribution will have incidental and > >>>> discretionary provisions that aren't particularly indicative of the > "reference" > >>>> aspects and have not been the subject of standardization. > >>>> > >>>> Important Context: There is wide latitude for discretion in the ODF > >>>> specifications and even wider latitude for user-interface, > >>>> non-UI-based processors, etc., that are not the subject matter of > >>>> the ODF specification at all. It would be good to remove confusion > >>>> around that. Also, a reference implementation, to the extent it is > >>>> usable in practice, should not be taken as being in any sense > >>>> compelling with regard to anything but its conformant support for > >>>> the file format itself. A reference implementation that can be > >>>> operated needs to do something in discretionary areas. The > >>>> incidental and discretionary choices should be soundly done and > >>>> well-narrated. But there must be no suggestion that the approach > >>>> to such incidental and discretionary cases reflect requirements of > >>>> ODF. The user interface and its functionality is not subject > >>>> matter for the ODF specification as it now exists. One wants ways to > produce features of the format. > >>>> One wants ways to deal with provisions of the format in any input > >>>> that is processed. But the gap from input to user presentation and > >>>> interaction and from there to output is not prescribed in the ODF > >>>> specification, nor are mappings between different formats and the > >>>> treatment of different formats as defaults. > >>>> > >>>> I'm not sure how much the technology transfer/deployment would > work > >>>> from Apache ooo to OpenOffice.org and that is something we need to > >>>> figure out. > >>> > >>> Can you elaborate on what you mean by this? I'm confused. > >>> > >>> When we have the code and the collateral artifacts in > >>>> > >>>> hand, our inspection may provide insight into how we can get > >>>> rolling and also understand how the development can be modularized > >>>> in a productive way. > >>>> > >>>> - Dennis > >>>> > >>>> > >>> > >>> good discussion... > >>> > >>>> > >>>> > >>> > >>> -- > >>> -------------------------------------------------------------------- > >>> ---- > >>> MzK > >>> > >>> "If you can keep your head when all others around you are losing > >>> theirs - maybe you don't fully understand the situation!" > >>> -- Unknown > >>> > > > > -- > > ------------------------------------------------------------------------ > > MzK > > > > "If you can keep your head when all others around you > > are losing theirs - maybe you don't fully understand > > the situation!" > > -- Unknown > >
