[dev] Re: Consolidating build instructions for the community
T. J. Frazier cfl.rr.com> writes: > > done. > > Okay, guys, TOC template time, or transclusion time, to get rid of all > that "redirect" trash at the top of every referenced page. Ugh, true. > The TOC has to be changed on every BG page. Is anybody else volunteering, > or shall I do something (transclusion or template, not sure which)? Please go ahead, I am not really that skilled with wiki stuff. From what I read on transclusion when you mentioned it, it seems to be the right tool for the job. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev]Re: Consolidating build instructions for the community
Bjoern Michaelsen wrote: Per Eriksson openoffice.org> writes: I agree that striping OpenOffice.org and moving to documentation is a good idea. Bjoern feel free to do it. done. Okay, guys, TOC template time, or transclusion time, to get rid of all that "redirect" trash at the top of every referenced page. The TOC has to be changed on every BG page. Is anybody else volunteering, or shall I do something (transclusion or template, not sure which)? -- /tj/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Consolidating build instructions for the community
Per Eriksson openoffice.org> writes: > I agree that striping OpenOffice.org and moving to documentation is a > good idea. Bjoern feel free to do it. done. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: Build Comments
Terrence Miller wrote: > If OOo wants to be able to reproduce builds, we will need to have a > local snapshot of any package > listed as a build requirement. > > The idea is that QA person should be be able to take a blank machine, a > Linux install CD, > and a CD containning a milestone and after doing an install and loading > the second CD do only: > > cd milestone; ./product_build > > Then she/he should be able to come back a year later and build the same > binaries. hmmm... it seems to me that what you want is what our release engineering team calls the "baseline". this is basically the standard stuff that lives in /usr/include (only those things that really are standard across all distributions and come with backward compatibility guarantees), with assorted binaries, libraries, and of course the toolchain (compiler, linker, etc.). unfortunately, the exact composition of that "baseline" for OOo is not publicly documented; only release engineering knows what's really in it. everything that is not guaranteed to be standard across all distributions is in the modules in the "external" project. but for developers, the baseline is actually not really needed; afaik it is most important for doing releases that are binary compatible (for the parts of OOo where that is important) and that work on all semi-recent linux distributions. (of course, there are also baselines for the other platforms) an unfortunate aspect of the OOo build system is that there are actually two entirely different ways to configure it: one way is via autoconf/configure, the other one with special "setsolar" tool that only works in Sun Hamburg network; i believe release engineering is currently planning to or working on using configure everywhere: that would mean less stuff to maintain and keep in sync. regards, michael -- A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Consolidating build instructions for the community (an about to be orphaned wiki page)
Hi Terrenace, Terrence Miller skrev: Doesn't: Category:Distribution-Specific_Build_Instructions need to be be referenced from Development/OpenOffice.org_Building_Guide/Building_on_Linux You are right, these should be referenced. Some contain a fairly good amount of information, so I wouldn't include this content in the build instructions. If you wish, please go ahead and make these changes. Per - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Consolidating build instructions for the community (an about to be orphaned wiki page)
Doesn't: Category:Distribution-Specific_Build_Instructions need to be be referenced from Development/OpenOffice.org_Building_Guide/Building_on_Linux (or from where that page gets moved to). It points to Ubuntu 8.10 info so can not be too ancient. Terrence - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Consolidating build instructions for the community
Hi, Eike Rathke skrev: Hi Bjoern, On Monday, 2009-07-20 12:33:48 +, Bjoern Michaelsen wrote: I would further suggest to strip the Development hierarchy and make Building_Guide the top level hierarchy, so that would be http://wiki.services.openoffice.org/wiki/Building_Guide How about putting it in the Documentation hierarchy instead, where we already have: Documentation/Administration_Guide Documentation/BASIC_Guide Documentation/DevGuide/OpenOffice.org_Developers_Guide At the end almost everything in the wiki is documentation ... but why not. I agree that striping OpenOffice.org and moving to documentation is a good idea. Bjoern feel free to do it. Per - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Consolidating build instructions for the community
Hi Bjoern, On Monday, 2009-07-20 12:33:48 +, Bjoern Michaelsen wrote: > >I would further suggest to strip the Development hierarchy and make > > Building_Guide the top level hierarchy, so that would be > > > > http://wiki.services.openoffice.org/wiki/Building_Guide > How about putting it in the Documentation hierarchy instead, > where we already have: > > Documentation/Administration_Guide > > Documentation/BASIC_Guide > > Documentation/DevGuide/OpenOffice.org_Developers_Guide At the end almost everything in the wiki is documentation ... but why not. > Im not a native speaker either, but google says you are probably wrong: > - 572000 results for "Building Guide" > - 64000 for "Build Guide" hmm.. house building, team building, muscle building, hey even igloo building ... well, be it ;) Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpKoYUji0aU2.pgp Description: PGP signature
Re: [dev] Build Comments
Christian Lohmaier wrote: > Hi Terrence, *, > > On Mon, Jul 20, 2009 at 6:45 PM, Terrence Miller > wrote: >> >> any source information needed to do a build should be in a source file and >> stored locally. > > No. That differs from system to system and thus cannot be stored in a > sensible way. > >> Examples of information that should be in a source files are: >> >> - A list of all the packages which need to be installed in order for the >> build to succeed. > > configure checks for that. If counfigure doesn't report any issues and > your build still doesn't succeed, then it is a bug in configure that > should be fixed. I agree. Unfortunately not enough attention is paid to that - on a properly configured Linux system configure should run without parameters and without errors. > >> (better yet a script which will put a system in the desired state.) > > Again, see above. > >> - the options specified to configure > > Don't know what you're up to here. options are options for the reason > of being optionally turned on/off. So what sense does it make to > hardcode options? See above. As long as we can't guarantee that on most systems configure does not need any options to build OOo, we need to document that somehow. >> Also having any source files copied into external is (in my opinion) a >> problem. For example, >> the URL for gpc.[ch] could go dead overnight with no warning. > > gpc is no longer needed (for a looong time). Are you sure? You are right that OOo can be built without gpc (with the option to disable it), but no developer could tell me if that will create a loss of functionality or not. Kai Ahrens told me that he is going to make sure in 3.2 that gpc is no longer needed. Until then it's unclear to me wether we need it or not. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [qa-dev] Proposal : "Recheck of verified issues isn't mandatory anymore"
Hi,
the proposal was approved yesterday in the Release Status Meeting.
http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes#2009-07-20
After the meeting I started the queries and closed 916 fixed/verified
issues.
-> 12 issues without a target ('-')
-> 15 issues with target 'DevTools'
-> 11 issues with target 'milestone1', 'next build' or 'not determine'
-> 2 issues with target 'OOo 2.2'
-> 1 issue with target 'OOo 2.2.1'
-> 141 issues with target 'OOo 2.3'
-> 16 issues with target 'OOo 2.3.1'
-> 217 issues with target 'OOo 2.4'
-> 10 issues with target 'OOo 2.4.x'
-> 10 issues with target 'OOo 2.x'
-> 438 issues with target 'OOo 3.0'
-> 43 issues with target 'OOo 3.0.1'
By accident I closed 83 issues wrongly. I fixed this error with the
result, that the owner of the issues get 3 additional mails. Now the
issues should be again in status 'fixed/verified'. Sorry for that.
All issues with target equal or higher than release OOo 3.1 are still
open for verification (873 issues).
-> 260 issues with target 'OOo 3.1'
-> 60 issues with target 'OOo 3.1.1' (isn't release until now)
-> 553 issues with target 'OOo 3.2' (isn't release until now)
There are still 118 'fixed/verified' issues open with other target. In
the next days I will try to identify if there are integrated in OOo or
not. Perhaps some of the following issues can/will be closed too.
-> 26 issues without any target ('-')
-> 35 issues with target 'DevTools'
-> 33 issues with target 'milestone1', 'next build' or 'not determine'
-> 21 issues with target 'OOo 3.x'
-> 3 issues with target 'OfficeLater'
After one night there is only one issues reopened.
http://qa.openoffice.org/issues/show_bug.cgi?id=87538
All other are still closed!
Now I will try to change the documentation for "how to handle fixed
and verified issues" and link to the Wiki. This will take some days.
Regards,
Thorsten
Thorsten Ziehm wrote:
Hi QA community, (cc'd dev@openoffice.org)
in nearly all past discussions (threads) in the QA list I read about the
annoying job to close all fixed/verified issues. I collect some feedback
from community members and worked with Joerg Jahnke on a proposal that a
recheck of verified issues isn't mandatory anymore.
Read the whole proposal :
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues
If there are bigger disadvantage let's discuss it in the qa mailing list
d...@qa.openoffice.org.
I set this topic/proposal on the agenda for the next release status
meetings (each Monday in IRC #oooreleases at 15:00 CET). I hope we can
decision on this proposal quickly.
Thorsten
-
To unsubscribe, e-mail: dev-unsubscr...@qa.openoffice.org
For additional commands, e-mail: dev-h...@qa.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] ODF amendments for colored sheet tabs and more border types
Hi Kirill, thanks a lot for sending the proposal. It will surely get my vote. Unfortunately, it's unlikely, that you get feedback from the ODF TC there. There's is a policy, that OASIS comment lists are exclusively for public comments, but it's not intended to be used for discussions between a technical committee and the general public. To what I understand this has a legal background, because feedback you give is under an 'Intellectual Property Rights (IPR) Policy'. http://www.oasis-open.org/who/intellectualproperty.php INAL, so please excuse me, that I'm not trying to explain it. ;-) (wanted to give an example, but found it rather clumsy than enlightening, hence deleted it again) Best regards, Peter Kirill Palagin wrote: > Hello Peter, Mathias, everybody. > > I have submitted first part of my proposal - > http://lists.oasis-open.org/archives/office-comment/200907/msg3.html > > Seeing that it did not generate a lot of feedback I would like to ask if > I used the right list. > > TIA. > WBR, > KP. > > > Peter Junge wrote: >> Hi Kirill, >> >> I will not have the time to take action on these issues myself, but I >> would like to briefly summarize how you (and of course others) can get >> heard by the OASIS ODF TC. >> >> For each standards TC, OASIS is offering a public comment list and they >> have a policy, that each comment submitted must be tracked. I am a >> member of the ODF TC for only six month now, but so far the process >> seems to work, hence I can recommend using the list. As there are some >> policies to consider, please have a look at [1] to learn about it and >> also find the information for subscribing to the mailing list there. >> >> Your comment to the ODF list can be just like the original mail, but I >> would recommend to add some information like name, contact, application >> (e.g. text, spreadsheet or presentation), category (formatting in your >> case) and a brief use case. >> >> If you or anyone else would like to invest more time, you might consider >> to submit a complete proposal. A proposal template you can find at [2], >> examples are available at [3]. >> Please refer the ODF TC wiki for more information [4]. >> >> Best regards, >> Peter >> >> [1] >> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office >> [2] http://wiki.oasis-open.org/office/ProposalTemplate >> [3] http://wiki.oasis-open.org/office/List_of_Proposals >> [4] http://wiki.oasis-open.org/office >> >> >> Kirill S. Palagin wrote: >> >>> Hello everybody. >>> >>> We have highly desired issues >>> http://www.openoffice.org/issues/show_bug.cgi?id=5560 and >>> http://www.openoffice.org/issues/show_bug.cgi?id=8275 , which require >>> amendments for ODF specification. Issue 5560 is even implemented in >>> code. >>> So could somebody, who is member of OASIS ODF committee, introduce these >>> two proposals for next version of ODF? >>> >>> TIA. >>> WBR, >>> KP. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.org > For additional commands, e-mail: dev-h...@openoffice.org > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
