Follow

I have been a bad open source maintainer. It's not one of my usual hats, but now that I have it I will endeavor to be better at wearing it.

now has a new code repo at gitlab.com/brutaldon/brutaldon from which I plan on handling any new code contributions.

I'll get some docs together tomorrow around a code of conduct for the project and contributor guidelines and such.

If you are a brutaldon user and/or a python programmer who would like to see some changes in brutaldon, swing on by!

:blobpats:

@djsundog @z @Truck Hey, y'all.

If you may have noticed, I'm Alexis on #thetubes™️. I actually maintain a Brutaldon instance over on brutal.werefox.dev running in a docker container that I composed myself.

I would absolutely love to migrate the source remote from where I currently have it to here, and since I actually have experience with Python and Django, I've been seriously looking to find a reason to actually update and maintain this project. This might be a good reason.

@alexis @djsundog @Truck adding a Dockerfile was going to be my first suggestion actually!

@alexis @z @Truck

I would adore having you join the project and take it in hand to any degree you'd like! I was the maintainer of last resort when the original author decided to move on, but I am definitely not the best suited person for the job. It sounds like you very well might be though.

do you have a gitlab.com account I can invite into the project? 😍

@djsundog @z @Truck I don't, but I do have a Gitea instance. I can look into making in a while in a bit here. I will certainly put it on my list of things to do, since I just finished a move and am still getting settled. :blobfoxdead:

@alexis @z @Truck no hurry - I've been sitting on my butt not getting this much done for months, but yeah, awesome - I am excite!

@alexis @djsundog @z

That is AWESOME. I also have a gitea instance which I was planning to use for my expiriments with this, which should begin ... "sometime soonish? when I have healed enough."

(Which would require explanation of why I need to heal, which is long, so short version: "I need to heal, so things are in delay.")

One thing I definately need to fix soon is the fact that I can't authenticate via the browser I use currently (badwolf.) I need to debug that (:

I'm also cool with docker, so long as we also maintain instructions/support for NOT using containers. As, well, I don't think setting a container up on a small allwinner A20 device should need a container layer (:

@Truck @djsundog @z oh, absolutely. The original project just uses a Django instance, so that's just a pip install through Python. I see no issues with maintaining that.

@alexis @Truck @djsundog when you dockerized it, did you swap out the SQLite db for a separate DB image or anything?

@alexis @djsundog @z

This is very cool (the discussion.)

Ok: so - if I'm not mistaken, some of us will use our local gitea envs for our local work/tests, and the main will be at djsundog's gitlab - and we could have the bug reports there, etc?

(I should go look and get an account etc.)

@Truck @alexis @z

I figured it was easier to have a commonly used hosted git forge than trying to get potential contributors to all sign up for a self-hosted one but I am completely open to any other arrangements y'all would like to set up - I'm inclined to just let y'all drive tbqh ;)

@djsundog @alexis @z

I think that's a very good idea, yes. My gitea is ... well, sort of mine (: and not exactly public.

Also as I understand it, mntmn moved various reform2 things from gitea to gitlab because gitea's ability to run CI pipelines is not exactly state-of-the-art. So if we'd need that for testing, it's better to have this.

I just like having a local that I can mess with. (I do a LOT of branching. Some people REALLY don't get branching. They're more used to the svn workflow. I dumped that as soon as I realized how I could branch for each idea... BUT that also isn't the greatest for collaboration. So ... "Truck on his own, doing truck things, and contributing when the truck things are more or less ready for public consumption" is a good way to go, I think.

Of course for work I'm doing the whole SVN-style gerrit mess, with JIRA tickets required and so on, so: I'm flexible (:

@Truck @alexis @djsundog Not trying to be prescriptive if it works for you but is there a reason to not just consolidate all work into the GitLab repo and use feature branches to do dev?

@z @Truck @djsundog I'm cool with either way, honestly. I think the simpler version would be to just do GitLab, but it's not really a big deal to me.

When I used docker I kept sqlite at the time to ensure compatibility, I believe. I would not mind at all moving that to something like Postgres.

@z @alexis @djsundog

Essentially, that's what I'll be doing. Just - the feature branch will be visible to me on my local gitea.

See "another post in this thread" as for why this is probably the best thing for me to do. (Short version: My workflow, locally, uses a LOT of branches, and I can 'consolidate' before pushing.)

@Truck @alexis @djsundog do y'all want a project board to help track/prioritize issues? I don't think this project really needs it but I'm a tech lead at the day job and so I'm comfortable facilitating something like that if y'all want it.

@z @Truck @djsundog I've got a kanboard instance we can use if y'all are interested tbh

@alexis @z @djsundog

OOoh I am! Let's see what the others say, as there's already - what I assume - is activity over on the gitlab - but: yes. I work well with Kanban.

@Truck @alexis @djsundog I'm not especially particular, but I would prefer to use the GitLab board so that it all stays in one platform. I'm not really familiar with Kanban , but as long as it can integrate with the GL merge requests I wouldn't object to using it. Here's the really minimal board I set up in GL already:

gitlab.com/brutaldon/brutaldon

(Y'all may only be able to see the open/close columns without being on the project team?)

@z @alexis @djsundog

Kanban is the use of cards or pieces of colored paper or similar things on a wall to mark tasks. It originated in Japan. It's benefits are, when used non-virtually, there's a bit of a sense of accomplishment as you see things PHYSICALLY moving. That's lost with the virtual parts, but there's still good things that happen with it.

It's worth giving it a shot for organizing tasks.

It is visible, but that may be because I've applied to BE a contributor, though that hasn't been accepted yet.

@djsundog good to hear brutaldon is still alive. Is there a list of maintained instances floating around anywhere?

@liaizon I do not know of such a list, but I am running it on brutaldon.org/ for anyone who just wants to use it without having to deal with hosting it.

@djsundog Do yall take patches by mail? Gitlab (or more precisely: Cloudflare) won't let me log in from my desktop machine, because I guess I'm not using one of the browsers sanctioned by the High Committee.
So that means no pull requests.

@csepp we can certainly try, although I cannot guarantee timely processing of your submissions because I am full of slack this weekend. however, send them to sundog@reclaim.technology and I shall endeavor to get them handled at some point in the not so distant future.

Sign in to participate in the conversation
reclaim.technology

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!