I think, if this is for the purpose of having an homogeneous permission
system across all the parts of srht, it's a really good idea.

Maybe git could be out of this because granting access only for people
you want to see the repository when it's private is enough (but keeping
the visibility field), but otherwise, a perfect idea.

>> I have been very conflicted about making that move myself. As on one
>> hand, I really want this project to continue and think my go skills
>> could be sufficient, but on the other hand I totally lack any experience
>> in maintaining an open source project and I am afraid I don't have the
>> time right now to learn it on the job. So I am glad you did.
>
>I felt quite similar, but thought you have to start somewhere and it's
>better for aerc to have an inexperienced, but willing maintainer, than
>none at all.

I think, if you're willing to put the effort and the time to an open
source project being the maintainer (an inexperienced one), some of the
veterans would help if you need it. You just have to ask!

>just wanted to let the avid reader of this mailing list know, that I
>applied to become the maintainer of aerc. If Drew agrees to it, I intend
>to keep everything as transparent and open as it is right now, and I
>intend to reduce the number of open issues, in order to give aerc a new
>release after more than 9 months in the hope to make this great mail
>client even better. (Especially when it comes to PGP and Docs.)

Nice! Hope Drew agrees!

Hello all!

Yesterday I spent a few hours doing some initial documentation for the
Husky project. I tried to keep it really simple, but at the same time,
with all the context I could for newcomers.

The documentation can be found at
[man.sr.ht/~captainepoch/husky-man][1].

For now, the section that is most completed is the [Contributing][2]
section. Again, this is an initial version, it can be changed.

The [Building][3] section will be completed once I make the changes I
want in the application files. For now, it's empty. Stay tuned for news.

Hello there!

So, after thinking about the project and experiencing weird bugs while
using the application, I decided to take the step to take a look at the
application and maintain it.

I already talked with the actual maintainer and he is alright with this,
so this will be the new home of Husky!

I have still to take a few things into how I would like to drive the
development of the application, but it will be an email-based workflow,
that's why the project will be hosted at Sourcehut.

There're already two mailist:

Oh, hi!

> Just your neighborhood list admin with a reminder that you should write
> something for your blog! If you're unsure of what to write, start
> keeping a list of ideas as they occur to you, and when you're in the
> mood to write, you'll have ideas at hand.

Thank you, Drew, really good advice. And you're right. I had a list with
topics, but some of them weren't good enough for a post, so I ended
thrashing the list out...

But sure, I'll be following this advice from now on!

Cheers, everybody!

Hey!

> Drew, thank you for for setting up this list. I've always wanted a
> community to share my drafts with, and I'm excited about finding other
> technical blogs to follow.

Yeah, thank you, Drew! I noticed this list while lurking a bit :P


> I'll humor myself. My name's Jakob

Nice to meet you, Jacob :)

> and I like to write about

On Fri, Jul 12, 2019 at 03:13:43PM +0000, Simon Ser wrote:
> On Friday, July 12, 2019 5:45 PM, Drew DeVault <sir@cmpwn.com> wrote:
> > Currently, only the mailing list owner can export the entire archives as
> > an mbox file. Should I make this option available to everyone? List
> > admins, do you have an opinion?
>
> +1
>
> What would be the drawbacks of doing this?

If it's a private project discussed in a private list, the list
shouldn't be allowed to be exported. If the list it's public, I don't
see the problem.

I didn't thought on patching the pacman.conf
file, but it works (now the build fails for another
thing).

Thank you for the patch!

>I don't know if builds.sr.ht has its own way of enabling multilib repo,
>but you can always use the generic arch way of doing it,
>i.e. uncomment the right lines in /etc/pacman.conf
>
>I made an example builds.sr.ht job that does that and then installs
>lib32-zlib. (Then it also prints the content of /etc/pacman.conf,
>which you don't have to do, I just wanted to see if the patch
>applied correctly).

I looked at the doc but didn't see anything there...

>Maybe you need to enable the multilib repo?