Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
References: <578F898E.1070104@itextpdf.com> <CAB917RKabO06PJbNZevb-ZMY3gCsh+MVpAGS3BNXgK1AJwiWWA@mail.gmail.com>
 <158fcb92-f344-1173-1e42-7277d0efdcf8@itextpdf.com> <CAB917RJsQYh9EpD6zp6L6U5Q_WrZVkbYr7dPnqW1YWjRf-pkzw@mail.gmail.com>
 <HE1PR0501MB2218AD1806E986F6399364018A150@HE1PR0501MB2218.eurprd05.prod.outlook.com>
In-Reply-To: <HE1PR0501MB2218AD1806E986F6399364018A150@HE1PR0501MB2218.eurprd05.prod.outlook.com>
From: Benedikt Ritter <britter@apache.org>
Date: Thu, 18 Aug 2016 14:06:17 +0000
Message-ID: <CAB917R+HXOgmYPOtGCXTqO0=rT566+X7d=vcuRVVbGwsW6LyKA@mail.gmail.com>
Subject: Re: [IMAGING] issue tracker?
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a114433508c7217053a5916fb
archived-at: Thu, 18 Aug 2016 14:06:34 -0000

--001a114433508c7217053a5916fb
Content-Type: text/plain; charset=UTF-8

Hello Amedee,

Amedee Van Gasse <amedee.vangasse@itextpdf.com> schrieb am Do., 18. Aug.
2016 um 15:30 Uhr:

> Where can I find a single issue tracker with all issues that block a
> release of commons-imaging? And, if available, estimated time / story
> points / other metric for those blocking issues?
>
> Based on that input, we at iText Software can decide how we can work with
> Apache Commons to get to a release of Commons-imaging.
>

I'm happy to hear that iText Software is still considering joining the
development of Commons Imaging after we had kind of a tough start - sorry
for that.

The issue tracker is here [1]. We don't estimate issues. I don't think that
this would work for a community like Commons. What we do have are special
versions for Issues that need more discussion, issues that need a patch and
issues that have a patch the needs to be reviewed.
TBH I think we need to go through all issues reevaluate whether we want
them in 1.0 or not and then set the version according to that.

From my PoV what is blocking the release is finalizing the public API. As a
library vendor, you probably know that it is important to come up with a
stable API for the first release. Currently we have a lot of FindBugs
errors indicating that Imaging is leaking internal representation of data
[2]. I think we have to discuss whether we can fix this by changing the API
or not. Since we're talking about the byte array representations of the
image date being processed, I don't see a way to fix this without
excessively copying data around in memory. This what certainly degrade
performance.

Another interesting aspect would be your feedback as a user. Does the API
work well from a user perspective or do we need to change stuff? Now is the
time to introduce those changes as it will be harder to evolve the API
after release 1.0.

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/IMAGING
[2] http://commons.apache.org/proper/commons-imaging/findbugs.html


>
> Best regards,
> Amedee Van Gasse
> QA Engineer
> iText Software
> ________________________________
> From: Benedikt Ritter <britter@apache.org>
> Sent: Wednesday, July 27, 2016 8:18:21 PM
> To: Commons Developers List
> Subject: Re: [IMAGING] Update from Java 5 to 7.
>
> Hello Amedee,
>
> Amedee Van Gasse <amedee.vangasse@itextpdf.com> schrieb am Di., 26. Juli
> 2016 um 18:00 Uhr:
>
> > Hello Benedikt,
> >
> > Op 21-07-16 om 08:39 schreef Benedikt Ritter:
> > > Hallo Amedee,
> >
> > *snip*
> >
> > >> However, if the answer really is no, we will explore the other
> options.
> > >>
> > >
> > > I'm not really happy with what your saying here. You're basically
> saying:
> > > please invest your (spare time) to maintain Java 5 code,
> >
> > I'm afraid you misinterpreted my email.
> >
> > I asked a question, and I said beforehand that I would accept "no" as an
> > answer.
> >
> > > now you're "threaten" us that you'll fork the project.
> >
> > I'm afraid there is again a misinterpretation. Hey, I *know* how
> > sensitive the "fork" topic is in Open Source. Really. We've had our own
> > share of forks too, and they weren't as nice (because they intentionally
> > tried to circumvent an AGPL license).
> >
> > I gave 4 options that we are choosing from, and only those 4 options. I
> > will repeat them again:
> >
> > 1. Tell our affected customers to move to Java 7
> > 2. Switch the dependency from commons-imaging to sanselan, and loose
> > some features
> > 3. Remove the functionality that depends on commons-imaging alltogether
> > 4. Depend on a 'release' of commons-imaging that is on Java 5.
> >
> > Below that, I mentioned something that was not numbered, forking. It
> > came up in an internal brainstorm in a meeting, and I personally gave
> > lots of arguments why we should really really REALLY avoid to fork. I
> > repeat: forking was briefly considered, and rejected.
> >
> > > I'm open for discussion how we can get to a 1.0 release that is 5.0
> > > compatible *together* or how we can backport some of the fixes and
> > features
> > > to sanselan and release it as 0.98.
> >
> > Emmanuel Bourg and Gary Gregory already answered the question. I read
> > between the lines of Gary Gregory's email that a contribution would be
> > welcomed. I would like to thank Emmanuel and Gary for their replies.
> > When there is a 1.0 release, and if at that time our Java 5 product
> > isn't EOL yet, then a contribution will most definitely be considered,
> > obviously. After all, we're an Open Source company ourselves, and we
> > know very well how Open Source works.
> >
>
> Thank you for this clarification. Sorry, if I came along harshly. We're
> looking forward to collaborating with you.
>
> Regards,
> Benedikt
>
>
> >
> >
> > --
> > Amedee Van Gasse
> > QA Engineer | iText Software BVBA
> > amedee.vangasse@itextpdf.com
> > http://itextpdf.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

--001a114433508c7217053a5916fb--