2011-07-01 PPMC Status: Bringing Initial Committers On-Board
As of end of day 2011-07-01, this is the state of the PPMC membership and the actions needed/underway to bring the initial committers on-bard the Apache OpenOffice.org incubator podling. The tallies have been refactored a bit so there is no complete week-over-week comparison. But you should have some sense of where we are making headway: CURRENT PPMC STATUS: BRINGING INITIAL COMMITTERS ON-BOARD WHO'S ON-BOARD 1 champion 5 mentor 2 mentor/committer 31 PPMC/committer 17 committer (includes pending "PPMC?") 7 other ASF Member observers, etc. 63 total = Pending PPMC? + complete PENDING ACTIONS 0 invite committer/PPMC invitation pending 0 accepted? waiting for invitation acceptance 27 iCLA? waiting for iCLA; 31 sent e-mail reminders 6/23 0 choose ID invite to choose ID 4 ID chosen? waiting for choice 5 ID pending account creation underway 14 PPMC? waiting for accept/follow-up 49 complete 2 other special completion case 101 Total -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Saturday, June 25, 2011 00:46 To: OOo-dev Apache Incubator Subject: 2011-06-24 PPMC Status: Bringing Initial Committers On-Board As of end of day 2011-06-24, this is the state of the PPMC and the actions needed/underway to bring the initial committers on-board the Apache OpenOffice.org incubator podling: CURRENT PPMC STATUS: BRINGING INITIAL COMMITTERS ON-BOARD WHO'S ON-BOARD 1 champion 7 mentor mentor/committers (player coaches?) count below too 17 PPMCare committers not counted below 24 committer includes those in "PPMC?" pending status PENDING ACTIONS - What the PPMC Is Working On 0 invite committer/PPMC invitation pending 0 accepted? waiting for acceptance and initiating next steps 32 iCLA? waiting for CLA 0 choose ID invitation to choose ID pending 4 ID chosen? waiting for choice of ID 8 ID pending ID account creation and committer addition pending 19 PPMC? waiting for subscription to ooo-private to serve on PPMC 35 complete nothing further required 3 *other*some special completion cases: declined, etc. I intend to provide updates to this status at least weekly until the on-board activity is completed. - Dennis E. Hamilton
Re: fetch-all-cws.sh (was: Building a single Hg repository)
On Fri, Jul 1, 2011 at 17:18, Greg Stein wrote: > On Fri, Jul 1, 2011 at 16:58, Michael Stahl wrote: >... >> but actually i think that a lot of these 250 CWSes will not contain a >> changeset that is not in the master already; a lot of developers create new >> CWS and then (have to) work on something else for some weeks... >> >> so i have adapted the fetch script to skip empty CWSes. > > Saw that. Great! I used that code to figure out which are empty, and then commented those out from the cws-list.txt file. I think it is best to keep the code in there, regardless. Somebody may want run it in the future. When I was working on this, however, I noticed we were not attempting to fetch the cws_l10n repositories. So I fixed the filter, but Mercurial said those repositories are not related to DEV300. What is going on there, and what do we need to fix? Should we be fetching the cws_l10n/* repositories? And if so... how do we integrate that into our single repository, and then into our svn repository? Cheers, -g
RE: [CONF] Apache OpenOffice.org Community > OpenOffice Domains
> -Original Message- > From: Dave Fisher [mailto:dave2w...@comcast.net] > Sent: Saturday, 2 July 2011 9:35 AM > To: ooo-dev@incubator.apache.org > Subject: Re: [CONF] Apache OpenOffice.org Community > OpenOffice > Domains > > I know. I'm working on it. I've turned it off for the moment and I am > experimenting with my own account. > > Thanks for noticing. More next week. > > On Jul 1, 2011, at 4:20 PM, Greg Stein wrote: > > > Hrm. This isn't showing a diff. Is there a setting to make that > > happen? Just displaying the whole page isn't very useful :-( > > Note that by default, if you 'watch' a space it will send you email notifications (I've set mine to daily) and that the email will not contain diffs of all pages but rather links where you can click on and go to the online diff of that change. example: Page: Transition Planning edited by Raphael Bircher [10:00 PM] (view changes) where that 'view changes' is a link to https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=2 7361521&originalVersion=5&revisedVersion=6 I think, currently, it is the best Confluence does in regards to diffs. Last time I checked, there was no native or plugin way of emailing the diff contents directly. I also notice you created a role account with the email address set to a mailing list, as soon as somebody decides to do a password reset on that account, guess where the password reset mail will go to? There needs to be a better way, currently I haven't got one. Gav... > > On Fri, Jul 1, 2011 at 17:23, wrote: > >> Space: Apache OpenOffice.org Community > >> (https://cwiki.apache.org/confluence/display/OOOUSERS) > >> Page: OpenOffice Domains > >> > (https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Dom > a > >> ins) > >> > >> Change Comment: > >> - > >> Another innocuous change - making sure notifications are set properly. > >> > >> Edited by David Fisher: > >> - > >> *After checking a few random entries here, all these domains seem to > >> exist on one physical server.* > >> > >> h1. Accepted Projects > >> ...
Re: [CONF] Apache OpenOffice.org Community > OpenOffice Domains
On Fri, Jul 1, 2011 at 7:46 PM, Greg Stein wrote: > Awesome. Thanks, Dave! > > On Fri, Jul 1, 2011 at 19:34, Dave Fisher wrote: > > I know. I'm working on it. I've turned it off for the moment and I am > experimenting with my own account. > > > > Thanks for noticing. More next week. > Did some more annotations of the Incubation projects and some of the Accepted. > > > > On Jul 1, 2011, at 4:20 PM, Greg Stein wrote: > > > >> Hrm. This isn't showing a diff. Is there a setting to make that > >> happen? Just displaying the whole page isn't very useful :-( > >> > >> On Fri, Jul 1, 2011 at 17:23, wrote: > >>> Space: Apache OpenOffice.org Community ( > https://cwiki.apache.org/confluence/display/OOOUSERS) > >>> Page: OpenOffice Domains ( > https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains) > >>> > >>> Change Comment: > >>> - > >>> Another innocuous change - making sure notifications are set properly. > >>> > >>> Edited by David Fisher: > >>> - > >>> *After checking a few random entries here, all these domains seem to > exist on one physical server.* > >>> > >>> h1. Accepted Projects > >>> ... > > > > > -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org
Re: [CONF] Apache OpenOffice.org Community > OpenOffice Domains
Awesome. Thanks, Dave! On Fri, Jul 1, 2011 at 19:34, Dave Fisher wrote: > I know. I'm working on it. I've turned it off for the moment and I am > experimenting with my own account. > > Thanks for noticing. More next week. > > On Jul 1, 2011, at 4:20 PM, Greg Stein wrote: > >> Hrm. This isn't showing a diff. Is there a setting to make that >> happen? Just displaying the whole page isn't very useful :-( >> >> On Fri, Jul 1, 2011 at 17:23, wrote: >>> Space: Apache OpenOffice.org Community >>> (https://cwiki.apache.org/confluence/display/OOOUSERS) >>> Page: OpenOffice Domains >>> (https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains) >>> >>> Change Comment: >>> - >>> Another innocuous change - making sure notifications are set properly. >>> >>> Edited by David Fisher: >>> - >>> *After checking a few random entries here, all these domains seem to exist >>> on one physical server.* >>> >>> h1. Accepted Projects >>> ... > >
Re: [CONF] Apache OpenOffice.org Community > OpenOffice Domains
I know. I'm working on it. I've turned it off for the moment and I am experimenting with my own account. Thanks for noticing. More next week. On Jul 1, 2011, at 4:20 PM, Greg Stein wrote: > Hrm. This isn't showing a diff. Is there a setting to make that > happen? Just displaying the whole page isn't very useful :-( > > On Fri, Jul 1, 2011 at 17:23, wrote: >> Space: Apache OpenOffice.org Community >> (https://cwiki.apache.org/confluence/display/OOOUSERS) >> Page: OpenOffice Domains >> (https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains) >> >> Change Comment: >> - >> Another innocuous change - making sure notifications are set properly. >> >> Edited by David Fisher: >> - >> *After checking a few random entries here, all these domains seem to exist >> on one physical server.* >> >> h1. Accepted Projects >> ...
Re: [CONF] Apache OpenOffice.org Community > OpenOffice Domains
Hrm. This isn't showing a diff. Is there a setting to make that happen? Just displaying the whole page isn't very useful :-( On Fri, Jul 1, 2011 at 17:23, wrote: > Space: Apache OpenOffice.org Community > (https://cwiki.apache.org/confluence/display/OOOUSERS) > Page: OpenOffice Domains > (https://cwiki.apache.org/confluence/display/OOOUSERS/OpenOffice+Domains) > > Change Comment: > - > Another innocuous change - making sure notifications are set properly. > > Edited by David Fisher: > - > *After checking a few random entries here, all these domains seem to exist on > one physical server.* > > h1. Accepted Projects >...
Re: fetch-all-cws.sh (was: Building a single Hg repository)
On Fri, Jul 1, 2011 at 16:58, Michael Stahl wrote: > On 01.07.2011 13:42, Greg Stein wrote: >... >> This is the approach that I took. Please look at >> tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) >> are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are >> over 2 Gb each, and another over 1 Gb. And this is with the clone/pull >> technique. > > indeed, i get similar numbers. > a clone with hardlinks is 34 MB on my filesystem. > a CWS with a single changeset takes 670MB. > reason is that for every commit, 2 files that store changelogs and manifests > are modified, and together these are >600 MB in our repo. While away from the laptop, I realized that I may have messed up the counting due to the hardlinks. But I find that 'du' counts files just once per execution, which is the right thing. So it is good to see you have an explanation for why it takes so much space. >... > but actually i think that a lot of these 250 CWSes will not contain a > changeset that is not in the master already; a lot of developers create new > CWS and then (have to) work on something else for some weeks... > > so i have adapted the fetch script to skip empty CWSes. Saw that. Great! > >> A possible alternative to pulling N repositories, then combining them >> in a second step, is to attempt to bring them all into a single >> repository, one at a time. This is a little more scary for me, not >> knowing Hg, to understand how restartable and repeatable this process >> will be in the face of errors. Either starting from scratch, or (I >> believe an important feature) if it needs to be resumed after some >> minor failure (eg. network failure). > > this would of course take much less space, but then it would be necessary to > mark the newly pulled head immediately to know which CWS it corresponds to. Could you review Herbert's script? I think we'd actually put that into single-hg.sh, and delete the fetch-all-cws.sh script as unneeded. Is that a safe approach? What happens if it stops part way through? Can it be restarted with minimal effort? And what happens to the bookmarks in such a case? >> We have a script. It is time to make it work. >> >> Michael: you say that some CWS repositories are useless. If so, then >> please update tools/dev/cws-list.txt to comment-out those CWS's with >> some explanation for future readers. No need for us to attempt to >> process them if they're bogus. > > i have checked the status in EIS, and it seems like the repos for almost all > integrated/deleted CWSes have already been automatically removed from the > server. > found a couple that were in a state "cancelled", which i didn't even know > existed, sounds like we don't need those, so i've commented them out. Great. > of course some CWSes contain stuff that's not useful, but i don't know which > these are :) Right. I think we just bring it all over, and then sort it out in our repository. Cheers, -g
Re: fetch-all-cws.sh (was: Building a single Hg repository)
On 01.07.2011 13:42, Greg Stein wrote: On Wed, Jun 29, 2011 at 05:04, Michael Stahl wrote: ... in principle the size of a CWS is on the same order as the master, because it's just another HG repository. but HG supports hardlinks between repositories (in newer versions even on win32), so you can "hg clone" the master on the same filesystem and then pull in the CWS, and it will be _much_ faster and take _much_ less additional space This is the approach that I took. Please look at tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are over 2 Gb each, and another over 1 Gb. And this is with the clone/pull technique. indeed, i get similar numbers. a clone with hardlinks is 34 MB on my filesystem. a CWS with a single changeset takes 670MB. reason is that for every commit, 2 files that store changelogs and manifests are modified, and together these are >600 MB in our repo. I don't have enough space on my laptop to do a complete trial run. I'm hoping that somebody can figure out how to reduce the disk footprint, or determine that we just have to suck it up. And it would be nice to understand what that target size will be, for all 250 CWS repositories. i think i wrote that all CWSes as HG repos take ~100 GB, but actually i now think i remembered wrong and the number was more like ~150 GB. (i did this originally in 2 steps, and i remembered only the second step...) (and if it weren't so late now i'd even dig out my external hd and run du...) of course the filesystem used could make a difference here. but actually i think that a lot of these 250 CWSes will not contain a changeset that is not in the master already; a lot of developers create new CWS and then (have to) work on something else for some weeks... so i have adapted the fetch script to skip empty CWSes. A possible alternative to pulling N repositories, then combining them in a second step, is to attempt to bring them all into a single repository, one at a time. This is a little more scary for me, not knowing Hg, to understand how restartable and repeatable this process will be in the face of errors. Either starting from scratch, or (I believe an important feature) if it needs to be resumed after some minor failure (eg. network failure). this would of course take much less space, but then it would be necessary to mark the newly pulled head immediately to know which CWS it corresponds to. We have a script. It is time to make it work. Michael: you say that some CWS repositories are useless. If so, then please update tools/dev/cws-list.txt to comment-out those CWS's with some explanation for future readers. No need for us to attempt to process them if they're bogus. i have checked the status in EIS, and it seems like the repos for almost all integrated/deleted CWSes have already been automatically removed from the server. found a couple that were in a state "cancelled", which i didn't even know existed, sounds like we don't need those, so i've commented them out. of course some CWSes contain stuff that's not useful, but i don't know which these are :) -- "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." -- Alan J. Perlis
Re: ODF Toolkit Incubation Pre-Proposal
On 7/1/11 7:33 AM, Rob Weir wrote: [...] 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, the AODL project's home page says that the library is Apache2-licensed; however the AODL library relies on the SharpZipLib library, which is GPL2 with some Classpath-like exception explained here: http://sharpdevelop.net/OpenSource/SharpZipLib/ http://sharpdevelop.net/OpenSource/SharpZipLib/GPL.asp It looks like someone removed this GPL SharpZipLib dependency when someone did a Silverlight port, but I don't see that this patch is in the main code, but rather in a fork: http://odftoolkit.org/bugzilla/show_bug.cgi?id=109 https://bitbucket.org/chrisc/aodl/
RE: Differences between OOO and LibreOffice.
Got it! Thanks for the clarification with regard to audience. My suggestion is to talk about them being compatible for must usage and not mention standards and metrics (like 100%). I agree completely on advice to individuals. I do the same with family members who only have simple needs for productivity software but need to be able to interchange files for volunteer work or something like that. Regards, - Dennis -Original Message- From: Ian Lynch [mailto:ianrly...@gmail.com] Sent: Friday, July 01, 2011 02:25 To: dennis.hamil...@acm.org Cc: ooo-dev@incubator.apache.org; giffu...@tutopia.com Subject: Re: Differences between OOO and LibreOffice. On 30 June 2011 17:18, Dennis E. Hamilton wrote: [ ... ] I wasn't thinking in a particular detailed way with the original post, it was really just saying hey this end user asked which product to choose. His main concerns I'm guessing would be are they similar to use (almost identical), can I exchange files the same from and between these products and others. (hopefully identically) and will any license differences affect me (probably not) [ ... ]
Re: fetch-all-cws.sh (was: Building a single Hg repository)
On 01.07.2011 13:42, Greg Stein wrote: [...] Please look at tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are over 2 Gb each, and another over 1 Gb. And this is with the clone/pull technique. Because of the disk space demands I think an approach with one repository with one branch per CWS would be better for the initial import. In hg there are more opportunities for this approach (using NamedBranched, UnnamedBranches, MultipleHeads, LocalBranches or Bookmarks) than I as git-fan would care to know. Please see the attached file where I hacked together a script that imports the CWSs into one repository with multiple bookmarks. I don't have enough space on my laptop to do a complete trial run. I'm hoping that somebody can figure out how to reduce the disk footprint, or determine that we just have to suck it up. And it would be nice to understand what that target size will be, for all 250 CWS repositories. As Michael mentioned it's much less than the 250, as only about 15 CWSses (see http://goo.gl/gczAH for details) are marked as fully tested and but not-yet integrated. From these the ones targeted at the stabilization branch (calc67, calc68, ooo34gsl01, ooo34gsl02, writerfilter10, native373, jl167) are more important than the ones targeted for trunk (sb140, sb143, hsqldb19, hr77, ause131, sd2gbuild). There are a few more very good CWSses which were not yet officially approved in the old OOo system. E.g. CWS aw080 Armin mentioned. If Armin can confirm that this CWS is ready we should pull it in too. Once we have a better picture of what is ready or not cws-list.txt needs to be updated. We have a script. It is time to make it work. Please see the attached file. I'm afraid to check it in as the related single-hg.sh is not yet updated accordingly and also because I'm more of a HG victim than a HG power-user ;-) Please note that you either have to use HG>=1.8 or enable its bookmark extension before you run the attached script. Best regards, Herbert Duerr #!/bin/sh # # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you 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 # # 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. # # # Use this script to fetch all the CWS repositories listed in the # specified file (typically, cws-list.txt). Before using this script, # you should have a local Hg repository of the DEV300 repository. # See http://wiki.services.openoffice.org/wiki/Getting_It. # # USAGE: # $ ./fetch-all-cws.sh CWS-LIST WORK-DIR # # CWS-LIST is a file containing the list of CWSs to fetch # (see the file tools/dev/cws-list.txt) # WORK-DIR is the repository where each CWS will be represented as a bookmark # # The script may be restarted. Each existing CWS will be refreshed, # and the remaining CWSs will be fetched. # # Once the repositories are all fetched, see tools/dev/single-hg.sh to # combine them into a single repository. # if test "$#" != 2; then echo "USAGE: $0 CWS-LIST WORK-DIR" exit 1 fi REPOS='http://hg.services.openoffice.org' # Make the trunk directory, in case it does not exist yet if test ! -e "$2"; then mkdir "$2" pushd "$2" hg clone -U "$REPOS/DEV300" . hg bookmark DEV300 hg pull -u "$REPOS/OOO340" hg bookmark OOO340 hg update --clean DEV300 popd fi cwsdir=`dirname "$1"` cwsfile=`basename "$1"` cwslist=`(cd "$cwsdir" ; pwd)`/$cwsfile cd "$2" for cws in `sed -n '/^cws\//s#^cws/##p' $cwslist` ; do echo " updating bookmark '$cws' from upstream CWS '$cws' ..." hg update -C -r "$cws" hg pull -u "$REPOS/cws/$cws" hg bookmark -r tip "$cws" # prepare to restore trunk by forgetting current bookmark # see http://www.selenic.com/pipermail/mercurial/2011-January/036883.html rm .hg/bookmarks.current # restoring trunk to smallest common denominator hg update --clean DEV300 done
Re: Please add your name to the contributors page
I have not seen that error before. Maybe this discussion will help: http://www.svnforum.org/threads/37328-SSL-error-when-doing-a-large-commit (I know that this isn't a large file, but you might have a timeout situation from China, even with smaller files) Also, be sure that you re running the latest version of your SVN client. -Rob 2011/7/1 hanshuwang > ** > Hi Rob, > I have aquired a Apache ID for OOo,but I can't commit in the file > "people.mdtext",can you help me? the error info as follow: > > Regards, > -- > ShuWang Han > RedOffice > Tel：(86-10)51570010-6150 > email：hanshuw...@redoffice.com,hanshuw...@tsinghua.org.cn > MSN: han_shuw...@hotmail.com > Address:2F HuiLongSen Tower A,18 Xihuan South Road, YiZhuang >Economic and Technological Develop Zone, Daxing District, Beijing, > China. > -- > *发件人：* Rob Weir > *发送时间：* 2011-06-29 03:10:05 > *收件人：* ooo-dev@incubator.apache.org > *抄送：* > *主题：* Please add your name to the contributors page > > http://incubator.apache.org/openofficeorg/people.html > > I've updated the page to have a table rather than just a flat list. > Every committer should add themselves to the list, as well as ever > other person who is contributing via the the discussion lists, wiki, > etc. You're all contributors to the project. > > Committers should follow the instruction here, to learn how to use the > CMS to edit the web site: > > http://incubator.apache.org/openofficeorg/docs/edit-cms.html > > This is an essential project skill, so if you have not already studied > that page, it would be good to take this as an opportunity to pick up > this skill. If you are a programmer, comfortable with Subversion, the > the command line instructions are easy. If you would prefer the web > interface, then skip down to where it says "Editing in the browser". > > For contributors who are not committers, you would need to submit a > patch with your information to the list. > > In addition to ensuring that everyone understands how to update the > web site, this is also a good opportunity to build a quick directory > of what skills project members have. > > Regards, > > -Rob >
Re: Naming of trunk and feature branches
Am 07/01/2011 05:23 PM, schrieb Alexandro Colorado: On Fri, Jul 1, 2011 at 10:20 AM, Alexandro Coloradowrote: On Fri, Jul 1, 2011 at 10:13 AM, Marcus (OOo)wrote: Am 07/01/2011 04:56 PM, schrieb Alexandro Colorado: On Fri, Jul 1, 2011 at 9:46 AM, Marcus (OOo) wrote: Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado: On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo) wrote: Sorry, it seems I wasn't clear enough. I don't think about how to name directories and files in the SVN repo itself. Sure we can stick with the schema like it is done in other projects. It's more a general thing how to present trunk and branches to the outside. E.g., when we release bits we have to make clear into which direction they point. It's a difference if we use a name like "branch 3.4.x" or tell the people it's "OOO 3.4.0" or maybe "AOOO 3.4.0". So, I don't think that a trailing 0 is not ? when it is the 3.4.0 release. And the OOO is still necessary to show it's from our project. Of course it could be "AOOO" or whatever we will agree to. How to name the release files is another thing. There should be a clear structure to keep it simple and straight for scripts. But this is a topic for later. I hope it's more clear now. ;-) My bad also misconstruct the naming conversation. Well we used to have different branches each with a name OOODEV was for the always development branch and OOO for the actual release branches. I don't remember OOODEV as a name somewhere. So usually they got rid of the dots for clarity, and added a m for milestone: http://development.openoffice.org/releases/ and DEV: http://development.openoffice.org/releases/dev_index.html I'm sorry but I don't understand what you want to express with the both links. Please can you describe it in other words? I am pointing you to the naming of the branches and their dinamics. Isn't that what you were addressing at first? Not sure what you mean by not Yes, that's right. remembering OOODEV as a name, after you saw the link with the OOODEV branch. There is no OOODEV on the webpage. It's speaking about DEV and OOO milestones. You sure? there is the unstable codeline: http://development.openoffice.org/releases/dev_index.html#dev300 You dont get the OOO till the actual filename download. I guess it was getting long. If you go to the latest DEV300m106 http://development.openoffice.org/releases/DEV300m106_snapshot.html you'll see: This snapshot build will install as OOo-Dev 3.4. Ah, you mean the product name that is the filename, too. I wasn't away of that you meant this. As stated elsewhere in this thread choosing the right filenames can be done later. Marcus
Re: Naming of trunk and feature branches
On Fri, Jul 1, 2011 at 10:20 AM, Alexandro Colorado wrote:
>
>
> On Fri, Jul 1, 2011 at 10:13 AM, Marcus (OOo) wrote:
>
>> Am 07/01/2011 04:56 PM, schrieb Alexandro Colorado:
>>
>> On Fri, Jul 1, 2011 at 9:46 AM, Marcus (OOo)
>>> wrote:
>>>
>>> Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado:
On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo)
> wrote:
>
> Sorry, it seems I wasn't clear enough.
>
>>
>> I don't think about how to name directories and files in the SVN repo
>> itself. Sure we can stick with the schema like it is done in other
>> projects.
>> It's more a general thing how to present trunk and branches to the
>> outside.
>>
>> E.g., when we release bits we have to make clear into which direction
>> they
>> point. It's a difference if we use a name like "branch 3.4.x" or tell
>> the
>> people it's "OOO 3.4.0" or maybe "AOOO 3.4.0".
>>
>> So, I don't think that a trailing 0 is not ? when it is the 3.4.0
>> release.
>> And the OOO is still necessary to show it's from our project. Of
>> course
>> it
>> could be "AOOO" or whatever we will agree to.
>>
>> How to name the release files is another thing. There should be a
>> clear
>> structure to keep it simple and straight for scripts. But this is a
>> topic
>> for later.
>>
>> I hope it's more clear now. ;-)
>>
>> My bad also misconstruct the naming conversation. Well we used to
> have
> different branches each with a name OOODEV was for the always
> development
> branch and OOO for the actual release branches.
>
I don't remember OOODEV as a name somewhere.
So usually they got rid of the dots for clarity, and added a m for
> milestone:
> http://development.openoffice.org/releases/
> and DEV:
> http://development.openoffice.org/releases/dev_index.html
>
I'm sorry but I don't understand what you want to express with the both
links. Please can you describe it in other words?
>>>
>>> I am pointing you to the naming of the branches and their dinamics. Isn't
>>> that what you were addressing at first? Not sure what you mean by not
>>>
>>
>> Yes, that's right.
>>
>>
>> remembering OOODEV as a name, after you saw the link with the OOODEV
>>> branch.
>>>
>>
>> There is no OOODEV on the webpage. It's speaking about DEV and OOO
>> milestones.
>
>
> You sure? there is the unstable codeline:
> http://development.openoffice.org/releases/dev_index.html#dev300
> You dont get the OOO till the actual filename download. I guess it was
> getting long.
>
If you go to the latest DEV300m106
http://development.openoffice.org/releases/DEV300m106_snapshot.html
you'll see:
This snapshot build will install as OOo-Dev 3.4.
>
>
>>
>>
>> Marcus
>>
>>
>>
>> Am 06/29/2011 03:03 PM, schrieb Greg Stein:
>
>> On Wed, Jun 29, 2011 at 08:09, Marcus (OOo)
>> wrote:
>>
>>
>>> With the discussions about the master and feature branches, the
>>>
following
question comes to my mind.
What about this naming schema for master and feature branches? *)
In the past we had the following:
DEV300 = master/trunk/head
This will never lead to a release
We're using Subversion, and nearly every svn repository across the
>>> planet names this "trunk". Unless there is a specific reason to vary
>>> from that, I don't see why we'd want to name the directory "DEV300".
>>>
>>> OOO340 = branch
>>>
>>> Branched from a specific DEV300 milestone to stablize the code when
coming
closer to a specific release (here: OOo 3.4)
Branches can be named whatever we'd like. My own preference would
>>> be
>>> to call this: /branches/3.4.x
>>>
>>> The "OOO" is awfully redundant, and the last digit ("0") doesn't make
>>> sense since we would be releasing patches from the branch such as
>>> 3.4.1. The "3.4.x" naming is used by many products, and it has worked
>>> out very well.
>>>
>>
>
>
> --
> *Alexandro Colorado*
> *OpenOffice.org* Español
> http://es.openoffice.org
>
>
--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org
Re: Naming of trunk and feature branches
On Fri, Jul 1, 2011 at 10:13 AM, Marcus (OOo) wrote:
> Am 07/01/2011 04:56 PM, schrieb Alexandro Colorado:
>
> On Fri, Jul 1, 2011 at 9:46 AM, Marcus (OOo)
>> wrote:
>>
>> Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado:
>>>
>>> On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo)
>>>
wrote:
Sorry, it seems I wasn't clear enough.
>
> I don't think about how to name directories and files in the SVN repo
> itself. Sure we can stick with the schema like it is done in other
> projects.
> It's more a general thing how to present trunk and branches to the
> outside.
>
> E.g., when we release bits we have to make clear into which direction
> they
> point. It's a difference if we use a name like "branch 3.4.x" or tell
> the
> people it's "OOO 3.4.0" or maybe "AOOO 3.4.0".
>
> So, I don't think that a trailing 0 is not ? when it is the 3.4.0
> release.
> And the OOO is still necessary to show it's from our project. Of course
> it
> could be "AOOO" or whatever we will agree to.
>
> How to name the release files is another thing. There should be a clear
> structure to keep it simple and straight for scripts. But this is a
> topic
> for later.
>
> I hope it's more clear now. ;-)
>
> My bad also misconstruct the naming conversation. Well we used to have
different branches each with a name OOODEV was for the always
development
branch and OOO for the actual release branches.
>>>
>>> I don't remember OOODEV as a name somewhere.
>>>
>>> So usually they got rid of the dots for clarity, and added a m for
>>>
milestone:
http://development.openoffice.org/releases/
and DEV:
http://development.openoffice.org/releases/dev_index.html
>>>
>>> I'm sorry but I don't understand what you want to express with the both
>>> links. Please can you describe it in other words?
>>>
>>
>> I am pointing you to the naming of the branches and their dinamics. Isn't
>> that what you were addressing at first? Not sure what you mean by not
>>
>
> Yes, that's right.
>
>
> remembering OOODEV as a name, after you saw the link with the OOODEV
>> branch.
>>
>
> There is no OOODEV on the webpage. It's speaking about DEV and OOO
> milestones.
You sure? there is the unstable codeline:
http://development.openoffice.org/releases/dev_index.html#dev300
You dont get the OOO till the actual filename download. I guess it was
getting long.
>
>
> Marcus
>
>
>
> Am 06/29/2011 03:03 PM, schrieb Greg Stein:
>>>
> On Wed, Jun 29, 2011 at 08:09, Marcus (OOo)
> wrote:
>
>
>> With the discussions about the master and feature branches, the
>>
>>> following
>>> question comes to my mind.
>>>
>>> What about this naming schema for master and feature branches? *)
>>>
>>> In the past we had the following:
>>>
>>> DEV300 = master/trunk/head
>>> This will never lead to a release
>>>
>>>
>>> We're using Subversion, and nearly every svn repository across the
>> planet names this "trunk". Unless there is a specific reason to vary
>> from that, I don't see why we'd want to name the directory "DEV300".
>>
>> OOO340 = branch
>>
>> Branched from a specific DEV300 milestone to stablize the code when
>>> coming
>>> closer to a specific release (here: OOo 3.4)
>>>
>>>
>>> Branches can be named whatever we'd like. My own preference would be
>> to call this: /branches/3.4.x
>>
>> The "OOO" is awfully redundant, and the last digit ("0") doesn't make
>> sense since we would be releasing patches from the branch such as
>> 3.4.1. The "3.4.x" naming is used by many products, and it has worked
>> out very well.
>>
>
--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org
Re: Naming of trunk and feature branches
Am 07/01/2011 04:56 PM, schrieb Alexandro Colorado:
On Fri, Jul 1, 2011 at 9:46 AM, Marcus (OOo) wrote:
Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado:
On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo)
wrote:
Sorry, it seems I wasn't clear enough.
I don't think about how to name directories and files in the SVN repo
itself. Sure we can stick with the schema like it is done in other
projects.
It's more a general thing how to present trunk and branches to the
outside.
E.g., when we release bits we have to make clear into which direction
they
point. It's a difference if we use a name like "branch 3.4.x" or tell the
people it's "OOO 3.4.0" or maybe "AOOO 3.4.0".
So, I don't think that a trailing 0 is not ? when it is the 3.4.0
release.
And the OOO is still necessary to show it's from our project. Of course
it
could be "AOOO" or whatever we will agree to.
How to name the release files is another thing. There should be a clear
structure to keep it simple and straight for scripts. But this is a topic
for later.
I hope it's more clear now. ;-)
My bad also misconstruct the naming conversation. Well we used to have
different branches each with a name OOODEV was for the always development
branch and OOO for the actual release branches.
I don't remember OOODEV as a name somewhere.
So usually they got rid of the dots for clarity, and added a m for
milestone:
http://development.openoffice.org/releases/
and DEV:
http://development.openoffice.org/releases/dev_index.html
I'm sorry but I don't understand what you want to express with the both
links. Please can you describe it in other words?
I am pointing you to the naming of the branches and their dinamics. Isn't
that what you were addressing at first? Not sure what you mean by not
Yes, that's right.
remembering OOODEV as a name, after you saw the link with the OOODEV branch.
There is no OOODEV on the webpage. It's speaking about DEV and OOO
milestones.
Marcus
Am 06/29/2011 03:03 PM, schrieb Greg Stein:
On Wed, Jun 29, 2011 at 08:09, Marcus (OOo)
wrote:
With the discussions about the master and feature branches, the
following
question comes to my mind.
What about this naming schema for master and feature branches? *)
In the past we had the following:
DEV300 = master/trunk/head
This will never lead to a release
We're using Subversion, and nearly every svn repository across the
planet names this "trunk". Unless there is a specific reason to vary
from that, I don't see why we'd want to name the directory "DEV300".
OOO340 = branch
Branched from a specific DEV300 milestone to stablize the code when
coming
closer to a specific release (here: OOo 3.4)
Branches can be named whatever we'd like. My own preference would be
to call this: /branches/3.4.x
The "OOO" is awfully redundant, and the last digit ("0") doesn't make
sense since we would be releasing patches from the branch such as
3.4.1. The "3.4.x" naming is used by many products, and it has worked
out very well.
Re: ODF Toolkit Incubation Pre-Proposal
On Fri, 1 Jul 2011, Rob Weir wrote: 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, I'm happy to help with mentoring this proposal. Let me know if you need a hand with drafting the proposal. In terms of an eventual TLP goal, and POI interaction/integration, that's something we can all discuss and decide during the incubation process 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. One thing to be aware of is that your first release at Apache is always much much harder than every subsequent one! There's a lot to be said for doing a small, incremental release ASAP to get the process sorted, rather than trying to tackle the release when there's lots of exciting features blocked by (say) a missing license and a broken signature! Nick
Re: Naming of trunk and feature branches
On Fri, Jul 1, 2011 at 9:46 AM, Marcus (OOo) wrote:
> Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado:
>
> On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo)
>> wrote:
>>
>> Sorry, it seems I wasn't clear enough.
>>>
>>> I don't think about how to name directories and files in the SVN repo
>>> itself. Sure we can stick with the schema like it is done in other
>>> projects.
>>> It's more a general thing how to present trunk and branches to the
>>> outside.
>>>
>>> E.g., when we release bits we have to make clear into which direction
>>> they
>>> point. It's a difference if we use a name like "branch 3.4.x" or tell the
>>> people it's "OOO 3.4.0" or maybe "AOOO 3.4.0".
>>>
>>> So, I don't think that a trailing 0 is not ? when it is the 3.4.0
>>> release.
>>> And the OOO is still necessary to show it's from our project. Of course
>>> it
>>> could be "AOOO" or whatever we will agree to.
>>>
>>> How to name the release files is another thing. There should be a clear
>>> structure to keep it simple and straight for scripts. But this is a topic
>>> for later.
>>>
>>> I hope it's more clear now. ;-)
>>>
>>>
>> My bad also misconstruct the naming conversation. Well we used to have
>> different branches each with a name OOODEV was for the always development
>> branch and OOO for the actual release branches.
>>
>
> I don't remember OOODEV as a name somewhere.
>
>
> So usually they got rid of the dots for clarity, and added a m for
>> milestone:
>> http://development.openoffice.org/releases/
>> and DEV:
>> http://development.openoffice.org/releases/dev_index.html
>>
>
> I'm sorry but I don't understand what you want to express with the both
> links. Please can you describe it in other words?
>
I am pointing you to the naming of the branches and their dinamics. Isn't
that what you were addressing at first? Not sure what you mean by not
remembering OOODEV as a name, after you saw the link with the OOODEV branch.
>
> Thanks
>
>
> Marcus
>
>
>
> Am 06/29/2011 03:03 PM, schrieb Greg Stein:
>>>
>>> On Wed, Jun 29, 2011 at 08:09, Marcus (OOo)
>>> wrote:
>>>
With the discussions about the master and feature branches, the
> following
> question comes to my mind.
>
> What about this naming schema for master and feature branches? *)
>
> In the past we had the following:
>
> DEV300 = master/trunk/head
> This will never lead to a release
>
>
We're using Subversion, and nearly every svn repository across the
planet names this "trunk". Unless there is a specific reason to vary
from that, I don't see why we'd want to name the directory "DEV300".
OOO340 = branch
> Branched from a specific DEV300 milestone to stablize the code when
> coming
> closer to a specific release (here: OOo 3.4)
>
>
Branches can be named whatever we'd like. My own preference would be
to call this: /branches/3.4.x
The "OOO" is awfully redundant, and the last digit ("0") doesn't make
sense since we would be releasing patches from the branch such as
3.4.1. The "3.4.x" naming is used by many products, and it has worked
out very well.
>>>
--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org
Re: Naming of trunk and feature branches
Am 06/30/2011 04:03 AM, schrieb Alexandro Colorado:
On Wed, Jun 29, 2011 at 8:33 AM, Marcus (OOo) wrote:
Sorry, it seems I wasn't clear enough.
I don't think about how to name directories and files in the SVN repo
itself. Sure we can stick with the schema like it is done in other projects.
It's more a general thing how to present trunk and branches to the outside.
E.g., when we release bits we have to make clear into which direction they
point. It's a difference if we use a name like "branch 3.4.x" or tell the
people it's "OOO 3.4.0" or maybe "AOOO 3.4.0".
So, I don't think that a trailing 0 is not ? when it is the 3.4.0 release.
And the OOO is still necessary to show it's from our project. Of course it
could be "AOOO" or whatever we will agree to.
How to name the release files is another thing. There should be a clear
structure to keep it simple and straight for scripts. But this is a topic
for later.
I hope it's more clear now. ;-)
My bad also misconstruct the naming conversation. Well we used to have
different branches each with a name OOODEV was for the always development
branch and OOO for the actual release branches.
I don't remember OOODEV as a name somewhere.
So usually they got rid of the dots for clarity, and added a m for
milestone:
http://development.openoffice.org/releases/
and DEV:
http://development.openoffice.org/releases/dev_index.html
I'm sorry but I don't understand what you want to express with the both
links. Please can you describe it in other words?
Thanks
Marcus
Am 06/29/2011 03:03 PM, schrieb Greg Stein:
On Wed, Jun 29, 2011 at 08:09, Marcus (OOo) wrote:
With the discussions about the master and feature branches, the following
question comes to my mind.
What about this naming schema for master and feature branches? *)
In the past we had the following:
DEV300 = master/trunk/head
This will never lead to a release
We're using Subversion, and nearly every svn repository across the
planet names this "trunk". Unless there is a specific reason to vary
from that, I don't see why we'd want to name the directory "DEV300".
OOO340 = branch
Branched from a specific DEV300 milestone to stablize the code when
coming
closer to a specific release (here: OOo 3.4)
Branches can be named whatever we'd like. My own preference would be
to call this: /branches/3.4.x
The "OOO" is awfully redundant, and the last digit ("0") doesn't make
sense since we would be releasing patches from the branch such as
3.4.1. The "3.4.x" naming is used by many products, and it has worked
out very well.
Re: ODF Toolkit Incubation Pre-Proposal
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
Incubator PMC/Board report for July 2011 (ooo-dev@incubator.apache.org)
Dear OpenOffice.org Developers, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 20 July 2011, 10 am Pacific. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted one week before the board meeting, to allow sufficient time for review. Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is one week prior to the board meeting. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. This should be appended to the Incubator Wiki page at: http://wiki.apache.org/incubator/July2011 Note: This manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: fetch-all-cws.sh (was: Building a single Hg repository)
Hi Greg, *, On Fri, Jul 1, 2011 at 1:42 PM, Greg Stein wrote: > On Wed, Jun 29, 2011 at 05:04, Michael Stahl wrote: >>... >> in principle the size of a CWS is on the same order as the master, because >> it's just another HG repository. >> >> but HG supports hardlinks between repositories (in newer versions even on >> win32), so you can "hg clone" the master on the same filesystem and then >> pull in the CWS, and it will be _much_ faster and take _much_ less >> additional space > [...] > I've fetched a dozen, and a couple are > over 2 Gb each, and another over 1 Gb. And this is with the clone/pull > technique. Then something is obviously wrong. Or you're using the wrong tool/parameters to measure disk-usage. In any case would be helpful if you stated what cws for example would use up so much more despite being a clone only. saying that the local clone+pull uses 2GB or repository-data is hard to believe, after all the size of a repo-only clone with all cws pulled in only consumes 2.6GB (all cws=all cws that the tinderbox did built, this doesn't include cws that are not flagged as public in EIS, didn't compare how many this would be) Currently that repo has 134 heads = 133 non-integrated cws/cws with changes compared to DEV300 (as already integrated cws don't add a new head, all their changes are included in the DEV300 repo already) > I don't have enough space on my laptop to do a complete trial run. I'm > hoping that somebody can figure out how to reduce the disk footprint, Well, stating the obvious: You must not cross filesystems/disk partitions otherwise you don't get hardlinks. And you should not use an ancient version of mercurial (but that's true for every vcs) > or determine that we just have to suck it up. And it would be nice to > understand what that target size will be, for all 250 CWS > repositories. See above much less than 5GB > A possible alternative to pulling N repositories, then combining them > in a second step, is to attempt to bring them all into a single > repository, one at a time. This is a little more scary for me, not > knowing Hg, Nothing scary at all. (well, scary to git users who are afraid of having multiple heads - with git this really is a problem, but it's very different in hg). The only thing is to keep track which head belongs to what cws - using bookmarks was suggested, but if you prefer, you can just keep a flat list of hg id = head revisions of the cws along with your clone. ciao Christian
Re: Please add your name to the contributors page
Hi Joe, On Wednesday, 2011-06-29 07:02:32 -0700, Joe Schaefer wrote: > You need to commit the change after editing. Ah, that was it.. thanks. I thought hitting Submit in Edit was committing already. Just a remark: I had to undergo a chain of resolving conflicts steps because of course the line I added conflicted with changes other people added in the mean time. I'd say I managed that only because I know how SVN works, a contributor not familiar with SVN probably would be lost if that happened when presented with the resolve conflict page. > You can either click on the Commit link after editing, > or click on the Quick Commit button during your editing > session. Would be nice if there was some indication what the Quick Commit option actually does, I might had checked it ;-) Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpnWYyCWdAXL.pgp Description: PGP signature
fetch-all-cws.sh (was: Building a single Hg repository)
On Wed, Jun 29, 2011 at 05:04, Michael Stahl wrote: >... > in principle the size of a CWS is on the same order as the master, because > it's just another HG repository. > > but HG supports hardlinks between repositories (in newer versions even on > win32), so you can "hg clone" the master on the same filesystem and then > pull in the CWS, and it will be _much_ faster and take _much_ less > additional space This is the approach that I took. Please look at tools/dev/fetch-all-cws.sh. Each of these CWS repositories (on Mac OS) are consuming 600 Mb *minimum*. I've fetched a dozen, and a couple are over 2 Gb each, and another over 1 Gb. And this is with the clone/pull technique. I don't have enough space on my laptop to do a complete trial run. I'm hoping that somebody can figure out how to reduce the disk footprint, or determine that we just have to suck it up. And it would be nice to understand what that target size will be, for all 250 CWS repositories. A possible alternative to pulling N repositories, then combining them in a second step, is to attempt to bring them all into a single repository, one at a time. This is a little more scary for me, not knowing Hg, to understand how restartable and repeatable this process will be in the face of errors. Either starting from scratch, or (I believe an important feature) if it needs to be resumed after some minor failure (eg. network failure). We have a script. It is time to make it work. Michael: you say that some CWS repositories are useless. If so, then please update tools/dev/cws-list.txt to comment-out those CWS's with some explanation for future readers. No need for us to attempt to process them if they're bogus. Any thoughts, please? Cheers, -g
Re: Differences between OOO and LibreOffice.
On 30 June 2011 17:18, Dennis E. Hamilton wrote: > From this, is it more precise to say that OpenOffice.org and > LibreOffice.org provide 100% fidelity in interchange of documents with each > other when employing their common native format, ODF? > I'm happy with that, I wasn't thinking in a particular detailed way with the original post, it was really just saying hey this end user asked which product to choose. His main concerns I'm guessing would be are they similar to use (almost identical), can I exchange files the same from and between these products and others. (hopefully identically) and will any license differences affect me (probably not) And the presumption for that is the common code base which is their common > inheritance assures that, at least for now? > Yes - but I'm not a dev so I can't be 100% certain :-) Is it safe to conclude that this statement does not extend to anything about > completeness and quality of support for ODF beyond the fact that, all else > being equal, whatever the one produces and carries via the ODF format, the > other successfully consumes? And this is without qualification? > Yes again. Remember the average end user is not going to understand anything about odf, its extensibility or differences in implementation. I just think at this level too much information will only serve to confuse. If this statement were made in front of an audience of users or officials or > executives, would it be better to say that OpenOffice.org and > LibreOffice.org are compatible (in their support for and reliance on ODF)? > Is this a promise that they are and will be kept that way? > That is more difficult. I was simply thinking in terms of replying to an individual asking a question on a mailing list :-) What is it you want the take-away to be that has you use the expression "odf > files with 100% fidelity." What is meant to be reassuring about that? > I worded it badly, fell between two stools. Not technically precise enough for someone like yourself and probably unnecessary technical terms for the user I was intending it to be for. -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales.
RE: Mac dev and QA setup
> -Original Message- > From: Rolf Eder [mailto:e...@herrmannsdorfer.de] > Sent: Friday, 1 July 2011 5:39 PM > To: ooo-dev@incubator.apache.org > Subject: Mac dev and QA setup > > Hi, > > I had a conversation with Raphael Bircher about the status quo of the > German community and he reminded me that there is a urgent need for Mac > support (build env) and QA concerning the automatic test setup. > > I can offer a Mac build env at once and depending on the workload can > upgrade that with more CPU, RAM, ... Maybe Maho Nakata can advise me > with some background about the setup he did with the Macporting project? > > And if somebody can enlighten me on the current test scenario and the > action needed? Note the ASF has a few build machines, for MAC we have a Buildbot slave and a Hudson one. See http://ci.apache.org for more info. Gav... > > TIA and greetings > -- > Rolf Eder
Re: An svn question
Am 27.06.2011 10:47, schrieb Michael Stahl: On 27.06.2011 10:14, Mathias Bauer wrote: On 26.06.2011 23:15, Michael Stahl wrote: On 23.06.2011 19:15, Mathias Bauer wrote: Another option would be to commit the initial source code (the code that is directly retrieved from the software grant from Oracle) into a local Mercurial repository, add all the patches and then convert this into an svn repository. hmm... perhaps we could first merge all CWSes that are nominated/finished anyway into the HG OOO340 repo, then import the result into SVN... We can't look at this only from a technical POV. We also should try to avoid more legal work as this will slow down the integration. As I wrote, patches are easy as they are owned by those who made them, on whatever files. And as long as the base where you apply the patches to is "clean", you can't get into legal trouble. actually i don't see a difference between the two approaches (but as you know IANAL). consider that the original SGA only lists _part_ of the repository. so, in order to get anything useful that can actually build we need to ask for additional stuff anyway. if we have all the rights to the Oracle owned files in OOO340 + all outstanding CWSes, does it really make a difference if we first merge the CWSes in HG and then import the result, or whether we do it the other way around? the result should be the same, but with merging first the history will be much more useful, plus it's less work. the stuff that we need to remove from the repo can be removed either before merging the CWSes (if a CWS changes a removed file there will be a conflict on merge), or after; can't see much of a difference here. However it will be done, I want to suggest aw080 as test case. It is probably the biggest CWS with lots of changes to lots of modules. If it works with aw080, it should work with others. Also a good test for history stuff, aw080 was resynced to several DEV300 milestones already, so contains a mix of local change comments and the ones coming in from those big resyncs. For conflict removal, other mergings and to get back to a running state I would prefer to do that when we have a buildable, running version of the main trunc here. Until then it might be best that I continue with the changes on the CWS itself. Still, I want to change over to Apac he as work base ASAP. Of course - if someone describes in detail what to do to merge and get back to SVN - I'll try to do the move myself. For conflict solving I'll have to step in anyways, I guess :-) This brings me to the next point: If this CWS is wanted (for content, please refer to my Introduction) I'll need commit rights due to the sheer size of the changes and the probably unavoidable number of conflicts. I'm new here, so I've read a lot of news already, but currently not really sure how to get there... regards, michael
Re: Certification programs (was: Differences between OOO and LibreOffice)
On 30 June 2011 18:04, Shane Curcuru wrote: > Isn't this related to certification programs? Speaking of which, does > anyone have a brief explanation and some links to any existing official OOo > certification or training or similar programs? > Just to be clear on terms because "certification" can apply to two key different things. Certification of the product ie this product is 100% compliant with ISO 26300 :2006 and certification of people either as users of products or developers/technical support professionals. Certification implies that there is a set of systems and/or policies and procedures that have been applied and that the certificate is the manifest that this has occurred and the outcomes are as described by the certificate. While the concept is generic, the specifics are very different and require different expertise and knowledge. AFAIK the only "certifications" associated with OOo are the odf file format as it is effectively certified by OASIS and OSI certification (I think but not absolutely sure) because it is licensed with a recognised FOSS license. There could be others I'm not aware of. These certifications are about the product, not the people that use it or develop it. There are end-user competence based certificates that can apply to users of OOo such as ECDL/ICDL and ITQ. Degrees in computer science and similar provide generic certification of the skills and knowledge of developers administrators etc of OOo. However, competing proprietary products often have vendor certification for people that is specific to the product eg MOS (Microsoft Office Professional). I don't know of any comparable system for FOSS. Clearly the vendors of proprietary software see end-user certification as part of their marketing strategy to strengthen their ecosystems. As a revenue driver they are probably more at the margins compared to license fees and other sales for these big companies but of course what is marginal to MS, Cisco etc is likely to be very significant to a FOSS project. This is a major area for end users (and trainers, consultants, and the like) > that we need to figure out how to effectively transition to the ASF. > > As a non-profit public charity, the mission of the ASF is to produce > software for the public good, given away freely. The way that the ASF does > this is loosely known as the Apache Way, which is mostly about meritocratic > communities making consensus based decisions on project directions, leading > to high quality software that everyone can use. > > Along with our software, our projects also offer basic community-led > support and help, through our mailing lists and bugtrackers. However the > ASF does not directly offer support contracts, trainings, certification, or > other services about our products. This is because of our volunteer nature, > and the fact that we do not charge for any of the software (or services) > that we provide. > > I'm sure we can provide sufficiently documented licensing procedures for > trainers who want to provide certifications in Apache OO, although it may > take a little while to get it right, and to ensure the Apache folk here > understand what's important to the broader and pre-existing OOo community. > We have a load of CC licensed policies and procedures accredited by the UK National Regulators that can be used if they are helpful. These include things such as equality of opportunity, the disabilities act etc. I can put together a generic set of requirements that could apply to any training or outcome based qualifications system but of course I could be seen to have a conflict of interest in carrying out that work so I don't want to put the time in if its likely to be discounted on those grounds ;-) Of course anything I do at Apache is under the ICLA so anyone can modify it. -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales.
Re: Punjabi Translation
Hi A S Alam san, Thanks. On Thu, Jun 30, 2011 at 10:13 AM, A S Alam wrote: > Hi, > I would like to work for Punjabi Translation of OpenOffice Can you introduce yourselves more and your interests on OpenOffice.org? > Punjabi (Volunteers = Ammanpreet Alam) Please add this line in the following page; https://cwiki.apache.org/confluence/display/OOOUSERS/Build-Translate-Plan Thanks, khirano > > thanks > -- > A S Alam > - > Punjabi Open Source Team > http://www.satluj.com/ > -- Kazunari Hirano http://openoffice.exblog.jp/ Tohoku Japan needs your help.
Mac dev and QA setup
Hi, I had a conversation with Raphael Bircher about the status quo of the German community and he reminded me that there is a urgent need for Mac support (build env) and QA concerning the automatic test setup. I can offer a Mac build env at once and depending on the workload can upgrade that with more CPU, RAM, ... Maybe Maho Nakata can advise me with some background about the setup he did with the Macporting project? And if somebody can enlighten me on the current test scenario and the action needed? TIA and greetings -- Rolf Eder
