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

[Robert L K. <rl...@al...>]

   Date: Wed, 03 May 2000 11:02:23 +0200
   From: Thomas Tonino <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.

That's the idea.

   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.

I was thinking along much the same lines; pick a set of controls that
make sense from a user perspective.  Things that I think a user is
concerned about are:

* Desired print quality/speed

* Image type (people know whether they're printing text, or a photo,
  or something in between)

* Paper type (using 1440 dpi on cheap paper is wasteful; using 360 dpi
  on glossy film, likewise) and size

* Image size/positioning

* Printer model

* Paper source (for printers with multiple input trays)

* Printer name

* Black & white vs. grayscale vs. color


Things that users might be concerned about, but belong elsewhere,
might include:

* Brightness

* Contrast

* MAYBE color balance settings and saturation


Things that only advanced users will ever care about:

* Printer command (we should somehow try to autodetect that)

* Gamma

* Dither algorithm

* Ink type (if you're using e. g. MIS monochrome inks, you're an
  advanced user, period).

   As far as print quality is concerned: it can always be improved, and
   that means it is never 'ready' for release.

The former is correct; that doesn't make the latter true.  Clearly you
agree, but I just want to make clear that "release" doesn't mean
"perfect".  There are never any "perfect" releases, and we have to
accept that at some point we have to cut things off.  My issue here
is, is print quality "good enough" to merit a 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.

I don't want to support two contemporaneous releases.  Marking
printers that are not tested well enough as experimental (maybe having
a separate page to select these printers) might do.  Anyway, I don't
think that 3.2 or 4.0 or whatever we call it will be a single release;
we'll surely do point releases along the way, with new printers
included (that's why getting the printer description architecture
right is important -- if we do it right, we can just add printers to
printers.xml and have everything just work, assuming that the printers
don't need some new feature that we don't know about yet.  We're not
there yet.)

   Gamma is probably good to have as the gamma of different CRTs is quite
   different.

But do most users have a clue what it means?  We can always put
something in the doc discussing how to fine tune the output.
	      
	      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.

I like this idea.  I'm not sure I like how the thing scales with paper size.

   > 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...)

Performance is really a bit separate here, but a lot of people
complain about the speed (or lack thereof).  Some of this is just a
matter of doing the right constant folding, but some of it is a matter
of having the right tuning points in the dither routine (NOT user
visible directly, but if someone picks a low resolution and low-end
paper and such we should intuit that we should use a faster
algorithm.  Likewise, if someone picks all high-end settings, we know
they expect top quality and not high printer performance.)

   > 4) Documentation.

   For the user? In the UI mostly.

That's what I meant about a help system.

				   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.

Well, a lot of people on the list complain (with justification, I
think) that the code is poorly documented.  It's a lot easier for
people to code and submit changes if they understand what's going on.

   > 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.

OK, well that's a specific criterion that I rather tend to agree with.

Thanks!

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton