I disagree with this. We fixed or closed about 80 issues this month but
most are new issues. The older an issue is, the most unlikely it can be
fixed.
You labeled many a "fix version" which would mean they "must" be fixed
for 2.0. One example: PDFBOX-2402
<https://issues.apache.org/jira/browse/PDFBOX-2402> is about a parser
improvement related to some bad PDFs that is relevant to one user only
(I will fix that one soon, I just need to create a test file, but we
could as well live without it). Another example was a color problem I
had opened (PDFBOX-2142) which is probably only relevant to rendering
advertising flyers.
2.0 is more and more becoming the "Duke Nukem Forever" of open source.
I'm also thinking about the new Berlin airport. Although there is one
difference: the people of "Duke Nukem Forever" and the new Berlin
airport made the mistake to announce release dates.
I agree with Simon. 2.0 is already a massive improvement.
We should name maybe 10 issues that "must" be solved before 2.0. I'm
thinking about regressions, issues were we are close to success
(patterns), and issues where somebody attached his name (with the
meaning "I can fix that and I know what has to be done"). And a short
documentation about what has changed.
Tilman
Am 11.10.2014 um 04:37 schrieb John Hewson:
Hi All,
I really want to give a better answer to this question, but the JIRA issues
were not
labelled with enough version-related information to allow me to simply view a
list
of issues which are due to be fixed in 2.0.
As you’re probably aware, I went through pretty much all the issues and made
sure
that issues which definitely affect 2.0 had that in their "Affects Version/s”
field. I also
set the "Fix Version/s” for issues which are due to be fixed in 2.0, so for the
first time
we have a way to see which issues are due to be fixed. The end result is here:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20PDFBOX%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%202.0.0%20ORDER%20BY%20priority%20DESC
So I can now say that we have 166 issues due to be fixed in 2.0. We might want
to
choose to defer some of these (we’ll need to add a “Later” version to JIRA to
do that)
and to maybe take a look at issues which overlap with current development such
as
xrefs, rendering, and parsing.
Cheers
-- John
On 10 Oct 2014, at 11:05, John Hewson <j...@jahewson.com> wrote:
Simon,
Andreas has the best handle on this, but off the top of my head what we need is
to finish
making breaking API changes and for the code to have been stable for a while
before
making a 2.0 release.
Improvements and fixes which still need breaking API changes include:
- Pattern rendering
- Pages resource caching (significant memory usage issues)
- Font embedding (particularly TTF)
- Parsing (Andreas?)
- Page Tree (needs completely re-writing)
- Text extraction on Java 8 (this might end up being a breaking change
to the sort)
There’s probably more, such as work on Acroforms, and we need to have much
better
example code for 2.0 due to all the changes.
This seems like a good time to explicitly try to make sure that we have JIRA
issues open
for all outstanding tasks, so that we can track how close 2.0 is to being
ready. The stability
of the code is a pretty good indicator - we’re not there yet.
I’m going to open some JIRA issues. Andreas, Tilman - please open issues for any
2.0 features which you think we need.
Thanks
-- John
On 10 Oct 2014, at 08:08, Simon Steiner <simonsteiner1...@gmail.com> wrote:
Hi,
Could you set a target date for 2.0 release. What's missing to make a
release?
Thanks
