Re: [Gimp-print-devel] 3.2 or 4.0 Release criteria

[Thomas T. <tt...@bi...>]

Robert L Krawitz wrote:

> If we're going to do that, we need to start thinking about release
> criteria.  The obvious issues to consider are:

What about using the Linux odd/even model? 3.1 is development, and 3.2
(or 4.0) would have everything that is good and works in an easy to use
package. 3.3.x would have new printers built in, and when they reach
'the right quality' they would move to 3.2.x. Or maybe hide the
in-developemnt models under a 'development' part of the UI: see my
answer on print quality.

> 1) What is the minimum required functionality to make a new stable
>    release worthwhile to users?  That should be measured in quality
>    and features.  I believe that we're getting toward that point in
>    terms of devices (well, Epson devices at any rate) and quality
>    (maybe I should try the 3.0-based plugin that comes with the Gimp
>    for comparison some time).  There are other issues, such as
>    device-specific settings, a help system, and so forth that we need
>    to consider.

A help system for a printer plugin? Hmmm. I'd rather have the
bewildering number of choices reduced somewhat myself. As a naive user,
I have to try something like 3 modes * 8 resolutions * 6 dithers. I'd
like to select my printer and then find only modes that work for my
model, are useful, and understandeable. 4 speed/quality settings should
be enough, and maybe a photo/solid color/b&w lineart/ink saving setting
that changes dither and other things.

As far as print quality is concerned: it can always be improved, and
that means it is never 'ready' for release. So I'd like to see a 'user'
version with printers and settings that work. Maybe this version has a
'development' mode as well that gives access to the new printer models,
or maybe those versions are just in the development version.

> 2) What do we need to do with the interface?  It's still rough in some
>    ways: the print coordinates aren't correct (the origin isn't the
>    top left of the paper, it's the top left of the printable area;
>    Gimp users probably don't care too much, but Ghostscript users know
>    what I'm talking about); there are a number of features that are of
>    more interest to developers (such as dithering algorithms, and
>    gamma) than to end users, and there's still a lot of clutter.  We
>    also need to decide which of the two interfaces we're going to
>    support.

Gamma is probably good to have as the gamma of different CRTs is quite
different. The page layout thingy could use margin display etc. I must
say the thingy looks nice and is useful, but actually it is a strange
thing as it is very small. Some kind of displayed rows and columns could
help align stuff on your expensive photo paper.

> 3) Quality.  I don't mean print quality; I mean robustness,
>    performance, and correctness.

If some features of the code are removed performance may increase a bit,
but I think that increasing performance will be a separate effort. And
performance may bite quality, although it does not have to be bad. Think
about re-using random values or using our own random number generator
(it does not have to be terribly good...)

> 4) Documentation.

For the user? In the UI mostly. For the developer I wouldn't worry. It's
a 'release' version - but as more people will have a look, it would
probably be good to have it in shape.

> 5) The Ghostscript driver is a mess right now, and there's no error
>    checking (everyone who has tried using a mode that's not compatible
>    with their printer knows what THAT means).  I think that this is
>    even more important than the Gimp plugin from a strategic point of
>    view.

I personally was more interested in the Ghostscript driver, but I
switched to testing with the GIMP version because that is much easier to
do. Ghostscript probably is more important for the time being. Anyone
know what the Gnome Printing Model is doing? Ghostscript could end up
printing to the Gnome printer, just like the Windows version can print
to the Windows printing layer. I think there should be just one place
where people set up their printer

> 7) Testing.  I know that there are a fair number of people using this;
>    I don't know just how many.  Freshmeat says that about 900 people
>    have hit one of the two download URL's (both on Sourceforge); I
>    haven't found how to get download statistics from Sourceforge, but
>    I'd really like to know how much use it's getting.

Would it be much effort to include a 'feedback' button in the UI?
Probably not, but analyzing the received data might be.

> 8) Is this a 3.2 or a 4.0 release?  Is it overall a substantial enough
>    change (I don't think that improved print quality alone would
>    count) from release 3.0 to merit a new major number, or do we
>    consider it incremental?

If the UI is bastard proofed, I think it would justify a 4.0 number.

> The other thing I'm going to try to do is spin a release once a week,
> if there's enough new material.  The month between 3.1.2 and 3.1.3 was
> quite long, although the dither code was undergoing a lot of changes.

As a non-developer I would not give comments to a mailing list that
quickly. If there is a feedback method that attracts more responses,
that could help us a lot: to collect bugs, find out which settings
people use, etc.


Thomas