Syncing packages to upstream one oh one. (was: Welcome to The XEmacs Development Team.)
|--==> "VS" == Ville Skytt <Ville> writes:
VS> At this point, I think this would be the best way to proceed:
Yep, looks good. I generally do my syncing like this:
1) diff -urNb xemacs-pkg-src/ upstream-src/ > initial-patch.diff
I use that as a starting point and reference if I need it. I *don't*
send 'initial-patch.diff' to xemacs-patches, it's only for my own
personal use to aid in syncing.
2) find xemacs-src/ -type f | xargs grep -l \
"[Xx][Ee]macs [Cc]hange" > files-to-inspect-closely
This should give you a list of files in the XEmacs package source that
have been modified for XEmacs. This isn't a definitive list because
those "XEmacs change" comments aren't always used, but it is a good
starting point.
I'll go through these files one by one and see if those changes are
still needed in the upstream. If so, create a diff (diff -u our-file
their-file > upstream.diff) and send it upstream, asking if they could
incorporate it into their next release.
3) Look for '*.upstream' files in xemacs-pkg-src/ and rename the equiv
upstream-src/ files accordingly
4) Make a backup of xemacs-pkg-src/ then rm all the files (sans
any CVS/*) from xemacs-pkg-src/. Dump upstream-src/* into
xemacs-pkg-src/
5) M-x cvs-update RET /path/to/xemacs-pkg-src/ RET
The resulting CVS buffer gives you a number of things that you need to
pay attention to:
- "Up-to-date" files need to be 'cvs rm'd' because they
don't
exist in the upstream-src/ These files may also need to be
removed from the Makefile (ELCS), so at this point, fix the
Makefile. Then "mark" these files in the CVS buffer by
pressing 'm' on each one and then press 'r' to 'cvs rm'
them. (type 'u' on these files to "unmark" them).
- "Unknown" files need to be 'cvs add'd' because they
don't
exist in the xemacs-pkg-src/ These files may also need to
be added to the Makefile (ELCS), so at this point, fix the
Makefile accordingly. Then "mark" thses files (same as
above), and type 'a' to 'cvs add' them. Unmark them as
above.
_*DON'T* commit anything at this point._
Now the CVS buffer should only have "Modified", "Removed", or
"Added"
files in it.
6) Make another backup of the xemacs-pkg-src/ in case things go
wrong in the next steps.
7) C-x d /path/to/xemacs-pkg-src/ RET
M-x compile RET make RET
(save the compilation buffer)
As you can see, I now do a test build. If it doesn't build at all,
investigate and fix. If the fix is something outside of the Makefile,
in other words, in one of the upstream .el files etc, then prepare a
patch to go upstream. But 9 times out of 10 it would probably be
something to do with the Makefile or similar.
Check to make sure that everything got built (there's no missing .elc
files), fix the Makefile if needed.
8) Test the other Makefile targets ('clean', 'distclean',
'bindist', 'install').
Make sure they all work correctly. Be careful to make sure that
'clean' and 'distclean' does *NOT* delete any .el files. This will
happen if you list any files in the Makefile ELCS as *.el instead of
*.elc. This is also one of the reasons for step 6) above. :-P
9) Remember that saved compilation buffer? Now scan through it
looking for "The following function(s) are not known to be
defined:" warnings.
Some of these can be ignored (eg 'overlay*' functions if the package
takes into account both Emacs and XEmacs and uses our extents, or
'timer*' functions if the package takes into account our 'itimer*'
functions). It's sometimes not an easy call, but you can always ask
if you're not sure.
Some of these undefined function warnings can be fixed by adding
things to the Makefile (REQUIRES).
10) Repeat steps 7, 8, and 9 if you've made changes along the
way.
11) Make sure that 'package-info.in' is correct and up to date,
especially 'provides'. I do it like this:
grep "(provide '" *.el | cut -d "'" -f 2 | cut -d
")" -f 1
That gives you what needs to be in 'provides' in package-info.in.
Update it as necessary.
12) Update 'AUTHOR_VERSION' in the Makefile.
13) Install the package on your system and test, test, test it.
Finally we get to the actual testing. Why isn't this done a lot
further up the list, say at step 1?
Because the package has to function correctly as an XEmacs package.
If you can't build an XEmacs package in the XEmacs packages source
tree out of what you're syncing there's not much point in going
further. That's why I always make sure it'll build first, then I
make sure the package does what it is supposed to do.
14) Test it some more, in every possible way you can think of.
15) Repeat step 14.
16) See step 15.
17) Prepare a patch to send in to xemacs-patches. This is made
real easy if you have Didier's excellent "patcher" (it's in
xemacs-devel), or you can, from your mail buffer, do:
C-u M-! cvs diff -uN xemacs-pkg-src/ RET
Remove the ChangeLog hunks and then:
C-u M-! cvs diff -U 0 xemacs-pkg-src/ChangeLog RET
18) Send in the patch.
19) cvs ci -m "Sync to upstream version X" xemacs-pkg-src/
I'm not 100% sure if that command line is correct because I always use
either patcher.el or PCL-CVS.
And you might want to wait before you commit to see if anyone objects
to the patch for any reason.
That should be about it, I think it pretty well covers everything.
Maybe something similar to this should go into a TeXinfo file
somewhere?
Any comments? Is anything blatantly wrong or did I leave anything
out? Ville, what do you think?
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|