tmux versioning and development

[Helmut K. C. Tessarek]

Hello,

I have a few questions/comments and I hope that Thomas or Nicholas find
the time to reply.

I've noticed that as soon as a release is made the version is bumped and
debug is turned on. I was not even able to turn this off with the
configure option --disable-debug.
So a static binary compiled from git has 4.5 MB while a static binary
compiled from a release tarball has close to 2 MB.
People should be able to choose, if they want debug info or optimized code.

Setting the version to 2.4 is _very_ confusing. As it is now, people
think they are running release 2.4 while they're not.

Other projects use versioning like:

2.4-dev
2.3-<number of commits since release tag>-<7 character long git hash>
(e.g.: 2.3-17-76a9e6f)

The development model does not follow a pull request model, nor does it
seem to be git aware at all.

People send patches and their code is commited by either Nicholas or
Thomas, which is fine, but the author field should still have the name
of the coder. It has not. Instead the author is mentioned in the commit
message. I don't want to complain, but this looks very strange, as if
the developers have no idea how git works.

One of the reasons why I haven't sent any patches is, because I don't
want to write code, test it, send a patch file via git to a mailing list
(which is another annyoance) and then my name does not even show up as
the author. I don't know why pull requests are such a problem.

Anyway, it certainly sounds that I only have negative feedback. This is
not the case. tmux is a great product and I use it daily. I just wanted
to comment on a few things I just don't understand. Maybe the developers
can shed a light on these things.

Cheers,
K. C.


--
regards Helmut K. C. Tessarek
lookup http://sks.pkqs.net for KeyID 0xC11F128D

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

[Nicholas Marriott]

Hi

On Wed, Oct 12, 2016 at 12:27:01PM -0400, Helmut K. C. Tessarek wrote:
> Hello,
>
> I have a few questions/comments and I hope that Thomas or Nicholas find
> the time to reply.
>
> I've noticed that as soon as a release is made the version is bumped and
> debug is turned on. I was not even able to turn this off with the
> configure option --disable-debug.
> So a static binary compiled from git has 4.5 MB while a static binary
> compiled from a release tarball has close to 2 MB.
> People should be able to choose, if they want debug info or optimized code.

No, I want people using Git master to build with debug symbols. I don't
want bug reports without symbols.

>
> Setting the version to 2.4 is _very_ confusing. As it is now, people
> think they are running release 2.4 while they're not.

People don't know when they've built from Git and when they haven't? I
don't think this is a real problem.

> Other projects use versioning like:
>
> 2.4-dev
> 2.3-<number of commits since release tag>-<7 character long git hash>
> (e.g.: 2.3-17-76a9e6f)
>
> The development model does not follow a pull request model, nor does it
> seem to be git aware at all.
>
> People send patches and their code is commited by either Nicholas or
> Thomas, which is fine, but the author field should still have the name
> of the coder. It has not. Instead the author is mentioned in the commit
> message. I don't want to complain, but this looks very strange, as if
> the developers have no idea how git works.
>
> One of the reasons why I haven't sent any patches is, because I don't
> want to write code, test it, send a patch file via git to a mailing list
> (which is another annyoance) and then my name does not even show up as
> the author. I don't know why pull requests are such a problem.

People are credited in the commit message if they send a patch and I
know their name (that is, I have a real name to credit and not an
account name or alias).

> Anyway, it certainly sounds that I only have negative feedback. This is
> not the case. tmux is a great product and I use it daily. I just wanted
> to comment on a few things I just don't understand. Maybe the developers
> can shed a light on these things.
>
> Cheers,
> K. C.
>
>
> --
> regards Helmut K. C. Tessarek
> lookup http://sks.pkqs.net for KeyID 0xC11F128D
>
> /*
> Thou shalt not follow the NULL pointer for chaos and madness
> await thee at its end.
> */
>

> --
> You received this message because you are subscribed to the Google Groups "tmux-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
> To post to this group, send an email to tmux-...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Nicholas Marriott]

On Wed, Oct 12, 2016 at 05:34:06PM +0100, Nicholas Marriott wrote:
> Hi
>
> On Wed, Oct 12, 2016 at 12:27:01PM -0400, Helmut K. C. Tessarek wrote:
> > Hello,
> >
> > I have a few questions/comments and I hope that Thomas or Nicholas find
> > the time to reply.
> >
> > I've noticed that as soon as a release is made the version is bumped and
> > debug is turned on. I was not even able to turn this off with the
> > configure option --disable-debug.

I think you made a mistake here: --disable-debug works fine in Git, we
only change the default.

[Thomas Adam]

On Wed, Oct 12, 2016 at 12:27:01PM -0400, Helmut K. C. Tessarek wrote:

> Other projects use versioning like:
>
> 2.4-dev
> 2.3-<number of commits since release tag>-<7 character long git hash>
> (e.g.: 2.3-17-76a9e6f)

Whilst it's possible to easily include the output of git-describe into the
version string at build time (I do this with other projects which I run), it's
not really necessary here.

> The development model does not follow a pull request model, nor does it
> seem to be git aware at all.

Of course not, it's an OpenBSD project which is using CVS.

> People send patches and their code is commited by either Nicholas or
> Thomas, which is fine, but the author field should still have the name
> of the coder. It has not. Instead the author is mentioned in the commit
> message. I don't want to complain, but this looks very strange, as if
> the developers have no idea how git works.

This can't happen, and you're misunderstanding how the workflow happens.
You're not the first one to either. Tmux is developed as part of OpenBSD.
It's in the base system. OpenBSD uses CVS for all of its source code
management and they have their own servers.

As with most projects in OpenBSD, if it's popular enough then a portable
version of it is produced to run on Linux/Solaris/{Free,Net}BSD/Mac. At that
point, the portable version is free to live wherever; in the past we housed it
on SF (using SVN). Now we're using Git, we've migrated to Github.

But once there, people are free to download and use it, and since it's GH they
can now also send through issues and pull-requests. The thing to bear in mind
is that it's a collection point only for feeding BACK INTO OPENBSD. I put
this in capitals so you understand its importance. Commiting *back* to
OpenBSD relies on Nicholas doing so as the commiter, and hence he is the
author. This is why he has to attriute patches to authors that way.

When changes go into OpenBSD then they're synched to tmux-portable on Github;
again, the attribution has come out of CVS which will almost always be
Nicholas (or someone else with commit-bit rights to the CVS repository).

> One of the reasons why I haven't sent any patches is, because I don't
> want to write code, test it, send a patch file via git to a mailing list
> (which is another annyoance) and then my name does not even show up as
> the author. I don't know why pull requests are such a problem.

They're not a problem. You just can't have your name as the author directly
in the commit since we don't use Git like that as it's all coming from
OpenBSD.

If you want to find out who did what, grep the git logs.

We do use PRs, by the way, but only as a means of gathering patches together.
Should you want to do that rather than using git-send-email, that's OK too.

The only time that you'll see commits in the portable version directly is when
I am fixing up things specifically to do with tmux portable, or there's a
change to the documentation, or I am doing a release of tmux, for instance.

Hope this helps.

-- Thomas Adam

[Helmut K. C. Tessarek]

Hello,

Thank you for the reply.

On 2016-10-12 12:34, Nicholas Marriott wrote:
> People don't know when they've built from Git and when they haven't?
> I don't think this is a real problem.

It only works for people who build it themselves. But since there is
only 1 realease every year, a lot of port systems (I maintain the
MacPorts tmux port) introduced git releases at a certain level (not git
master), and these dev releases are more frequent than the releases.

So yes, if you compile it yourself, you know that it was some commit
point after the 2.3 release, butthis is all you know. How would you do a
bisect, if you even don't know the build number?

You want debug symbols but don't care when a problem occured (at which
commit point)?

> People are credited in the commit message if they send a patch and I
> know their name (that is, I have a real name to credit and not an
> account name or alias).

Well, it's the author's choice to use an alias or their real name, but
git does use an author field for a reason. Author and commiter do not
have to be the same person. Git can also make use of signed-off-by tags.

In any case, the way development is handled is very untypical to any
project I've ever seen. That's why I'm so puzzled by it.

[Helmut K. C. Tessarek]

On 2016-10-12 12:40, Nicholas Marriott wrote:
> I think you made a mistake here: --disable-debug works fine in Git, we
> only change the default.

I'll try again, but it did not work when I used it yesterday. Maybe I
have to delete the .cache dirs or start completely from scratch.

I'll check it out.

[Helmut K. C. Tessarek]

Hello Thomas,

On 2016-10-12 14:46, Thomas Adam wrote:
> This can't happen, and you're misunderstanding how the workflow happens.

Yes, this is certainly true. That's why I asked. :-)

> You're not the first one to either. Tmux is developed as part of OpenBSD.
> It's in the base system. OpenBSD uses CVS for all of its source code
> management and they have their own servers.

That explains a lot.

> But once there, people are free to download and use it, and since it's GH they
> can now also send through issues and pull-requests. The thing to bear in mind
> is that it's a collection point only for feeding BACK INTO OPENBSD. I put
> this in capitals so you understand its importance. Commiting *back* to
> OpenBSD relies on Nicholas doing so as the commiter, and hence he is the
> author. This is why he has to attriute patches to authors that way.

Ok, I didn't know that. This also explains the way how dev is handled.

> When changes go into OpenBSD then they're synched to tmux-portable on Github;
> again, the attribution has come out of CVS which will almost always be
> Nicholas (or someone else with commit-bit rights to the CVS repository).

It all starts to make sense.

> We do use PRs, by the way, but only as a means of gathering patches together.
> Should you want to do that rather than using git-send-email, that's OK too.

Yes, on some systems git-send depends on additional libs that are not
always there. I happened to experience a dependency nightmare several times.

> Hope this helps.

Yes, I really appreciate the time for the elaborate explanation. Thank you.

[Helmut K. C. Tessarek]

On 2016-10-12 15:35, Helmut K. C. Tessarek wrote:
> In any case, the way development is handled is very untypical to any
> project I've ever seen. That's why I'm so puzzled by it.

Never mind. Thomas explained the OpenBSD dev process. It makes sense now.

[Ethan Raynor]

On Wed, Oct 12, 2016 at 5:27 PM, Helmut K. C. Tessarek
<tess...@evermeet.cx> wrote:
> One of the reasons why I haven't sent any patches is, because I don't
> want to write code, test it, send a patch file via git to a mailing list
> (which is another annyoance) and then my name does not even show up as
> the author. I don't know why pull requests are such a problem.

I agree - the notion that a project being managed in 2016 should work
in these, frankly, draconian ways is stupid.

Fair enough, I supose, if this info is embedded in the git commit log
rather than as an author but it can't be that difficult to provide a
web page with a list of people who have contributed, can it?

I am sure that even I can provide a script to do this - and would it
be accepted if so? Having a web page with this on it would look nice
on the tmux website, no?

I don't know why Nicholas or Thomas aren't listening or thinking about
these things because I feel as though people do care how they are
represented with a project. tmux is a popular project!

That's also why I want to really take over the release engineering of
tmux - I think - frankly - I can do a much better job of it. I am not
happy at all with the way releases have happened for the past two or
three for tmux.

Ethan

[Nicholas Marriott]

Ethan -

You have made no code contributions to tmux and made no bug
reports. Until that changes - even if there was a release engineering
position going, you wouldn't be a candidate.

In 10 years, nobody who has sent patches has complained about how they
are credited. If someone sends code and does have a suggestion, I will
see what I can do - within reason - to accommodate them. Until then,
surely you can think of better ways to contribute than complaining about
how other people's work is credited?

It should be clear by looking at tmux development that most does now go
through GitHub PRs and issues, and I am - time permitting - happy to
work with people in the way they prefer. Using email is just a
preference, it is not a rule.

Please bear in mind that tmux is a volunteer project and that we are not
required to do things the way you think they should be done.

[Ethan Raynor]

On Thu, Oct 13, 2016 at 4:32 PM, Nicholas Marriott
<nicholas...@gmail.com> wrote:
> Ethan -
>
> You have made no code contributions to tmux and made no bug
> reports. Until that changes - even if there was a release engineering
> position going, you wouldn't be a candidate.

I don't have to make contributions to see where the deficiencies are,
Nicholas. What I think we should do is open up the release process to
more than one person - it's quite clear it needs more than one person
to do it - that's a good thing isn't it? I'm willing to help with
that.

Ethan

[Nicholas Marriott]

That is not how it works and you must be aware of that. You don't just
walk into an open source project knowing nobody and offering nothing,
you need to get involved and do some work, then you get the
responsibility. The next release won't be for six months, you have ample
time to get going.

[Nicholas Marriott]

I think you have some strange idea of what the release process
involves. The release is easy. A small project like tmux does not need
more people with some sort of special release engineer hat.

What we could use is a more testing, formal or informal, in the time
between releases. If we come up to release time and there are 100 open
issues on GitHub, we are not going to do the release until they are
looked at. Or if someone was maintaining a good test suite, we would
wait until they were happy.

But neither of these is the case.

If those 100 issues were all opened by one person, we might want to
bring them into the project. But nobody is doing that.

I don't use tmux releases and I don't really want to spend my time
fussing about them, but if you open good bug reports I will look at
them, and if they are fixed before making it into a release... well,
then releases are better.

I don't think we need to discuss this any further.