Re: To All Package Maintainers & Would-be Maintainers.
|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> I understand your frustration, but that frustration is more XEmacs's
SJT> fault than the external package maintainers',
SJT> (1) There should be a mechanism at top level (I mean in Local.rules)
SJT> to omit building a package which is in the tree. AFAICT, it is not
SJT> possible to inhibit building of autoloads (at least) without munging
SJT> lower-level Makefiles.
True. But we also need a way to prevent someone from excluding a
package that is required by another package that they do wish to
build. I guess that would come under the banner of "dependencies"
huh?
SJT> (2) We need a safe way for maintainers who are making big changes to
SJT> their packages to check them in gradually. This is especially true
SJT> where xemacs-packages is the primary repository for the package
SJT> source, or where the package maintainer may primarily work with GNU
SJT> Emacs, not XEmacs.
I disagree with this. Why should there be any need for xemacs.org to
be the primary repository for any external package? What's wrong with
the external package maintainer's local machine, or if [s]he wants
somewhere public, how about SourceForge?
Here's an example with my package 'Eicq':
I would dearly love more people to work on Eicq so I keep the primary
CVS repository on SourceForge. When I wish to update the XEmacs
package version I simply do a cvs update from the SourceForge
repository, copy that to my local copy of the xemacs-packages tree,
and do a cvs commit to cvs.xemacs.org. And because I'm on first name
terms with the XEmacs Packages Release Engineer, he immediately rolls
a new Eicq package for me. :-)
That way, hopefully, the mistakes get made on cvs.sourceforge.net, not
cvs.xemacs.org.
SJT> One possibility would be for each package's trunk to be the
SJT> maintainer's preserve, and for you to maintain a release branch which
SJT> is the Package Release Engineer's preserve. This would impose a
SJT> substantial burden on you AFAICT, but it's a "natural" way to go.
SJT> Alternatively, maintainers could be asked to make (temporary) unstable
SJT> branches if they are going to be making a lot of changes and don't
SJT> want to commit to your schedule. Or you could do that for them.
I disagree with these two points (see my comments above).
SJT> If the packages need an unstable branch on a regular basis, as Martin
SJT> suggested, we should consider whether maintaining a package hierarchy
SJT> makes sense, or whether we should throw it all back into the users's
SJT> laps as GNU does.
Exactly what is the way that GNU handles packages? I don't want to
dismiss something without knowing what that something is.
SJT> (3) Dependencies are getting out of hand. Furthermore, problems with
SJT> dependencies still seem to occasionally get hidden unless you do a
SJT> make distclean.
SJT> This is a long-term project, but we need to do something about better
SJT> dependency handling.
Agreed. And this brings me back to something that has been mentioned
quite a few times - This is a job for, dum dum dummmm;
Capt^H^H^H^Hautoconf (amongst other things).
SJT> (4) There is no simple way to maintain just one's own package; you
SJT> have to check out all the dependencies as well, and build them too.
So, how is that different from any other software package that has
dependencies?
SJT> But this doesn't work very well if somebody screws up, since the build
SJT> stops in the middle.
Would it be better if the build continue on regardless? I don't
think so, and my reason for that is simple:
- Maintainer of package A updates his package
- package A requires package B
- package A has a bug (unknown to the maintainer) that will only show up
if package B is built successfully
- package B has a bug and won't build
- maintainer of package A does a test build of his package
- it doesn't pick up the dependencies from package B but continues the
build of package A because we're using Steve T's "don't stop build
process"
- maintainer of package A "thinks" he has a working package so he commits
it to cvs.xemacs.org
- I release a flashy new "A" package
- Complaints start showing up on xemacs-beta "hey this package "A"
doesn't
do xyz for me"
But the way it is now package A wouldn't build because package B
didn't build. And then the maintainer of package A could: "Hey Joe,
your package B is screwed buddy, it won't build. And because I'm such
a nice guy, here's a patch that fixes it.". Or he could jump up and
down and yell and scream. Whichever he felt like doing.
SJT> So really, when you say "make sure it builds in
SJT> the XEmacs packages tree," you're demanding that people check out 70MB
SJT> or so of package hierarchy, keep it updated, and do full builds from
SJT> `make [dist]clean' which involve a lot of time and a total of about
SJT> 100MB.
Yes it might take a bit of time to initially check out the
xemacs-packages module. But after that all they need to do when the
wish to update their package is:
cvs-update
make distclean
make autoloads
build their package
There is no need for them to do a complete build of the entire tree, a
'make distclean && make autoloads' will suffice.
I honestly don't think this is too much to ask.
SJT> And *all* the build targets? Including ringing the changes on
SJT> symlinks=t and build_without_mule?
Changing symlinks= wouldn't make any difference, but
BUILD_WITHOUT_MULE is a good idea. Thanks for bringing that up,
Steve. :-)
SJT> If that's what we need, that's what we need, but this is a lot of
SJT> effort and resources on the part of an external package maintainer.
Yep, it's what we need and it's not much effort and hard disk space is
cheap these days.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|