| Xenguy | LeePen, IIUC, the file format has changed from .txt to .md | 01:11 |
|---|---|---|
| Xenguy | Secondly, would it make sense to merge your branch file into the master branch, and continue the work there? | 01:12 |
| Xenguy | I'm still trying to learn the best way to collaborate with git, so please feel free to enlighten me. Or is this proliferation of files and separate branches just the common way of working in git? | 01:13 |
| golinux | This was on yesterdays pad: (rrq) just a note against confusion: that url is to the git store's web gui access to the editing place for that document (viewed via markup processing that is triggered by the file extension being "md"). The document should also have a **publishing place** somewhere on www.d.o as well as being included in the local /docs directory on the installer ISOs. The links in that document should be coded so that they poi | 01:18 |
| golinux | nt out the publishing places of all documents it refers to as well as, where applicable, self-relative urls for any of the local /docs documents it refers to. (I *think* those are all correctly coded in this document source, but I haven't verified) | 01:18 |
| golinux | That regarding the Release Notes. | 01:18 |
| Xenguy | Thank you, points taken, and I think my questions about branches, and where we're authoring content, still stand | 01:20 |
| rrq | Xenguy: yes, there are a couple of different collaboration principles one may use with git, and LeePen habitually uses the second, compared to rrq (and golinux) who too often uses the first, and beer (and plasma41) who prefer using the third. | 01:24 |
| rrq | the numbering is random :) | 01:24 |
| rrq | the first is to edit the files where they are, and commit to changes directly ont the "residence branch" | 01:25 |
| rrq | the second is to edit within the project, but capture your edits as a new branch (typically named wip/something). The idea is that when those edits seem to be right for the "residence branch" file, then they are merged into that branch. | 01:26 |
| rrq | the wip/something branch may then be deleted or kept depending on the agreed policy or taste of the people involved. | 01:27 |
| Xenguy | Makes sense, alright, and the third is the 'pull request' model? | 01:27 |
| rrq | the third principle is where the editor first forks the project, and then updates files on the residence branch of their fork, before at times issuing "pull requests" where the edit(s) are merged into the residence project. | 01:29 |
| rrq | note, I'd say plasma41's copying of the chimaera install guide from the installer-iso project to the www.devuan.org project follows the second collaboration principle | 01:30 |
| rrq | sorry I just typed, and didn't see your not: yes | 01:31 |
| Xenguy | I consider myself further educated then, thank you. I personally do prefer a workflow that is simple, clear, and consistent, if only because with 'copies' floating around all over the place, it becomes an extra task just to figure out where things are being authored, and which is the real working copy. | 01:32 |
| rrq | technically I'm a supporter of the second (LeePen's) principle although habitually I often fall into doing the first, especially for projects where I believe myself to be "the owner" of that project | 01:33 |
| Xenguy | Also I recall reading chillfan's documentation for the, ah, 'documentation' repo, and IIRC he encouraged us to work on the 'master' branch of that repo | 01:33 |
| Xenguy | Anyhow, it sounds like there's more than one way to do it : -) | 01:34 |
| Xenguy | I do recall Hendrik commenting 'I don't know where everything is', so for collaboration purposes in the 'documentation' repo, it might make sense to merge to 'master' and just work there. Not everyone is versed in high-level git operations. Nuff said. | 01:36 |
| golinux | Things were much less complicated when I was the only one poking www. I always worked directly on the beta. | 01:37 |
| golinux | This confusion is why I predicted that the fragmentation of parts of the website would make thing more difficult. | 01:39 |
| golinux | Not that thats necessarily a bad thing but definitely makes things more complicated. | 01:39 |
| Xenguy | I personally think so, and it raises the bar of entry for some new person who might otherwise choose to contribute their help | 01:42 |
| rrq | basically, unless you edit in situ (principle one in my numbering) you expect and require "someone else" to merge your edits and (subliminally) take responsibility for the goodness of your edit(s). | 02:49 |
| rrq | at the same time, both principles two and three provide an encapsulation of the edits that is useful for gathering review and feedback | 02:52 |
| rrq | gathering = garnering = getting | 02:52 |
| Xenguy | Fascinating, thanks for these explanations of different ways of working with git | 02:55 |
| rrq | note that that "someone else" in our setting is typically expected to be the editor themselves, taking on a "project owner hat" after having collated all review and feedback and perfected their update. | 02:58 |
| Xenguy | Yeah, it's not like we have a large 'editorial board' happening, hah | 02:59 |
| rkta | I just had a weird crash which needed MagicSq key to reboot after an 'aptitude safe-upgrade' and pressing Enter at the 'needrestart' prompt (I just asked in #devuan about it). I already experienced a crash of X when doing an upgrade. My question here is: What do I do to get some logs etc of such a case to report it? Is doing the upgrade from vt2 and using script sufficient? | 20:34 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!