Re: [screen-devel] screen maintainer

[Mike Gerwitz]

[Sent this message originally from the wrong e-mail address---moderators,
you can delete the one from the other address.]


On Thu, Apr 03, 2014 at 01:57:48AM +0200, Axel Beckert wrote:
> > 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.)

I think he means `git blame`; see 8507a32, which is the reformatting commit.
Like you said, that's fine---I had no trouble finding the history for the
code that I needed to look at.

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

While that is certainly great, one of the biggest complaints over the years
I've seen when researching screen is that it's been left up to Debian to
merge the patches (back in the day, one popular one was vertical split
support). I'm certainly thankful for that, but it just works around an
underlying issue.

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

I starting adding test cases for all new code that I contributed to Amade's
repository:

  https://github.com/amade/screen/tree/winmsg/src/tests
  (Some of those are also in the devel branch)

It follows gnulib's test cases; I'm open to a different format. The old code
can be tested as it's refactored, but it relies heavily on globals, so
testing it in its current state is difficult.

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

It would be nice to keep every major feature/change in its own branch as
well, until it's merged into master.

-- 
Mike Gerwitz
Free Software Hacker | GNU Maintainer
http://mikegerwitz.com
FSF Member #5804 | GPG Key ID: 0x8EE30EAB

signature.asc
Description: Digital signature