Re: Ip Clearance: 1st version of Svg replacement available
On 19/12/2011 Armin Le Grand wrote: as mentioned in [1] I have now finished and reintegrated the first version of the Svg replacement from the branch Very good stuff, really. I can only blame you for not turning this into a blog post! Really, all it would take is a copy and paste of the message you wrote, with a couple of screenshots and BugZilla links from Eric's nice post http://eric.bachard.org/news/index.php?post/2011/12/03/In-progress-%3A-native-support-of-the-SVG-graphic-format-in-Apache-OpenOffice.org and, if you wish to ask volunteers to test, a link to a development build with this feature enabled and some public repositories of SVG files for testing. So far there is nothing on https://blogs.apache.org/OOo/ explaining users what to expect for Apache OpenOffice 3.4. If developers don't post interesting information like this announcement there, most users will never get (directly or indirectly) information about it. Regards, Andrea.
Re: Ip Clearance: 1st version of Svg replacement available
Hi Andrea, On 26.12.2011 19:29, Andrea Pescetti wrote: On 19/12/2011 Armin Le Grand wrote: as mentioned in [1] I have now finished and reintegrated the first version of the Svg replacement from the branch Very good stuff, really. I can only blame you for not turning this into a blog post! You are right and I'm planning to do exactly that (that was the reason for the long message a little bit :-)). Let me do that next Year, I need some days off right now... Really, all it would take is a copy and paste of the message you wrote, with a couple of screenshots and BugZilla links from Eric's nice post http://eric.bachard.org/news/index.php?post/2011/12/03/In-progress-%3A-native-support-of-the-SVG-graphic-format-in-Apache-OpenOffice.org and, if you wish to ask volunteers to test, a link to a development build with this feature enabled and some public repositories of SVG files for testing. So far there is nothing on https://blogs.apache.org/OOo/ explaining users what to expect for Apache OpenOffice 3.4. If developers don't post interesting information like this announcement there, most users will never get (directly or indirectly) information about it. Absolutely right. I'll take some time next Year to blog about enhancements already done. I've already got the blog rights, to be able to do so. Regards, Andrea. Sincerely, Armin -- ALG
Re: Ip Clearance: 1st version of Svg replacement available
On 12/19/11 7:07 PM, Armin Le Grand wrote: Hi *, as mentioned in [1] I have now finished and reintegrated the first version of the Svg replacement from the branch [2] to trunk after uptating and building Mac and Win versions. It is stable and works well and is also pretty complete from an Svg point of view. Main features/differences to the version which was in OOo3.4beta are: - IP clearance: This change allowed to remove six Gpl/Lgpl libs, namely librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango gettext. These were used as an external renderer. The new Svg uses an internal interpreter in a new library and some services. - File Format: In Odf, Svg is now embedded to the Pictures folder as one would expect and can be easily extracted. There is also a Png file written there as replacement image. The draw:frame is now multi-image capable (as the spec allows). In the case of a Svg it writes a good quality Png and the original Svg as draw:image elements. Since older (and other) office versions are only capable of loading a single (and thus the first) image, the Png is written first. This allows file exchange with other and older offices. At load time, multi-image support will choose the best quality graphic available for further work, e.g. preferring vector format over pixel format, pixel format with transparency over non-transparent and loss less formats over those with losing info (you get the idea). Other Odf implementations (e.g. a viewer) may just use the pixel graphic available. Multi-image support is independent from Svg in principle and will work with all image file formats. This is implemented for the Drawinglayer graphic object (used in Draw/Impress/Calc) and the Writer graphic object (used in Writer). - Interpretation: Svg is no longer interpreted each time it needs to be rendered (as by an extrenal renderer), but only once transformed to a sequence of primitives. That sequence is then used for all outputs, transformed to the graphic object form and viewport (resolution). The sequence itself is completely view-independent. Internally, it is reused and thus it makes no difference if you have your Svg graphic added once or multiple times to your document. The same is true for the replacement Png image used. Both, the sequence of primitives and the replacement image are created using new Uno Api services. One is capable of converting an io::XInputStream to a sequence of primitives, the other is able to convert every sequence of primitives to a rendering::XBitmap with given Dpi and discrete sizes (pixels, with automatic resolution reduction to a given maximum square pixel count). This will be useful for other purposes, too, since it creates a fully alpha-capable representation of anything in primitive format to use as e.g. sprite. - Quality: For all graphic processing the created vector graphic in form of sequence of primitives is used. This means that You will get best quality in all zoom situations and all resolutions. This is also true for all exports, e.g. printing or Pdf export which also use the vector format. With an external renderer, it is unavoidable to use bitmaps with discrete solution here, not only looking bad in high resolutions, but also needing more space in most cases. There is one caveat since not all paths here already use primitives; some will use the internal MetaFile format in-between (One more reason for more reworks to primitive usages in the future). - Completeness: I implemented most Svg features from Svg1.1, but not yet using animations or interactions (but possible in the future due to an own interpreter, impossible with an extern Svg renderer). It supports all geometric Svg forms. It supports Gradients (using a new primitive for this which can be reused when we want to add Svg gradients to SdrObjects one day), these have a resolution-dependent low-level format to not waste runtime on low resolutions. It supports Masks, clipPath, Markers, linked content, embedded graphics and Svg (intern, extern, base64), Use nodes, Text, Text on curve and patterns. It does not yet support filters, color profiles, embedded scripts, interactions and linking. These can be added when needed, most of them will need to implement new basic primitives (e.g. filtering) which would be useful anyways. - Side effects: I had to fix cropping (unified with new primitive) which works now also for mirrored graphics (vecer worked) and quite some other stuff. We are prepared for Svg gradients as possible future feature (we can already render them now). You can work with an added Svg as with an graphic object; crop it, Break it (To SdrObjects, limited to the transfer over the old MetaFile format, though). You can convert an inserted Tux to 3D, You can bend the Svg in vector quality in Draw. It is possible to directly export the original Svg again by selecting the object and using 'Save as Picture...'. You can add Text, Border, fill style, pretty much the same as most other graphic objects. You can
Re: Ip Clearance: 1st version of Svg replacement available
+1 Big kudos to Armin ... I hadn't said it before so let me say this is really, REALLY cool!! Pedro. --- Lun 19/12/11, Jürgen Schmidt ha scritto: ... > On 12/19/11 7:07 PM, Armin Le Grand > wrote: > > Hi *, > > > > as mentioned in [1] I have now finished and > reintegrated the first > > version of the Svg replacement from the branch [2] to > trunk after > > uptating and building Mac and Win versions. It is > stable and works well > > and is also pretty complete from an Svg point of view. > Main > > features/differences to the version which was in > OOo3.4beta are: > > > > - IP clearance: This change allowed to remove six > Gpl/Lgpl libs, namely > > librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango > gettext. These > > were used as an external renderer. The new Svg uses an > internal > > interpreter in a new library and some services. > > > > - File Format: In Odf, Svg is now embedded to the > Pictures folder as one > > would expect and can be easily extracted. There is > also a Png file > > written there as replacement image. The draw:frame is > now multi-image > > capable (as the spec allows). In the case of a Svg it > writes a good > > quality Png and the original Svg as draw:image > elements. Since older > > (and other) office versions are only capable of > loading a single (and > > thus the first) image, the Png is written first. This > allows file > > exchange with other and older offices. At load time, > multi-image support > > will choose the best quality graphic available for > further work, e.g. > > preferring vector format over pixel format, pixel > format with > > transparency over non-transparent and loss less > formats over those with > > losing info (you get the idea). Other Odf > implementations (e.g. a > > viewer) may just use the pixel graphic available. > Multi-image support is > > independent from Svg in principle and will work with > all image file > > formats. This is implemented for the Drawinglayer > graphic object (used > > in Draw/Impress/Calc) and the Writer graphic object > (used in Writer). > > > > - Interpretation: Svg is no longer interpreted each > time it needs to be > > rendered (as by an extrenal renderer), but only once > transformed to a > > sequence of primitives. That sequence is then used for > all outputs, > > transformed to the graphic object form and viewport > (resolution). The > > sequence itself is completely view-independent. > Internally, it is reused > > and thus it makes no difference if you have your Svg > graphic added once > > or multiple times to your document. The same is true > for the replacement > > Png image used. Both, the sequence of primitives and > the replacement > > image are created using new Uno Api services. One is > capable of > > converting an io::XInputStream to a sequence of > primitives, the other is > > able to convert every sequence of primitives to a > rendering::XBitmap > > with given Dpi and discrete sizes (pixels, with > automatic resolution > > reduction to a given maximum square pixel count). This > will be useful > > for other purposes, too, since it creates a fully > alpha-capable > > representation of anything in primitive format to use > as e.g. sprite. > > > > - Quality: For all graphic processing the created > vector graphic in form > > of sequence of primitives is used. This means that You > will get best > > quality in all zoom situations and all resolutions. > This is also true > > for all exports, e.g. printing or Pdf export which > also use the vector > > format. With an external renderer, it is unavoidable > to use bitmaps with > > discrete solution here, not only looking bad in high > resolutions, but > > also needing more space in most cases. There is one > caveat since not all > > paths here already use primitives; some will use the > internal MetaFile > > format in-between (One more reason for more reworks to > primitive usages > > in the future). > > > > - Completeness: I implemented most Svg features from > Svg1.1, but not yet > > using animations or interactions (but possible in the > future due to an > > own interpreter, impossible with an extern Svg > renderer). It supports > > all geometric Svg forms. It supports Gradients (using > a new primitive > > for this which can be reused when we want to add Svg > gradients to > > SdrObjects one day), these have a resolution-dependent > low-level format > > to not waste runtime on low resolutions. It supports > Masks, clipPath, > > Markers, linked content, embedded graphics and Svg > (intern, extern, > > base64), Use nodes, Text, Text on curve and patterns. > It does not yet > > support filters, color profiles, embedded scripts, > interactions and > > linking. These can be added when needed, most of them > will need to > > implement new basic primitives (e.g. filtering) which > would be useful > > anyways. > > > > - Side effects: I had to fix cropping (unified with > new primitive) which > > works now also for mirrored graphics (vecer worked) > and quite
RE: Ip Clearance: 1st version of Svg replacement available
Amazing work! Thanks for the comprehensive account. It will be wonderful to see it show up in the nightlies. - Dennis -Original Message- From: Armin Le Grand [mailto:armin.le.gr...@me.com] Sent: Monday, December 19, 2011 10:08 To: ooo-dev@incubator.apache.org Subject: Ip Clearance: 1st version of Svg replacement available Hi *, as mentioned in [1] I have now finished and reintegrated the first version of the Svg replacement from the branch [2] to trunk after uptating and building Mac and Win versions. It is stable and works well and is also pretty complete from an Svg point of view. Main features/differences to the version which was in OOo3.4beta are: - IP clearance: This change allowed to remove six Gpl/Lgpl libs, namely librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango gettext. These were used as an external renderer. The new Svg uses an internal interpreter in a new library and some services. - File Format: [ ... ] - Interpretation: Svg is no longer interpreted each time it needs to be rendered (as by an extrenal renderer), [ ... ] - Quality: [ ... ] - Completeness: I implemented most Svg features from Svg1.1, but not yet using animations or interactions (but possible in the future due to an own interpreter, impossible with an extern Svg renderer). [ ... ] - Side effects: I had to fix cropping (unified with new primitive) which works now also for mirrored graphics (vecer worked) and quite some other stuff. [ ... ] - Caveats: This is a bigger change, but most stuff is isolated in the two mentioned services. There will be errors (I'm too long a programmer to deny that :-)), but I tried to be as careful as possible. To find them, Your help will be needed. Please feel free to play around with any Svg You can find and report problems early. [1] http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201112.mbox/%3Cjcamku$fep$1...@dough.gmane.org%3E [2] https://svn.apache.org/repos/asf/incubator/ooo/branches/alg/svgreplacement Sincerely, Armin -- ALG
Re: Ip Clearance: 1st version of Svg replacement available
On Mon, Dec 19, 2011 at 1:07 PM, Armin Le Grand wrote: > Hi *, > > as mentioned in [1] I have now finished and reintegrated the first version > of the Svg replacement from the branch [2] to trunk after uptating and > building Mac and Win versions. It is stable and works well and is also > pretty complete from an Svg point of view. Main features/differences to the > version which was in OOo3.4beta are: > Good work, Armin. I'm sure we all appreciate this early Christmas present. -Rob
Re: Ip Clearance: 1st version of Svg replacement available
Well done! Thank Armin, this is really great stuff. On Mon, Dec 19, 2011 at 1:07 PM, Armin Le Grand wrote: >Hi *, > > as mentioned in [1] I have now finished and reintegrated the first version > of the Svg replacement from the branch [2] to trunk after uptating and > building Mac and Win versions. It is stable and works well and is also > pretty complete from an Svg point of view. Main features/differences to the > version which was in OOo3.4beta are: > > - IP clearance: This change allowed to remove six Gpl/Lgpl libs, namely > librsvg, libcroco, libgsf, gdk-pixbuf, glib, and pango gettext. These were > used as an external renderer. The new Svg uses an internal interpreter in a > new library and some services. > > - File Format: In Odf, Svg is now embedded to the Pictures folder as one > would expect and can be easily extracted. There is also a Png file written > there as replacement image. The draw:frame is now multi-image capable (as > the spec allows). In the case of a Svg it writes a good quality Png and the > original Svg as draw:image elements. Since older (and other) office > versions are only capable of loading a single (and thus the first) image, > the Png is written first. This allows file exchange with other and older > offices. At load time, multi-image support will choose the best quality > graphic available for further work, e.g. preferring vector format over > pixel format, pixel format with transparency over non-transparent and loss > less formats over those with losing info (you get the idea). Other Odf > implementations (e.g. a viewer) may just use the pixel graphic available. > Multi-image support is independent from Svg in principle and will work with > all image file formats. This is implemented for the Drawinglayer graphic > object (used in Draw/Impress/Calc) and the Writer graphic object (used in > Writer). > > - Interpretation: Svg is no longer interpreted each time it needs to be > rendered (as by an extrenal renderer), but only once transformed to a > sequence of primitives. That sequence is then used for all outputs, > transformed to the graphic object form and viewport (resolution). The > sequence itself is completely view-independent. Internally, it is reused > and thus it makes no difference if you have your Svg graphic added once or > multiple times to your document. The same is true for the replacement Png > image used. Both, the sequence of primitives and the replacement image are > created using new Uno Api services. One is capable of converting an > io::XInputStream to a sequence of primitives, the other is able to convert > every sequence of primitives to a rendering::XBitmap with given Dpi and > discrete sizes (pixels, with automatic resolution reduction to a given > maximum square pixel count). This will be useful for other purposes, too, > since it creates a fully alpha-capable representation of anything in > primitive format to use as e.g. sprite. > > - Quality: For all graphic processing the created vector graphic in form > of sequence of primitives is used. This means that You will get best > quality in all zoom situations and all resolutions. This is also true for > all exports, e.g. printing or Pdf export which also use the vector format. > With an external renderer, it is unavoidable to use bitmaps with discrete > solution here, not only looking bad in high resolutions, but also needing > more space in most cases. There is one caveat since not all paths here > already use primitives; some will use the internal MetaFile format > in-between (One more reason for more reworks to primitive usages in the > future). > > - Completeness: I implemented most Svg features from Svg1.1, but not yet > using animations or interactions (but possible in the future due to an own > interpreter, impossible with an extern Svg renderer). It supports all > geometric Svg forms. It supports Gradients (using a new primitive for this > which can be reused when we want to add Svg gradients to SdrObjects one > day), these have a resolution-dependent low-level format to not waste > runtime on low resolutions. It supports Masks, clipPath, Markers, linked > content, embedded graphics and Svg (intern, extern, base64), Use nodes, > Text, Text on curve and patterns. It does not yet support filters, color > profiles, embedded scripts, interactions and linking. These can be added > when needed, most of them will need to implement new basic primitives (e.g. > filtering) which would be useful anyways. > > - Side effects: I had to fix cropping (unified with new primitive) which > works now also for mirrored graphics (vecer worked) and quite some other > stuff. We are prepared for Svg gradients as possible future feature (we can > already render them now). You can work with an added Svg as with an graphic > object; crop it, Break it (To SdrObjects, limited to the transfer over the > old MetaFile format, though). You can convert an inserted Tux to 3D, You > can bend the Svg in vector quality in
Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
I think that is a good idea with regard to a lot of feature adjustments, and especially the SVG one. It would be useful to blog or wiki both a view of how it is brought along and a view of how folks can participate in confirming the operation of features and other changes in these early technology builds. Are bug reports going to be accepted against nightlies and technology/developer builds that are now being made available to those who know where to find them? There are the builds that Ariel has made and there are the builds that Raphael makes available as well. If so, how will they be identified? One suggestion is to use the latest SVN update number applicable to the working copy when the build was made. That seems like a simple enough procedure. There are recommendations for additional details (such as a build date), but anything that gets us a non-decreasing unique identifier between builds will work. For us to handle the QA, there needs to be some kind of scheme for this. It is also important to not expect folks to keep retesting the same things when there is no change to them, so something helpful is needed for that too. - Dennis [Anecdotal experience: When I noticed an early beta of LO 3.4.0, I tried it. When I noticed betas coming out at weekly intervals I threw my hands up and stopped testing altogether. Oddly, with AOO nightlies and individual committer builds being made available, I don't mind so much, knowing that I will simply be behind and whether it is wasted or not depends on whether somebody else noticed and it was fixed already. I could apply that attitude to LO 3.5 and WLO 3.3.1 but I am already running on overwhelm with AOO and it gets my first priority.] -Original Message- From: Andrea Pescetti [mailto:pesce...@openoffice.org] Sent: Monday, December 26, 2011 10:29 To: ooo-dev@incubator.apache.org Subject: Re: Ip Clearance: 1st version of Svg replacement available On 19/12/2011 Armin Le Grand wrote: > as mentioned in [1] I have now finished and reintegrated the first > version of the Svg replacement from the branch Very good stuff, really. I can only blame you for not turning this into a blog post! Really, all it would take is a copy and paste of the message you wrote, with a couple of screenshots and BugZilla links from Eric's nice post http://eric.bachard.org/news/index.php?post/2011/12/03/In-progress-%3A-native-support-of-the-SVG-graphic-format-in-Apache-OpenOffice.org and, if you wish to ask volunteers to test, a link to a development build with this feature enabled and some public repositories of SVG files for testing. So far there is nothing on https://blogs.apache.org/OOo/ explaining users what to expect for Apache OpenOffice 3.4. If developers don't post interesting information like this announcement there, most users will never get (directly or indirectly) information about it. Regards, Andrea.
Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
On 12/26/2011 15:06, Dennis E. Hamilton wrote: I think that is a good idea with regard to a lot of feature adjustments, and especially the SVG one. It would be useful to blog or wiki both a view of how it is brought along and a view of how folks can participate in confirming the operation of features and other changes in these early technology builds. Are bug reports going to be accepted against nightlies and technology/developer builds that are now being made available to those who know where to find them? There are the builds that Ariel has made and there are the builds that Raphael makes available as well. If so, how will they be identified? One suggestion is to use the latest SVN update number applicable to the working copy when the build was made. That seems like a simple enough procedure. There are recommendations for additional details (such as a build date), but anything that gets us a non-decreasing unique identifier between builds will work. For us to handle the QA, there needs to be some kind of scheme for this. It is also important to not expect folks to keep retesting the same things when there is no change to them, so something helpful is needed for that too. - Dennis [Anecdotal experience: When I noticed an early beta of LO 3.4.0, I tried it. When I noticed betas coming out at weekly intervals I threw my hands up and stopped testing altogether. Oddly, with AOO nightlies and individual committer builds being made available, I don't mind so much, knowing that I will simply be behind and whether it is wasted or not depends on whether somebody else noticed and it was fixed already. I could apply that attitude to LO 3.5 and WLO 3.3.1 but I am already running on overwhelm with AOO and it gets my first priority.] [snip] Hi, Dennis, For a peek at how the devs are JFDI, see: https://issues.apache.org/ooo/show_bug.cgi?id=118698 -- /tj/
RE: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
So what does "version58 mean?" Where did that come from? If it is fixed in another build, how is that identified? I can make it up too. It doesn't help for collaborative understanding. I don't care what the scheme is, so long as I can find out what it is and follow it. I mainly don't want to waste mine or anyone else's time retesting and also have devs to be able to tell if something is against something already repaired later. (I am not talking about CTR/JFDI versus RTC, I am seeking something that can be consistently relied upon, that's all.) - Dennis -Original Message- From: TJ Frazier [mailto:tjfraz...@cfl.rr.com] Sent: Monday, December 26, 2011 13:11 To: ooo-dev@incubator.apache.org Subject: Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available) On 12/26/2011 15:06, Dennis E. Hamilton wrote: > I think that is a good idea with regard to a lot of feature adjustments, and > especially the SVG one. It would be useful to blog or wiki both a view of > how it is brought along and a view of how folks can participate in confirming > the operation of features and other changes in these early technology builds. > > Are bug reports going to be accepted against nightlies and > technology/developer builds that are now being made available to those who > know where to find them? There are the builds that Ariel has made and there > are the builds that Raphael makes available as well. > > If so, how will they be identified? One suggestion is to use the latest SVN > update number applicable to the working copy when the build was made. That > seems like a simple enough procedure. There are recommendations for > additional details (such as a build date), but anything that gets us a > non-decreasing unique identifier between builds will work. [ ... ] Hi, Dennis, For a peek at how the devs are JFDI, see: https://issues.apache.org/ooo/show_bug.cgi?id=118698 -- /tj/
Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
Dennis E. Hamilton wrote: So what does "version58 mean?" Where did that come from? If it is fixed in another build, how is that identified? "version58" just happens to be the last in alphabetical order, but I doubt it is correct. It is probably useful to write the SVN revision number in the comments, I just did so in https://issues.apache.org/ooo/show_bug.cgi?id=118698 (actually when people do QA on branches this won't work, but for the trunk it should be OK). Regards, Andrea.
Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
Am 12/26/2011 10:33 PM, schrieb Dennis E. Hamilton: So what does "version58 mean?" Where did that come from? This is the default value when you create new issues. Maybe an BZ admin could change this to "OOo 3.3"? If it is fixed in another build, how is that identified? And if she/he is already working on it, please create a new item like "AOO 3.4" or similar. "OOo 3.4 Beta" is out of the game and - with the new nightly and dev builds - we need now a new version entry in that list. Marcus -Original Message- From: TJ Frazier [mailto:tjfraz...@cfl.rr.com] Sent: Monday, December 26, 2011 13:11 To: ooo-dev@incubator.apache.org Subject: Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available) On 12/26/2011 15:06, Dennis E. Hamilton wrote: I think that is a good idea with regard to a lot of feature adjustments, and especially the SVG one. It would be useful to blog or wiki both a view of how it is brought along and a view of how folks can participate in confirming the operation of features and other changes in these early technology builds. Are bug reports going to be accepted against nightlies and technology/developer builds that are now being made available to those who know where to find them? There are the builds that Ariel has made and there are the builds that Raphael makes available as well. If so, how will they be identified? One suggestion is to use the latest SVN update number applicable to the working copy when the build was made. That seems like a simple enough procedure. There are recommendations for additional details (such as a build date), but anything that gets us a non-decreasing unique identifier between builds will work. [ ... ] Hi, Dennis, For a peek at how the devs are JFDI, see: https://issues.apache.org/ooo/show_bug.cgi?id=118698
Re: Early User-QA Engagement (was RE: Ip Clearance: 1st version of Svg replacement available)
On Mon, Dec 26, 2011 at 12:06:13PM -0800, Dennis E. Hamilton wrote: > I think that is a good idea with regard to a lot of feature > adjustments, and especially the SVG one. It would be useful to blog > or wiki both a view of how it is brought along and a view of how folks > can participate in confirming the operation of features and other > changes in these early technology builds. > > Are bug reports going to be accepted against nightlies and > technology/developer builds that are now being made available to those > who know where to find them? There are the builds that Ariel has made > and there are the builds that Raphael makes available as well. > > If so, how will they be identified? One suggestion is to use the > latest SVN update number applicable to the working copy when the build > was made. That seems like a simple enough procedure. There are > recommendations for additional details (such as a build date), but > anything that gets us a non-decreasing unique identifier between > builds will work. > > For us to handle the QA, there needs to be some kind of scheme for > this. It is also important to not expect folks to keep retesting the > same things when there is no change to them, so something helpful is > needed for that too. > > - Dennis > > [Anecdotal experience: When I noticed an early beta of LO 3.4.0, > I tried it. When I noticed betas coming out at weekly intervals > I threw my hands up and stopped testing altogether. Oddly, with AOO > nightlies and individual committer builds being made available, > I don't mind so much, knowing that I will simply be behind and whether > it is wasted or not depends on whether somebody else noticed and it > was fixed already. I could apply that attitude to LO 3.5 and WLO > 3.3.1 but I am already running on overwhelm with AOO and it gets my > first priority.] This discussion is pointless in the current situation where the buildboot only builds deb packages for x86-64, that by the way cannot be installed on Debian; and these build do not offer all the functionality (the don't enable category b). Regards -- Ariel Constenla-Haile La Plata, Argentina pgphGVqOcJots.pgp Description: PGP signature
