Re: XEmacs at a crossroads

>>>>> Stephen J. Turnbull writes:
> Some of your ideas are more directed at improving the project than at
> reducing maintenance cost and I'd like to highlight those.

Yes, maybe we can improve and rationalize at the same time as we remove
unnecessary tasks and free resources . Let's see ;-)

[ About xemacs-patches ]
> Pull requests are worth discussing, since that would represent a
> modernization of our workflows, and might make it easier to contribute.

I haven't really checked bitbucket but I'd would think that pull requests
would be a possibility for the contributor to choose. If you would like to
contribute and get the commit inspected before pushing you could do a pull
request. So it would zero cost for us at the moment.

For developers who would like to push directly that would still be possible
and IMHO the preferred way for this size of a project.

So it is more like an answer to anyone missing xemacs-patches - How do I get
my patch inspected: Answer: Do a pull request.

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

Remember we are at the crossroad. Looking into the mirror and extrapolate that
into the future isn't IMO the right thing when the core developers, you and I
included, more or less unanimously said there is no time for doing anything in
the foreseeable future.

What I'm also asking is our opinion on if this service is really worth
maintaining. If we drop it we would at least theoretically free resources to
do other stuff. [1][2]

[ About the web xemacs.org ]
> The effort is in choosing "valuable".  It would be just as easy to
> create an "unmaintained and likely inaccurate hierarchy" on the current
> site [...]

There will be one service less to maintain since everything will be hosted on
bitbucket. It will also be easier if things would take of again since the fork
from bitbucket will have all without thinking about xemacs.org at all.

> Storage is a one-off; I don't think it's difficult to fix.

This is what the at the crossroad is all about I think. The storage problem
has been there for what, a year, two years? Is it important? Yes. Have we
fixed it? No. So let's remove the problem because it will not be easier in the
future.

> 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.

Well I don't understand the problem probably because I just run my own home
server. I bought the domain address a few years ago, configured the DNS in the
providers control panel and then I have payed the bills for the name. That is
it. What more do we need?

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

See at the crossroad argument above.

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

No that is not necessary. I feel that there is valuable info in the tracker
for anyone who would like to hack on XEmacs so it would be terrible to loose
that info. How often that is accessed now is not important.

So if you don't feel you loose hours that could be spent better it will be a
valuable service to keep I think.

Yours Mats

Footnotes: 
[1]  Well, this argument to free resources to put into work
elsewhere is I guess applicable to all of this discussion. 

[2] I checked the package smoke test just now and realized that it has been
hanging since the end of October. It sort of tells you the state of affairs
right. I haven't noticed. No one has complained. I need to spend a few hours
(maybe) getting it up and running again.