Re: XEmacs at a crossroads

Mats Lidell writes:

 > That could mean:

Thanks for the suggestions, but I've already been through most of
these, and for most there are technical reasons for not doing them (I
could explain if you want).  Some of your ideas are more directed at
improving the project than at reducing maintenance cost and I'd like
to highlight those.

 >   - even move over to use pull requests at bitbucket?

Pull requests are worth discussing, since that would represent a
modernization of our workflows, and might make it easier to contribute.

 >   - Drop the buildbots. With no or few commits coming it is not
 >     worth the time and resources spent maintaining them.

Up to you, that's work you've been doing.  But I regularly see
buildbot posts for the packages.

 >   - Replace the old web pages with a simple static website on
 >     bitbucket.

For practical purposes that's what we already have.

 >     This will remove in one stroke a lot of info that is aged and
 >     wrong. Just supply the very necessary information possibly by
 >     lifting over the valuable pages from the old web.

The effort is in choosing "valuable".  It would be just as easy to
create an "unmaintained and likely inaccurate hierarchy" on the current
site and move unreliable pages into that.  (I propose "HereBeDragons"
for the name of the top directory of that hierarchy. ;-)

 >   - Stop providing binary packages. They can be built from
 >     source. The storage problem is removed and with no activity
 >     there will hardly be any releases after all.

Storage is a one-off; I don't think it's difficult to fix.  The bigger
issues are domain-maintenance things like DNS, which I really need to
get off of Tux.  Sandy W. is still handling the registrar stuff.

BTW, there is hardly "no activity" in packages.  In fact people are
committing to packages quite regularly.

 >   - Don't know what to do with the tracker. It could be moved into
 >     the bitbucket issue tracker but I fear that will be much work
 >     and we will loose info. Maybe if can be dumped in some format
 >     for reference and new issues handled at bitbucket.

The tracker is actually zero-maintenance, and I use it.  I could check
the access log if you like.