On 4/25/2013 1:16 AM, Jürgen Schmidt wrote:
On 4/25/13 9:55 AM, janI wrote:
On 25 April 2013 07:34, Jürgen Schmidt <jogischm...@gmail.com> wrote:
On 4/24/13 11:34 PM, janI wrote:
On 24 April 2013 22:33, Juergen Schmidt <jogischm...@gmail.com> wrote:
Am Mittwoch, 24. April 2013 um 17:06 schrieb janI:
On 24 April 2013 16:25, Jürgen Schmidt <jogischm...@gmail.com> wrote:
On 4/22/13 10:50 PM, janI wrote:
On 22 April 2013 22:27, Jürgen Schmidt <jogischm...@gmail.com>
<snip snip snip>
But again, if the general opinion is, that is better to keep a selfmade
deadline and release a half finished product, it would not be fair of me
to
stand in the way.
See above, I think we have to hold our deadlines to show confidence to
the outside. But we can of course improve our planning in the future.
Or we should think about a real train model where we release every 3 or
4 month. But where we maintain also a more stable branch where we fix
mainly bugs and potential security fixes.
this would be a good idea for minor/maintenance releases but not for a
major release.
However, it seems I am the only one with this concern, so I will silence
myself. You
are the voted in release maneger (which I highly support) so according the
apache way,
it is your call together with a majority vote is a release is acceptable.
I simply volunteered to do this task, I am happy if somebody else steps
in ;-)
And in general I share your opinion that releases should not have 100%
fixed dates but should more take the planned features into account.
Fixed dates result often in poor software or poor quality. But I believe
we have to find a compromise and what's possible and to show the
necessary confidence to the public about the progress in the project and
in the product. It's not easy ...
Juergen
Have we discussed, as a project, the tradeoffs that we are making
here? On one hand we have solid decisions on the release made by
Jürgen which trim features, but lead to a predictable, stable, and
complete release. On the other hand, we have we have the reasonable
question by Jan, as to whether there is an alternative approach that
sacrifices the schedule (i.e. pushing back release date) for the
features. My question is "Do we have a solid understanding of this
trade-off, and should we make this decision as a project?"
To me there are three major changes that would be good to be in AOO 4.0
which are currently in jeopardy:
* Accessibility - the integration of iA2 - work is ongoing. This has a
major impact on the product, and the ability of large corporations
and governmental agencies to embrace the product.
* New Translation Infrastructure - this is the major change to use the
po files directly in the code, the consolidation of the poo files,
and the new pootle server infrastructure.
* Brand Refresh - this work is moving along now, but there is some
question as to how much of this project can be completed in the
timeframe necessary. (logo + icons/resources + full brand/splash
screens + color schemes + ??)
I see a few directions that this could go:
1. Follow the current trajectory and push off a significant amount of
originally planned 4.0 work to 4.1
2. Push off the release by 3 months and get all of these features in
completely
3. Hold the release indefinitely, waiting of these features
I think that pretty much everyone would disagree with option #3.
Option #1 is a solid option, but I think that there is some portion of
our community that is not fully comfortable with this.
That leaves us with option #2, which is not perfect, either. Do we have
estimates from each of the deferred features how long they would need to
be complete (with a reasonably high confidence level)? If the time
frame would be 6 months instead of 3 months, would anyone be comfortable
with that?
Could we explore option #2 as a project, and get the answers to these
questions? Then with a more full understanding, can we make a decision
as a project for #1 over #2 (or vice versa)?
A
