Re: [screen-devel] screen maintainer

[Axel Beckert]

Hi,

On Thu, Apr 03, 2014 at 01:11:27AM +0200, Amadeusz Sławiński wrote:
> Ok, from those comments and other mails clearly there are some people
> who use most of this stuff (maybe except for zmodem ;).

I just have a rough idea of how zmodem transfer works (and no idea how
screen handles them), but I think that functionality can be obtained
by using Chuck Forsberg's rz/sz tools (the according Debian package is
"lrzsz") on the commandline (e.g. inside screen) instead.

Added an item to my todo list to compare those two implementations.

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

Hrm. How lossy will that be?

Do you mean "commit history" as in "git blame only shows that one
reformatting commit"? (Which IMHO is fine unless it's only very few,
preferable only one commit.)

Or as in "history rewrite" and "git push -f" needed?

I would avoid the latter whenever possible.

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

Debian's configuration:

                    --with-socket-dir=/var/run/screen \
                    --enable-pam \
                    --with-pty-mode=0620 \
                    --with-pty-group=${TTYGROUP} \
                    --enable-rxvt_osc \
                    --with-sys-screenrc=/etc/screenrc \
                    --enable-colors256 \
                    --enable-telnet \
                    --enable-use-locale

You may be right. ;-)

Just had a look at config.h.in. Seems as most of those you listed are
part of the not-SIMPLESCREEN group which seems to be the default already.

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

Jürgen? Sadrul?

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

I can try to upload git snapshots more often to Debian Experimental
(i.e. they get through all the build daemon machinery on all
architectures, but doesn't hurt any release management neither a big
bunch of users (only those who explicitly want to try it).

Apropos: What would be also helpful is a test suite. Even a totally
incomplete one is better than nothing and may find some types of
regressions quickly. But I know that this is anything but easy in a
project with so much history... Wanted to mention it nevertheless,
because I would try to run such a test suite at build time on all
architectures. That way, a bunch of portability issues which don't
result in compile time errors can be found quickly, too.

(Then again, interactive programs are harder to test than simple
programs that just use STDIN and STDOUT...)

> Because looking at git, project which has 4 commits in one year
> (2013) and no release in 5~6 years, looks basically dead

I still disagree on "dead" -- compared to "not very active". But
that's just nitpicking and a different threshold for "dead", I know.
;-)

P.S.: As a distro package maintainer I'd be of course very happy about
separated development and stable branches as Amadeusz proposed and
seems to practise.

                Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | address@hidden  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | address@hidden (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)