Re: [screen-devel] screen maintainer

[Amadeusz Sławiński]

On Wed, 2 Apr 2014 21:27:27 +0200
Axel Beckert <address@hidden> wrote:

> > > > * removal of features which didn't seem useful or could be
> > > > replaced
> [...]
> > > Please list which features you removed, so that people at least
> > > have a chance to object.
> [...]
> > From fast comparing between source files:
> 
> Thanks for that list. At least it removes some of my fears. :-)
> 
> > multiuser - seemed more like security risk to me
> 
> Do you mean "screen -x" or the "acl*" commands?
> 
> "screen -x" is used quite often by admin groups when e.g. working
> together on the same issue but from different locations. It surely
> would be missed.
> 
> But I've never had use for using a single screen session with more
> than one unix account, i.e. the "acl*" commands. So no crying from
> here there.
> 
> (Once this topic is clarified, I'll write a summary to screen-users to
> see if there's anyone out there who would care.)

-x is still there, but other mail gives convincing case for acls usage

> > braille - couldn't test :(
> 
> I'll ask on the grml mailing list for that. Grml is a sysadmin live CD
> which relies heavily on well preconfigured Zsh and GNU Screen. It has
> quite some blind users and the Grml maintainers care about supporting
> blind users. I suspect that we could also collect some testers for
> braille stuff there. :-)
> 
> > utmp - seemed broken and there is also utmpx?
> 
> I don't really use Ctrl-A L, but I prefer if my shells inside screen
> show up in the output of "w" and think that it's a helpful feature
> (for admins looking at their users :-). I though wouldn't cry too loud
> if that would be gone.
> 
> Doesn't look broken for me though. Works fine for me on Debian Wheezy
> (current Debian stable, ships a screen snapshot from early 2012).
> 
> > nethack - funny, but who really needs it?
> 
> Funny, but does it really hurt?
> 
> It's used by the Grml live CD IIRC. Will mention that on their mailing
> list, too.
> 
> And I already got some comment on that one on a private IRC channel:
> 
> 21:18:22 <blindcoder> "nethack - funny, but who really needs it?"
> 21:18:22 <blindcoder> M E ! ME! ME ! :D
> 
> ;-)

"You may wish for a screen, what do you want?"

> > zmodem - according to wiki some ancient file transfer protocol
> > there may be something else...
> 
> Never used, but maybe helpful when screen is connected to a serial
> console. (Actually I wasn't aware of that feature, sounds useful at
> least to some extent. Should try it while it's still there. ;-)

Ok, from those comments and other mails clearly there are some people
who use most of this stuff (maybe except for zmodem ;).
So it should probably be done some other way instead of direct merge.

> > One of my goals was to make code far more readable, so I reformatted
> > whole tree,
> 
> Sounds sane if done at one point and not distributed over many
> commits. (Haven't checked and I won't argue if there were feature or
> bugfix commits in between. :-)

It was just a matter of running it at some point through reformatting
utility, the only minus is (mentioned in previous talks about release)
that one loses commit history.

> > and also enabled most of features by removing #ifdefs.
> 
> If they weren't enabled by default previously, this may cause some
> build failures on less common architectures or operating systems, but
> that means, it's about time to fix the code of these seldomly used
> features. :-)

Well they were probably used by most like: fonts, double width,
encodings, utf, colors (8/16/256 colors) and more.

> > And believe me it's far more easy to understand what's going on.
> 
> Sounds good. I've had my issues there in the past, too.
> 
> > I want to make sure that screen stays as usable as it is to people
> > who use it, but also would like to see new stuff happening, that's
> > why I started this talk.
> 
> Thanks.
> 
> Just as a summary, my fears come from two directions:
> 
> A) I tend to be used to less commonly used features. (Call it
>    conservative, but old habits die hard. :-)
> 

I certainly understand where it comes from.

> B) I currently maintain Screen in Debian. Debian is a Linux dist…
>    -- scratch that -- Debian is a free software distribution that
>    officially runs with at least three different operating system
>    kernels (Linux, FreeBSD kernel and GNU Hurd) and some more, e.g.
>    DysonOS and Illumian are ports of Debian to Illumos and I already
>    got a bug report that something in Screen didn't work there
>    properly. (Permission issue, more packaging related.)
> 
>    It is also one of the Linux distributions with the most officially
>    supported architectures and quite a bunch of not yet or no more
>    supported architectures.
> 
>    Hence I prefer Screen to stay portable as some Debian users (or the
>    Debian build daemons) will surely run into issues otherwise -- and
>    it's currently my fate to get it fixed again. ;-)

Ok, summarizing, let's propose alternative plan.

I can spend time separating patches into something that can be
acceptable for official tree without breaking existing functionality.
But I would need some kind of guarantee that it gets reviewed and
applied, either by myself after getting commit rights and sending it to
mailing list to let people comment on those changes or by some
resurrected maintainer.

So coming back to mail which started it all. I've already offered myself
to do maintaining, is there someone else willing to do this/helping with
patch review or anything else? Because looking at git, project which
has 4 commits in one year (2013) and no release in 5~6 years, looks
basically dead and that's not good sign, especially considering that
there was some interesting patches send in last few years which are not
in official git.

Amadeusz