Yes please.

On Mon Nov 30, 2020 at 12:45 PM EST, Asa Zeren wrote:
> Actually, this brings up another question. The advantage you give in the
> blog post is that the lack of a backlog eliminates the culture of
> "catching up." My question is then how does this do this? If I ignore
> IRC for some time (taking a nap, eating food, focused work, etc) and
> then come back to find several hundred (or thousand) messages (because
> my client has been open), how is this any better than Matrix
> et. al. with a persistent backlog?

You are not expected to read all of them. And most people don't leave
their clients open ALL the time.

On Mon Nov 30, 2020 at 12:22 PM EST, Asa Zeren wrote:
> > You participate in conversations that happen while you're there
>
> The issue I have is with the notion of "while you're there." Is this
> supposed to mean "while you have the irc window open in front of you?"
> If so, I don't see how a conversation could ever start, because if there
> is no ongoing conversation, then there is little possibility of someone
> having the window open, as there is nothing to engage with. Thus, if you
> have something (a question or thought) to post, who would see it?

I keep an IRC window open all day every day and participate in
conversations on and off as I can spare the attention and things are
going on. I can assure you that conversations do, in fact, take place on
IRC.

You participate in conversations that happen while you're there, and
maybe if you step away from the keyboard for a bit you'd read the top
ten or so lines to get whatever context you can before participating.

If it doesn't make sense then I'd recommend just using IRC for a bit so
that you can grok it for yourself.

The git:// transport is deliberately unsupported by git.sr.ht. You need
to use the HTTPS or SSH transports.

Thanks!

To git@git.sr.ht:~sircmpwn/git.sr.ht
   b59ed72..5c21171  master -> master

Using -o skip-ci is the only supported method, and the only method I
intend to support. Third-party software should be updated to support
this.

That's weird, I really have no idea what might cause it.

Are you really running OpenSSL or are you running one of the several
libraries which pretends to be OpenSSL, like LibreSSL or GNUTLS?

The ability to specify the precision of an enum type was ultimately
removed - perhaps the parser or example schemas in go-bare is out of
date. enums and uint/int types are definitely supported in general
terms.