sr.ht or sourcehut, is an open source GPL based alternative to Microsoft's github. It tries to avoid requring lots of javascript, which often has proprietary and non-free licenses and it tries to provide support for a completely email driven workflow. It was originally inspired by people posting to the emacs list who wanted a github like experience without being forced to use non-free software or forced to use a web based workflow. One of the main objectives for the sourcehut developers is to provide a more modern development and maintenance experience for Emacs which would encourage greater communityh participation (this is assuming that the perceived old fashioned sevannah envrionment where emacs is currently hosted is a significant impediment to community participation, which I'm not sure it is). John Covici <covici@xxxxxxxxxxxxxx> writes: > What is sr.ht? Also, how to use github from the command line -- never > heard of how to do that. > > On Wed, 06 Mar 2024 22:34:49 -0500, > Robert Melton (via emacspeak Mailing List) wrote: >> >> [1 <text/plain; us-ascii (7bit)>] >> Not pushing for it in anyway, but just as an FYI for those interested. >> >> sr.ht actually is completely accessible from the command line hut >> tool, they actually go beyond gh, as I believe every last feature of >> the website is supported. >> >> Additionally, the entire website and all features work 100% without >> javascript so the experience is eww is actually pleasant. >> >> >> > On Mar 6, 2024, at 20:59, T.V Raman <raman@xxxxxxxxxx> wrote: >> > >> > 1+ on both points. >> > >> > A good thing about Github is that the commandline gh lets you do >> > everything you can on the Web, and by limiting ourselves to using >> > email for most things and using gh to close issues, we get to be >> > relatively free of getting too tangled into the Github Web mess. >> > >> > >> > Tim Cross writes: >> >> >> >>> For now, I'll recommend the lazy solution: do nothing, just remember to >> >>> CC the list. Let's see how that scales. >> >> >> >> Always like the lazy approach! >> >> >> >> More seriously, I do feel this needs some carful thought. We want to get >> >> the right balance here. I think the point about early issue discussions >> >> often not being of much value to the list generally is quite >> >> relevant. We don't want too much 'noise' on the list. >> >> >> >> Ideally, we probably want the ability to send interersting threads from >> >> issues to the list - those which show how to solve a common problem or >> >> those which show how people can investigate, tweak or otherwise improve >> >> their emacspeak configuration. >> >> >> >> As a trial and to see how useful the list finds it, I'd agree that what >> >> we should do is just CC the list when an issue seems worthwhile to share >> >> with everyone. >> >> >> >> BTW the point Robert mentioned regarding sourcehut mayu be worth >> >> consideration. One of the main aims of sourcehut was to have workflow >> >> driven primarily via email instead of JS based web interfaces. Any >> >> workflow which does not include JS dependencies is likely going to be >> >> better from an emacs and emacspeak perspective. >> > >> > -- >> >> -- >> Robert "robertmeta" Melton >> lists@xxxxxxxxxxxxxxxx >> >> [2 <text/plain; UTF-8 (8bit)>] >> Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx >> To unsubscribe send email to: >> emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe
|Full archive May 1995 - present by Year|Search the archive|
If you have questions about this archive or had problems using it, please contact us.