# Devuan meet 2022-08-11 @20:30 UTC
Present: fsmithred, golinux, bb|hcb, Hendrick, plasma41, stevelitt
Regrets: Xenguy (unable to attend meetings for the forseeable future)
## Old Business
### golinux
* /documentation solution(s) needed. Since I have pretty much bowed out,
I don't know whether I really have a "vote" anymore but since
disorganization drives me nuts . . . I see two issues . . . current
relevancy and document format. Will expand at the meet. Lots of talk.
Needs a reorginization maybe this weekend . . .
### Xenguy
#### Documentation workflow
* There have been ongoing discussions about this issue, and I am
continuing to consider the best approach to take, in consultation with
other team members.
* Life is 'busy' currently, so patience is required.
* I mentioned to golinux and rrq that I would try to create a list of
specific files, and see what workflow options might be best associated
with each. So will try to get some work done with that between now
and the next weekly meeting.
* I will also continue to leave notes here at the weekly meeting, and
keep an eye on others' notes here also.
* (fsr) Keep art, maintainers, release-docs. Everything else can go into
archive/history/trash.
* (gl) Hopefully we can get together to do that in the next few days.
* (Xenguy) Agreed fsr, this seems to be the way to go. New
contributors who want to improve web site pages can clone the repo,
modify pages, then issue a merge/pull request. Works for me.
## Old Actions
## New Business
### golinux
* Daniel Pocock is in DNG moderation . . . and will stay there. :D
### LeePen NB: I will be away next week.
* Updated packages: util-linux, openvpn, udisks2, main-menu
* There is a [request](http://bugs.devuan.org/701) that we provide
AppStream metadata. Any takers?
### plasma41
* I personally find it hard to follow these documentation discussions in
realtime during the meeting. I know I would benefit from a central
place to share and collaborate in writing on specific issues and
proposed solutions where I can read things multiple times if necessary
and be able to write out a response with the ability to reason about
the topic without having to immediately think up an answer and respond
off the cuff during a meeting where lots of people are talking and
it's hard to think straight.
* To that end, I think it would be very helpful if Devuan created
additional, more focused mailing list where these more focused
topic-specific discussions could take place. As a starting point I
would suggest adding:
* devuan-www@???
* devuan-infra@???
* devuan-patches@???
* (gl) NO MORE MAILING LISTS!
* (hendrik) I find it hard to follow these documentation discussions
in realtime, too. So far using devuan-dev has been suggested while
we taLk. Do those other email lists already exist?
* (plasma41)No, but I'm proposing that they be created.
* (hendrk) We need to pick one.
* (gl) NO MORE MAILING LISTS! We need less not more. More
doesn't fix the problem(s). dyne hosts our mail lists along
with many dyne lists and who knows what else. I would not even
consiider bothering jaromil and alv to request such a
non-essential service.
* (plasma41) For the current documentation discussions I
recommend a devuan-doc list. I'm simply additionally
suggesting lists I for topics I think would benefit from that
form of discussion.
* (gl) Again to (hopefully) drive the point home. We have very
little control over the dyne mail servers. So PLEASE forget
that cul de sac . . .
* (hendrik) I'll use devuan-dev until devuan-doc exists.
* (gl) It will NEVER exist!
* (gl) COMMENT . . . I'm having a deja vu moment. This kind of
thinking is exactly what lead to the www rollout paralysis last
year. Adding another layer of unnecessary infrastructure/complexity
does not actually get things done. Getting things done is what gets
things done.
* (Xenguy) There was doubtless some 'this kind of thinking', but for
the sake of the record, the "www rollout paralysis" you refer to
was primarily caused by the question of how our (wait for it)
**documentation workflow** should be structured. And here we are,
much later, finally coming to grips with this important question :
-)
* (gl) The restructuring of /documentation does not address the
issue of "documentation workflow". That is TBD. It just cleans
up the working environment where it may or may not reside in the
future. I always kept the upgraded files locally on my computer
until release time at which point I moved them to the
appropriate beta branch a few days before the release. Since,
going forward, the work on www will be more collaborative, a
staging area in /documentation may be necessary because the
updates (which should be prepared months in advance) cannot go
into the current beta branch. Oh wait . . . the lights just
went on . . . What is needed for workflow is a daedalus-beta or
d-beta (easier to type) branch to be created in www to work on
the www pages for the next release. DUH! How could I be so
obtuse . . . Have we finally gotten to where we needed to go?
* (Xenguy) re: "The restructuring of /documentation does not
address the issue of "documentation workflow". That is TBD.":
Maybe you're right. It's a fair distinction I suppose. In any
case it appears that we are finally getting around to
addressing the issue of documentation workflow, and that will
be a relief to get settled. re: "separate branch": Yes, we
have done this kind of thing in the past.
* (gl) :)
## New Actions
### stevelitt
* I can make a program to enhanced Markdown if you ever decide to write
the website in Markdown. I can add arbitrary character and paragraph
styles. And custom CSS.
* (plasma41) FWIW, in the beginning the Devuan website was actually
written as markdown fragments which were combined into file HTML
pages by a Ruby program called 'middleman'. Then the only person who
spoke Ruby departed from the project. :-/ After that the final
generated HTML was treated as the source from then on and was
editted directly.
* (gl) I had totally forgotten about the middleman headache. That's
why I converted the site to straight html!
* (Xenguy) The middleman episode is an example of what can be
referred to as a kind of 'technical debt'. A complex system is
implemented that works well provided someone is present who
understands said system. Once such a person (in this case)
leaves, then someone else has to learn the complex system, which
may not always be feasible. The big system is now a big
problem.
### golinux
* possible real-time meet to clean up gitea /documentation directory.
~~Friday evening CST~~ or sometime Sunday after 1:00. Please state
preference and availability. This is basically what will be done:
* (fsr) Keep art, maintainers, release-docs. Everything else can go
into archive/history/trash. (Copied from above.) MISSION
ACCOMPLISHED by fsr, plasma41 and golinux
* I will check in with LeePen and rrq if they don't respond here. DONE
* On a positive note . . . it appears that the hash collisions on the
mail archive have been fixed in the upgrade/migration that alv did
recently. jaromil's "Valentine's" email is now there in all its
glory!!