:: [devuan-dev] Meeting notes 2022-08-…
Top Pagina
Delete this message
Reply to this message
Auteur: B Stack
Datum:  
Aan: devuan developers internal list
Onderwerp: [devuan-dev] Meeting notes 2022-08-04
# Devuan meet 2022-08-04 @20:30 UTC

Present: golinux, fsmithred, plasma41, rrq, Hendrik, Jaromil

## Old Business update of Devuan financial situation to 2022 Q2 -jaromil

## Old Actions

## New Business

### Xenguy

#### Documentation workflow There is a d1g forum thread here that has
raised the (unresolved) issue of documentation workflow:
https://dev1galaxy.org/viewtopic.php?id=5147 A fellow named Tomasz
would like to improve the [Bullseye to Chimaera migration
documentation](https://www.devuan.org/os/documentation/install-guides/chimaera/bullseye-to-chimaera.html).
In order to arrange this, Devuan team members need to clarify a
suitable agreed-upon documentation workflow. I don't believe this is
something that I can sort out without assistance, discussion, and
feedback from the team members. The situation at the moment seems
quite unclear to me, and I'm not 100% sure how to find a solution.

##### Question(s) for LeePen 1. IIUC (my git-fu is modest at best) git
logs from the
[www.devuan.org](https://git.devuan.org/devuan/www.devuan.org/commits/branch/new-beta)
('www') repo appear to indicate that you created documents such as:
*
https://www.devuan.org/os/documentation/install-guides/chimaera/bullseye-to-chimaera
*
https://www.devuan.org/os/documentation/install-guides/chimaera/upgrade-to-chimaera.html
These appear to have been merged to the 'www' repo main branch from
another branch 'wip/leepen' perhaps? I'm curious where these
documents originated from though. For example, were they just copied
from previous documents and then customized for Chimaera before being
committed to a repo? (LeePen) I imagine something like that, although
I don't remember precisely. 2. The same 2 documents above have now
both been subsequently modified in 'www' repo by others. Are these
documents intended to be the canonical or source versions at this
point? To play devil's advocate, for example, this README file found
in the same directory on 'www' seems to suggest that the canonical
source of these files is *not* the 'www' repo but rather the
'installer-iso' repo:
https://git.devuan.org/devuan/www.devuan.org/src/branch/new-beta/source/os/documentation/install-guides/chimaera/README.
When I check the latter repo, however, I do not see these same files
in evidence in the 'docs/docs' directory:
https://git.devuan.org/devuan/installer-iso/src/branch/master/docs/docs
. So just seeking some clarification regarding proper workflow for
these files, going forward. (LeePen) I don't think it is completely
clear. Some docs (certainly README, maybe others) have been created
first for the installer-iso and then duplicated to www.
* (Xenguy) Note that the README linked above is *not* be the main README
file, e.g. for the ISO's. Click through and have a quick look, as I
think perhaps it is inaccurate and creating confusion, and should
perhaps be removed if it is no longer valid. The main question here
is which files in which repos should be edited by others wanting to
contribute to Devuan's documentation. This needs to be clarified, or
folks like Tomasz won't be able to know which files to modify.

##### Question(s) for rrq 1. Is it possible to give a person permissions
  to modify a git repo like 'documentation' while *not* giving
  permissions to modify the 'www' repo? (e.g. it would be nice to offer
  new contributors a means to help us improve our documentation, whilst
  not handing over all the keys to the publishing rights kingdom, if
  that makes sense).
  * (plasma41) Maybe it would be useful to start a devuan-patches
    mailing list to allow accountless contributions to Devuan repos
    using `git send-email`? (see also https://git-send-email.io/)
* (rrq) afaik gitea does have per-project permissions, yes. Also, when
  it comes to "larger" editing I think it common practice to fork the
  project, then edit in the fork, and then make merge-requests for
  propagating updates into the original project. The "documentation"
  project was set up for developing and authoring various documentaion
  pages and page sets, and then the "www.devuan.org" was seen as the
  publishing place. I'm not sure if that process chain has actually been
  followed much (or at all) but rather that the published pages have
  been hand-edited. So nowadays the connections between documents in the
  two projects is less immediate or clear. But in any case, the git
  store is not meant to be a publishing place although essentially all
  projects (at least the Devuan projects) are publically viewable
  through the gitea wen interface.