squash and merge, license documentation, "size" documentation

[Clemens Lang]

Hi Perry,

On Fri, Aug 17, 2018 at 09:44:47AM -0400, Perry E. Metzger wrote:
> As many of you are aware, I merge a significant fraction of the pull
> requests these days.

Thanks!

> 1. We have squash and merge disabled. This means that I often have to
> coach people through doing the squash on their own. If we enabled
> that, often it would not be necessary because I could do it for them.
> Is there a good reason we have that disabled?

IIRC we had concerns that the topmost available from the list of (merge,
squash, rebase) will become the default. We definitely don't want merge
commits, so we disabled those, but that makes squashing the default. We
prefer rebases over squashes.

On the other hand, it seems that GitHub does remember your last choice
per repository, so we could just enable squashing and assume all our
developers that click the merge/squash/rebase button know what they are
doing (and if they don't, the squash button is not nearly as bad as the
merge button).

Considering this situation, I'd be willing to enable this for you if you
don't see mis-use as a big concern.


> 2. The guide has poor documentation on what license strings are
> acceptable, and port lint doesn't check that the license string is an
> acceptable string. If these were fixed, it would be much easier to
> direct people to the correct license string etc.

Agreed, it would be nice if that were better. As a first stop-gap
measure, we should probably point to [1], which is the script that
processes our license specs.

There was also a discussion to support SPDX license identifiers [2]
instead (or in addition), since those are somewhat standardized and seem
to be emerging as a standard in distribution land.


> 3. There's no real documentation of the "size" parameter to checksums,
> and I'm constantly asking people to add the size. Note that I don't
> think "size" is a reasonable thing to require given that finding two
> files of the same size with the same SHA-2 hash is probably worth a
> doctoral dissertation at this point, but if we are going to require it
> (why do we require it?), it should be documented, and port lint should
> complain that it isn't there, and doing port -v checksums should spit
> it out if it isn't there.

I think the idea of the size keyword is to start to use it to display
download progress bars for servers that do not send a Content-Length
HTTP header (or do not have an equivalent of such a header due to the
used protocol). This is currently not implemented.

'port -v checksums' does generate the size field in newer versions of
MacPorts. Until such a version becomes the released default, I think
it's fine not to require adding it in PRs.

[1] https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl
[2] https://spdx.org/licenses/


HTH,
Clemens