~samwhited

Atlanta, GA

https://blog.samwhited.com

~samwhited/public-inbox

Last active 4 months ago

~samwhited/mellium-devel

Last active 5 months ago

~samwhited/mellium-patches

Last active 5 months ago

~samwhited/mellium-announce

Last active 5 months ago

~samwhited/mellium-discuss

Last active 5 months ago

~samwhited/soquee-announce

Last active 5 months ago

~samwhited/soquee-devel

Last active 5 months ago

~samwhited/soquee-discuss

Last active 5 months ago

~samwhited/patches

Last active 1 year, 4 months ago

~samwhited/terraform-provider-sourcehut

Last active 1 year, 7 months ago
View more

Recent activity

Re: Building with multiple language versions a month ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

FWIW, the last time I caught something like this was very recently. I
always support the last two releases of Go per their support policy, and
recently found a bug that occurred because of a change to the standard
library in Go 1.15. This also isn't a one off, it's fairly common for me
to find minor breakages between versions, especially in more complicated
packages like the net package. The recent preemption changes a version
or two ago also caused a lot of issues to be found that I wouldn't have
seen if I weren't running tests on a version that didn't have the
changes as well.

—Sam

On Mon, Aug 31, 2020, at 09:01, Drew DeVault wrote:
> Another option is to not build for multiple language versions. When

Re: Do not rebuild same commit? 3 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

You definitely don't want to prevent a rebuild if the hash has changed
because the underlying source may still be different and the unchanged
patch may react differently with different code in other parts of the
code base causing failures that have now been skipped.

—Sam

On Tue, Jul 14, 2020, at 08:32, Drew DeVault wrote:
> Also, after you merge or rebase commits from your feature branch to
> master, their hash changes. So now we're deep comparing commits, and
> we have to store the full patch somewhere instead of just the sha to
> know that we've already built it.
>

Re: RFC: Antipolitical Software Manifest 3 months ago

From Sam Whited to ~sircmpwn/free-writers-club

If you have more than 1 person working together on something, it's
political. Pretending to be a-political is itself a political statement.
You can't escape it by putting something in your license. License
proliferation and using it to enforce your political beliefs (which are
apparently that software should not be a force for change in the world,
which is itself a political belief) is probably much more dangerous than
the Rust team including a BLM banner on their site or whatever it is
that's made you write this.


—Sam

On Sat, Jul 4, 2020, at 08:25, Philipp Stanner wrote:
> Hi!

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

I would find any of these alternatives acceptable as it would still
allow me to keep all of my projects in one place, while discouraging
proprietary projects (which I sadly still have a few of that I either
can't or am not interested in open sourcing for one reason or another,
but which I'd like to be at least source-available).

—Sam

On Thu, Jun 4, 2020, at 13:44, Jordan wrote:
> With that being said, I do have a couple of ideas to maintain the foss
> spirit of sr.ht while allowing developers to use their choice of
> license. Sr.ht could allow for only foss repos and projects to be
> listed on the hub as highlighted projects. The search feature could
> filter results based on its license; foss only are searchable by

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

On Fri, May 29, 2020, at 10:00, Wolf480pl wrote:
> IOW, adding a LICENSE file to a non-copyrightable work is a no-
> op, right?

It is definitely a no-op, but it still seems confusing at best and
misleading at worst. I'd definitely think twice about putting a CC-0 on
my repo, then also saying somewhere "please ignore the license, it's
just there so that we can make this public". This particular line of
inquiry doesn't really matter though since Drew said he'd make an
exception for it.

—Sam

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

Another quick question:

What about repos that are not actually copyrightable? For example, I
maintain a list of folk dances (some that I have written, some by other
callers). In the U.S. at least these are not copyrightable even if
you're the author of the dance, so a license like CC would not apply.

—Sam

On Thu, May 28, 2020, at 21:07, Drew DeVault wrote:
> I'm looking for user feedback on a set of proposed changes to the
> terms of service. You can read the full diff here:
>
> https://paste.sr.ht/~sircmpwn/c5516b2c64466b2381710092af37453ce204d2b9

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

On Fri, May 29, 2020, at 00:23, Drew DeVault wrote:
> No, I haven't made up my mind, and I am receptive to feedback. I'm
> just saying that negative feedback from a few people was expected, and
> is not the only criteria which will make the decision.

Ah yes, of course. I apologize if I implied that I thought that just by
providing negative feedback it would sway you, I just wanted to provide
some feedback like you asked and try to explain why I would no longer be
able to use Sourcehut. Hopefully it will be useful to you as you make
your decision.

Thanks again,
Sam

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

On Fri, May 29, 2020, at 00:12, Drew DeVault wrote:
> Then I'm afraid you would have no recourse under these terms. Not
> everyone is going to come away happy here, I am well aware that some
> users are not going to find these changes tolerable.

May I ask, the way this response was phrased sounded like you've already
made up your mind and asking was just a formality? If so fair enough, I
just wanted to provide feedback like you asked.


> You could use unlisted repositories in this case.

Ah yes, I did forget this was supported, this specific case would be
okay then.

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

On Thu, May 28, 2020, at 23:57, Drew DeVault wrote:
> You should just make them open source :) This is exactly the kind of
> repository that would be affected by these changes, by design. You can
> make software open source without committing to its maintenance, your
> logic doesn't follow here.

I don't want them to be open source because I don't want them
redistributed or because I'm not sure what if anything I'm going to do
with them yet. I may open source them in the future, or I may not.
However, I may still end up wanting them to be public.

Another example I just thought of is Go libraries we maintain at work: a
number of them aren't open source, but Go code has to be public to be
redistributed (ie so that go get can fetch the repos). If I wanted to do

Re: Discuss: proposed changes to the SourceHut terms of service 4 months ago

From Sam Whited to ~sircmpwn/sr.ht-discuss

I would be incredibly disappointed if these changes were applied.

While I only have a handful of proprietary things on Sourcehut, and
they're all private repos for now, at some point I might want to make
them public. Not to open source them, but to make sure that anyone who
uses the software can build it themselves and know exactly what code
they are running (even though they still don't have the right to
redistribute that code or the binaries) or because I do not plan on
maintaining them anymore and want users to have the source code so that
they can continue to support their own internal installs.

I also have a handful of projects (none of which I've moved to Sourcehut
yet, thankfully) that do use licenses that are not OSI approved. These
are mostly joke projects or small experiments that use silly licenses