πΎ Archived View for gemi.dev βΊ gemini-mailing-list βΊ 001052.gmi captured on 2024-05-12 at 16:22:16. Gemini links have been rewritten to link to archived content
β¬ οΈ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Hi All, I just want to quickly update people about the current Sourcehut migration progress, and inform y'all of my plan. If you have any suggestions or critiques, please let me know. The following is my todo list: [x] create Sourcehut project *** [x] create protocol issue-tracker [x] create Gemtext issue-tracker [x] license Gitlab repos [x] clone protocol repo to Sourcehut [x] clone Gemtext repo to Sourcehut [ ] copy old protocol issues to Sourcehut tracker [ ] copy old Gemtext issues to Sourcehut tracker [x] create meta-repo explaining Sourcehut project [x] meta CONTRIBUTING [ ] meta README *** [ ] resolve & triage old issues [ ] begin accepting new issues Note that the list is ordered in groups, which are separated by "***". There isn't any particular order within groups. ## Specific notes I don't think that the meta README needs to be thorough. It will probably just be something to the effect of "These are the Project Gemini specification repositories" with a link to the website/capsule. I will probably have time to copy the Gitlab issues tomorrow. I obviously hope to get to all of them, but I might only get through one set. I also have a medium-sized assignment tomorrow, but I don't have anything else so it shouldn't be a problem. I hope to finish coping the issues the meta README by the end of the weekend (UTC-4), though it may be the end of Monday (2021-10-25). Just to reiterate: If you think anything should be done differently or in a different order, let me know. This plan is not set in stone - it's my general plan. Cheers, -- DJ Chase They, Them, Theirs
Hi, i'm all for what James Tomasino wrote: "please slow down" You stated earlier - let me cite you: "As I do not have an abundance of excess time, I would love for someone to step-up to fill Sean's role." But yet you try to push a move to Sourcehut on people. The gitlab repos are still there and i'm pretty sure there are plenty of mirrors already set up. So nothing will be lost if the gitlab repos disappear all of a sudden. There's absolutely no point in having yet another repo that will be abandonded in 3 months. At first we need to create an idea of how we want to organize in the future. I mostly read ansers from people that don't want to step up as a protocol maintainer, but till now no one said "yeah, i'm in, lets build a team and get going". A push to Sourcehut is a completely unnecessary action at the moment. regards RenΓ©
> From Solderpunk's gemlog, 2021-10-08: > This prolonged absence was not planned but was, I think, sorely needed. > That said, I think I am ready to start slowly and carefully re-engaging > with the online world. > The Gemini community, or perhaps a subset of it, or perhaps none of it > (I genuinely haven't checked and genuinely don't know) are maybe > wondering just exactly when I'm going to return to that scene and take > charge and finish things up, huh? Look. I don't know. I'm sorry. > I'm going to do it. Gemini is not abandoned. I haven't given up on > it. Please believe me that it's important that I take my time my time > with this, and be patient with me. It's a virtue, and further more, > it's the attitude at the very heart of this whole small internet thing. > We'll get there. gemini://gemini.circumlunar.space/users/solderpunk/gemlog/been-an-even-longer-time.gmi
Truthfully? I'm at this point concerned for solderpunk's mental wellbeing. If he needs to keep hanging back for the sake of sorting himself out? Gemini as is, is not in a horrible place from the standpoint of me as a user. It can sit as is. It needs to be 'finished' but I don't want the guy to break himself for our sakes. On 10/23/21 2:32 AM, RenΓ© Wagner wrote: > Hi, > > i'm all for what James Tomasino wrote: > "please slow down" > > You stated earlier - let me cite you: > "As I do not have an abundance of excess time, I would love for someone > to step-up to fill Sean's role." > > But yet you try to push a move to Sourcehut on people. > The gitlab repos are still there and i'm pretty sure there are plenty > of mirrors already set up. So nothing will be lost if the gitlab repos > disappear all of a sudden. > > There's absolutely no point in having yet another repo that will be > abandonded in 3 months. > > At first we need to create an idea of how we want to organize in the future. > I mostly read ansers from people that don't want to step up as a protocol > maintainer, but till now no one said "yeah, i'm in, lets build > a team and get going". > A push to Sourcehut is a completely unnecessary action at the moment. > > regards > RenΓ© -- ----- http://singletona082.flounder.online gemini://singletona082.flounder.online My online presence
Il 23 ottobre 2021 09:32:02 CEST, "RenΓ© Wagner" <rwagner@rw-net.de> ha scritto: >Hi, > >i'm all for what James Tomasino wrote: >"please slow down" > >You stated earlier - let me cite you: >"As I do not have an abundance of excess time, I would love for someone >to step-up to fill Sean's role." > >But yet you try to push a move to Sourcehut on people. >The gitlab repos are still there and i'm pretty sure there are plenty >of mirrors already set up. So nothing will be lost if the gitlab repos >disappear all of a sudden. > >There's absolutely no point in having yet another repo that will be >abandonded in 3 months. > >At first we need to create an idea of how we want to organize in the future. >I mostly read ansers from people that don't want to step up as a protocol >maintainer, but till now no one said "yeah, i'm in, lets build >a team and get going". >A push to Sourcehut is a completely unnecessary action at the moment. I wholeheartedly agree about the need to slow down. Moving from one repo that was created by the official maintainer and yet undocumented (there is no link to the GitLab repo from the official Gemini documentation) to another repo that is equally undocumented and run without any agreement by the bdfl, nor by the community, is not something to rush for. All the best steko
On Sat, 2021-10-23 at 09:32 +0200, RenΓ© Wagner wrote: > i'm all for what James Tomasino wrote: > "please slow down" > > You stated earlier - let me cite you: > "As I do not have an abundance of excess time, I would love for someone > to step-up to fill Sean's role." Excellent. It's great to here that the community does not need/want a speedy transition. > There's absolutely no point in having yet another repo that will be > abandonded in 3 months. > > At first we need to create an idea of how we want to organize in the future. > I mostly read ansers from people that don't want to step up as a protocol > maintainer, but till now no one said "yeah, i'm in, lets build > a team and get going". I'm all for taking this slowly and focusing on organization. I was moving quickly to avoid stagnation, but now I do not think that progress will stagnate if the pace slows. I'd love to build a team and get going. If anyone else wants to as well, please say so. -- DJ Chase They, Them, Theirs
"Slow and steady wins the race" Perhaps I should raise my hand for a couple voluntary activities. As I mentioned on the ML, I will be shall be looking into developing tools for issue management/bug tracking. I shall be able to do this (and suplementary activities) fulltime ONCE I sign a memorandum of understanding with NLNet - the main thing holding up the project (beyond some resolved health impediments) is the definitive criteria from which to access my ~GPL3+ output and receive consumate 'philanthropy'. If you have thoughts/ideas please email me privately, as Im still taking the burrs off my submission. Some shadow boxing would be appreciated. By dint of me going through some administrative hoops (and gumption/luck) I do not consider my claim to be greater than any other for eligability for implementing/managing a/numerous issue tracker(s) for the specification if not Gemini projects. For the record:
On Sun, 2021-10-24 at 06:44 +0000, Jonathan McHugh wrote: > Hi DJ Chase, > > I did wonder if Id conflated things, no worries. > > Ill try again. > * I will be working fulltime to support the development of a Gemini based issue/bug tracker. > * I could volunteer support for hosting/maintaining something for the Gemini community > * I lack the relevant experience to be a leader for the specification A Gemini-based issue tracker sounds like an great utility, but I think it may be best to avoid yet another move. I think it will be awesome for other Gemini-based projects or capsules, though. I'm excited for its eventual release. PS: I've included the rest of the thread below so that people can follow the conversation. I must have accidentally hit "Reply" instead of "Reply all" last night; I'll look into how I can prevent that in my mail client. -- DJ Chase Them, Them, Theirs > > TBH, (today) I would prefer to focus on coding the aforementioned than performing the necessaries of hosting/maintenance right now. I could certainly perform moderation in any case, while my coding comes into place. > > ==================== > Jonathan McHugh > indieterminacy@libre.brussels > > October 24, 2021 12:02 AM, "DJ Chase" <u9000@posteo.mx> wrote: > > > Hi Jonathan, > > > > On Sat, 2021-10-23 at 18:25 +0000, Jonathan McHugh wrote: > > > > > "Slow and steady wins the race" > > > > > > Perhaps I should raise my hand for a couple voluntary activities. > > > > > > As I mentioned on the ML, I will be shall be looking into developing tools for issue management/bug > > > tracking. > > > > > > I shall be able to do this (and suplementary activities) fulltime ONCE I sign a memorandum of > > > understanding with NLNet - the main thing holding up the project (beyond some resolved health > > > impediments) is the definitive criteria from which to access my ~GPL3+ output and receive consumate > > > 'philanthropy'. > > > > > > If you have thoughts/ideas please email me privately, as Im still taking the burrs off my > > > submission. Some shadow boxing would be appreciated. > > > > > > By dint of me going through some administrative hoops (and gumption/luck) I do not consider my > > > claim to be greater than any other for eligability for implementing/managing a/numerous issue > > > tracker(s) for the specification if not Gemini projects. > > > > > > For the record: > > > * Im no way am I capable to manage the minutae of Gemini's specification. > > > * IMHO, a pause would be good to allow people to provide more Gemini content and tools. > > > > I'm a bit confused by your email. Are you saying that you want to help > > maintain Gemini or that you cannot? Or, are you offering to host the > > issue trackers? > > > > I apologize for my lack of understanding, and do not wish to cause any > > offense by asking for clarification. > > > > -- > > DJ Chase > > They, Them, Theirs
Goodgood. This week Im having a look at Guix's Debbugs history, hopefully Ill have some insights from that. Ill be parsing in TXR Lisp, FYI. ==================== Jonathan McHugh indieterminacy@libre.brussels October 24, 2021 5:26 PM, "DJ Chase" <u9000@posteo.mx> wrote: > On Sun, 2021-10-24 at 06:44 +0000, Jonathan McHugh wrote: > >> Hi DJ Chase, >> >> I did wonder if Id conflated things, no worries. >> >> Ill try again. >> * I will be working fulltime to support the development of a Gemini based issue/bug tracker. >> * I could volunteer support for hosting/maintaining something for the Gemini community >> * I lack the relevant experience to be a leader for the specification > > A Gemini-based issue tracker sounds like an great utility, but I think > it may be best to avoid yet another move. I think it will be awesome for > other Gemini-based projects or capsules, though. I'm excited for its > eventual release. > > PS: I've included the rest of the thread below so that people can follow > the conversation. I must have accidentally hit "Reply" instead of "Reply > all" last night; I'll look into how I can prevent that in my mail > client. > > -- > DJ Chase > Them, Them, Theirs > >> TBH, (today) I would prefer to focus on coding the aforementioned than performing the necessaries >> of hosting/maintenance right now. I could certainly perform moderation in any case, while my coding >> comes into place. >> >> ==================== >> Jonathan McHugh >> indieterminacy@libre.brussels >> >> October 24, 2021 12:02 AM, "DJ Chase" <u9000@posteo.mx> wrote: >> >> Hi Jonathan, >> >> On Sat, 2021-10-23 at 18:25 +0000, Jonathan McHugh wrote: >> >>> "Slow and steady wins the race" >>> >>> Perhaps I should raise my hand for a couple voluntary activities. >>> >>> As I mentioned on the ML, I will be shall be looking into developing tools for issue >> management/bug >>> tracking. >>> >>> I shall be able to do this (and suplementary activities) fulltime ONCE I sign a memorandum of >>> understanding with NLNet - the main thing holding up the project (beyond some resolved health >>> impediments) is the definitive criteria from which to access my ~GPL3+ output and receive >> consumate >>> 'philanthropy'. >>> >>> If you have thoughts/ideas please email me privately, as Im still taking the burrs off my >>> submission. Some shadow boxing would be appreciated. >>> >>> By dint of me going through some administrative hoops (and gumption/luck) I do not consider my >>> claim to be greater than any other for eligability for implementing/managing a/numerous issue >>> tracker(s) for the specification if not Gemini projects. >>> >>> For the record: >>> * Im no way am I capable to manage the minutae of Gemini's specification. >>> * IMHO, a pause would be good to allow people to provide more Gemini content and tools. >> >> I'm a bit confused by your email. Are you saying that you want to help >> maintain Gemini or that you cannot? Or, are you offering to host the >> issue trackers? >> >> I apologize for my lack of understanding, and do not wish to cause any >> offense by asking for clarification. >> >> -- >> DJ Chase >> They, Them, Theirs
> I'd love to build a team and get going. If anyone else wants to as > well, please say so. I'm willing to help. In the spirit of showing what sort of things I'd be about: I like to use git directly. We can all collaborate using our respective git repositories and pull requests. If one of us uses a repository available via GitLab, SourceHut or some other platform, that's a nice bonus, but as far as I'm concerned, I'm happy with using git, and discussions on the mailing list. I'd like to keep changes to the spec very, very small. For example, I'd say that there "must" be a space after the asterisk in list items because some people might start their paragraph with emphasis using asterisks. I'd say there "should" be a space after the link indicator, but there's no reason to make it mandatory that I've seen. In an effort to show the kind of work I'd like to do most of all, I've made some changes to my branch and would invite others to pull it. The first one adds a section on dealing with bots if you're serving dynamic content to Best Practices. https://alexschroeder.ch/cgit/gemini-spec/commit/?id=efb2955e8d33a9d434c540 f2a86be49a099066f9 The second one replaces gus.guru with geminispace.info in the FAQ. https://alexschroeder.ch/cgit/gemini-spec/commit/?id=61584fce0680fe724b56cb 40ea7fc09be3525ba8 I currently run a very small wiki dedicated to Gemini, which is where I would write drafts. gemini://transjovian.org/gemini The page I wrote today lists our git repositories, and has a copy of the specification generated from the main branch of my repository. That's where you can see the above changes in context. gemini://transjovian.org/gemini/page/Gemini%20Specification My preferred way of working would be discussing things on the mailing list, me writing a draft on the wiki, and finally committing it to my repository and then inviting others to pull it. For the two changes above I skipped the discussion on the mailing list because I felt I needed something to show before volunteering. Based on the above, I guess I'm volunteering for draft writing, maintaining one of the repos, and the process of getting things into that repo, and less for lively mailing list discussion. In an ideal world, friends would read the mailing list for me and summarize the discussion for me. Anyway, if you're interested in having me on the team in a role that plays to my strength, then you have my β¦ keyboard, I guess. :) Cheers Alex
On Sun, 2021-10-24 at 22:52 +0200, Alex Schroeder wrote: > > I'd love to build a team and get going. If anyone else wants to as > > well, please say so. > > I'm willing to help. Great! Thank you. > > In the spirit of showing what sort of things I'd be about: TLDR: I agree with most of these things. I've replied to a few disagreements below, but otherwise I pretty-much agree. I'd love to have you on the team. > > I like to use git directly. We can all collaborate using our respective > git repositories and pull requests. If one of us uses a repository > available via GitLab, SourceHut or some other platform, that's a nice > bonus, but as far as I'm concerned, I'm happy with using git, and > discussions on the mailing list. I mostly agree with this. I agree we should be "using git directly", but I don't consider sending around pull-requests to various repos to be using git directly. Multiple repos are totally fine, but we should use git's native way of distributing patches: git send-email. I know that requiring send-email would put some people off, though, so I'm fine with also accepting patches via the method you described above. Either way, though, I think that we should still have one central/official repo. Not having one would mean that new contributors would have nothing to clone in order to get started. > [...] I'm happy with using git, and discussions on the mailing list. This brings up a good point - though probably best suited for the parent thread - of whether we even need issue trackers. What do y'all think of this? > My preferred way of working would be discussing things on the mailing > list, me writing a draft on the wiki, and finally committing it to my > repository and then inviting others to pull it. I think it's important that people be able to submit patches in addition to just discussing it on the mailing list. A draft branch may be the best way of doing this, but of course I'm open to ideas. > Based on the above, I guess I'm volunteering for draft writing, > maintaining one of the repos, and the process of getting things into > that repo, Awesome. > and less for lively mailing list discussion. Also great, though I am confused as to how this does not conflict with your above quote: "I'm happy with using git, and discussions on the mailing list". > In an ideal > world, friends would read the mailing list for me and summarize the > discussion for me. It could be good to have an actual digest-mode instead of simply grouped-emails. > Anyway, if you're interested in having me on the team in a role that > plays to my strength, then you have my β¦ keyboard, I guess. :) I'd love to have you on the team assuming people aren't greatly upset by this. It seems improbable that people would be so. -- DJ Chase They, Them, Theirs
> I mostly agree with this. I agree we should be "using git directly", > but I don't consider sending around pull-requests to various repos to > be using git directly. Multiple repos are totally fine, but we should > use git's native way of distributing patches: git send-email. I know > that requiring send-email would put some people off, though, so I'm > fine with also accepting patches via the method you described above. Git does have another native way of sharing changes: `man git-request-pull`. You upload your repo somewhere publicly accessible and kindly ask upstream to pull some commits from there. Maybe Alex meant this kind of pull requests? -- dalz
dalz <gemini@alsd.eu> writes: > Git does have another native way of sharing changes: > `man git-request-pull`. You upload your repo somewhere publicly > accessible and kindly ask upstream to pull some commits from there. > Maybe Alex meant this kind of pull requests? Yeah, that's what I am thinking of. But since development is slow, and the number of developers is small, I was just thinking of writing ordinary human-to-human email. I've been enjoying that sort of approach within the Elpher project (a Gopher & Gemini client for Emacs). And of course, emails with patches are still welcome from people without public repositories, for sure. Cheers Alex -- Fingerprint: DF94 46EB 7B78 4638 7CCC 018B C78C A29B ACEC FEAE
DJ Chase <u9000@posteo.mx> writes: > This brings up a good point - though probably best suited for the parent > thread - of whether we even need issue trackers. What do y'all think of > this? It depends on activity of the project, in my experience. I know that for my personal projects, or projects where just a handful of people collaborate, an issue tracker is nice to have but also overhead that's easily ignored. Futhermore, in our current setup, with all eyes focused on the mailing list, perhaps keeping issues on a repository website is not only alienating because of javascript and all that, but also a black hole into which topics disappear, the assumption being that "somebody" is going to handle them. My suggestion is for somebody intending to write up stuff (what I volunteered to do) to keep a todo list, for sure, and in public, if possible, but without the expectation that people take the discussion from the mailing list to the issue tracker. Incidentaly, I suspect that having a Gemini-based issue tracker is not going to solve the problem of tearing appart the discussion which is why I personally don't want to invest too much energy into it. And if we find that discussions go in circles, or too many hot spots are in discussion at any one time, we can always bring issue trackers back. But for now, perhaps them being separate from the mailing list was a mistake as it cut them off from discussion. > Also great, though I am confused as to how this does not conflict with > your above quote: "I'm happy with using git, and discussions on the > mailing list". Yeah, I'm unsure of how to bridge that gap myself. We'll see how it goes. Perhaps I can pick up items from discussion on the mailing list without having to involve myself in every discussion, or somebody can tell me: "Hey Alex, I think we're ready to fix that section on X. Why don't you take a look at the thread in the archives and write up a draft?" And then I can separate myself from the flames emotionally, or something like that. I'll have to figure something out. > It could be good to have an actual digest-mode instead of simply > grouped-emails. Perhaps one good way of working out issues after a lively discussion on the mailing list would for the draft writer (e.g. me) to go through the thread and pick out the various arguments in favour and against, and write that summary for future reference, as part of the drafting process. Cheers Alex -- Fingerprint: DF94 46EB 7B78 4638 7CCC 018B C78C A29B ACEC FEAE
Hi Alex, Im personally ok with these suggestions. There is certainly no harm falling back to the mailing list for discussions for the time being. If people can synthesize things for future infrastructure and governance then we can hopefully minimise duplication and align more effectively. And people summarising issues and a tree of options would be helpful, particularly is cross threading is deployed. Kind regards, Jonathan Alex Schroeder <alex@alexschroeder.ch> writes: > DJ Chase <u9000@posteo.mx> writes: > >> This brings up a good point - though probably best suited for the parent >> thread - of whether we even need issue trackers. What do y'all think of >> this? > > It depends on activity of the project, in my experience. I know that for > my personal projects, or projects where just a handful of people > collaborate, an issue tracker is nice to have but also overhead that's > easily ignored. > > Futhermore, in our current setup, with all eyes focused on the mailing > list, perhaps keeping issues on a repository website is not only > alienating because of javascript and all that, but also a black hole > into which topics disappear, the assumption being that "somebody" is > going to handle them. > > My suggestion is for somebody intending to write up stuff (what I > volunteered to do) to keep a todo list, for sure, and in public, if > possible, but without the expectation that people take the discussion > from the mailing list to the issue tracker. > > Incidentaly, I suspect that having a Gemini-based issue tracker is not > going to solve the problem of tearing appart the discussion which is why > I personally don't want to invest too much energy into it. > > And if we find that discussions go in circles, or too many hot spots are > in discussion at any one time, we can always bring issue trackers back. > But for now, perhaps them being separate from the mailing list was a > mistake as it cut them off from discussion. > >> Also great, though I am confused as to how this does not conflict with >> your above quote: "I'm happy with using git, and discussions on the >> mailing list". > > Yeah, I'm unsure of how to bridge that gap myself. We'll see how it > goes. Perhaps I can pick up items from discussion on the mailing list > without having to involve myself in every discussion, or somebody can > tell me: "Hey Alex, I think we're ready to fix that section on X. Why > don't you take a look at the thread in the archives and write up a > draft?" And then I can separate myself from the flames emotionally, or > something like that. I'll have to figure something out. > >> It could be good to have an actual digest-mode instead of simply >> grouped-emails. > > Perhaps one good way of working out issues after a lively discussion on > the mailing list would for the draft writer (e.g. me) to go through the > thread and pick out the various arguments in favour and against, and > write that summary for future reference, as part of the drafting > process. > > Cheers > Alex
On Mon, 2021-10-25 at 13:02 +0200, indieterminacy@libre.brussels wrote: > Hi Alex, > > Im personally ok with these suggestions. > > There is certainly no harm falling back to the mailing list for > discussions for the time being. > > If people can synthesize things for future infrastructure and governance > then we can hopefully minimise duplication and align more effectively. > > And people summarising issues and a tree of options would be helpful, > particularly is cross threading is deployed. Yeah, I feel the same. -- DJ Chase They, Them, Theirs
On Mon, 2021-10-25 at 12:13 +0200, Alex Schroeder wrote: > dalz <gemini@alsd.eu> writes: > > > Git does have another native way of sharing changes: > > `man git-request-pull`. You upload your repo somewhere publicly > > accessible and kindly ask upstream to pull some commits from there. > > Maybe Alex meant this kind of pull requests? > > Yeah, that's what I am thinking of. But since development is slow, and > the number of developers is small, I was just thinking of writing > ordinary human-to-human email. I've been enjoying that sort of approach > within the Elpher project (a Gopher & Gemini client for Emacs). > > And of course, emails with patches are still welcome from people without > public repositories, for sure. I was going to write an email this morning saying that I just read your post "Gemini Opinions!", and now I better understand what you meant last night about git. It looks like dalz beat me to it, though! -- DJ Chase They, Them, Theirs
Alex Schroeder <alex@alexschroeder.ch> writes: > I like to use git directly. We can all collaborate using our respective > git repositories and pull requests. If one of us uses a repository > available via GitLab, SourceHut or some other platform, that's a nice > bonus, but as far as I'm concerned, I'm happy with using git, and > discussions on the mailing list. I'm strongly in favor of this, and I may be able to put in more effort if it is managed this way. That said (putting on mailing list admin hat), I would like to propose a separate and smaller mailing list for spec discussion. That way, we'd be able to git-send-email to the list and have issue threads without spamming up the discussion list. I
As a note: I do not use git. I have had no real reason to USE git before beyond 'go clone this git, follow these instructions, and your whatsit should be up and going.' Which was helpful in getting proper wifi up on my machine. I'm on my second read through since.... just at a concept level this gets a 'but why?' out of me. Ya, jumping to a whole new protocol is neat and exciting and has some uses. Re-purposing git has me scratching my head. In a way I get it at a conceptual level and like it. Have the client do a pull request for your material so that if something ever happens to yoru server their copy still exists. Which part of me finds agreeable. On the other hand I dislike how Solderpunk is talking that the pull requests seem to be automated and continual whenever you visit a given site. What if I stumble on a site i don't want? I shouldn't have to go dig through settings to kick it out of the pull request chain. Nitpicky I suppose and easily fixed by making it a proactive choice to add a given site to your pull request list (Essentially your favorites list really.) The other is why not automate the process? I'm fairly sure that is something git already does and allows since I can literally go into command line and 'git clone: [address]' So having a timer function to make pull requests at x time and or when connect next' should be a no-brainer for clients to handle. I don't like this as a solution though since it feels like one of those things that works just well enough to fix the problem, but doesn't solve the other problems Solderpunk himself admits this has yet keeps talking like it's 'temporary.' Software, much like carpentry, is a case where the temporary fix often becomes permanent. So while conceptually having a git-like setup for gemini servers to use so clients with the git feature (or just users performing pull requests) is neat. The fact that the guy that is pitching this as a fix himself admits this doens't solve everything leaves me not liking it, since any fix down the road will have to account for this blessed by the creator concept is now out there and ... I mean there are worse things than having background pull requests that are handled by the client? I'm just afraid, as a user, that this could introduce something that would hamstring a more proper solution rather than this '80/20' that Solderpunk is speaking of. -- ----- http://singletona082.flounder.online gemini://singletona082.flounder.online My online presence
Hi Andrew, On Mon, 2021-10-25 at 11:36 -0500, Andrew Singleton wrote: > Β I'm on my second read through since.... just at a concept level this > gets a 'but why?' out of me. Ya, jumping to a whole new protocol is > neat and exciting and has some uses. Re-purposing git has me > scratching my head. In a way I get it at a conceptual level and like > it. Have the client do a pull request for your material so that if > something ever happens to yoru server their copy still exists. Which > part of me finds agreeable. > Β > Β On the other hand I dislike how Solderpunk is talking that the pull > requests seem to be automated and continual whenever you visit a given > site. What if I stumble on a site i don't want? I shouldn't have to go > dig through settings to kick it out of the pull request chain. > Nitpicky I suppose and easily fixed by making it a proactive choice to > add a given site to your pull request list (Essentially your favorites > list really.) The other is why not automate the process? I'm fairly > sure that is something git already does and allows since I can > literally go into command line and 'git clone: [address]' So having a > timer function to make pull requests at x time and or when connect > next' should be a no-brainer for clients to handle. > Β > Β I don't like this as a solution though since it feels like one of > those things that works just well enough to fix the problem, but > doesn't solve the other problems Solderpunk himself admits this has > yet keeps talking like it's 'temporary.' Software, much like > carpentry, is a case where the temporary fix often becomes permanent. > Β > Β So while conceptually having a git-like setup for gemini servers to > use so clients with the git feature (or just users performing pull > requests) is neat. The fact that the guy that is pitching this as a > fix himself admits this doens't solve everything leaves me not liking > it, since any fix down the road will have to account for this blessed > by the creator concept is now out there and ... I mean there are worse > things than having background pull requests that are handled by the > client? I'm just afraid, as a user, that this could introduce > something that would hamstring a more proper solution rather than this > '80/20' that Solderpunk is speaking of. I think you've conflated Solderpunk's post and this thread. This thread is not about using git as a text-distribution system, but still, thank you for sharing your thoughts. -- DJ Chase They, Them, Theirs
Andrew Singleton <singletona082@gmail.com> writes: > As a note: I do not use git. I have had no real reason to USE git before beyond 'go > clone this git, follow these instructions, and your whatsit should be up and going.' > Which was helpful in getting proper wifi up on my machine. [snip] For ease of reference, could you please provide a link to the content your message is a response to? Alexis.
oh sure, sorry. gemini://gemini.circumlunar.space/~solderpunk/gemlog/low-budget-p2p-content -distribution-with-git.gmi On 10/25/21 12:21 PM, Alexis wrote: > > [snip] > > For ease of reference, could you please provide a link to the content your message is a response to? > > > Alexis. -- ----- http://singletona082.flounder.online gemini://singletona082.flounder.online My online presence
On Mon, 2021-10-25 at 12:24 -0500, Andrew Singleton wrote: > *facepalm* > > uuuugh. sorry guys. No need to be sorry; replying to the wrong thread is not a big deal. Cheers, -- DJ Chase They, Them, Theirs
Jason McBrayer <jmcbray@carcosa.net> writes: > I'm strongly in favor of this, and I may be able to put in more effort > if it is managed this way. That said (putting on mailing list admin > hat), I would like to propose a separate and smaller mailing list for > spec discussion. That way, we'd be able to git-send-email to the list > and have issue threads without spamming up the discussion list. I > *think* Our Generous Host orbitalfox would be able to handle this, but > we can use something else if needed. Please disregard. I composed this message before Solderpunk came back, and I had mail queued for sending from offline. Those mails got sent today, before I realized several of them were out of date. -- Jason McBrayer | βStrange is the night where black stars rise, jmcbray@carcosa.net | and strange moons circle through the skies, | but stranger still is lost Carcosa.β | β Robert W. Chambers,The King in Yellow
---