Re: [spec] Sourcehut migration progress-update and Re: [spec] Patience

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: * 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. ==================== Jonathan McHugh indieterminacy@libre.brussels October 23, 2021 3:30 PM, "DJ Chase" <u9000@posteo.mx> wrote: > 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

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=efb2955e8d33a9d434c540f2a86be49a099066f9 The second one replaces gus.guru with geminispace.info in the FAQ. https://alexschroeder.ch/cgit/gemini-spec/commit/?id=61584fce0680fe724b56cb40ea7fc09be3525ba8 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 *think* Our Generous Host orbitalfox would be able to handle this, but we can use something else if needed. -- 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

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.

*facepalm* uuuugh. sorry guys.

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