freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Searching for an FT2 tester program


From: Werner LEMBERG
Subject: Re: [ft-devel] Searching for an FT2 tester program
Date: Tue, 17 Mar 2009 12:59:55 +0100 (CET)

> I've finished merging my changes with 2.3.9 and doing some cleanups.
> I think I'm more or less happy with the results.

Looks good.  Great work!  As usual, there are some `defualt' in the
code :-)

> I can't think of any good way I can separate that diff to meaningful
> chunks other than starting the work from the beginning and then
> sending a diff after each struct is handled, and even if I did that,
> only the final diff would be the one that can actually run.

Now we use git, so managing small chunks has become much easier -- and
you can prepare everything `at home' (using your local git clone of
the FreeType repository) in a separate branch, submitting the whole
set of changes then very easily.

Just split the diff into, say,

  PIC related stuff (e.g., ftoption.h, ftpic.h, ftpic.c, basepic.c)

  module management header files

  header files

  PIC service changes
  remaining service header files

  PIC autofit files
  remaining autofit changes

  PIC truetype files
  remaining autofit changes

  ...

This basically means just committing selected files for a single
commit and not all in one rush.  Nothing difficult I think.  In total,
I estimate that you can split your diff into about 20 smaller units
quite easily without much work.  The set of changes which belong
together, and which must be applied as a complete series should be
enumerated and named (as the git header line) like this:

  [3/10] PIC support: Header files.

However, changes like the memory -> library change in ftstroke.c
should be put into a separate patch (to be applied before the rest)
since it is not directly related to the rest.

BTW, a quite time consuming job is to write proper ChangeLog entries
which *look similar to other ChangeLog entries* -- something which I
ask you to add.  git's commit entries are the same then.

Finally, I ask you to add *a bit* more documentation to the source
code.  Most of it is self-explanatory (which always indicate
well-written code IMHO), but it would be helpful to explain the
`end-hacker macros' needed for adding a new service, for example.


    Werner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]