Migrating to sourcehut - what's missing?

Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Hi!

Is there still interest in moving over to Sourcehut for emacs
development?  If so, what blockers are left for emacs development?  I
just had a small chat on irc with Drew DeVault, the developer of
Sourcehut, and got some directions for at least one important issue:
sending patches as attachments for them to be rendered in the web view.

Should we assemble a general list of what is missing in etc/TODO?

For the attachment issue, the one implementing this needs to build
'lists' and 'meta' subsystems of sourcehut.  To build sourcehut, there
are directions on some blogs: [1] and [2].

I'm planning to look into this myself a little during the holidays, but
not sure how much time I realistically can spend on this, so therefore
this mail.  Possibly it may be useful if someone other than me wishes to
tackle this over the holidays?  In general they are pretty responsive
over at #sr.ht, so they might be willing to help out a little.

Theo


[1]: https://emersion.fr/blog/2021/setting-up-sr.ht-for-local-development/
[2]: https://man.sr.ht/installation.md

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Theodor Thornhill <theo@thornhill.no> writes:

> Is there still interest in moving over to Sourcehut for emacs
> development?

My understanding is that the answer is yes.  AFAIK, no final decision
has yet been taken, but it seems like the consensus is more or less that
sourcehut is the most likely candidate to have what we need within some
reasonable time-frame.

> I'm planning to look into this myself a little during the holidays, but
> not sure how much time I realistically can spend on this, so therefore
> this mail.  Possibly it may be useful if someone other than me wishes to
> tackle this over the holidays?  In general they are pretty responsive
> over at #sr.ht, so they might be willing to help out a little.

I would personally start with setting up a sourcehut instance with a
mirror of the Emacs source code.  This would allow you to start
experimenting with it to see how it works and what is missing.  In this
work, I would specifically compare the sourcehot workflow to what we
have now.  If you could make the instance publicly accessible, other
interested parties could help with this work more easily.

Preferably any gotchas when installing should be noted down somewhere
(e.g. sent to emacs-devel).

Next, I would start looking into those things that are still missing.
For starters, they would need to be listed and it should be ensured that
there are good feature requests on the sourcehut issue tracker.  If the
sourcehut developers are willing to implement those things then great,
otherwise it would be obviously be very useful if someone would
volunteer to start working on those things.

In all steps of the way, I would try to involve emacs-devel for further
input and feedback.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>> Is there still interest in moving over to Sourcehut for emacs
>> development?
>
> My understanding is that the answer is yes.  AFAIK, no final decision
> has yet been taken, but it seems like the consensus is more or less that
> sourcehut is the most likely candidate to have what we need within some
> reasonable time-frame.
>

Good to hear.  I think it would be stupid to decide this without trying
it properly first anyway.

>> I'm planning to look into this myself a little during the holidays, but
>> not sure how much time I realistically can spend on this, so therefore
>> this mail.  Possibly it may be useful if someone other than me wishes to
>> tackle this over the holidays?  In general they are pretty responsive
>> over at #sr.ht, so they might be willing to help out a little.
>
> I would personally start with setting up a sourcehut instance with a
> mirror of the Emacs source code.  This would allow you to start
> experimenting with it to see how it works and what is missing.  In this
> work, I would specifically compare the sourcehot workflow to what we
> have now.  If you could make the instance publicly accessible, other
> interested parties could help with this work more easily.
>

Workflow-wise I believe it already is established that sourcehut
supports most if not all aspects of the emacs development workflow,
modulo the patch-rendering issue when patches are sent as attachments.
One of the biggest improvements would be to set up builds on patch
submission, running tests etc.  All of this works properly in Sourcehut.

> Preferably any gotchas when installing should be noted down somewhere
> (e.g. sent to emacs-devel).
>
> Next, I would start looking into those things that are still missing.
> For starters, they would need to be listed and it should be ensured that
> there are good feature requests on the sourcehut issue tracker.  If the
> sourcehut developers are willing to implement those things then great,
> otherwise it would be obviously be very useful if someone would
> volunteer to start working on those things.
>

Actually, I think that running Sourcehut as a local instance wouldn't
really be necessary for the evaluation, because it is the same code that
is running on sr.ht.  Apart from the fiddly bits with self hosting, the
workflow should be the same.  I'd encourage people on this list getting
their own user there and trying it out, as I think many already have.
Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
`todo` and `builds` subprojects, that is all apart from the `hg` one.

> In all steps of the way, I would try to involve emacs-devel for further
> input and feedback.

Of course.  However, I think that getting some sense of what _needs_ to
be supported before even considering sourcehut would be smart.  The self
hosting can come later, IMO.

For example, its author suggests that emacs-devel adopts the `git
send-email` workflow rather than using attachments anyway, but I believe
that was a hard no.

I'll start the list of hard requirements:

- [ ] patches as attachments


Theo

Re: Migrating to sourcehut - what's missing?

[Eric Abrahamsen]

Theodor Thornhill <theo@thornhill.no> writes:

>>> Is there still interest in moving over to Sourcehut for emacs
>>> development?
>>
>> My understanding is that the answer is yes.  AFAIK, no final decision
>> has yet been taken, but it seems like the consensus is more or less that
>> sourcehut is the most likely candidate to have what we need within some
>> reasonable time-frame.
>>
>
> Good to hear.  I think it would be stupid to decide this without trying
> it properly first anyway.
>
>>> I'm planning to look into this myself a little during the holidays, but
>>> not sure how much time I realistically can spend on this, so therefore
>>> this mail.  Possibly it may be useful if someone other than me wishes to
>>> tackle this over the holidays?  In general they are pretty responsive
>>> over at #sr.ht, so they might be willing to help out a little.
>>
>> I would personally start with setting up a sourcehut instance with a
>> mirror of the Emacs source code.  This would allow you to start
>> experimenting with it to see how it works and what is missing.  In this
>> work, I would specifically compare the sourcehot workflow to what we
>> have now.  If you could make the instance publicly accessible, other
>> interested parties could help with this work more easily.
>>
>
> Workflow-wise I believe it already is established that sourcehut
> supports most if not all aspects of the emacs development workflow,
> modulo the patch-rendering issue when patches are sent as attachments.
> One of the biggest improvements would be to set up builds on patch
> submission, running tests etc.  All of this works properly in Sourcehut.
>
>> Preferably any gotchas when installing should be noted down somewhere
>> (e.g. sent to emacs-devel).
>>
>> Next, I would start looking into those things that are still missing.
>> For starters, they would need to be listed and it should be ensured that
>> there are good feature requests on the sourcehut issue tracker.  If the
>> sourcehut developers are willing to implement those things then great,
>> otherwise it would be obviously be very useful if someone would
>> volunteer to start working on those things.
>>
>
> Actually, I think that running Sourcehut as a local instance wouldn't
> really be necessary for the evaluation, because it is the same code that
> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
> workflow should be the same.  I'd encourage people on this list getting
> their own user there and trying it out, as I think many already have.
> Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
> `todo` and `builds` subprojects, that is all apart from the `hg` one.

I wonder if it would make sense to have one of the maintainers sign up
there and start a "pretend" official Emacs repo. They could start a
mailing list alongside it that we could play with, and who knows, maybe
that would eventually become the "real" official sr.ht repo.

Eric

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>>> Preferably any gotchas when installing should be noted down somewhere
>>> (e.g. sent to emacs-devel).
>>>
>>> Next, I would start looking into those things that are still missing.
>>> For starters, they would need to be listed and it should be ensured that
>>> there are good feature requests on the sourcehut issue tracker.  If the
>>> sourcehut developers are willing to implement those things then great,
>>> otherwise it would be obviously be very useful if someone would
>>> volunteer to start working on those things.
>>>
>>
>> Actually, I think that running Sourcehut as a local instance wouldn't
>> really be necessary for the evaluation, because it is the same code that
>> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
>> workflow should be the same.  I'd encourage people on this list getting
>> their own user there and trying it out, as I think many already have.
>> Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
>> `todo` and `builds` subprojects, that is all apart from the `hg` one.
>
> I wonder if it would make sense to have one of the maintainers sign up
> there and start a "pretend" official Emacs repo. They could start a
> mailing list alongside it that we could play with, and who knows, maybe
> that would eventually become the "real" official sr.ht repo.
>
> Eric

So that would be something like git.sr.ht/~eliz/emacs or
git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the user
names are in the sourcehut code base.  Assuming the GNU project would
host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
source.gnu.org, or whatever, would it still be possible to remove the
"~..." username part? (I know this is as minor of an issue as it gets,
it's just curiosity).

Until then, it seems that the username "~gnu" is not taken.  Maybe
someone more entitled than me could mirror a few repositories over there
for testing purposes?

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>
> So that would be something like git.sr.ht/~eliz/emacs or
> git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the user
> names are in the sourcehut code base.  Assuming the GNU project would
> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
> source.gnu.org, or whatever, would it still be possible to remove the
> "~..." username part? (I know this is as minor of an issue as it gets,
> it's just curiosity).
>
> Until then, it seems that the username "~gnu" is not taken.  Maybe
> someone more entitled than me could mirror a few repositories over there
> for testing purposes?
>

See my other mail just sent.  ~emacs is owned by me as for now, unless
~gnu is preferred :)

Theo

Re: Migrating to sourcehut - what's missing?

[Eric Abrahamsen]

Theodor Thornhill <theo@thornhill.no> writes:

>>
>> So that would be something like git.sr.ht/~eliz/emacs or
>> git.sr.ht/~lars/emacs? This makes me wonder how "hard coded" the
>> user
>> names are in the sourcehut code base. Assuming the GNU project would
>> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
>> source.gnu.org, or whatever, would it still be possible to remove
>> the
>> "~..." username part? (I know this is as minor of an issue as it
>> gets,
>> it's just curiosity).
>>
>> Until then, it seems that the username "~gnu" is not taken. Maybe
>> someone more entitled than me could mirror a few repositories over
>> there
>> for testing purposes?
>>
>
> See my other mail just sent. ~emacs is owned by me as for now, unless
> ~gnu is preferred :)

Sounds like a good start! We could try assigning a few bug reports to
sr.ht and its workflow, and see how that goes -- merging the fixes back
into savannah (assuming everything works well enough to actually get the
bugs fixed!).

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

>>
>> So that would be something like git.sr.ht/~eliz/emacs or
>> git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the user
>> names are in the sourcehut code base.  Assuming the GNU project would
>> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
>> source.gnu.org, or whatever, would it still be possible to remove the
>> "~..." username part? (I know this is as minor of an issue as it gets,
>> it's just curiosity).
>>
>> Until then, it seems that the username "~gnu" is not taken.  Maybe
>> someone more entitled than me could mirror a few repositories over there
>> for testing purposes?
>>
>
> See my other mail just sent.  ~emacs is owned by me as for now, unless
> ~gnu is preferred :)

My understanding is that this would be a practical demonstration right?
(I believe the consensus last time was that the service should be hosted
on FSF servers.) If that is the case, I think that if you could set up a
few example repositories (emacs, elpa, nongnu) on git., import a few
mailing list archives on lists. and make up some issues on todo. then
the discussion could become more concrete and the path forward more
clear.

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Philip Kaludercic <philipk@posteo.net> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>>>
>>> So that would be something like git.sr.ht/~eliz/emacs or
>>> git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the user
>>> names are in the sourcehut code base.  Assuming the GNU project would
>>> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
>>> source.gnu.org, or whatever, would it still be possible to remove the
>>> "~..." username part? (I know this is as minor of an issue as it gets,
>>> it's just curiosity).
>>>
>>> Until then, it seems that the username "~gnu" is not taken.  Maybe
>>> someone more entitled than me could mirror a few repositories over there
>>> for testing purposes?
>>>
>>
>> See my other mail just sent.  ~emacs is owned by me as for now, unless
>> ~gnu is preferred :)
>
> My understanding is that this would be a practical demonstration right?
> (I believe the consensus last time was that the service should be hosted
> on FSF servers.) If that is the case, I think that if you could set up a
> few example repositories (emacs, elpa, nongnu) on git., import a few
> mailing list archives on lists. and make up some issues on todo. then
> the discussion could become more concrete and the path forward more
> clear.
>

I'll set this up asap, and see where we will go from this.

And yes, this will be for demotstration purposes for the time being.

> -- 
> 	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>
> I'll set this up asap, and see where we will go from this.
>
> And yes, this will be for demotstration purposes for the time being.
>

Ok, now there at least is something to look at there:

Repo: https://git.sr.ht/~emacs/emacs
Todo: https://todo.sr.ht/~emacs/emacs
List: https://lists.sr.ht/~emacs/emacs-devel

Feel free to post things and to look at it.  We can figure out how to
hook in builds and proper mirroring sometime later, if someone still is
interested in this.

Theo

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

>>
>> I'll set this up asap, and see where we will go from this.
>>
>> And yes, this will be for demotstration purposes for the time being.
>>
>
> Ok, now there at least is something to look at there:
>
> Repo: https://git.sr.ht/~emacs/emacs
> Todo: https://todo.sr.ht/~emacs/emacs
> List: https://lists.sr.ht/~emacs/emacs-devel

From what I remember you can import a mbox into a mailing list, right?
Could you download the most recent archive from
https://mail.gnu.org/archive/html/emacs-devel/2021-12/threads.html,
replace emacs-devel@gnu.org with ~emacs/emacs-devel@lists.sr.ht to see
how that looks like?

> Feel free to post things and to look at it.  We can figure out how to
> hook in builds and proper mirroring sometime later, if someone still is
> interested in this.
>
> Theo

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

> From what I remember you can import a mbox into a mailing list, right?
> Could you download the most recent archive from
> https://mail.gnu.org/archive/html/emacs-devel/2021-12/threads.html,
> replace emacs-devel@gnu.org with ~emacs/emacs-devel@lists.sr.ht to see
> how that looks like?
>

Done.  I only imported the december 2021 mbox, but that should be
sufficient, I think :)


Repo: https://git.sr.ht/~emacs/emacs
Todo: https://todo.sr.ht/~emacs/emacs
List: https://lists.sr.ht/~emacs/emacs-devel


Theo

Re: Migrating to sourcehut - what's missing?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Tue, Dec 21, 2021 at 11:28:32PM +0100, Theodor Thornhill wrote:
> 
> >
> > I'll set this up asap, and see where we will go from this.
> >
> > And yes, this will be for demotstration purposes for the time being.
> >
> 
> Ok, now there at least is something to look at there:
> 
> Repo: https://git.sr.ht/~emacs/emacs
> Todo: https://todo.sr.ht/~emacs/emacs
> List: https://lists.sr.ht/~emacs/emacs-devel

Nice :)

I like it. Refreshingly unobtrusive.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Migrating to sourcehut - what's missing?

[Po Lu]

Since this discussion is here to stay, here's two cents of mine.

<tomas@tuxteam.de> writes:

>> List: https://lists.sr.ht/~emacs/emacs-devel

It seems that the mailing list archive is not very usable:

  - It shows messages and replies in the entire thread, without a way to
    present an overview of the thread.
  - It doesn't seem to provide the ability to reply to specific messages
    in a thread via a mailto: link.  (Useful when I need to reply to
    something while away from my usual machine.)
  - It doesn't archive messages by period, but instead by pages.

There are probably a few more issues, but the ones I listed were enough
to put me back.  So until those issues are resolved, I hope we will not
move the mailing list archive to SourceHut.

I did not try out the others features of SourceHut, so I have not formed
an opinion about them.

Re: Migrating to sourcehut - what's missing?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

On Wed, Dec 22, 2021 at 05:40:56PM +0800, Po Lu wrote:
> Since this discussion is here to stay, here's two cents of mine.
> 
> <tomas@tuxteam.de> writes:
> 
> >> List: https://lists.sr.ht/~emacs/emacs-devel
> 
> It seems that the mailing list archive is not very usable:

[...]

good points.

> I did not try out the others features of SourceHut, so I have not formed
> an opinion about them.

TBH, I only looked at the git repo interface; I've yet to find a mailing
list archive web interface I could classify as satisfying [1]. Given your
description, the sr.ht interface isn't an exception.

I've come to the conclusion that I must be weird :)

Cheers

[1] among others: why do thread indexes to be broken at arbitrary (e.g.
   monthly) time intervals?

-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> It seems that the mailing list archive is not very usable:
>
>   - It shows messages and replies in the entire thread, without a way to
>     present an overview of the thread.
>   - It doesn't seem to provide the ability to reply to specific messages
>     in a thread via a mailto: link.  (Useful when I need to reply to
>     something while away from my usual machine.)
>   - It doesn't archive messages by period, but instead by pages.

Agreed on all these points.

Could you open tickets for them?  According to this page

    https://todo.sr.ht/~sircmpwn/lists.sr.ht

you would start by mailing ~sircmpwn/sr.ht-discuss@lists.sr.ht with your
observations.  The procedure they seem to prefer is that they will then
confirm the issue(s) before you open the ticket(s).

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> Ok, now there at least is something to look at there:
>
> Repo: https://git.sr.ht/~emacs/emacs
> Todo: https://todo.sr.ht/~emacs/emacs
> List: https://lists.sr.ht/~emacs/emacs-devel
>
> Feel free to post things and to look at it.  We can figure out how to
> hook in builds and proper mirroring sometime later, if someone still is
> interested in this.

Thanks for doing this work.

I've clicked around for a few minutes, and it looks really good to me.

One thing that's not quite clear to me -- will we be able to import the
old bug reports from debbugs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> One thing that's not quite clear to me -- will we be able to import
> the old bug reports from debbugs?

Another problem: will there be something like the Debbugs SOAP frontend
for SourceHut?

I find the ability to interact with the bug tracker inside Emacs quite
convenient, and it would be a shame to switch to a system where that
isn't available.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 13:19:52 CET, Po Lu <luangruo@yahoo.com> wrote:
>Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> One thing that's not quite clear to me -- will we be able to import
>> the old bug reports from debbugs?
>
>Another problem: will there be something like the Debbugs SOAP frontend
>for SourceHut?
>
>I find the ability to interact with the bug tracker inside Emacs quite
>convenient, and it would be a shame to switch to a system where that
>isn't available.

There is a cli in the works, and the api is open, so yes :) 

Re: Migrating to sourcehut - what's missing?

[Po Lu]

Theodor Thornhill <theo@thornhill.no> writes:

> On 22 December 2021 13:19:52 CET, Po Lu <luangruo@yahoo.com> wrote:
>>Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> One thing that's not quite clear to me -- will we be able to import
>>> the old bug reports from debbugs?
>>
>>Another problem: will there be something like the Debbugs SOAP frontend
>>for SourceHut?
>>
>>I find the ability to interact with the bug tracker inside Emacs quite
>>convenient, and it would be a shame to switch to a system where that
>>isn't available.

> There is a cli in the works, and the api is open, so yes :) 

I'm asking whether or not there's a package for that which already
exists, not if it can be done.  Thanks.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 14:01:30 CET, Po Lu <luangruo@yahoo.com> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> On 22 December 2021 13:19:52 CET, Po Lu <luangruo@yahoo.com> wrote:
>>>Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>
>>>> One thing that's not quite clear to me -- will we be able to import
>>>> the old bug reports from debbugs?
>>>
>>>Another problem: will there be something like the Debbugs SOAP frontend
>>>for SourceHut?
>>>
>>>I find the ability to interact with the bug tracker inside Emacs quite
>>>convenient, and it would be a shame to switch to a system where that
>>>isn't available.
>
>> There is a cli in the works, and the api is open, so yes :) 
>
>I'm asking whether or not there's a package for that which already
>exists, not if it can be done.  Thanks.

Then no. I'll stop pushing now. 

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> Then no. I'll stop pushing now. 

Please do continue to keep pushing -- we won't make any progress on this
unless we explore, and what you're doing is very useful.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 14:05:05 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Then no. I'll stop pushing now. 
>
>Please do continue to keep pushing -- we won't make any progress on this
>unless we explore, and what you're doing is very useful.
>

OK! 

Docs for the legacy api for todos. Mind that all apis are transitioning to graphql. Some are done, some are not. 

Legacy:  https://man.sr.ht/todo.sr.ht/api.md
New: https://man.sr.ht/todo.sr.ht/graphql.md

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> Docs for the legacy api for todos. Mind that all apis are
> transitioning to graphql. Some are done, some are not.
>
> Legacy:  https://man.sr.ht/todo.sr.ht/api.md
> New: https://man.sr.ht/todo.sr.ht/graphql.md

Skimming both the legacy and the new interfaces, it seems like it'd be
pretty easy to make an interface that's similar to debbugs-gnu.

Is the new interface up and running already?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 14:17:28 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Docs for the legacy api for todos. Mind that all apis are
>> transitioning to graphql. Some are done, some are not.
>>
>> Legacy:  https://man.sr.ht/todo.sr.ht/api.md
>> New: https://man.sr.ht/todo.sr.ht/graphql.md
>
>Skimming both the legacy and the new interfaces, it seems like it'd be
>pretty easy to make an interface that's similar to debbugs-gnu.
>
>Is the new interface up and running already?
>

https://sourcehut.org/blog/2021-12-15-whats-cooking-december-2021/ mentions that todo is not completely done yet. It looks high priority though. 

Theo

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> https://sourcehut.org/blog/2021-12-15-whats-cooking-december-2021/
> mentions that todo is not completely done yet. It looks high priority
> though.

Ah, and it also has that thing that I've been missing from debbugs all
these years:

------
For example, the following commit message:

build: work around gcc 4.2 bug

Fix build with ancient gcc.

Fixes: https://todo.sr.ht/~arkanoid/foobar/666
Signed-off-by: John Doe <john@doe.io>

Will cause the following change on the referenced issue:

~arkanoid UNRESOLVED -> FIXED 9 seconds ago
------

So we won't have to both do a commit and then send a message to debbugs,
so one step less.  Nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Theodor Thornhill <theo@thornhill.no> writes:

> https://sourcehut.org/blog/2021-12-15-whats-cooking-december-2021/
> mentions that todo is not completely done yet. It looks high priority
> though.

Could we just use the old API for the migration, or is there anything in
the new API we would need?  I assume the old one will not be immediately
removed once the new one is out, so maybe we could just rely on that
instead of waiting.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 17:53:40 CET, Stefan Kangas <stefankangas@gmail.com> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> https://sourcehut.org/blog/2021-12-15-whats-cooking-december-2021/
>> mentions that todo is not completely done yet. It looks high priority
>> though.
>
>Could we just use the old API for the migration, or is there anything in
>the new API we would need?  I assume the old one will not be immediately
>removed once the new one is out, so maybe we could just rely on that
>instead of waiting.

Apart from graphql being more fun, I _think_ migration would be fine. However, these may be questions for the Srht people

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

And we've probably covered this before, but I've forgotten: What's the
CI situation at Sourcehut?  I poked around briefly, but didn't see
anything in

  https://git.sr.ht/~emacs/emacs

Is it an add-on service?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 14:38:43 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>And we've probably covered this before, but I've forgotten: What's the
>CI situation at Sourcehut?  I poked around briefly, but didn't see
>anything in
>
>  https://git.sr.ht/~emacs/emacs
>
>Is it an add-on service?
>

You just supply a build.yml, and it runs on many platforms. See https://man.sr.ht/builds.sr.ht/

Theo

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Theodor Thornhill <theo@thornhill.no> writes:

> You just supply a build.yml, and it runs on many platforms. See
> https://man.sr.ht/builds.sr.ht/

D'oh.  I didn't notice the buttons at the top of

  https://git.sr.ht/~emacs/emacs


[-- Attachment #2: Type: image/png, Size: 39305 bytes --]

[-- Attachment #3: Type: text/plain, Size: 33 bytes --]


Were they really always there?


[-- Attachment #4: Type: image/png, Size: 39258 bytes --]

[-- Attachment #5: Type: text/plain, Size: 256 bytes --]


Oh!  They showed up because I created an account there -- but if you're
not logged in, the links to builds/todo/lists aren't there.

That's confusing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 14:47:44 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> You just supply a build.yml, and it runs on many platforms. See
>> https://man.sr.ht/builds.sr.ht/
>
>D'oh.  I didn't notice the buttons at the top of
>
>  https://git.sr.ht/~emacs/emacs
>

Ah! Yeah:) if you want to, I can ask drew to give us a free trial, so that you can submit builds to check how it works? 

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> Ah! Yeah:) if you want to, I can ask drew to give us a free trial, so
> that you can submit builds to check how it works?

I've got a paid account, so I can submit a job.  What would the yaml
file for Emacs look like?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 15:00:38 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Ah! Yeah:) if you want to, I can ask drew to give us a free trial, so
>> that you can submit builds to check how it works?
>
>I've got a paid account, so I can submit a job.  What would the yaml
>file for Emacs look like?
>

Something like this

image: archlinux
packages:
  - gcc
  - foo
sources:
  - https://git.sr.ht/~emacs/emacs
tasks:
  - setup: |
      Setup things here
  - test: |
      Etc ntc

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

I made a proper yaml file for sourcehut to see what the build looks
like, and I'm pretty impressed.  You get a nice interactive update,
which is handy when poking at stuff, and if the build fails, it offers
you the possibility to ssh into the VM to check stuff, which sounds like
something that could be very handy.

The VMs at sr.ht aren't exactly fast (a normal build took 23 minutes),
but I guess that's just a question of how much money the FSF is willing
to put into the build server.

My dream is to have a CI that'll tell me within a minute of pushing a
change about all the systems I've broken the build on, but I guess that
will probably have to remain a dream (unless the FSF has more money than
it should).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I made a proper yaml file for sourcehut to see what the build looks
> like

I forgot to include it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

[-- Attachment #2: emacs.yml --]
[-- Type: application/octet-stream, Size: 713 bytes --]

image: debian/bookworm
packages:
  - libncurses5-dev
  - texinfo
  - liblockfile-dev
  - librsvg2-dev
  - dbus-x11
  - git
  - gnupg-agent
  - libgif-dev
  - libtiff-dev
  - libsystemd-dev
  - procps
  - xaw3dg-dev
  - libpng-dev
  - libjpeg-dev
  - libwebp-dev
  - libm17n-dev
  - libotf-dev
  - libgpm-dev
  - libdbus-1-dev
  - autoconf
  - automake
  - libxaw7-dev
  - sharutils
  - libcairo-dev
  - libgmp-dev
  - libgtk-3-dev
  - libgnutls28-dev
  - libxml2-dev
  - libselinux1-dev
  - libharfbuzz-dev
  - libjansson-dev
  - libasound2-dev
  - libacl1-dev
  - zlib1g-dev
  - libsqlite3-dev
sources:
  - https://git.sr.ht/~emacs/emacs
tasks:
  - build: |
      cd emacs
      make -j2
      cd test; make -j2

Re: Migrating to sourcehut - what's missing?

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> My dream is to have a CI that'll tell me within a minute of pushing a
> change about all the systems I've broken the build on, but I guess that
> will probably have to remain a dream (unless the FSF has more money than
> it should).

The Emacs build has several parts with no paralellization. In my humble
8-thread machine most of the 4.5 minutes it takes to build (without
native-comp) only one thread is active, and today's CPUs are not much
faster than mine doing single-threaded tasks.

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> The Emacs build has several parts with no paralellization. In my humble
> 8-thread machine most of the 4.5 minutes it takes to build (without
> native-comp) only one thread is active, and today's CPUs are not much
> faster than mine doing single-threaded tasks.

It takes about two minutes to build Emacs on my 3.6GHz/8 core build
machine, and about half of that is single-threaded (I did a long
analysis of the build process on a thread here somewhere).  So getting
down to 1 minute is probably feasible.

But convincing somebody to buy a CI server like that will probably
remain a beautiful dream.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> The Emacs build has several parts with no paralellization. In my humble
>> 8-thread machine most of the 4.5 minutes it takes to build (without
>> native-comp) only one thread is active, and today's CPUs are not much
>> faster than mine doing single-threaded tasks.
>
> It takes about two minutes to build Emacs on my 3.6GHz/8 core build
> machine, and about half of that is single-threaded (I did a long
> analysis of the build process on a thread here somewhere).

Double the threads plus some improvements on single-thread execution,
2 minutes sounds right.

> So getting down to 1 minute is probably feasible.

You will need many threads and a fast CPU for that :-) More so as new
barriers are made apparent as you increase the threads. Plus the machine
will often execute more than one build on parallel, or queue them.

> But convincing somebody to buy a CI server like that will probably
> remain a beautiful dream.

Yeah, only in dreams I could have enough spare money to donate a 64-core
machine to the FSF ;-)

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Yeah, only in dreams I could have enough spare money to donate a 64-core
> machine to the FSF ;-)

128 core 5.5GHz CPU or bust!

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 20:08:11 +0100
> 
> The Emacs build has several parts with no paralellization. In my humble
> 8-thread machine most of the 4.5 minutes it takes to build (without
> native-comp) only one thread is active, and today's CPUs are not much
> faster than mine doing single-threaded tasks.

If you have 8 threads, why don't you use "make -j8"?  Then most of the
time you'd see 8 compilation processes run in parallel.  That's what I
see here.

Re: Migrating to sourcehut - what's missing?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The Emacs build has several parts with no paralellization. In my humble
>> 8-thread machine most of the 4.5 minutes it takes to build (without
>> native-comp) only one thread is active, and today's CPUs are not much
>> faster than mine doing single-threaded tasks.
>
> If you have 8 threads, why don't you use "make -j8"?

That's what I use.

> Then most of the time you'd see 8 compilation processes run in
> parallel.
>
> That's what I see here.

Probably you are talking about an incremental build. Lars refers to a
C.I. build, which always does a full build, starting with `git clone'
(or `git clean -fdx && git pull'), then `autogen.sh', `configure' and
`make bootstrap'. What takes 4.5 minutes in my machine starts with
`autogen.sh'. The C.I. system would also run the test suite.

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 21:14:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The Emacs build has several parts with no paralellization. In my humble
> >> 8-thread machine most of the 4.5 minutes it takes to build (without
> >> native-comp) only one thread is active, and today's CPUs are not much
> >> faster than mine doing single-threaded tasks.
> >
> > If you have 8 threads, why don't you use "make -j8"?
> 
> That's what I use.
> 
> > Then most of the time you'd see 8 compilation processes run in
> > parallel.
> >
> > That's what I see here.
> 
> Probably you are talking about an incremental build.

No, I'm talking about a fresh build, or bootstrap, or a build after
all the *.elc files have been deleted.

The only single-threaded parts I see is (a) the configure script (and
autogen.sh, if that needs to be run), and (b) the link stage of the
Emacs executable.  Everything else runs in parallel, and if I says
"make -j8" I see load-average show numbers around 8 most of the time
on the mode line.

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The only single-threaded parts I see is (a) the configure script (and
> autogen.sh, if that needs to be run), and (b) the link stage of the
> Emacs executable.  Everything else runs in parallel, and if I says
> "make -j8" I see load-average show numbers around 8 most of the time
> on the mode line.

See

https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00104.html

Summary:

> But to sum up, (+ 22 12 37 4) => 75 seconds of the Emacs compilation is
> single-threaded, while 90 seconds are multi-threaded (and as machines
> get more and more cores, we'll probably see the single-threaded parts
> take more than 50% of the time spent).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 21:14:37 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> The Emacs build has several parts with no paralellization. In my humble
>> >> 8-thread machine most of the 4.5 minutes it takes to build (without
>> >> native-comp) only one thread is active, and today's CPUs are not much
>> >> faster than mine doing single-threaded tasks.
>> >
>> > If you have 8 threads, why don't you use "make -j8"?
>> 
>> That's what I use.
>> 
>> > Then most of the time you'd see 8 compilation processes run in
>> > parallel.
>> >
>> > That's what I see here.
>> 
>> Probably you are talking about an incremental build.
>
> No, I'm talking about a fresh build, or bootstrap, or a build after
> all the *.elc files have been deleted.

If I execute

rm -rf * && time make bootstrap -j9

on the build directory, it takes 1m28s. If I go to the source directory
and:

git clean -fdx && ./autogen.sh

then go back to the build directory and:

rm -rf * && time ../emacs/configure  --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick

20s

time make -j9

4m9s

Apart from the configure script and dumping, the bulk of the time the
build is running single-threaded is while doing:

INFO     Processing OKURI-NASI entries...

and even longer:

INFO     Scraping files for loaddefs.el...

BTW, this is in Debian Testing.

> The only single-threaded parts I see is (a) the configure script (and
> autogen.sh, if that needs to be run), and (b) the link stage of the
> Emacs executable.  Everything else runs in parallel, and if I says
> "make -j8" I see load-average show numbers around 8 most of the time
> on the mode line.

Try building after `git clean -fdx'.

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've got a paid account, so I can submit a job.  What would the yaml
> file for Emacs look like?

Well, that was easy:

image: archlinux
packages:
  - cairo
sources:
  - https://git.sr.ht/~emacs/emacs
tasks:
  - build: |
      cd emacs
      make

OK, that failed because I don't have all the packages installed in the
"packages" section, but it otherwise looks quite good.

The only OS images are from free operating systems, though, so no
Windows or Macos.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The only OS images are from free operating systems, though, so no
> Windows or Macos.

Could that be resolved with self-hosting?  Assuming we are allowed to
put proprietary junk on GNU servers for testing...

Re: Migrating to sourcehut - what's missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Could that be resolved with self-hosting?  Assuming we are allowed to
  > put proprietary junk on GNU servers for testing...

No way!

Not only because we dont want any nonfree software installed on our
machines, but also because we don't want to give the impression
that support for nonfree systems is a priority for us.

We invite people to volunteer to maintain support for them,
but we won't treat those systems as if they deserve support.

See the node Platforms in Information for Maintainers of GNU Software.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 15:00:38 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Ah! Yeah:) if you want to, I can ask drew to give us a free trial, so
>> that you can submit builds to check how it works?
>
>I've got a paid account, so I can submit a job. 

Well, I did it anyway. If anyone wants to try CI in srht without paying, ping me after making a free account there, so I can give you rw access to the ~emacs/emacs repo. It's available the next 3 months. 

Theo

Re: Migrating to sourcehut - what's missing?

[Jean-Christophe Helary]

> On Dec 22, 2021, at 22:38, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> And we've probably covered this before, but I've forgotten: What's the
> CI situation at Sourcehut?  I poked around briefly, but didn't see
> anything in
> 
>  https://git.sr.ht/~emacs/emacs
> 
> Is it an add-on service?

https://builds.sr.ht

No, but it is limited to paying users because of the abuse they've had to deal with:

https://lists.sr.ht/~sircmpwn/sr.ht-announce/%3CCC4AKM5UKA8G.SF6QBMUFZ4XJ%40taiga%3E

Documentation:
https://man.sr.ht/builds.sr.ht/

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 12:57:17 CET, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>Theodor Thornhill <theo@thornhill.no> writes:
>
>> Ok, now there at least is something to look at there:
>>
>> Repo: https://git.sr.ht/~emacs/emacs
>> Todo: https://todo.sr.ht/~emacs/emacs
>> List: https://lists.sr.ht/~emacs/emacs-devel
>>
>> Feel free to post things and to look at it.  We can figure out how to
>> hook in builds and proper mirroring sometime later, if someone still is
>> interested in this.
>
>Thanks for doing this work.
>
>I've clicked around for a few minutes, and it looks really good to me.
>
>One thing that's not quite clear to me -- will we be able to import the
>old bug reports from debbugs?


Yes. They need to be converted to a json following their specs. Should be doable, and when the graphql api is ready it should be even easier to make an emacs frontend. 

>

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

After futzing around with the bug tracker, I think that it's going to be
pretty annoying to work with in its current state.  See:

  https://todo.sr.ht/~emacs/emacs/1

The main problem is that the email integration is lacking.  The mails it
sends out are unreadable, and when you send mails to it, they'll usually
end up being unreadable on the web interface.

It sounds like fixing this on the er todo list, but is not a priority.
So I don't think moving to it is an option at this time.

But working on importing debbugs into it would be useful anyway (if they
ever fix the mail stuff).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> After futzing around with the bug tracker, I think that it's going to be
> pretty annoying to work with in its current state.  See:
>
>   https://todo.sr.ht/~emacs/emacs/1
>
> The main problem is that the email integration is lacking.  The mails it
> sends out are unreadable, and when you send mails to it, they'll usually
> end up being unreadable on the web interface.
>

That would imply that moving to sourcehut in general is not desired as
of yet, correct?  I mean, lists are off the table, and there are some
todo problems as you mentioned.  Then this discussion probably can rest
for some time :)

Thanks for your patience though!

Theo

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Theodor Thornhill <theo@thornhill.no> writes:

> That would imply that moving to sourcehut in general is not desired as
> of yet, correct?  I mean, lists are off the table, and there are some
> todo problems as you mentioned.  Then this discussion probably can rest
> for some time :)

We're getting closer, though.  I think the mail issues on todo could
probably be solved by somebody pretty quickly if they work with the
Sourcehut people to get it implemented.

(But I'm not volunteering.  😀)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> We're getting closer, though.  I think the mail issues on todo could
> probably be solved by somebody pretty quickly if they work with the
> Sourcehut people to get it implemented.
>
> (But I'm not volunteering.  😀)

So just to clarify, it sounds like SourceHut is not yet ready, but still
is the most likely candidate?

For example, GitLab is even further away and AFAICT don't even have a
long-term plan to make any of the necessary changes.

Re: Migrating to sourcehut - what's missing?

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> So just to clarify, it sounds like SourceHut is not yet ready, but still
> is the most likely candidate?

BTW, it seems that the Guix people have a system that provides a web
interface to debbugs, much like SourceHut's bug tracker.  It seems to
even allow people to reply to issues:

  https://git.elephly.net/gitweb.cgi?p=software/mumi.git

It seems to me that the easiest way to make the bug tracker more
accessible would be to extend Mumi to allow creating issues.

Does anyone want to work on this?

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> So just to clarify, it sounds like SourceHut is not yet ready, but still
> is the most likely candidate?

Yes, I think so.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, Philip Kaludercic
>  <philipk@posteo.net>, emacs-devel@gnu.org
> Date: Thu, 23 Dec 2021 09:53:37 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > After futzing around with the bug tracker, I think that it's going to be
> > pretty annoying to work with in its current state.  See:
> >
> >   https://todo.sr.ht/~emacs/emacs/1
> >
> > The main problem is that the email integration is lacking.  The mails it
> > sends out are unreadable, and when you send mails to it, they'll usually
> > end up being unreadable on the web interface.
> >
> 
> That would imply that moving to sourcehut in general is not desired as
> of yet, correct?  I mean, lists are off the table, and there are some
> todo problems as you mentioned.  Then this discussion probably can rest
> for some time :)

From my POV, the problem is not with how mailing lists are handled
there, the problem is with how email communications are handled when
those are involved in discussing patches and other issues.  AFAIU,
this is what Lars was flagging, not the way mailing lists are hosted
there: we don't intend to move the Emacs mailing lists to sourcehut,
we just want to move the bug tracker and its related functionalities,
and that includes sending and receiving email.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>From my POV, the problem is not with how mailing lists are handled
>there, the problem is with how email communications are handled when
>those are involved in discussing patches and other issues.  AFAIU,
>this is what Lars was flagging, not the way mailing lists are hosted
>there: we don't intend to move the Emacs mailing lists to sourcehut,
>we just want to move the bug tracker and its related functionalities,
>and that includes sending and receiving email.

Yes, this would mean that emacs devs would have to adopt a markdown based approach, which I assume also is unwanted. 

I'm just glad this thread yielded some results, undecisive or not

Theo

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 10:22:47 +0100
> From: Theodor Thornhill <theo@thornhill.no>
> CC: larsi@gnus.org, eric@ericabrahamsen.net, philipk@posteo.net,
>  emacs-devel@gnu.org
> 
> >From my POV, the problem is not with how mailing lists are handled
> >there, the problem is with how email communications are handled when
> >those are involved in discussing patches and other issues.  AFAIU,
> >this is what Lars was flagging, not the way mailing lists are hosted
> >there: we don't intend to move the Emacs mailing lists to sourcehut,
> >we just want to move the bug tracker and its related functionalities,
> >and that includes sending and receiving email.
> 
> Yes, this would mean that emacs devs would have to adopt a markdown based approach, which I assume also is unwanted. 

We need to use Markdown in email messages?  That sounds tough on us,
isn't it?  I thought sourcehut was handling email exchange as
first-class citizen, which would mean that any format, including plain
text, is handled in some reasonable fashion.

> I'm just glad this thread yielded some results, undecisive or not

Yes, thanks.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 23 December 2021 10:53:40 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 23 Dec 2021 10:22:47 +0100
>> From: Theodor Thornhill <theo@thornhill.no>
>> CC: larsi@gnus.org, eric@ericabrahamsen.net, philipk@posteo.net,
>>  emacs-devel@gnu.org
>> 
>> >From my POV, the problem is not with how mailing lists are handled
>> >there, the problem is with how email communications are handled when
>> >those are involved in discussing patches and other issues.  AFAIU,
>> >this is what Lars was flagging, not the way mailing lists are hosted
>> >there: we don't intend to move the Emacs mailing lists to sourcehut,
>> >we just want to move the bug tracker and its related functionalities,
>> >and that includes sending and receiving email.
>> 
>> Yes, this would mean that emacs devs would have to adopt a markdown based approach, which I assume also is unwanted. 
>
>We need to use Markdown in email messages?  That sounds tough on us,
>isn't it?  I thought sourcehut was handling email exchange as
>first-class citizen, which would mean that any format, including plain
>text, is handled in some reasonable fashion.
>

You don't need to, but to get syntax highlighting for diffs in todo you currently have to, yes. The author expressed this as a shortcoming of the current implementation, but without plans for its conception. 


>> I'm just glad this thread yielded some results, undecisive or not
>
>Yes, thanks.

No problem - let's revisit this some other time, perhaps

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

Theodor Thornhill <theo@thornhill.no> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> After futzing around with the bug tracker, I think that it's going to be
>> pretty annoying to work with in its current state.  See:
>>
>>   https://todo.sr.ht/~emacs/emacs/1
>>
>> The main problem is that the email integration is lacking.  The mails it
>> sends out are unreadable, and when you send mails to it, they'll usually
>> end up being unreadable on the web interface.
>>
>
> That would imply that moving to sourcehut in general is not desired as
> of yet, correct?  I mean, lists are off the table, and there are some
> todo problems as you mentioned.  Then this discussion probably can rest
> for some time :)

Do you know if there are any estimates when Sourcehut is to leave the
beta phase?  I would guess that it would make sense to bring up the
topic when that happens (as long as the issues mentioned in this thread
are still noted by the Sourcehut developers).

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>Do you know if there are any estimates when Sourcehut is to leave the
>beta phase?  I would guess that it would make sense to bring up the
>topic when that happens (as long as the issues mentioned in this thread
>are still noted by the Sourcehut developers).
>

Not sure. Soon™, I presume!

Re: Migrating to sourcehut - what's missing?

[Sean Whitton]

Hello,

On Thu 23 Dec 2021 at 02:24PM GMT, Philip Kaludercic wrote:

> Do you know if there are any estimates when Sourcehut is to leave the
> beta phase?  I would guess that it would make sense to bring up the
> topic when that happens (as long as the issues mentioned in this thread
> are still noted by the Sourcehut developers).

It's alpha right now, but they've said [1] that the beta will only be
polish and documentation not features, so it's leaving the alpha that
matters most.

As for that, they said recently [2] that there's only rote work left:

    Our main focus this year has been on implementing our GraphQL API,
    which is now about halfway done. This is the main blocker for the
    SourceHut beta, and we have by now solved most of the unknowns and
    are working our way through the rote work of building out the
    remainder of the services.

[1]  https://sourcehut.org/alpha-details/#goals-for-the-beta-and-beyond
[2]  https://sourcehut.org/blog/2021-11-15-sourcehuts-third-year/

-- 
Sean Whitton

Re: Migrating to sourcehut - what's missing?

[Drew DeVault]

Please do not interpret "alpha" as meaning "unstable" or "incomplete".
It has a specific meaning within SourceHut that has to do with our
higher-than-average quality standards. The alpha details page covers the
specifics:

https://sourcehut.org/alpha-details/

The main thing which could trip you up is using the REST API, which is
slated for deprecation in favor of GraphQL (this is the biggest change
which defines the alpha).

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Theodor Thornhill <theo@thornhill.no>
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
> Date: Tue, 21 Dec 2021 23:28:32 +0100
> 
> Ok, now there at least is something to look at there:
> 
> Repo: https://git.sr.ht/~emacs/emacs
> Todo: https://todo.sr.ht/~emacs/emacs
> List: https://lists.sr.ht/~emacs/emacs-devel
> 
> Feel free to post things and to look at it.  We can figure out how to
> hook in builds and proper mirroring sometime later, if someone still is
> interested in this.

Thanks, but I think I'm missing something here.

First, why is emacs-devel mirrored there? we aren't going to migrate
the list archives to sourcehut, do we?  (The display of the list is
less useful than mailman archives, but since this is not supposed to
be the place to read the list, I'm not sure discussing this part is
useful.)

Next, where are the bugs? I thought migration from debbugs would mean
the bugs will be handled on sourcehut, but instead I see everything
but the bugs?  I'd like to see how bugs look there, and how to work
with bug reports and patches.  What did I miss?

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Repo: https://git.sr.ht/~emacs/emacs
>> Todo: https://todo.sr.ht/~emacs/emacs
>> List: https://lists.sr.ht/~emacs/emacs-devel

[...]

> Next, where are the bugs? I thought migration from debbugs would mean
> the bugs will be handled on sourcehut, but instead I see everything
> but the bugs?  I'd like to see how bugs look there, and how to work
> with bug reports and patches.  What did I miss?

Sourcehut calls the bug tracker "todo", so it's in the second link.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Theodor Thornhill <theo@thornhill.no>,  eric@ericabrahamsen.net,
>   philipk@posteo.net,  emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 16:14:44 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Repo: https://git.sr.ht/~emacs/emacs
> >> Todo: https://todo.sr.ht/~emacs/emacs
> >> List: https://lists.sr.ht/~emacs/emacs-devel
> 
> [...]
> 
> > Next, where are the bugs? I thought migration from debbugs would mean
> > the bugs will be handled on sourcehut, but instead I see everything
> > but the bugs?  I'd like to see how bugs look there, and how to work
> > with bug reports and patches.  What did I miss?
> 
> Sourcehut calls the bug tracker "todo", so it's in the second link.

But there seems to be nothing there but a single todo, where's the
rest?

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> But there seems to be nothing there but a single todo, where's the
> rest?

No issues have been imported yet, but you can see them discussing that
in that one todo.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 17:35:28 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Theodor Thornhill <theo@thornhill.no>,  eric@ericabrahamsen.net,
>>   philipk@posteo.net,  emacs-devel@gnu.org
>> Date: Wed, 22 Dec 2021 16:14:44 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Repo: https://git.sr.ht/~emacs/emacs
>> >> Todo: https://todo.sr.ht/~emacs/emacs
>> >> List: https://lists.sr.ht/~emacs/emacs-devel
>> 
>> [...]
>> 
>> > Next, where are the bugs? I thought migration from debbugs would mean
>> > the bugs will be handled on sourcehut, but instead I see everything
>> > but the bugs?  I'd like to see how bugs look there, and how to work
>> > with bug reports and patches.  What did I miss?
>> 
>> Sourcehut calls the bug tracker "todo", so it's in the second link.
>
>But there seems to be nothing there but a single todo, where's the
>rest?

As I said, they need to be converted. I haven't done that yet. You can add one now if you want to see how it works, but for to see a real debbug there the wait will be longer. The holidays slurps a lot of time these days :) I wanted to post something useful fast. If its not that, maybe things will improve in time. Contributions welcome

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 16:11:03 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Theodor Thornhill <theo@thornhill.no>
>> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
>> Date: Tue, 21 Dec 2021 23:28:32 +0100
>> 
>> Ok, now there at least is something to look at there:
>> 
>> Repo: https://git.sr.ht/~emacs/emacs
>> Todo: https://todo.sr.ht/~emacs/emacs
>> List: https://lists.sr.ht/~emacs/emacs-devel
>> 
>> Feel free to post things and to look at it.  We can figure out how to
>> hook in builds and proper mirroring sometime later, if someone still is
>> interested in this.
>
>Thanks, but I think I'm missing something here.
>
>First, why is emacs-devel mirrored there? we aren't going to migrate
>the list archives to sourcehut, do we?  (The display of the list is
>less useful than mailman archives, but since this is not supposed to
>be the place to read the list, I'm not sure discussing this part is
>useful.)
>
>Next, where are the bugs? I thought migration from debbugs would mean
>the bugs will be handled on sourcehut, but instead I see everything
>but the bugs?  I'd like to see how bugs look there, and how to work
>with bug reports and patches.  What did I miss?

You missed nothing, but seeing how that conversion isnt one click I didn't get to that yet. As for the mailing list, it is just for demo. 

Re: Migrating to sourcehut - what's missing?

[Dmitry Gutov]

On 22.12.2021 18:16, Theodor Thornhill wrote:
> As for the mailing list, it is just for demo.

That's too bad: low accessibility of the mailing lists for the average 
user will remain a barrier for participation.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 16:22:46 CET, Dmitry Gutov <dgutov@yandex.ru> wrote:
>On 22.12.2021 18:16, Theodor Thornhill wrote:
>> As for the mailing list, it is just for demo.
>
>That's too bad: low accessibility of the mailing lists for the average user will remain a barrier for participation.

Not sure if I understand what you mean. I converted some mails from emacs-devel to show what it would look like. The list is functional. It can be used or not, improvements can be made :) 

Re: Migrating to sourcehut - what's missing?

[Dmitry Gutov]

On 22.12.2021 18:45, Theodor Thornhill wrote:
> 
> On 22 December 2021 16:22:46 CET, Dmitry Gutov<dgutov@yandex.ru>  wrote:
>> On 22.12.2021 18:16, Theodor Thornhill wrote:
>>> As for the mailing list, it is just for demo.
>> That's too bad: low accessibility of the mailing lists for the average user will remain a barrier for participation.
> Not sure if I understand what you mean. I converted some mails from emacs-devel to show what it would look like. The list is functional. It can be used or not, improvements can be made:)  

Well I hope if we do switch to SourceHut, we would be able to migrate 
the mailing lists as well.

The threading feature in there seems less reliable than on Mailman, but 
that seems fixable.

OTOH, a better search and the "Reply to thread" button should at least 
be a step toward being more approachable.

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 22.12.2021 18:16, Theodor Thornhill wrote:
>> As for the mailing list, it is just for demo.
>
> That's too bad: low accessibility of the mailing lists for the average
> user will remain a barrier for participation.

I guess it's a demo *for now*.  We have not yet decided to migrate the
mailing list there, but we have also not decided to never do that, ever.

To lower the barrier, I'd focus on migrating the bug tracker, git,
etc. first and leave the mailing list(s) for later.  Once we have
migrated the important bits, we can consider the proposal to also move
the mailing list in more detail.  Of course, some will fear that
migrating the mailing list will then never happen, but on the other hand
we shouldn't let the perfect be the enemy of the good.

I'm personally not too happy with the features of lists.sr.ht right now,
but it's neither worse nor better than Mailman (in my use).  However, if
the mailing list archives on sr.ht improves significantly over the next
year or three, perhaps it can outdo Mailman and convince even the
skeptics at that point.

So I suggest we do what Eli says and leave this to one side for the
moment.

Re: Migrating to sourcehut - what's missing?

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

>> That's too bad: low accessibility of the mailing lists for the average
>> user will remain a barrier for participation.
>
> I guess it's a demo *for now*.  We have not yet decided to migrate the
> mailing list there, but we have also not decided to never do that, ever.

Yup.  I think the web interface on sourcehut would be more intuitive and
friendly for many users, so I wouldn't rule out moving the Emacs mailing
lists/archive to a sourcehut installation, either.  But it needs some
work first, I think.

> To lower the barrier, I'd focus on migrating the bug tracker, git,
> etc. first and leave the mailing list(s) for later.  Once we have
> migrated the important bits, we can consider the proposal to also move
> the mailing list in more detail.

Sounds like a plan to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 22 Dec 2021 08:07:22 -0800
> Cc: eric@ericabrahamsen.net, philipk@posteo.net, emacs-devel@gnu.org
> 
> We have not yet decided to migrate the mailing list there, but we
> have also not decided to never do that, ever.

No, sorry: migrating the Emacs mailing lists from mailman is not on
the table.  You are probably not aware of the infrastructure that we
enjoy with mailman-driven lists.gnu.org and its support by GNU
volunteers.  Ask yourself how come there's absolutely no spam on our
lists (except what we ourselves post there ;-), ever.  That's not a
miracle, but hard work by several people, day in and day out.  There
are large and important projects, including GNU projects, that don't
use lists.gnu.org, and their mailing lists are worse, in both
cleanliness and features like search, possibility to download past
messages, etc.

So we are not moving our lists from lists.gnu.org any time soon.

> To lower the barrier, I'd focus on migrating the bug tracker, git,
> etc. first and leave the mailing list(s) for later.  Once we have
> migrated the important bits, we can consider the proposal to also move
> the mailing list in more detail.  Of course, some will fear that
> migrating the mailing list will then never happen, but on the other hand
> we shouldn't let the perfect be the enemy of the good.

It's not just to lower the barrier: moving the bug tracker was the
single most important reason why we are doing this.  Please leave all
the other jobs alone.  The perfect is the worst enemy of the good.

> I'm personally not too happy with the features of lists.sr.ht right now,
> but it's neither worse nor better than Mailman (in my use).

Oh no, it's much worse.  Maybe not for you, but I'm the genie in the
bottle behind the management of the Emacs lists, and I'm telling you:
what we have on lists.gnu.org is much better, and doing the same
elsewhere will require a lot of work and volunteers to get to the same
level.  We didn't get there overnight, either: try looking at the
archives of bug-gnu-emacs 10 or 15 years ago, and you will see the
catastrophe we needed to deal with back then.

> So I suggest we do what Eli says and leave this to one side for the
> moment.

Yes, please!

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Dec 2021 17:22:46 +0200
> Cc: eric@ericabrahamsen.net, philipk@posteo.net, emacs-devel@gnu.org
> 
> On 22.12.2021 18:16, Theodor Thornhill wrote:
> > As for the mailing list, it is just for demo.
> 
> That's too bad: low accessibility of the mailing lists for the average 
> user will remain a barrier for participation.

??? What about https://lists.gnu.org/archive/html/emacs-devel/ ?  It's
as accessible as sourcehut, isn't it?  And allows to reply to
messages.

So I don't think I understand the comment.

Re: Migrating to sourcehut - what's missing?

[Dmitry Gutov]

On 22.12.2021 19:44, Eli Zaretskii wrote:
> And allows to reply to
> messages.

But not to the mailing list.

Which is what sourcehut's web UI (much younger than Mailman) allows you 
to do.

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> Cc: theo@thornhill.no, eric@ericabrahamsen.net, philipk@posteo.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 23 Dec 2021 00:16:51 +0200
> 
> On 22.12.2021 19:44, Eli Zaretskii wrote:
> > And allows to reply to
> > messages.
> 
> But not to the mailing list.
> 
> Which is what sourcehut's web UI (much younger than Mailman) allows you 
> to do.

Would someone like to work on providing the capability of replying to
the mailing list (or, alternatively, "Reply All") from the Web form of
reading the emacs-devel archives?  I asked the GNU staff and got this
in response:

> Yes, I think replicating the reply-all behavior from clients like emacs
> would be best, but even just replying to the list would be better.
> 
> mharc + mhonarc generates these pages, using $FROMNAME$ in the html
> template. I just took a look at the source code for mhonarc which
> populates FROMNAME and don't see any other variable that does the job we
> want, but I could have missed it, I don't see a general list of them. So
> it might require a patch to the perl code in the package mhonarc version
> 2.6.19-2, you can get it from any debian based distro. I don't have the
> time to make the patch, but I can review and apply any that someone else
> makes. The templates we use are in
> https://vcs.fsf.org/?p=mharc.git;a=tree

It sounds like the job might be simple enough, provided that you have
a working knowledge of Perl programming.

If someone would like to make this happen, please respond to this
message, either to the list or to me privately.  If this feature is
added, it will probably benefit all the GNU mailing lists managed and
archived by mailman.

TIA

Re: Migrating to sourcehut - what's missing?

[john muhl]

On Thu, 2021-12-23 at 00:16 +0200, Dmitry Gutov wrote:
> On 22.12.2021 19:44, Eli Zaretskii wrote:
> > And allows to reply to messages.
> 
> But not to the mailing list.
> 
> Which is what sourcehut's web UI (much younger than Mailman) allows
> you to do.

sourcehut lists do not let you create new posts or reply to posts from
the web. it provides mailto links when you are browsing on the web;
the same as mailman except the difference in what comes after the
mailto:.

what sourcehut does do is provide a web based git send-email workflow.
to use that the user needs a sourcehut hosted clone of emacs with
their changes pushed. there is no need for emacs itself to be on
sourcehut for users to take advantage of the web ui. the resulting
email looks identical to a git send-email patch.

Re: Migrating to sourcehut - what's missing?

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 16:16:14 +0100
> From: Theodor Thornhill <theo@thornhill.no>
> CC: philipk@posteo.net, eric@ericabrahamsen.net, emacs-devel@gnu.org
> 
> You missed nothing, but seeing how that conversion isnt one click I didn't get to that yet. As for the mailing list, it is just for demo. 

Ah, okay.  Keep up the good work, and I will keep an eye on the site
and check out stuff when it's added.

Thanks.

Re: Migrating to sourcehut - what's missing?

[john muhl]

On Tue, 2021-12-21 at 21:24 +0000, Philip Kaludercic wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> 
> > Theodor Thornhill <theo@thornhill.no> writes:
> > 
> > > > Preferably any gotchas when installing should be noted down
> > > > somewhere
> > > > (e.g. sent to emacs-devel).
> > > > 
> > > > Next, I would start looking into those things that are still
> > > > missing.
> > > > For starters, they would need to be listed and it should be
> > > > ensured that
> > > > there are good feature requests on the sourcehut issue
> > > > tracker.  If the
> > > > sourcehut developers are willing to implement those things
> > > > then great,
> > > > otherwise it would be obviously be very useful if someone
> > > > would
> > > > volunteer to start working on those things.
> > > > 
> > > 
> > > Actually, I think that running Sourcehut as a local instance
> > > wouldn't
> > > really be necessary for the evaluation, because it is the same
> > > code that
> > > is running on sr.ht.  Apart from the fiddly bits with self
> > > hosting, the
> > > workflow should be the same.  I'd encourage people on this list
> > > getting
> > > their own user there and trying it out, as I think many already
> > > have.
> > > Specifically, emacs-devel would want to use the `meta`, `lists`,
> > > `git`,
> > > `todo` and `builds` subprojects, that is all apart from the `hg`
> > > one.
> > 
> > I wonder if it would make sense to have one of the maintainers
> > sign up
> > there and start a "pretend" official Emacs repo. They could start
> > a
> > mailing list alongside it that we could play with, and who knows,
> > maybe
> > that would eventually become the "real" official sr.ht repo.
> > 
> > Eric
> 
> So that would be something like git.sr.ht/~eliz/emacs or
> git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the
> user
> names are in the sourcehut code base.  Assuming the GNU project
> would
> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
> source.gnu.org, or whatever, would it still be possible to remove
> the
> "~..." username part? (I know this is as minor of an issue as it
> gets,
> it's just curiosity).
> 
> Until then, it seems that the username "~gnu" is not taken.  Maybe
> someone more entitled than me could mirror a few repositories over
> there
> for testing purposes?
> 

organizations on sourcehut are still a work in progress. Drew has
mentioned a few times that if you setup a work-around for the lack of
orgs now (e.g. a user named gnu, emacs, etc.) there will be a
migration path once the work on orgs is done. so i think the
transition from ~user to ^org is either not very important or will be
handled as support for organizations is deployed.

https://sourcehut.org/alpha-details/
https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC0L8LGIM0C2I.3O209D1TSO6M3%40homura%3E

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

john muhl <email@johnmuhl.mx> writes:

> On Tue, 2021-12-21 at 21:24 +0000, Philip Kaludercic wrote:
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> 
>> So that would be something like git.sr.ht/~eliz/emacs or
>> git.sr.ht/~lars/emacs?  This makes me wonder how "hard coded" the
>> user
>> names are in the sourcehut code base.  Assuming the GNU project
>> would
>> host its sourcehut instance on the domain git.gnu.org, srht.gnu.org,
>> source.gnu.org, or whatever, would it still be possible to remove
>> the
>> "~..." username part? (I know this is as minor of an issue as it
>> gets,
>> it's just curiosity).
>> 
>> Until then, it seems that the username "~gnu" is not taken.  Maybe
>> someone more entitled than me could mirror a few repositories over
>> there
>> for testing purposes?
>> 
>
> organizations on sourcehut are still a work in progress. Drew has
> mentioned a few times that if you setup a work-around for the lack of
> orgs now (e.g. a user named gnu, emacs, etc.) there will be a
> migration path once the work on orgs is done. so i think the
> transition from ~user to ^org is either not very important or will be
> handled as support for organizations is deployed.

This isn't exactly what I meant, maybe to rephrase it in terms of
organisations: Can you have a single-organisation instance, where the
git repository for Emacs wouldn't be "whatever.org/~gnu/emacs",
"whatever.org/^gnu/emacs" but just "whatever.org/emacs"?

> https://sourcehut.org/alpha-details/
> https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CC0L8LGIM0C2I.3O209D1TSO6M3%40homura%3E

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I wonder if it would make sense to have one of the maintainers sign up
> there and start a "pretend" official Emacs repo. They could start a
> mailing list alongside it that we could play with,

Does it have to be one of the maintainers, or could anyone do it?

> and who knows, maybe
> that would eventually become the "real" official sr.ht repo.

AFAIK, it is GNU policy that we need to self-host this infrastructure.

Re: Migrating to sourcehut - what's missing?

[Eric Abrahamsen]

On 12/21/21 13:42 PM, Stefan Kangas wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I wonder if it would make sense to have one of the maintainers sign up
>> there and start a "pretend" official Emacs repo. They could start a
>> mailing list alongside it that we could play with,
>
> Does it have to be one of the maintainers, or could anyone do it?
>
>> and who knows, maybe
>> that would eventually become the "real" official sr.ht repo.
>
> AFAIK, it is GNU policy that we need to self-host this infrastructure.

I think that answers the first question -- as Philip notes, we would
eventually have to self-host, so in theory anyone could own this
account. Doesn't mean we can't fix real bugs with it, though...

Re: Migrating to sourcehut - what's missing?

[Sean Whitton]

Hello Theodor,

On Tue 21 Dec 2021 at 07:30PM +01, Theodor Thornhill wrote:

> Actually, I think that running Sourcehut as a local instance wouldn't
> really be necessary for the evaluation, because it is the same code that
> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
> workflow should be the same.  I'd encourage people on this list getting
> their own user there and trying it out, as I think many already have.
> Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
> `todo` and `builds` subprojects, that is all apart from the `hg` one.

How about just setting up meta, lists and builds, leaving debbugs and
savannah doing bug tracking and git hosting, and then add 'todo' and
'git' later?  Might make the migration easier.

-- 
Sean Whitton

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Hi, Sean!

>> Actually, I think that running Sourcehut as a local instance wouldn't
>> really be necessary for the evaluation, because it is the same code that
>> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
>> workflow should be the same.  I'd encourage people on this list getting
>> their own user there and trying it out, as I think many already have.
>> Specifically, emacs-devel would want to use the `meta`, `lists`, `git`,
>> `todo` and `builds` subprojects, that is all apart from the `hg` one.
>
> How about just setting up meta, lists and builds, leaving debbugs and
> savannah doing bug tracking and git hosting, and then add 'todo' and
> 'git' later?  Might make the migration easier.
>

I think an even easier way to start using srht would be to make an
official mirror on sr.ht.

Theo

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

>
> I think an even easier way to start using srht would be to make an
> official mirror on sr.ht.
>
> Theo

As a followup to this I actually 'own' the user 'emacs' on sr.ht, and
would gladly donate it to Lars, Eli or some other interested person.  If
so, the address would be https://git.sr.ht/~emacs/emacs

Theo

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Theodor Thornhill <theo@thornhill.no> writes:

> Actually, I think that running Sourcehut as a local instance wouldn't
> really be necessary for the evaluation, because it is the same code that
> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
> workflow should be the same.
[snip]
> Of course.  However, I think that getting some sense of what _needs_ to
> be supported before even considering sourcehut would be smart.  The self
> hosting can come later, IMO.

I might be wrong, but I suspect that we are much closer than we think.

Mainly, it needs someone to drive the work; whatever that might mean.
I gave the suggestion for where I would start, but any work in this
direction is of course very welcome.

My thinking is that it would be good to provide something that people
can easily look at and experiment with to convince themselves that this
is a good move.  Self-hosting makes it easier for people to just jump
right into it, and makes it more likely to happen.  But if someone could
set up an Emacs mirror on sr.ht and allow people to easily experiment
there, then I guess that works too.

The important thing here is to pick up one of the loose threads and
start making concrete progress.

> For example, its author suggests that emacs-devel adopts the `git
> send-email` workflow rather than using attachments anyway, but I believe
> that was a hard no.

On August 28, Lars wrote:

> Well, we really don't care as long as the patches reach us unscathed.
>
> In my experience, it's more likely that a patch won't be mangled if it's
> in an attachment (which is why CONTRIBUTE says that), but if you have a
> setup that allows you to send patches safely otherwise (i.e., you're not
> using Gmail :-)), then we don't care.

https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg01436.html

I don't see this as a "hard no"; it is just something we need to
properly look into and understand the implications of.

To add to what Lars said, if you support a web based workflow the people
using a bad MUA that would mangle your patches could just use the web
based workflow instead.  Or at least that's my understanding.

Personally, I tend to much agree with Lars that we don't (or shouldn't)
care too much if we are dealing with attached patches or "git
send-email" or whatever.  The end result will be mostly the same with
perhaps some small or trivial differences details such as which exact
command to run.

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

Stefan Kangas <stefankangas@gmail.com> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> Actually, I think that running Sourcehut as a local instance wouldn't
>> really be necessary for the evaluation, because it is the same code that
>> is running on sr.ht.  Apart from the fiddly bits with self hosting, the
>> workflow should be the same.
> [snip]
>> Of course.  However, I think that getting some sense of what _needs_ to
>> be supported before even considering sourcehut would be smart.  The self
>> hosting can come later, IMO.
>
> I might be wrong, but I suspect that we are much closer than we think.
>

I don't think you are wrong at all.

> Mainly, it needs someone to drive the work; whatever that might mean.
> I gave the suggestion for where I would start, but any work in this
> direction is of course very welcome.
>

Your suggestions are welcome, and were in line with what I was thinking
as well :)

> My thinking is that it would be good to provide something that people
> can easily look at and experiment with to convince themselves that this
> is a good move.  Self-hosting makes it easier for people to just jump
> right into it, and makes it more likely to happen.  But if someone could
> set up an Emacs mirror on sr.ht and allow people to easily experiment
> there, then I guess that works too.
>
IMO this will be the easiest option, at least until some of the more
senior emacs contributors/maintainers wants to take over the reigns.

> The important thing here is to pick up one of the loose threads and
> start making concrete progress.
>

I can at least donate the ~emacs user, but not sure if I have time to
maintain a mirror with no delay.  

>> For example, its author suggests that emacs-devel adopts the `git
>> send-email` workflow rather than using attachments anyway, but I believe
>> that was a hard no.
>
> On August 28, Lars wrote:
>
>> Well, we really don't care as long as the patches reach us unscathed.
>>
>> In my experience, it's more likely that a patch won't be mangled if it's
>> in an attachment (which is why CONTRIBUTE says that), but if you have a
>> setup that allows you to send patches safely otherwise (i.e., you're not
>> using Gmail :-)), then we don't care.
>
> https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg01436.html
>
> I don't see this as a "hard no"; it is just something we need to
> properly look into and understand the implications of.
>
> To add to what Lars said, if you support a web based workflow the people
> using a bad MUA that would mangle your patches could just use the web
> based workflow instead.  Or at least that's my understanding.
>
> Personally, I tend to much agree with Lars that we don't (or shouldn't)
> care too much if we are dealing with attached patches or "git
> send-email" or whatever.  The end result will be mostly the same with
> perhaps some small or trivial differences details such as which exact
> command to run.

What I meant was a hard no was to enforce the send-email workflow.  It
seems emacs wants to be a little more forgiving, which I agree with.

Theo

Re: Migrating to sourcehut - what's missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If we move the Emacs repository to the sourcehut software,
we shouldn't move it to sourcehut's service.  I will look into
installing that software on a GNU machine.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 05:16:48 CET, Richard Stallman <rms@gnu.org> wrote:
>[[[ To any NSA and FBI agents reading my email: please consider    ]]]
>[[[ whether defending the US Constitution against all enemies,     ]]]
>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>If we move the Emacs repository to the sourcehut software,
>we shouldn't move it to sourcehut's service.  I will look into
>installing that software on a GNU machine.
>

Absolutely. The effort made right now is just to give an impression, so that people can see what such a migration would look like. Their service is javascript free, so it should be usable right now. 

I hope the links prove useful, as many earlier discussion about this tend to result in no action. 

I don't have the seniority here nor the ability to persuade anybody on this, but something visual tend to help. 

Theo

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

> If we move the Emacs repository to the sourcehut software,
> we shouldn't move it to sourcehut's service.  I will look into
> installing that software on a GNU machine.


In the meantime, feel free to browse [1]. This is the 'project' page on
sourcehut, collecting the separate services into one site, so that one
more easily can browse it.  It should be representable for how such an
instance would look when self hosted.

Hope this helps

Theo

[1]; https://sr.ht/~emacs/emacs/

Re: Migrating to sourcehut - what's missing?

[Joost Kremers]

On Wed, Dec 22 2021, Theodor Thornhill wrote:
> In the meantime, feel free to browse [1]. This is the 'project' page on
> sourcehut, collecting the separate services into one site, so that one
> more easily can browse it.  It should be representable for how such an
> instance would look when self hosted.
[...]
> [1]; https://sr.ht/~emacs/emacs/

One thing I noticed: if you go to any of the sections (tabs) at the top of the
page ("source", "mailing list", "tickets"), there doesn't seem to be a way to
get back to the project page. The tabs at the top are replaced with another set
of tabs and none of these take you back to the project page.

Also, the project description (the README) doesn't display well on my mobile
device (using Firefox or Chrome), possibly because the README uses hard newlines
for line wrapping. (Not sure what the best solution would be for this, though.)

I realise you're not a Sourcehut developer and don't have the ability to improve
this yourself, but I thought I'd mention it.



-- 
Joost Kremers
Life has its moments

Re: Migrating to sourcehut - what's missing?

[Theodor Thornhill]

On 22 December 2021 11:25:19 CET, Joost Kremers <joostkremers@fastmail.fm> wrote:
>
>On Wed, Dec 22 2021, Theodor Thornhill wrote:
>> In the meantime, feel free to browse [1]. This is the 'project' page on
>> sourcehut, collecting the separate services into one site, so that one
>> more easily can browse it.  It should be representable for how such an
>> instance would look when self hosted.
>[...]
>> [1]; https://sr.ht/~emacs/emacs/
>
>One thing I noticed: if you go to any of the sections (tabs) at the top of the
>page ("source", "mailing list", "tickets"), there doesn't seem to be a way to
>get back to the project page. The tabs at the top are replaced with another set
>of tabs and none of these take you back to the project page.
>

IIRC this is an open issue for the beta, but not sure. 

>Also, the project description (the README) doesn't display well on my mobile
>device (using Firefox or Chrome), possibly because the README uses hard newlines
>for line wrapping. (Not sure what the best solution would be for this, though.)
>
>I realise you're not a Sourcehut developer and don't have the ability to improve
>this yourself, but I thought I'd mention it.
>

That's correct, but I think all feedback is valuable should emacs consider this. If nothing else, it makes the change feel a little more tangible

Re: Migrating to sourcehut - what's missing?

[Vitaly Ankh]

Why sourcehut? I believe GitLab is more feature rich, more familiar to many developers and also open source.

I know GNU has a self-host GitLab instance, but only for CI. Why not migrate to self-host GitLab fully?

Regards,
VitalyR

Re: Migrating to sourcehut - what's missing?

[Stefan Kangas]

Vitaly Ankh <vitalyankh@gmail.com> writes:

> Why sourcehut? I believe GitLab is more feature rich, more familiar to
> many developers and also open source.

I recommend searching the archives for a more detailed answer, but you
could start by reading:

https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Re: Migrating to sourcehut - what's missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Why sourcehut? I believe GitLab is more feature rich, more
  > familiar to many developers and also open source.

We do not advocate "open source" -- that's why we never use that term.
We champion the free software movement, which is a campaign for
freedom for all users of software.  For explanation of the difference,
https://gnu.org/philosophy/open-source-misses-the-point.html.

That's particularly relevant to the choice of repo site, because our
criteria for evaluating repo sites include how much the site helps
and supports good free software practices.

See https://www.gnu.org/software/repo-criteria.html.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Migrating to sourcehut - what's missing?

[xenodasein--- via Emacs development discussions.]

Hello, what features does sourcehut offer, in comparison to
the following site? https://git.savannah.gnu.org/cgit/emacs.git/

Re: Migrating to sourcehut - what's missing?

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Hello, what features does sourcehut offer, in comparison to
> the following site? https://git.savannah.gnu.org/cgit/emacs.git/

Sourcehut is a "development forge", that is to say it intends to provide
the services needed by projects to collaborate such as repository
hosting, mailing lists, build systems, issue trackers, etc.  The
difference to other provides (GitHub, GitLab, ...) is that it intends to
support mail driven development as a first class citizen.

Cgit is (to my understanding) just a web interface for a git repository,
which is only one part of sourcehut (the git.sr.ht).

Moving to sourcehut could provide a more integrated system and add
features such as continuous integration and issue tracking ("What has to
be done for feature/... to be merged", "What issues are blocking the
release of Emacs 28", etc.) that currently (appear) to not exist or be
used.  Especially the last thing could give new comers (but also people
like me who don't have the time to follow every thread) a better
overview of what the current state of a topic is, without having to read
through threads upon threads on the mailing list.

(I am just uncertain of how this and the mail driven development work
together.  Or would be need a special client for that?)

-- 
	Philip Kaludercic

Re: Migrating to sourcehut - what's missing?

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02070.html
From:	Philip Kaludercic
Subject: Re: Migrating to sourcehut - what's missing?
Date: Tue, 21 Dec 2021 22:08:11 +0000

> Cgit is (to my understanding) just a web interface for a git repository,
> which is only one part of sourcehut (the git.sr.ht).

I clicked around a bit but couldn't notice a functional difference,
but cgit looks nicer visually.

> Moving to sourcehut could provide a...

Sounds great. Thanks for your time.

> (I am just uncertain of how this and the mail driven development work
> together.  Or would be need a special client for that?)

If we had something to visualize the mails as a graph and be able
referto/from the tracker to/from the nodes, we could give GitHub
a run for their money.