I chatted briefly on mastodon about it, but I suppose I should reply to
this list too. I'd like to see appalachian.town not just shut down
because it had a bus factor of 1 as well.

We could get a few people together to keep running it as is, giving
everyone else plenty of time to migrate if they choose, or we could
potentially approach existing groups and ask if they'd be interested in
taking on the domain. For example, my main account is over on
social.coop which is, as the domain suggests, already cooperatively run
and very successful. They could likely give us some pointers or even
help us run the instance temporarily while we figure out bylaws,
responsibilities, whether it's feasible, etc.

—Sam

XMPP is extremely widely  used, has a plethora of working clients and
servers, and meets most of the requirements you outlined in your thread.
If by "failed" you mean "Google Talk doesn't use it anymore", fine, it
failed, but otherwise it seems to be succeeding quite well.

We need something new in terms of the app perhaps, but there's no reason
that can't be built on an existing network that's already good enough
(like Snikket is trying to do, or Quicksy, or any other "future app"
which could be the next thing).

—Sam

On Wed, Apr 7, 2021, at 15:06, Drew DeVault wrote:
> XMPP is a mess, and it has failed. A workable system cannot be pulled

I know you (Drew) have mentioned that you don't personally love XMPP,
but I'd wanted point out that some systems built on top of it already
meet most of the requirements you outline in this post. In fact, while
reading the post I briefly thought you were specifically describing XMPP
and leading up to mentioning it as the protocol on which to build the
"next chat app".

The protocol itself has its problems (XML is a nightmare, extensibility
causes problems, etc.), and of course it has all the problems that come
with a federated platform (you either become so bloated that there can
only be one or two implementations like Matrix and it ends up defacto
centralized, or you remain distributed but you end up with clients that
support different optional features and the fallback can be difficult)
but overall it's firmly in the category of "good enough" in my opinion

My manifests are all submitted by Git, I don't put them in manually.

—Sam

On Tue, Dec 1, 2020, at 21:48, jack@jpgleeson.com wrote:
>
> Would using the notes box when entering the manifest work for you
> here? It puts the text just below the id of the job, not as
> immediately readable as the headers above, but definitely apparent.
>
>

-- 
Sam Whited

Hi,

I'd like to suggest adding a title to the build pages pulled from
the manifest, or possibly just the build manifest filename somewhere
on the page.

Some of my projects launch several builds that run in parallel and have
similarly named tasks, so the pages appear the same and I can't tell
which builds I'm actually looking at. Having it say "Integration Tests"
or "Unit Tests" at the top (or whatever the case may be) would be
extremely helpful.

I'm posting here for discussion per the instructions on the issue
tracker.

It won't help you with hating having a license at all, but you might be
interested in the Center for Plain Language
(https://centerforplainlanguage.org/). The TL;DR is that there's nothing
magical about legalese, and no reason to continue using it, people just
do because they don't want to risk their words being twisted and used
against them when they could use a tried and true formulation that's
been litigated and is well understood. The Center for Plain Language
advocates for using normal language in the law.

—Sam

On Sun, Nov 8, 2020, at 15:36, ValleyKnight wrote:
> I can't stand license-speak, I can't stand copyright, and I truly
> can't stand having to use a license at all.

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

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

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!

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