[VOTE] Release Imaging 1.0 from RC7

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release Imaging 1.0 from RC7

Damjan Jovanovic-2
Please vote on releasing commons-imaging 1.0 from RC7.

Last failed vote was for RC5, RC6 had a bust POM. Many improvements
were made since:
* PMD configured better and all PMD warnings fixed, the ones remaining
now are bugs in PMD itself.
* Test coverage greatly improved in many areas, only a few packages
now have < 50% coverage, and that's due to obscure TIFF photometric
interpreters and PSD data parsers that require special images to test
which Imaging can't itself generate, a massive barely used
semi-obsolete Debug class that drags down coverage for
org.apache.commons.imaging.util, and areas of code I don't understand
and so can't easily test (ICC, PSD). While improving test coverage, I
also found and fixed 2 bugs.
* Added package-level Javadoc for image formats.
* RAT exclusions for text-based images, and made a single info.txt
with image formation for all images and added a license header to it.
* Fixed Jacoco configuration in the POM and started using it instead
of that 40+ minute Cobertura nonsense.
* Fixed website broken links.
* Also started assembling a list of why making releases is such a
pain, email coming later :).

Imaging 1.0 RC7 is available here:
https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)

Maven artifacts:
https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/

Change log(s):
https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html

Tag:
https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
(SVN revision 1544953)

Site:
http://people.apache.org/~damjan/imaging-1.0-RC7/

KEYS:
http://www.apache.org/dist/commons/KEYS

I have tested it with OpenJDK 6 on FreeBSD 9.1.

Please review and vote. This vote will close no sooner than 72 hours
from now, on Wednesday 27 November 2013 at 19:00 GMT.

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thank you!

Damjan Jovanovic

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Emmanuel Bourg-3
Hi Damjan,

I reviewed the API, here are my observations:

- Would that make sense to move the LZM implementation to commons-compress?

- What is the purpose of CachingInputStream and CachingOutputStream,
there is no Javadoc on these classes. Could they be merged into commons-io?

- Why is ZLibUtils in org.apache.commons.imaging.common instead of
org.apache.commons.imaging.util ?

- FastByteArrayOutputStream is only used by PackBits in the same
package, it could be made package private.

- BitArrayOutputStream in org.apache.commons.imaging.common is only used
by classes in org.apache.commons.imaging.common.itu_t4. It could be
moved into this package and made package private.

- There are several unused public methods in BinaryInputStream

- org.apache.commons.imaging.common.Compression is never used

- RgbBufferedImageFactory is only used in RoundtripTest, should this be
moved with the test sources?

- SimpleBufferedImageFactory is only used by ImageParser and could be
made package private.

- What about replacing org.apache.commons.imaging.common.ByteOrder with
java.nio.ByteOrder?

- Several methods in BinaryFunctions have an unused 'name' parameter.

- UnicodeUtils is only used by PngWriter and could be made package
private. Considering that any byte sequence is a valid ISO-8859-1 string
this class could also be removed.

- Why does RationalNumberUtilities extend Number? And shouldn't this
class be named RationalNumberUtils for consistency with the other *Utils
classes? I think the class could simply be merged into RationalNumber.

- There are several unused methods in ColorTools, I don't know if they
are actually useful and are just missing a unit test.

- ZigZag is only used in JpegDecoder and could be made package private

- The public permissive field in JpegImageParser is never used

- The public Attribute_Tag field in TiffField is never used

- Some public static final constants don't have an uppercased name, I
fixed them on the trunk

- The PixelParser classes in
org.apache.commons.imaging.formats.bmp.pixelparsers seems to be used
only internally by BmpImageParser. They can't be made package private
but could at least be excluded from the Javadoc.

- Same comment for org.apache.commons.imaging.formats.bmp.writers

- The Dct, JpegInputStream and YCbCrConverter classes in
org.apache.commons.imaging.formats.jpeg.decoder are only used internally
by JpegDecoder and could be made package private.

- What about moving the methods in ColorConversions into the respective
Color classes? For example, ColorConversions.convertCIELuvtoXYZ() could
become ColorCieLuv.toXYZ(). Another idea would be to use a fluent
interface to perform the conversions. Something like
ColorConverter.fromRGB(r, g, b).toHSL().


I haven't reviewed everything yet, but I have the feeling the public API
could be better polished to remove unused or internal stuff that are
probably not useful for the end users.

Emmanuel Bourg



Le 24/11/2013 17:54, Damjan Jovanovic a écrit :

> Please vote on releasing commons-imaging 1.0 from RC7.
>
> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> were made since:
> * PMD configured better and all PMD warnings fixed, the ones remaining
> now are bugs in PMD itself.
> * Test coverage greatly improved in many areas, only a few packages
> now have < 50% coverage, and that's due to obscure TIFF photometric
> interpreters and PSD data parsers that require special images to test
> which Imaging can't itself generate, a massive barely used
> semi-obsolete Debug class that drags down coverage for
> org.apache.commons.imaging.util, and areas of code I don't understand
> and so can't easily test (ICC, PSD). While improving test coverage, I
> also found and fixed 2 bugs.
> * Added package-level Javadoc for image formats.
> * RAT exclusions for text-based images, and made a single info.txt
> with image formation for all images and added a license header to it.
> * Fixed Jacoco configuration in the POM and started using it instead
> of that 40+ minute Cobertura nonsense.
> * Fixed website broken links.
> * Also started assembling a list of why making releases is such a
> pain, email coming later :).
>
> Imaging 1.0 RC7 is available here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>
> Change log(s):
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>
> Tag:
> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
> (SVN revision 1544953)
>
> Site:
> http://people.apache.org/~damjan/imaging-1.0-RC7/
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>
> Please review and vote. This vote will close no sooner than 72 hours
> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you!
>
> Damjan Jovanovic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


signature.asc (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Damjan Jovanovic-2
On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg <[hidden email]> wrote:
> Hi Damjan,

Hi Emmanuel

> I reviewed the API, here are my observations:

Thank you.

Firstly, we discussed several options before for the 1.0 release, and
agreed that the contents of trunk would be quickly pushed out as 1.0
with minimal changes (many/most users are using 1.0-SNAPSHOT), and
then the big API redesign would be 2.0. I've also been thinking of
doing a complete rewrite for 2.0 and only pulling in some of the good
bits we have now. So it's extremely discouraging to be pushed for more
and more changes, many of which will have no post-1.x value, and don't
even fit in with what was originally agreed on.

> - Would that make sense to move the LZM implementation to commons-compress?

I think you mean LZW, and let's discuss that on COMPRESS-243.

> - What is the purpose of CachingInputStream and CachingOutputStream,
> there is no Javadoc on these classes. Could they be merged into commons-io?

It looks like CachingInputStream is used by IccProfileParser, and
appears to be used to store data that has been read from the
underlying stream so it can be re-read later. You can copy it to
commons-io, but I'd prefer not having a runtime dependency on it. And
it's ByteSourceInputStream you really want in commons-io and/or
commons-compress, a gem that allows seeking over an InputStream.

> - Why is ZLibUtils in org.apache.commons.imaging.common instead of
> org.apache.commons.imaging.util ?

The whole org.apache.commons.imaging.util package is a bit dated.

> - FastByteArrayOutputStream is only used by PackBits in the same
> package, it could be made package private.

Yes.

> - BitArrayOutputStream in org.apache.commons.imaging.common is only used
> by classes in org.apache.commons.imaging.common.itu_t4. It could be
> moved into this package and made package private.

Yes.

> - There are several unused public methods in BinaryInputStream

Yes.

> - org.apache.commons.imaging.common.Compression is never used

I imagine the idea was to use it instead of using the different
compression classes directly, but whoever started writing it never
finished.

> - RgbBufferedImageFactory is only used in RoundtripTest, should this be
> moved with the test sources?

Was probably meant to be the way to create all images in the API, but
again never got finished, and is probably wrong now since some image
formats produce paletted images.

> - SimpleBufferedImageFactory is only used by ImageParser and could be
> made package private.

And bears suspiciously high resemblance to RgbBufferedImageFactory.

> - What about replacing org.apache.commons.imaging.common.ByteOrder with
> java.nio.ByteOrder?

Enum vs public static final, hmm.

> - Several methods in BinaryFunctions have an unused 'name' parameter.

Sometimes it's used to form exception text.

> - UnicodeUtils is only used by PngWriter and could be made package
> private. Considering that any byte sequence is a valid ISO-8859-1 string
> this class could also be removed.

Yes.

> - Why does RationalNumberUtilities extend Number? And shouldn't this
> class be named RationalNumberUtils for consistency with the other *Utils
> classes? I think the class could simply be merged into RationalNumber.

Merging seems best.

> - There are several unused methods in ColorTools, I don't know if they
> are actually useful and are just missing a unit test.

Not sure.

> - ZigZag is only used in JpegDecoder and could be made package private

Yes.

> - The public permissive field in JpegImageParser is never used

Yes.

> - The public Attribute_Tag field in TiffField is never used

Yes.

> - Some public static final constants don't have an uppercased name, I
> fixed them on the trunk

Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
users, so now we have to release RC7 as 1.0 :-).

> - The PixelParser classes in
> org.apache.commons.imaging.formats.bmp.pixelparsers seems to be used
> only internally by BmpImageParser. They can't be made package private
> but could at least be excluded from the Javadoc.

Hidden Javadocs don't hide packages from IDE code completion. There is
only 2 choices w.r.t. packages: keeping everything in one package to
hide internal classes by giving them package private access, and
keeping classes in different packages to better structure code but
then having to make them public as a result (and choice 3, a pipe
dream, use OSGi and don't export the packages with internal classes).
Maybe a public factory method in a public base class returning
package-private subclasses would work?

> - Same comment for org.apache.commons.imaging.formats.bmp.writers
>
> - The Dct, JpegInputStream and YCbCrConverter classes in
> org.apache.commons.imaging.formats.jpeg.decoder are only used internally
> by JpegDecoder and could be made package private.

Yes. YCbCrConverter could also be moved into ColorConversions, but I
also think there's better ways to write it than the massive lookup
tables I used.

> - What about moving the methods in ColorConversions into the respective
> Color classes? For example, ColorConversions.convertCIELuvtoXYZ() could
> become ColorCieLuv.toXYZ(). Another idea would be to use a fluent
> interface to perform the conversions. Something like
> ColorConverter.fromRGB(r, g, b).toHSL().

Maybe the former. Some of these conversions are lossy, and there is no
standard canonical color format that fromRGB() could return, so I'm
not sure you want to chain them. Also color conversions are also done
per pixel, so they're performance critical, and 2 method calls, 2
format conversions, and potentially an extra memory allocation in
fromRGB(), are going to be very slow. Already I think those methods
should be made to operate on reusable rewritable pre-allocated objects
they get passed in, not allocate and return a new object per pixel.

>
> I haven't reviewed everything yet, but I have the feeling the public API
> could be better polished to remove unused or internal stuff that are
> probably not useful for the end users.

Yes, there's plenty more. But users are begging for a 1.0 release, not
higher API standards.

Thank you again for the review - it will all get fixed or replaced at
some stage.

Finally, please remember: 1.0 releases are usually the ones that never work :-).

> Emmanuel Bourg

Damjan

> Le 24/11/2013 17:54, Damjan Jovanovic a écrit :
>> Please vote on releasing commons-imaging 1.0 from RC7.
>>
>> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
>> were made since:
>> * PMD configured better and all PMD warnings fixed, the ones remaining
>> now are bugs in PMD itself.
>> * Test coverage greatly improved in many areas, only a few packages
>> now have < 50% coverage, and that's due to obscure TIFF photometric
>> interpreters and PSD data parsers that require special images to test
>> which Imaging can't itself generate, a massive barely used
>> semi-obsolete Debug class that drags down coverage for
>> org.apache.commons.imaging.util, and areas of code I don't understand
>> and so can't easily test (ICC, PSD). While improving test coverage, I
>> also found and fixed 2 bugs.
>> * Added package-level Javadoc for image formats.
>> * RAT exclusions for text-based images, and made a single info.txt
>> with image formation for all images and added a license header to it.
>> * Fixed Jacoco configuration in the POM and started using it instead
>> of that 40+ minute Cobertura nonsense.
>> * Fixed website broken links.
>> * Also started assembling a list of why making releases is such a
>> pain, email coming later :).
>>
>> Imaging 1.0 RC7 is available here:
>> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)
>>
>> Maven artifacts:
>> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>>
>> Change log(s):
>> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
>> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
>> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>>
>> Tag:
>> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
>> (SVN revision 1544953)
>>
>> Site:
>> http://people.apache.org/~damjan/imaging-1.0-RC7/
>>
>> KEYS:
>> http://www.apache.org/dist/commons/KEYS
>>
>> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>>
>> Please review and vote. This vote will close no sooner than 72 hours
>> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thank you!
>>
>> Damjan Jovanovic
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Emmanuel Bourg-3
Hi Damjan,

Le 26/11/2013 06:31, Damjan Jovanovic a écrit :

> Firstly, we discussed several options before for the 1.0 release, and
> agreed that the contents of trunk would be quickly pushed out as 1.0
> with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> then the big API redesign would be 2.0. I've also been thinking of
> doing a complete rewrite for 2.0 and only pulling in some of the good
> bits we have now. So it's extremely discouraging to be pushed for more
> and more changes, many of which will have no post-1.x value, and don't
> even fit in with what was originally agreed on.

Sorry for the late review. I'm not opposed to the release and I won't
mind if you prefer to ignore my feedback :)


> It looks like CachingInputStream is used by IccProfileParser, and
> appears to be used to store data that has been read from the
> underlying stream so it can be re-read later. You can copy it to
> commons-io, but I'd prefer not having a runtime dependency on it. And
> it's ByteSourceInputStream you really want in commons-io and/or
> commons-compress, a gem that allows seeking over an InputStream.

I would be possible to avoid a runtime dependency by shading the classes.


> Enum vs public static final, hmm.

I don't think that makes any difference performance wise, in both cases
it leads to a comparison of references.


> Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
> users, so now we have to release RC7 as 1.0 :-).

;)


> Hidden Javadocs don't hide packages from IDE code completion. There is
> only 2 choices w.r.t. packages: keeping everything in one package to
> hide internal classes by giving them package private access, and
> keeping classes in different packages to better structure code but
> then having to make them public as a result (and choice 3, a pipe
> dream, use OSGi and don't export the packages with internal classes).
> Maybe a public factory method in a public base class returning
> package-private subclasses would work?

I know hiding the javadoc doesn't solve the issue, but that makes the
documentation cleaner and less intimidating.


Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 12:31 AM, Damjan Jovanovic <[hidden email]>wrote:

> On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg <[hidden email]> wrote:
>
> [Snip]

>
> > - The PixelParser classes in
> > org.apache.commons.imaging.formats.bmp.pixelparsers seems to be used
> > only internally by BmpImageParser. They can't be made package private
> > but could at least be excluded from the Javadoc.
>
> Hidden Javadocs don't hide packages from IDE code completion. There is
> only 2 choices w.r.t. packages: keeping everything in one package to
> hide internal classes by giving them package private access, and
> keeping classes in different packages to better structure code but
> then having to make them public as a result (and choice 3, a pipe
> dream, use OSGi and don't export the packages with internal classes).
> Maybe a public factory method in a public base class returning
> package-private subclasses would work?
>
>
>
The third choice is to have an '.internal' package à la Eclipse. The
package could also be called '.private' or '.impl'.  You can have one or
more such package of course.

You get the best of both world, cleaner organization of code and a red
flashing sign that says 'this is in an internal package, use at your own
risk.' In fact the current Javadocs comments could all be prefixed with
such a message.

Gary
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Emmanuel Bourg-3
On Tue, Nov 26, 2013 at 4:05 AM, Emmanuel Bourg <[hidden email]> wrote:

> Hi Damjan,
>
> Le 26/11/2013 06:31, Damjan Jovanovic a écrit :
>
> > Firstly, we discussed several options before for the 1.0 release, and
> > agreed that the contents of trunk would be quickly pushed out as 1.0
> > with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> > then the big API redesign would be 2.0. I've also been thinking of
> > doing a complete rewrite for 2.0 and only pulling in some of the good
> > bits we have now. So it's extremely discouraging to be pushed for more
> > and more changes, many of which will have no post-1.x value, and don't
> > even fit in with what was originally agreed on.
>
> Sorry for the late review. I'm not opposed to the release and I won't
> mind if you prefer to ignore my feedback :)
>
>
> > It looks like CachingInputStream is used by IccProfileParser, and
> > appears to be used to store data that has been read from the
> > underlying stream so it can be re-read later. You can copy it to
> > commons-io, but I'd prefer not having a runtime dependency on it. And
> > it's ByteSourceInputStream you really want in commons-io and/or
> > commons-compress, a gem that allows seeking over an InputStream.
>
> I would be possible to avoid a runtime dependency by shading the classes.
>

That's not necessary, the POM shows this is a test-only dependency.

Gary


>
>
> > Enum vs public static final, hmm.
>
> I don't think that makes any difference performance wise, in both cases
> it leads to a comparison of references.
>
>
> > Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
> > users, so now we have to release RC7 as 1.0 :-).
>
> ;)
>
>
> > Hidden Javadocs don't hide packages from IDE code completion. There is
> > only 2 choices w.r.t. packages: keeping everything in one package to
> > hide internal classes by giving them package private access, and
> > keeping classes in different packages to better structure code but
> > then having to make them public as a result (and choice 3, a pipe
> > dream, use OSGi and don't export the packages with internal classes).
> > Maybe a public factory method in a public base class returning
> > package-private subclasses would work?
>
> I know hiding the javadoc doesn't solve the issue, but that makes the
> documentation cleaner and less intimidating.
>
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 3:47 PM, Gary Gregory <[hidden email]> wrote:

> On Tue, Nov 26, 2013 at 4:05 AM, Emmanuel Bourg <[hidden email]> wrote:
>
>> Hi Damjan,
>>
>> Le 26/11/2013 06:31, Damjan Jovanovic a écrit :
>>
>> > Firstly, we discussed several options before for the 1.0 release, and
>> > agreed that the contents of trunk would be quickly pushed out as 1.0
>> > with minimal changes (many/most users are using 1.0-SNAPSHOT), and
>> > then the big API redesign would be 2.0. I've also been thinking of
>> > doing a complete rewrite for 2.0 and only pulling in some of the good
>> > bits we have now. So it's extremely discouraging to be pushed for more
>> > and more changes, many of which will have no post-1.x value, and don't
>> > even fit in with what was originally agreed on.
>>
>> Sorry for the late review. I'm not opposed to the release and I won't
>> mind if you prefer to ignore my feedback :)
>>
>>
>> > It looks like CachingInputStream is used by IccProfileParser, and
>> > appears to be used to store data that has been read from the
>> > underlying stream so it can be re-read later. You can copy it to
>> > commons-io, but I'd prefer not having a runtime dependency on it. And
>> > it's ByteSourceInputStream you really want in commons-io and/or
>> > commons-compress, a gem that allows seeking over an InputStream.
>>
>> I would be possible to avoid a runtime dependency by shading the classes.
>>
>
> That's not necessary, the POM shows this is a test-only dependency.

But it will be necessary if CachingInputStream is moved into
commons-io instead of copied.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Damjan Jovanovic-2
In the site's "Latest Sanselan Release" section, this link is broken:
https://people.apache.org/~damjan/imaging-1.0-RC7/release-history.html
It should be https://people.apache.org/~damjan/imaging-1.0-RC7/history.html

Gary


On Sun, Nov 24, 2013 at 11:54 AM, Damjan Jovanovic <[hidden email]>wrote:

> Please vote on releasing commons-imaging 1.0 from RC7.
>
> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> were made since:
> * PMD configured better and all PMD warnings fixed, the ones remaining
> now are bugs in PMD itself.
> * Test coverage greatly improved in many areas, only a few packages
> now have < 50% coverage, and that's due to obscure TIFF photometric
> interpreters and PSD data parsers that require special images to test
> which Imaging can't itself generate, a massive barely used
> semi-obsolete Debug class that drags down coverage for
> org.apache.commons.imaging.util, and areas of code I don't understand
> and so can't easily test (ICC, PSD). While improving test coverage, I
> also found and fixed 2 bugs.
> * Added package-level Javadoc for image formats.
> * RAT exclusions for text-based images, and made a single info.txt
> with image formation for all images and added a license header to it.
> * Fixed Jacoco configuration in the POM and started using it instead
> of that 40+ minute Cobertura nonsense.
> * Fixed website broken links.
> * Also started assembling a list of why making releases is such a
> pain, email coming later :).
>
> Imaging 1.0 RC7 is available here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision
> 3671)
>
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>
> Change log(s):
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
> (SVN revision 1544953)
>
> Site:
> http://people.apache.org/~damjan/imaging-1.0-RC7/
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>
> Please review and vote. This vote will close no sooner than 72 hours
> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you!
>
> Damjan Jovanovic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 12:31 AM, Damjan Jovanovic <[hidden email]>wrote:

> On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg <[hidden email]> wrote:
> > Hi Damjan,
>
> Hi Emmanuel
>
> > I reviewed the API, here are my observations:
>
> Thank you.
>
> Firstly, we discussed several options before for the 1.0 release, and
> agreed that the contents of trunk would be quickly pushed out as 1.0
> with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> then the big API redesign would be 2.0. I've also been thinking of
> doing a complete rewrite for 2.0 and only pulling in some of the good
> bits we have now. So it's extremely discouraging to be pushed for more
> and more changes, many of which will have no post-1.x value, and don't
> even fit in with what was originally agreed on.
>


The 1.0 release has not happened yet, quickly or otherwise ;) and that's
OK. I am grateful that Emmanuel was willing and able put the time in and
effort for a his review.

Damjan, you done a great job of patiently going through RCs, it's a slow
grind but we are getting there.

I know that we agreed on a road map for 1.0 and tentatively for 2.0 (where
is that thread...? ;), but we all have different schedules and priorities,
and no hard schedule for [imaging], so I see Emmanuel input and commits as
welcomed improvements.

The [VOTE] is still open of course, but Emmanuel's recent work seem worthy
of inclusion in 1.0. If we have volunteers willing to put in time to polish
this release, that much the better IMO. Even if 1.0 might be supplanted by
a 2.0, and who knows when that will be (look how long it tool [pool2] to
come out, years it seems), we might as well present the best 1.0 we can.

A short-term plan for 1.0 could be to keep the momentum Emmanuel and Damjan
have _right now_, resolve the issues in this thread, cut another RC and
then I'd bet we'd get a 1.0 ASAP.

Gary


>
> > - Would that make sense to move the LZM implementation to
> commons-compress?
>
> I think you mean LZW, and let's discuss that on COMPRESS-243.
>
> > - What is the purpose of CachingInputStream and CachingOutputStream,
> > there is no Javadoc on these classes. Could they be merged into
> commons-io?
>
> It looks like CachingInputStream is used by IccProfileParser, and
> appears to be used to store data that has been read from the
> underlying stream so it can be re-read later. You can copy it to
> commons-io, but I'd prefer not having a runtime dependency on it. And
> it's ByteSourceInputStream you really want in commons-io and/or
> commons-compress, a gem that allows seeking over an InputStream.
>
> > - Why is ZLibUtils in org.apache.commons.imaging.common instead of
> > org.apache.commons.imaging.util ?
>
> The whole org.apache.commons.imaging.util package is a bit dated.
>
> > - FastByteArrayOutputStream is only used by PackBits in the same
> > package, it could be made package private.
>
> Yes.
>
> > - BitArrayOutputStream in org.apache.commons.imaging.common is only used
> > by classes in org.apache.commons.imaging.common.itu_t4. It could be
> > moved into this package and made package private.
>
> Yes.
>
> > - There are several unused public methods in BinaryInputStream
>
> Yes.
>
> > - org.apache.commons.imaging.common.Compression is never used
>
> I imagine the idea was to use it instead of using the different
> compression classes directly, but whoever started writing it never
> finished.
>
> > - RgbBufferedImageFactory is only used in RoundtripTest, should this be
> > moved with the test sources?
>
> Was probably meant to be the way to create all images in the API, but
> again never got finished, and is probably wrong now since some image
> formats produce paletted images.
>
> > - SimpleBufferedImageFactory is only used by ImageParser and could be
> > made package private.
>
> And bears suspiciously high resemblance to RgbBufferedImageFactory.
>
> > - What about replacing org.apache.commons.imaging.common.ByteOrder with
> > java.nio.ByteOrder?
>
> Enum vs public static final, hmm.
>
> > - Several methods in BinaryFunctions have an unused 'name' parameter.
>
> Sometimes it's used to form exception text.
>
> > - UnicodeUtils is only used by PngWriter and could be made package
> > private. Considering that any byte sequence is a valid ISO-8859-1 string
> > this class could also be removed.
>
> Yes.
>
> > - Why does RationalNumberUtilities extend Number? And shouldn't this
> > class be named RationalNumberUtils for consistency with the other *Utils
> > classes? I think the class could simply be merged into RationalNumber.
>
> Merging seems best.
>
> > - There are several unused methods in ColorTools, I don't know if they
> > are actually useful and are just missing a unit test.
>
> Not sure.
>
> > - ZigZag is only used in JpegDecoder and could be made package private
>
> Yes.
>
> > - The public permissive field in JpegImageParser is never used
>
> Yes.
>
> > - The public Attribute_Tag field in TiffField is never used
>
> Yes.
>
> > - Some public static final constants don't have an uppercased name, I
> > fixed them on the trunk
>
> Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
> users, so now we have to release RC7 as 1.0 :-).
>
> > - The PixelParser classes in
> > org.apache.commons.imaging.formats.bmp.pixelparsers seems to be used
> > only internally by BmpImageParser. They can't be made package private
> > but could at least be excluded from the Javadoc.
>
> Hidden Javadocs don't hide packages from IDE code completion. There is
> only 2 choices w.r.t. packages: keeping everything in one package to
> hide internal classes by giving them package private access, and
> keeping classes in different packages to better structure code but
> then having to make them public as a result (and choice 3, a pipe
> dream, use OSGi and don't export the packages with internal classes).
> Maybe a public factory method in a public base class returning
> package-private subclasses would work?
>
> > - Same comment for org.apache.commons.imaging.formats.bmp.writers
> >
> > - The Dct, JpegInputStream and YCbCrConverter classes in
> > org.apache.commons.imaging.formats.jpeg.decoder are only used internally
> > by JpegDecoder and could be made package private.
>
> Yes. YCbCrConverter could also be moved into ColorConversions, but I
> also think there's better ways to write it than the massive lookup
> tables I used.
>
> > - What about moving the methods in ColorConversions into the respective
> > Color classes? For example, ColorConversions.convertCIELuvtoXYZ() could
> > become ColorCieLuv.toXYZ(). Another idea would be to use a fluent
> > interface to perform the conversions. Something like
> > ColorConverter.fromRGB(r, g, b).toHSL().
>
> Maybe the former. Some of these conversions are lossy, and there is no
> standard canonical color format that fromRGB() could return, so I'm
> not sure you want to chain them. Also color conversions are also done
> per pixel, so they're performance critical, and 2 method calls, 2
> format conversions, and potentially an extra memory allocation in
> fromRGB(), are going to be very slow. Already I think those methods
> should be made to operate on reusable rewritable pre-allocated objects
> they get passed in, not allocate and return a new object per pixel.
>
> >
> > I haven't reviewed everything yet, but I have the feeling the public API
> > could be better polished to remove unused or internal stuff that are
> > probably not useful for the end users.
>
> Yes, there's plenty more. But users are begging for a 1.0 release, not
> higher API standards.
>
> Thank you again for the review - it will all get fixed or replaced at
> some stage.
>
> Finally, please remember: 1.0 releases are usually the ones that never
> work :-).
>
> > Emmanuel Bourg
>
> Damjan
>
> > Le 24/11/2013 17:54, Damjan Jovanovic a écrit :
> >> Please vote on releasing commons-imaging 1.0 from RC7.
> >>
> >> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> >> were made since:
> >> * PMD configured better and all PMD warnings fixed, the ones remaining
> >> now are bugs in PMD itself.
> >> * Test coverage greatly improved in many areas, only a few packages
> >> now have < 50% coverage, and that's due to obscure TIFF photometric
> >> interpreters and PSD data parsers that require special images to test
> >> which Imaging can't itself generate, a massive barely used
> >> semi-obsolete Debug class that drags down coverage for
> >> org.apache.commons.imaging.util, and areas of code I don't understand
> >> and so can't easily test (ICC, PSD). While improving test coverage, I
> >> also found and fixed 2 bugs.
> >> * Added package-level Javadoc for image formats.
> >> * RAT exclusions for text-based images, and made a single info.txt
> >> with image formation for all images and added a license header to it.
> >> * Fixed Jacoco configuration in the POM and started using it instead
> >> of that 40+ minute Cobertura nonsense.
> >> * Fixed website broken links.
> >> * Also started assembling a list of why making releases is such a
> >> pain, email coming later :).
> >>
> >> Imaging 1.0 RC7 is available here:
> >> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision
> 3671)
> >>
> >> Maven artifacts:
> >>
> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
> >>
> >> Change log(s):
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
> >>
> >> Tag:
> >>
> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
> >> (SVN revision 1544953)
> >>
> >> Site:
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/
> >>
> >> KEYS:
> >> http://www.apache.org/dist/commons/KEYS
> >>
> >> I have tested it with OpenJDK 6 on FreeBSD 9.1.
> >>
> >> Please review and vote. This vote will close no sooner than 72 hours
> >> from now, on Wednesday 27 November 2013 at 19:00 GMT.
> >>
> >> [ ] +1 Release these artifacts
> >> [ ] +0 OK, but...
> >> [ ] -0 OK, but really should fix...
> >> [ ] -1 I oppose this release because...
> >>
> >> Thank you!
> >>
> >> Damjan Jovanovic
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 8:50 AM, Damjan Jovanovic <[hidden email]> wrote:

> On Tue, Nov 26, 2013 at 3:47 PM, Gary Gregory <[hidden email]>
> wrote:
> > On Tue, Nov 26, 2013 at 4:05 AM, Emmanuel Bourg <[hidden email]>
> wrote:
> >
> >> Hi Damjan,
> >>
> >> Le 26/11/2013 06:31, Damjan Jovanovic a écrit :
> >>
> >> > Firstly, we discussed several options before for the 1.0 release, and
> >> > agreed that the contents of trunk would be quickly pushed out as 1.0
> >> > with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> >> > then the big API redesign would be 2.0. I've also been thinking of
> >> > doing a complete rewrite for 2.0 and only pulling in some of the good
> >> > bits we have now. So it's extremely discouraging to be pushed for more
> >> > and more changes, many of which will have no post-1.x value, and don't
> >> > even fit in with what was originally agreed on.
> >>
> >> Sorry for the late review. I'm not opposed to the release and I won't
> >> mind if you prefer to ignore my feedback :)
> >>
> >>
> >> > It looks like CachingInputStream is used by IccProfileParser, and
> >> > appears to be used to store data that has been read from the
> >> > underlying stream so it can be re-read later. You can copy it to
> >> > commons-io, but I'd prefer not having a runtime dependency on it. And
> >> > it's ByteSourceInputStream you really want in commons-io and/or
> >> > commons-compress, a gem that allows seeking over an InputStream.
> >>
> >> I would be possible to avoid a runtime dependency by shading the
> classes.
> >>
> >
> > That's not necessary, the POM shows this is a test-only dependency.
>
> But it will be necessary if CachingInputStream is moved into
> commons-io instead of copied.
>

Personally, I prefer dependencies to code duplications.

Most of the projects I work on (Work) are large and end bringing in a bunch
of Apache Commons jars and others. Since images are stored in files or
streams, [imaging] and [io] seem like a natural pair. That's just me though.

Gary



>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

garydgregory
In reply to this post by Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 12:31 AM, Damjan Jovanovic <[hidden email]>wrote:

> On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg <[hidden email]> wrote:
> > Hi Damjan,
>
> Hi Emmanuel
>
> > I reviewed the API, here are my observations:
>
> Thank you.
>
> Firstly, we discussed several options before for the 1.0 release, and
> agreed that the contents of trunk would be quickly pushed out as 1.0
> with minimal changes (many/most users are using 1.0-SNAPSHOT), and
> then the big API redesign would be 2.0. I've also been thinking of
> doing a complete rewrite for 2.0 and only pulling in some of the good
> bits we have now. So it's extremely discouraging to be pushed for more
> and more changes, many of which will have no post-1.x value, and don't
> even fit in with what was originally agreed on.
>
> > - Would that make sense to move the LZM implementation to
> commons-compress?
>
> I think you mean LZW, and let's discuss that on COMPRESS-243.
>
> > - What is the purpose of CachingInputStream and CachingOutputStream,
> > there is no Javadoc on these classes. Could they be merged into
> commons-io?
>
> It looks like CachingInputStream is used by IccProfileParser, and
> appears to be used to store data that has been read from the
> underlying stream so it can be re-read later. You can copy it to
> commons-io, but I'd prefer not having a runtime dependency on it. And
> it's ByteSourceInputStream you really want in commons-io and/or
> commons-compress, a gem that allows seeking over an InputStream.
>
> > - Why is ZLibUtils in org.apache.commons.imaging.common instead of
> > org.apache.commons.imaging.util ?
>
> The whole org.apache.commons.imaging.util package is a bit dated.
>
> > - FastByteArrayOutputStream is only used by PackBits in the same
> > package, it could be made package private.
>
> Yes.
>
> > - BitArrayOutputStream in org.apache.commons.imaging.common is only used
> > by classes in org.apache.commons.imaging.common.itu_t4. It could be
> > moved into this package and made package private.
>
> Yes.
>
> > - There are several unused public methods in BinaryInputStream
>
> Yes.
>
> > - org.apache.commons.imaging.common.Compression is never used
>
> I imagine the idea was to use it instead of using the different
> compression classes directly, but whoever started writing it never
> finished.
>
> > - RgbBufferedImageFactory is only used in RoundtripTest, should this be
> > moved with the test sources?
>
> Was probably meant to be the way to create all images in the API, but
> again never got finished, and is probably wrong now since some image
> formats produce paletted images.
>
> > - SimpleBufferedImageFactory is only used by ImageParser and could be
> > made package private.
>
> And bears suspiciously high resemblance to RgbBufferedImageFactory.
>
> > - What about replacing org.apache.commons.imaging.common.ByteOrder with
> > java.nio.ByteOrder?
>
> Enum vs public static final, hmm.
>

I think the point is that ByteOrder is a JRE provided class, we should not
reinvent the wheel, unless we need to support middle-endian. Does Java run
on PDP-11? ;)

Gary


> > - Several methods in BinaryFunctions have an unused 'name' parameter.
>
> Sometimes it's used to form exception text.
>
> > - UnicodeUtils is only used by PngWriter and could be made package
> > private. Considering that any byte sequence is a valid ISO-8859-1 string
> > this class could also be removed.
>
> Yes.
>
> > - Why does RationalNumberUtilities extend Number? And shouldn't this
> > class be named RationalNumberUtils for consistency with the other *Utils
> > classes? I think the class could simply be merged into RationalNumber.
>
> Merging seems best.
>
> > - There are several unused methods in ColorTools, I don't know if they
> > are actually useful and are just missing a unit test.
>
> Not sure.
>
> > - ZigZag is only used in JpegDecoder and could be made package private
>
> Yes.
>
> > - The public permissive field in JpegImageParser is never used
>
> Yes.
>
> > - The public Attribute_Tag field in TiffField is never used
>
> Yes.
>
> > - Some public static final constants don't have an uppercased name, I
> > fixed them on the trunk
>
> Thank you, but that probably broke compatibility for 1.0-SNAPSHOT
> users, so now we have to release RC7 as 1.0 :-).
>
> > - The PixelParser classes in
> > org.apache.commons.imaging.formats.bmp.pixelparsers seems to be used
> > only internally by BmpImageParser. They can't be made package private
> > but could at least be excluded from the Javadoc.
>
> Hidden Javadocs don't hide packages from IDE code completion. There is
> only 2 choices w.r.t. packages: keeping everything in one package to
> hide internal classes by giving them package private access, and
> keeping classes in different packages to better structure code but
> then having to make them public as a result (and choice 3, a pipe
> dream, use OSGi and don't export the packages with internal classes).
> Maybe a public factory method in a public base class returning
> package-private subclasses would work?
>
> > - Same comment for org.apache.commons.imaging.formats.bmp.writers
> >
> > - The Dct, JpegInputStream and YCbCrConverter classes in
> > org.apache.commons.imaging.formats.jpeg.decoder are only used internally
> > by JpegDecoder and could be made package private.
>
> Yes. YCbCrConverter could also be moved into ColorConversions, but I
> also think there's better ways to write it than the massive lookup
> tables I used.
>
> > - What about moving the methods in ColorConversions into the respective
> > Color classes? For example, ColorConversions.convertCIELuvtoXYZ() could
> > become ColorCieLuv.toXYZ(). Another idea would be to use a fluent
> > interface to perform the conversions. Something like
> > ColorConverter.fromRGB(r, g, b).toHSL().
>
> Maybe the former. Some of these conversions are lossy, and there is no
> standard canonical color format that fromRGB() could return, so I'm
> not sure you want to chain them. Also color conversions are also done
> per pixel, so they're performance critical, and 2 method calls, 2
> format conversions, and potentially an extra memory allocation in
> fromRGB(), are going to be very slow. Already I think those methods
> should be made to operate on reusable rewritable pre-allocated objects
> they get passed in, not allocate and return a new object per pixel.
>
> >
> > I haven't reviewed everything yet, but I have the feeling the public API
> > could be better polished to remove unused or internal stuff that are
> > probably not useful for the end users.
>
> Yes, there's plenty more. But users are begging for a 1.0 release, not
> higher API standards.
>
> Thank you again for the review - it will all get fixed or replaced at
> some stage.
>
> Finally, please remember: 1.0 releases are usually the ones that never
> work :-).
>
> > Emmanuel Bourg
>
> Damjan
>
> > Le 24/11/2013 17:54, Damjan Jovanovic a écrit :
> >> Please vote on releasing commons-imaging 1.0 from RC7.
> >>
> >> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> >> were made since:
> >> * PMD configured better and all PMD warnings fixed, the ones remaining
> >> now are bugs in PMD itself.
> >> * Test coverage greatly improved in many areas, only a few packages
> >> now have < 50% coverage, and that's due to obscure TIFF photometric
> >> interpreters and PSD data parsers that require special images to test
> >> which Imaging can't itself generate, a massive barely used
> >> semi-obsolete Debug class that drags down coverage for
> >> org.apache.commons.imaging.util, and areas of code I don't understand
> >> and so can't easily test (ICC, PSD). While improving test coverage, I
> >> also found and fixed 2 bugs.
> >> * Added package-level Javadoc for image formats.
> >> * RAT exclusions for text-based images, and made a single info.txt
> >> with image formation for all images and added a license header to it.
> >> * Fixed Jacoco configuration in the POM and started using it instead
> >> of that 40+ minute Cobertura nonsense.
> >> * Fixed website broken links.
> >> * Also started assembling a list of why making releases is such a
> >> pain, email coming later :).
> >>
> >> Imaging 1.0 RC7 is available here:
> >> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision
> 3671)
> >>
> >> Maven artifacts:
> >>
> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
> >>
> >> Change log(s):
> >>
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
> >>
> >> Tag:
> >>
> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
> >> (SVN revision 1544953)
> >>
> >> Site:
> >> http://people.apache.org/~damjan/imaging-1.0-RC7/
> >>
> >> KEYS:
> >> http://www.apache.org/dist/commons/KEYS
> >>
> >> I have tested it with OpenJDK 6 on FreeBSD 9.1.
> >>
> >> Please review and vote. This vote will close no sooner than 72 hours
> >> from now, on Wednesday 27 November 2013 at 19:00 GMT.
> >>
> >> [ ] +1 Release these artifacts
> >> [ ] +0 OK, but...
> >> [ ] -0 OK, but really should fix...
> >> [ ] -1 I oppose this release because...
> >>
> >> Thank you!
> >>
> >> Damjan Jovanovic
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Damjan Jovanovic-2
On Tue, Nov 26, 2013 at 4:32 PM, Gary Gregory <[hidden email]> wrote:

> On Tue, Nov 26, 2013 at 12:31 AM, Damjan Jovanovic <[hidden email]>wrote:
>
>> On Mon, Nov 25, 2013 at 1:50 PM, Emmanuel Bourg <[hidden email]> wrote:
>> > Hi Damjan,
>>
>> Hi Emmanuel
>>
>> > I reviewed the API, here are my observations:
>>
>> Thank you.
>>
>> Firstly, we discussed several options before for the 1.0 release, and
>> agreed that the contents of trunk would be quickly pushed out as 1.0
>> with minimal changes (many/most users are using 1.0-SNAPSHOT), and
>> then the big API redesign would be 2.0. I've also been thinking of
>> doing a complete rewrite for 2.0 and only pulling in some of the good
>> bits we have now. So it's extremely discouraging to be pushed for more
>> and more changes, many of which will have no post-1.x value, and don't
>> even fit in with what was originally agreed on.
>>
>> > - Would that make sense to move the LZM implementation to
>> commons-compress?
>>
>> I think you mean LZW, and let's discuss that on COMPRESS-243.
>>
>> > - What is the purpose of CachingInputStream and CachingOutputStream,
>> > there is no Javadoc on these classes. Could they be merged into
>> commons-io?
>>
>> It looks like CachingInputStream is used by IccProfileParser, and
>> appears to be used to store data that has been read from the
>> underlying stream so it can be re-read later. You can copy it to
>> commons-io, but I'd prefer not having a runtime dependency on it. And
>> it's ByteSourceInputStream you really want in commons-io and/or
>> commons-compress, a gem that allows seeking over an InputStream.
>>
>> > - Why is ZLibUtils in org.apache.commons.imaging.common instead of
>> > org.apache.commons.imaging.util ?
>>
>> The whole org.apache.commons.imaging.util package is a bit dated.
>>
>> > - FastByteArrayOutputStream is only used by PackBits in the same
>> > package, it could be made package private.
>>
>> Yes.
>>
>> > - BitArrayOutputStream in org.apache.commons.imaging.common is only used
>> > by classes in org.apache.commons.imaging.common.itu_t4. It could be
>> > moved into this package and made package private.
>>
>> Yes.
>>
>> > - There are several unused public methods in BinaryInputStream
>>
>> Yes.
>>
>> > - org.apache.commons.imaging.common.Compression is never used
>>
>> I imagine the idea was to use it instead of using the different
>> compression classes directly, but whoever started writing it never
>> finished.
>>
>> > - RgbBufferedImageFactory is only used in RoundtripTest, should this be
>> > moved with the test sources?
>>
>> Was probably meant to be the way to create all images in the API, but
>> again never got finished, and is probably wrong now since some image
>> formats produce paletted images.
>>
>> > - SimpleBufferedImageFactory is only used by ImageParser and could be
>> > made package private.
>>
>> And bears suspiciously high resemblance to RgbBufferedImageFactory.
>>
>> > - What about replacing org.apache.commons.imaging.common.ByteOrder with
>> > java.nio.ByteOrder?
>>
>> Enum vs public static final, hmm.
>>
>
> I think the point is that ByteOrder is a JRE provided class, we should not
> reinvent the wheel, unless we need to support middle-endian. Does Java run
> on PDP-11? ;)

You laugh, but the leDOS JVM runs on MS-DOS, and JAmiga on Amigas, so
it might be possible :).

Also by the same analogy, org.omg.CORBA had IntHolder since Java SE
1.2, yet we still have MutableInt in commons-lang. But either way,
Imaging's ByteOrder has already been replaced with java.nio's.

Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Jörg Schaible
In reply to this post by Damjan Jovanovic-2
Hi Damjan,

it seems that we have already some changes and get a new RC, but I've tested
the source tarball with my complete compiler zoo (incl. Java 8) without any
problems. At least that looks great ;-)

Cheers,
Jörg


Damjan Jovanovic wrote:

> Please vote on releasing commons-imaging 1.0 from RC7.
>
> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> were made since:
> * PMD configured better and all PMD warnings fixed, the ones remaining
> now are bugs in PMD itself.
> * Test coverage greatly improved in many areas, only a few packages
> now have < 50% coverage, and that's due to obscure TIFF photometric
> interpreters and PSD data parsers that require special images to test
> which Imaging can't itself generate, a massive barely used
> semi-obsolete Debug class that drags down coverage for
> org.apache.commons.imaging.util, and areas of code I don't understand
> and so can't easily test (ICC, PSD). While improving test coverage, I
> also found and fixed 2 bugs.
> * Added package-level Javadoc for image formats.
> * RAT exclusions for text-based images, and made a single info.txt
> with image formation for all images and added a license header to it.
> * Fixed Jacoco configuration in the POM and started using it instead
> of that 40+ minute Cobertura nonsense.
> * Fixed website broken links.
> * Also started assembling a list of why making releases is such a
> pain, email coming later :).
>
> Imaging 1.0 RC7 is available here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision
> 3671)
>
> Maven artifacts:
>
https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>
> Change log(s):
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>
> Tag:
>
https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7

> (SVN revision 1544953)
>
> Site:
> http://people.apache.org/~damjan/imaging-1.0-RC7/
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>
> Please review and vote. This vote will close no sooner than 72 hours
> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you!
>
> Damjan Jovanovic



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Damjan Jovanovic-2
In reply to this post by Damjan Jovanovic-2
Vote closed, results were:

+1:
Damjan Jovanovic

No other votes were cast.

Vote fails since majority approval needs at least 3 votes of +1 ->
aborting release.

Damjan

On Sun, Nov 24, 2013 at 6:54 PM, Damjan Jovanovic <[hidden email]> wrote:

> Please vote on releasing commons-imaging 1.0 from RC7.
>
> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
> were made since:
> * PMD configured better and all PMD warnings fixed, the ones remaining
> now are bugs in PMD itself.
> * Test coverage greatly improved in many areas, only a few packages
> now have < 50% coverage, and that's due to obscure TIFF photometric
> interpreters and PSD data parsers that require special images to test
> which Imaging can't itself generate, a massive barely used
> semi-obsolete Debug class that drags down coverage for
> org.apache.commons.imaging.util, and areas of code I don't understand
> and so can't easily test (ICC, PSD). While improving test coverage, I
> also found and fixed 2 bugs.
> * Added package-level Javadoc for image formats.
> * RAT exclusions for text-based images, and made a single info.txt
> with image formation for all images and added a license header to it.
> * Fixed Jacoco configuration in the POM and started using it instead
> of that 40+ minute Cobertura nonsense.
> * Fixed website broken links.
> * Also started assembling a list of why making releases is such a
> pain, email coming later :).
>
> Imaging 1.0 RC7 is available here:
> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>
> Change log(s):
> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>
> Tag:
> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
> (SVN revision 1544953)
>
> Site:
> http://people.apache.org/~damjan/imaging-1.0-RC7/
>
> KEYS:
> http://www.apache.org/dist/commons/KEYS
>
> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>
> Please review and vote. This vote will close no sooner than 72 hours
> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thank you!
>
> Damjan Jovanovic

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Olivier Lamy
Sad!
Sorry I didn't have to check.
I hope it's not your final decision (yes final keyword is important here :-) )

On 28 November 2013 14:09, Damjan Jovanovic <[hidden email]> wrote:

> Vote closed, results were:
>
> +1:
> Damjan Jovanovic
>
> No other votes were cast.
>
> Vote fails since majority approval needs at least 3 votes of +1 ->
> aborting release.
>
> Damjan
>
> On Sun, Nov 24, 2013 at 6:54 PM, Damjan Jovanovic <[hidden email]> wrote:
>> Please vote on releasing commons-imaging 1.0 from RC7.
>>
>> Last failed vote was for RC5, RC6 had a bust POM. Many improvements
>> were made since:
>> * PMD configured better and all PMD warnings fixed, the ones remaining
>> now are bugs in PMD itself.
>> * Test coverage greatly improved in many areas, only a few packages
>> now have < 50% coverage, and that's due to obscure TIFF photometric
>> interpreters and PSD data parsers that require special images to test
>> which Imaging can't itself generate, a massive barely used
>> semi-obsolete Debug class that drags down coverage for
>> org.apache.commons.imaging.util, and areas of code I don't understand
>> and so can't easily test (ICC, PSD). While improving test coverage, I
>> also found and fixed 2 bugs.
>> * Added package-level Javadoc for image formats.
>> * RAT exclusions for text-based images, and made a single info.txt
>> with image formation for all images and added a license header to it.
>> * Fixed Jacoco configuration in the POM and started using it instead
>> of that 40+ minute Cobertura nonsense.
>> * Fixed website broken links.
>> * Also started assembling a list of why making releases is such a
>> pain, email coming later :).
>>
>> Imaging 1.0 RC7 is available here:
>> https://dist.apache.org/repos/dist/dev/commons/imaging/ (SVN revision 3671)
>>
>> Maven artifacts:
>> https://repository.apache.org/content/repositories/staging/org/apache/commons/commons-imaging/
>>
>> Change log(s):
>> https://dist.apache.org/repos/dist/dev/commons/imaging/RELEASE-NOTES.txt
>> http://people.apache.org/~damjan/imaging-1.0-RC7/changes-report.html
>> http://people.apache.org/~damjan/imaging-1.0-RC7/jira-report.html
>>
>> Tag:
>> https://svn.apache.org/repos/asf/commons/proper/imaging/tags/IMAGING_1_0_RC7
>> (SVN revision 1544953)
>>
>> Site:
>> http://people.apache.org/~damjan/imaging-1.0-RC7/
>>
>> KEYS:
>> http://www.apache.org/dist/commons/KEYS
>>
>> I have tested it with OpenJDK 6 on FreeBSD 9.1.
>>
>> Please review and vote. This vote will close no sooner than 72 hours
>> from now, on Wednesday 27 November 2013 at 19:00 GMT.
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thank you!
>>
>> Damjan Jovanovic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Thomas Neidhart
In reply to this post by Damjan Jovanovic-2
On 11/28/2013 04:09 AM, Damjan Jovanovic wrote:
> Vote closed, results were:
>
> +1:
> Damjan Jovanovic
>
> No other votes were cast.
>
> Vote fails since majority approval needs at least 3 votes of +1 ->
> aborting release.

Hi Damjan,

sorry that this vote failed, and I hope you still continue with this
release, I will at least review your next RC!

@all: something that bothered me while doing the release for collections
4 and I have seen too for this component:

While a vote is being cast, people other than the RM should restrain
themselves from making changes to trunk. Even if the intention is just
to help the RM and clean up things, such an action is usually quite
detrimental to the vote itself.

So I propose the following:

 * cast your vote with suggestions for improvement
 * compile your changes as patch and either attach them to an issue
   or send them to the RM

After the vote has ended or cancelled the changes can be included, but
just changing trunk during a vote has the following effect:

 * gives other people the impression that the vote will fail anyway
   thus postponing their vote for the next RC
 * putting pressure on the RM to cancel the vote as already many
   changes have been made to the trunk, even if they are purely of
   cosmetic nature

Imho, cosmetic or style related changes should *never* block a release.
These are things that can be worked on between releases, so we can
really focus on the important things during the release procedure.

If things are not perfect, just make another release a month later that
tidies up all the source code. We always say: release early, release
often, but in fact we never do that, the credo is always: release perfect.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

sebb-2-2
On 28 November 2013 08:05, Thomas Neidhart <[hidden email]> wrote:

> On 11/28/2013 04:09 AM, Damjan Jovanovic wrote:
>> Vote closed, results were:
>>
>> +1:
>> Damjan Jovanovic
>>
>> No other votes were cast.
>>
>> Vote fails since majority approval needs at least 3 votes of +1 ->
>> aborting release.
>
> Hi Damjan,
>
> sorry that this vote failed, and I hope you still continue with this
> release, I will at least review your next RC!
>
> @all: something that bothered me while doing the release for collections
> 4 and I have seen too for this component:
>
> While a vote is being cast, people other than the RM should restrain
> themselves from making changes to trunk. Even if the intention is just
> to help the RM and clean up things, such an action is usually quite
> detrimental to the vote itself.

I think that depends on the scale of the changes.
If there is a simple typo or change to the website, then it's more
effort to save the changes for later (and so they may get lost).
But I agree that large cosmetic changes should probably be left to
later (or perhaps be done in a branch).

> So I propose the following:
>
>  * cast your vote with suggestions for improvement
>  * compile your changes as patch and either attach them to an issue
>    or send them to the RM
>
> After the vote has ended or cancelled the changes can be included, but
> just changing trunk during a vote has the following effect:
>
>  * gives other people the impression that the vote will fail anyway
>    thus postponing their vote for the next RC
>  * putting pressure on the RM to cancel the vote as already many
>    changes have been made to the trunk, even if they are purely of
>    cosmetic nature
>
> Imho, cosmetic or style related changes should *never* block a release.

+1

> These are things that can be worked on between releases, so we can
> really focus on the important things during the release procedure.
>
> If things are not perfect, just make another release a month later that
> tidies up all the source code. We always say: release early, release
> often, but in fact we never do that, the credo is always: release perfect.

The problem here is that an imperfect API can cause long-term problems.

This means that the first release of an component is bound to take
longer as there is lots to review.
Subsequent releases should be easier as only the API changes need to be reviewed

==

Another aspect to release votes is that sometimes the first RC is sent
for a vote without any advance warning.
Unless others have been following the dev list very closely the RC
vote can be the first time that others have got to review the code.
Thus the RC vote may bring out lots of comments on the API.
I agree that reviews should also be done on individual commits, but if
a component is undergoing lots of changes, it won't always be clear
when it has stabilised. So again if the first RC generates lots of
changes it would be helpful to give advance notice of the next RC.

> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Benedikt Ritter-4
2013/11/28 sebb <[hidden email]>

> On 28 November 2013 08:05, Thomas Neidhart <[hidden email]>
> wrote:
> > On 11/28/2013 04:09 AM, Damjan Jovanovic wrote:
> >> Vote closed, results were:
> >>
> >> +1:
> >> Damjan Jovanovic
> >>
> >> No other votes were cast.
> >>
> >> Vote fails since majority approval needs at least 3 votes of +1 ->
> >> aborting release.
> >
> > Hi Damjan,
> >
> > sorry that this vote failed, and I hope you still continue with this
> > release, I will at least review your next RC!
> >
> > @all: something that bothered me while doing the release for collections
> > 4 and I have seen too for this component:
> >
> > While a vote is being cast, people other than the RM should restrain
> > themselves from making changes to trunk. Even if the intention is just
> > to help the RM and clean up things, such an action is usually quite
> > detrimental to the vote itself.
>
> I think that depends on the scale of the changes.
> If there is a simple typo or change to the website, then it's more
> effort to save the changes for later (and so they may get lost).
> But I agree that large cosmetic changes should probably be left to
> later (or perhaps be done in a branch).
>

This sounds like a job for git to me :)


>
> > So I propose the following:
> >
> >  * cast your vote with suggestions for improvement
> >  * compile your changes as patch and either attach them to an issue
> >    or send them to the RM
> >
> > After the vote has ended or cancelled the changes can be included, but
> > just changing trunk during a vote has the following effect:
> >
> >  * gives other people the impression that the vote will fail anyway
> >    thus postponing their vote for the next RC
> >  * putting pressure on the RM to cancel the vote as already many
> >    changes have been made to the trunk, even if they are purely of
> >    cosmetic nature
> >
> > Imho, cosmetic or style related changes should *never* block a release.
>
> +1
>
> > These are things that can be worked on between releases, so we can
> > really focus on the important things during the release procedure.
> >
> > If things are not perfect, just make another release a month later that
> > tidies up all the source code. We always say: release early, release
> > often, but in fact we never do that, the credo is always: release
> perfect.
>
> The problem here is that an imperfect API can cause long-term problems.
>
> This means that the first release of an component is bound to take
> longer as there is lots to review.
> Subsequent releases should be easier as only the API changes need to be
> reviewed
>
> ==
>
> Another aspect to release votes is that sometimes the first RC is sent
> for a vote without any advance warning.
> Unless others have been following the dev list very closely the RC
> vote can be the first time that others have got to review the code.
> Thus the RC vote may bring out lots of comments on the API.
> I agree that reviews should also be done on individual commits, but if
> a component is undergoing lots of changes, it won't always be clear
> when it has stabilised. So again if the first RC generates lots of
> changes it would be helpful to give advance notice of the next RC.
>
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Oliver Heger-3
In reply to this post by Thomas Neidhart


Am 28.11.2013 09:05, schrieb Thomas Neidhart:

> On 11/28/2013 04:09 AM, Damjan Jovanovic wrote:
>> Vote closed, results were:
>>
>> +1:
>> Damjan Jovanovic
>>
>> No other votes were cast.
>>
>> Vote fails since majority approval needs at least 3 votes of +1 ->
>> aborting release.
>
> Hi Damjan,
>
> sorry that this vote failed, and I hope you still continue with this
> release, I will at least review your next RC!
>
> @all: something that bothered me while doing the release for collections
> 4 and I have seen too for this component:
>
> While a vote is being cast, people other than the RM should restrain
> themselves from making changes to trunk. Even if the intention is just
> to help the RM and clean up things, such an action is usually quite
> detrimental to the vote itself.
>
> So I propose the following:
>
>  * cast your vote with suggestions for improvement
>  * compile your changes as patch and either attach them to an issue
>    or send them to the RM
>
> After the vote has ended or cancelled the changes can be included, but
> just changing trunk during a vote has the following effect:
>
>  * gives other people the impression that the vote will fail anyway
>    thus postponing their vote for the next RC
>  * putting pressure on the RM to cancel the vote as already many
>    changes have been made to the trunk, even if they are purely of
>    cosmetic nature
>
> Imho, cosmetic or style related changes should *never* block a release.
> These are things that can be worked on between releases, so we can
> really focus on the important things during the release procedure.
>
> If things are not perfect, just make another release a month later that
> tidies up all the source code. We always say: release early, release
> often, but in fact we never do that, the credo is always: release perfect.

Yes, I second that. For me commits on a component that is currently
voted for a release have the effect you described. I am confused whether
it makes sense to review and vote as it seems that the vote is going to
fail anyway.

Oliver

>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release Imaging 1.0 from RC7

Phil Steitz
On 11/28/13, 12:22 PM, Oliver Heger wrote:

>
> Am 28.11.2013 09:05, schrieb Thomas Neidhart:
>> On 11/28/2013 04:09 AM, Damjan Jovanovic wrote:
>>> Vote closed, results were:
>>>
>>> +1:
>>> Damjan Jovanovic
>>>
>>> No other votes were cast.
>>>
>>> Vote fails since majority approval needs at least 3 votes of +1 ->
>>> aborting release.
>> Hi Damjan,
>>
>> sorry that this vote failed, and I hope you still continue with this
>> release, I will at least review your next RC!
>>
>> @all: something that bothered me while doing the release for collections
>> 4 and I have seen too for this component:
>>
>> While a vote is being cast, people other than the RM should restrain
>> themselves from making changes to trunk. Even if the intention is just
>> to help the RM and clean up things, such an action is usually quite
>> detrimental to the vote itself.
>>
>> So I propose the following:
>>
>>  * cast your vote with suggestions for improvement
>>  * compile your changes as patch and either attach them to an issue
>>    or send them to the RM
>>
>> After the vote has ended or cancelled the changes can be included, but
>> just changing trunk during a vote has the following effect:
>>
>>  * gives other people the impression that the vote will fail anyway
>>    thus postponing their vote for the next RC
>>  * putting pressure on the RM to cancel the vote as already many
>>    changes have been made to the trunk, even if they are purely of
>>    cosmetic nature
>>
>> Imho, cosmetic or style related changes should *never* block a release.
>> These are things that can be worked on between releases, so we can
>> really focus on the important things during the release procedure.
>>
>> If things are not perfect, just make another release a month later that
>> tidies up all the source code. We always say: release early, release
>> often, but in fact we never do that, the credo is always: release perfect.
> Yes, I second that. For me commits on a component that is currently
> voted for a release have the effect you described. I am confused whether
> it makes sense to review and vote as it seems that the vote is going to
> fail anyway.

I appreciate the sentiment here.  Personally, it doesn't bother me
if I am RM other than this phenomenon of people not reviewing /
voting once a few commits have been made to trunk.  I agree with
Sebb that giving some advance warning that an RC is about to be cut
can help some.  We used to have a much more formal process where RMs
were "elected" via lazy consensus and release plans were documented
on the Wiki.  I don't think we need to go back to that level of
formalism, but I think we should agree to at least post a note
indicating that an RC is imminent based on trunk plus whatever WIP /
JIRAs the RM has in mind for inclusion.  And then those of us who
are going to review and vote on the release commit to looking at the
code and surfacing issues before the RC count gets painful for the
RM.  I would be OK using JIRAs with patches during RC cycles if that
makes things easier.  That does create a little extra work for the
RM though and when that is me I would prefer to just get the stuff
committed directly into trunk.

Another thing that will help is to try to get to "comment early,
comment often" or allow the do-ocracy to proceed.  We have lots of
great eyeballs here; but its actually better to get a smaller number
of us looking deeply at the code early than lots of people surfacing
nits late.

Phil

>
> Oliver
>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]