6:05 a.m.
Hi Steve,
I've just checked-in the repository the 1.0 version of the XSLT-process package
for XEmacs. I've setup a makefile that builds only the elisp files, without
trying to compile the Java classes.
This minor mode depends on beanshell.el from JDE. However the JDE version is
very old (2.1.9) and the functionality required from beanshell.el by
XSLT-process is not present. I talked to Paul Kinnucan, JDE's author, about
upgrading JDE to a newer version but he seems to be very busy right now to be
able to work on this. I was thinking as an intermediate solution we can only
upgrade the beanshell.el file inside JDE with a newer version, it looks like
there are no other dependencies. Of course, the nicest thing would be for
somebody to do the upgrade to a newer version of JDE.
One issue I found while writing the makefile was that in the REQUIRES variable
you not only have to put the package you depend on, but also all the packages
that package depends on. Am I missing something? If this is the case I believe
we have a problem, because changing one dependency in a base package requires
updates on all the depending packages.
Regards,
Ovidiu
8:15 a.m.
>>>> "Ovidiu" == Ovidiu Predescu
<ovidiu(a)xemacs.org> writes:
Ovidiu> I was thinking as an intermediate solution we can only
Ovidiu> upgrade the beanshell.el file inside JDE with a newer
Ovidiu> version, it looks like there are no other dependencies.
If the new beanshell.el provides a testable feature (using boundp or
fboundp, as well as featurep), you could require that, then if the
feature is not present, require xslt-beanshell (which would simply be
a copy of the more modern beanshell.el). This would be fragile, but
might work until JDE's beanshell.el gets updated. It would also have
the advantage of simply being ignored once beanshell.el does get
updated; you wouldn't have to worry about messing people up by having
an older version of xlst-beanshell than JDE's.
Of course Steve Youngs can always do as you suggest, and that is
best if JDE doesn't break without the older version.
Ovidiu> One issue I found while writing the makefile was that in
Ovidiu> the REQUIRES variable you not only have to put the package
Ovidiu> you depend on, but also all the packages that package
Ovidiu> depends on.
The packages dependency system is known to be problematic.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
2:18 p.m.
|--==> "OP" == Ovidiu Predescu <ovidiu(a)xemacs.org> writes:
OP> I've just checked-in the repository the 1.0 version of the XSLT-process
package
OP> for XEmacs. I've setup a makefile that builds only the elisp files, without
OP> trying to compile the Java classes.
OK, great. I'll take a look and see if I can't build and release it.
OP> This minor mode depends on beanshell.el from JDE. However the JDE version is
OP> very old (2.1.9) and the functionality required from beanshell.el by
Paul's been madly committing to CVS the last couple of days. He's
updating to 2.2.7. The version of beanshell.el in CVS currently is
1.3. Is that the one you need.
OP> One issue I found while writing the makefile was that in the REQUIRES variable
OP> you not only have to put the package you depend on, but also all the packages
OP> that package depends on. Am I missing something? If this is the case I believe
OP> we have a problem, because changing one dependency in a base package requires
OP> updates on all the depending packages.
I'm definitely open to suggestions for improvements.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
2:35 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> |--==> "OP" == Ovidiu Predescu <ovidiu(a)xemacs.org> writes:
OP> I've just checked-in the repository the 1.0 version of the XSLT-process
package
OP> for XEmacs. I've setup a makefile that builds only the elisp files, without
OP> trying to compile the Java classes.
SY> OK, great. I'll take a look and see if I can't build and release it.
OP> This minor mode depends on beanshell.el from JDE. However the JDE version is
OP> very old (2.1.9) and the functionality required from beanshell.el by
SY> Paul's been madly committing to CVS the last couple of days. He's
SY> updating to 2.2.7. The version of beanshell.el in CVS currently is
SY> 1.3. Is that the one you need.
OP> One issue I found while writing the makefile was that in the REQUIRES variable
OP> you not only have to put the package you depend on, but also all the packages
OP> that package depends on. Am I missing something? If this is the case I believe
OP> we have a problem, because changing one dependency in a base package requires
OP> updates on all the depending packages.
SY> I'm definitely open to suggestions for improvements.
To keep things sane, it makes sense to have an unstable branch of the
packages. Developers could check out the unstable branch using
cvs checkout -f -r unstable xemacs-packages
so that at any one time, only a few packages could have an unstable
branch.
This could also allow changes of questionable stability into the
packages without breaking users of stable xemacs. And commits would
not have to be delayed because of code freeze. When commits to
unstable have been deemed stable, they can be merged onto the trunk,
one package at a time.
The hard part of this is committer education. There are far more
xemacs packages committers than core committers, at least potentially.
3:01 a.m.
>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> To keep things sane, it makes sense to have an unstable branch
mb> of the packages. Developers could check out the unstable
mb> branch using
I think this would make things _in_sane. Individual packages can have
their own unstable branches, but this should be under control of the
package maintainer.
Furthermore, in Ovidiu's case, he would have to _depend_ on the
_unstable_ branch of JDE. Yuck! How the hell do we sort _that_ out
in the SUMOs?
mb> This could also allow changes of questionable stability into
mb> the packages without breaking users of stable xemacs. And
mb> commits would not have to be delayed because of code freeze.
mb> When commits to unstable have been deemed stable, they can be
mb> merged onto the trunk, one package at a time.
Again, this is all upstream policy in principle. Not all maintainers
do development on the cvs.xemacs.org sources; some simply check that
in as a vendor branch from a primary located elsewhere.
I agree that committer education will be hard, because we're going to
have to teach them to Do The Right Thing without knowing what it is
ourselves. Let's not go there.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
11:12 a.m.
|--==> "SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>>"mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> To keep things sane, it makes sense to
have an unstable branch
mb> of the packages. Developers could check out the unstable
mb> branch using
SJT> I think this would make things _in_sane. Individual packages can have
SJT> their own unstable branches, but this should be under control of the
SJT> package maintainer.
SJT> Furthermore, in Ovidiu's case, he would have to _depend_ on the
SJT> _unstable_ branch of JDE. Yuck! How the hell do we sort _that_ out
SJT> in the SUMOs?
I don't even wanna think about that one.
SJT> I agree that committer education will be hard, because we're going to
SJT> have to teach them to Do The Right Thing without knowing what it is
SJT> ourselves. Let's not go there.
Agreed, wholeheartedly.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
11:09 a.m.
|--==> "MB" == Martin Buchholz <martin(a)xemacs.org> writes:
>>>>>"SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> I'm definitely open to suggestions
for improvements.
MB> To keep things sane, it makes sense to have an unstable branch of the
MB> packages. Developers could check out the unstable branch using
Actually, I think this is a bad idea. There are probably lots of
reasons why, but the one that sticks out in my mind is that it would
be an administrative nightmare.
We currently have 88, yep *Eighty-eight* packages, I keep two copies
of the xemacs-packages CVS source tree locally, one for
testing/building and a clean copy from which I do all CVS
commits/updates etc. That's 264 (if you include cvs.xemacs.org)
packages that I keep abreast of.
And you want to double that number by having an unstable branch. Man,
my wife already thinks I love the computer more than her. :-)
In a perfect world (well one of my versions of a perfect world, at
least), each and every package would have an active maintainer. That
maintainer would keep their development tree somewhere else, such as
SourceForge, and only commit tested stable versions of their code to
our CVS.
But alas, it's not a perfect world...
And if I ever get some time to do it, I'm going to start posting lists
of packages that have no maintainer and try to encourage adoption.
MB> The hard part of this is committer education. There are far more
MB> xemacs packages committers than core committers, at least potentially.
Another reason for stricter controls on who gets commit privileges.
But that's a can of worms that I don't wish to re-open. Especially
since everyone has been so good lately. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8682
days inactive
8683
days old
6 comments
4 participants
participants (4)
-
Martin Buchholz -
Ovidiu Predescu -
Stephen J. Turnbull -
Steve Youngs