issue tracking in git

issue tracking in git

[Adriano Peluso]

Hello

some time ago, in the context of an on line conference about Guix,
someone suggested me that the bitcoin community had run a survey about
available solutions for issue tracking in git

I don't remember the name of such person and I am wondering if amy
progress has been achieved on that front

So if they're reading, please, chime in

I looked on line and found nothing

Thanks

Re: issue tracking in git

[Ricardo Wurmus]

Hi Adriano,

> some time ago, in the context of an on line conference about 
> Guix,
> someone suggested me that the bitcoin community had run a survey 
> about
> available solutions for issue tracking in git

Was it perhaps Carl Dong?

> I don't remember the name of such person and I am wondering if 
> amy
> progress has been achieved on that front

I don’t think there was a decision to do issue tracking in git.

Many years ago I used Bugs Everywhere 
(https://bugs-everywhere.readthedocs.io/en/latest/) for my 
personal projects.  I really quite liked it, not least because you 
can close a bug right as you fix the issue — it’s part of the same 
commit.

I have no idea how well it works when there’s a lot of “traffic” 
in a distributed project, e.g. when there are several comments to 
the same issue by different people.  Having merge conflicts in the 
issue tracker is a headache I’d like to avoid.

-- 
Ricardo

Re: issue tracking in git

[raingloom]

On Fri, 13 Aug 2021 08:29:07 +0200
Adriano Peluso <randomlooser@riseup.net> wrote:

> Hello
> 
> some time ago, in the context of an on line conference about Guix,
> someone suggested me that the bitcoin community had run a survey about
> available solutions for issue tracking in git
> 
> I don't remember the name of such person and I am wondering if amy
> progress has been achieved on that front
> 
> So if they're reading, please, chime in
> 
> I looked on line and found nothing
> 
> Thanks
> 
> 

I think this might be the result of that survey?
https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core

Re: issue tracking in git

[Giovanni Biscuolo]

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

Hi Adriano and Ricardo,

I'm also _very_ interested in keeping issues in the same repo as code
and I'm really envious of Fossil users [1] :-D

Ricardo Wurmus <rekado@elephly.net> writes:

[...]

> Many years ago I used Bugs Everywhere 
> (https://bugs-everywhere.readthedocs.io/en/latest/) for my 
> personal projects.  I really quite liked it, not least because you 
> can close a bug right as you fix the issue — it’s part of the same 
> commit.

I've still not tested it but there is also git-issue
(https://github.com/dspinellis/git-issue), there's also a Guix patch
[bug#49581]

> I have no idea how well it works when there’s a lot of “traffic” 
> in a distributed project, e.g. when there are several comments to 
> the same issue by different people.  Having merge conflicts in the 
> issue tracker is a headache I’d like to avoid.

Each issue and issue comment is a file named with a SHA, see
https://github.com/dspinellis/git-issue#internals for details; issues
and comments can be edited, so coordination and contribution guidelines
(also) for issues and comments are still needed.

There's no other interface than the CLI, so no email based workflows.

An interesting workflow could be to use emails as a "side-channel" for
discussions /about/ issues (and issue comments), and maintainers could
provide a public-inbox [2] of the "issues-discussion" messages; email
discussions can be linked with the git-issue managed issues (and
comments) by the maintainers of the project, in order to keep track of
the discussions while maintaining them separated from issues (and issue
comments).  This way, issues should be considered more like (meta-)code
than out-of-channel-text, from a maintainers POV. :-D

Last, AFAIK Diomidis Spinellis have compiled the most updated list of
tools for issue tracking "embedded" in git:
https://github.com/dspinellis/git-issue#related-work


Best regards, Gio'


[1] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki

[2] that in turn creates a git repo of the messages, and provides a
read-only web view of all the archived messages

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[Adriano Peluso]

Il giorno ven, 13/08/2021 alle 15.18 +0200, Ricardo Wurmus ha scritto:
> 
> Hi Adriano,

>  [...]

> Was it perhaps Carl Dong?

yes, it was Carl Dong

Thank you


> > I don't remember the name of such person and I am wondering if 
> > amy
> > progress has been achieved on that front
> 
> I don’t think there was a decision to do issue tracking in git.

Do you mean a decsion by the bitcoin community ?

Or by the Guix community ?

> I have no idea how well it works when there’s a lot of “traffic” 
> in a distributed project, e.g. when there are several comments to 

[...]

> the same issue by different people.  Having merge conflicts in the 
> issue tracker is a headache I’d like to avoid.
> 


I hadn't thought about this

This is a potential problem that deservses exploration

I think issue tracking in git could be explored starting with smaller
projects first

Probably Guix is too large and entrenched to be used as a test bed for
this kind of explorations

I'm asking about the state of the art in this regard because I feel
that server based solutions are problematic even for free software
oriented organizations

And should the bitcoin community explore this a bit, that would be a
very interesting development, in my view

Re: issue tracking in git

[Adriano Peluso]

Il giorno ven, 13/08/2021 alle 18.19 +0200, Giovanni Biscuolo ha
scritto:
> Hi Adriano and Ricardo,

thank you for your insights

Re: issue tracking in git

[Pjotr Prins]

On Fri, Aug 13, 2021 at 06:19:23PM +0200, Giovanni Biscuolo wrote:
> Hi Adriano and Ricardo,
> 
> I'm also _very_ interested in keeping issues in the same repo as code
> and I'm really envious of Fossil users [1] :-D

As a new initiative we are discussing/designing a gemini + git issue
tracker.

Rather than submitting to one central issue tracker the goal is to
create a distributed issue tracker (no conflicts and you can own - and
remove - your comments if you run a gemini server). It is early days,
but it ought to give a new perspective on issue tracking.

Pj.

Re: issue tracking in git

[Giovanni Biscuolo]

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

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Fri, Aug 13, 2021 at 06:19:23PM +0200, Giovanni Biscuolo wrote:
>> Hi Adriano and Ricardo,
>> 
>> I'm also _very_ interested in keeping issues in the same repo as code
>> and I'm really envious of Fossil users [1] :-D
>
> As a new initiative we are discussing/designing a gemini + git issue
> tracker.

I'm interested in follow your initiative, please announce it as soon as
it's published somewhere!

Thanks! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[Adriano Peluso]

Il giorno ven, 13/08/2021 alle 16.39 +0200, raingloom ha scritto:
> 


> I think this might be the result of that survey?
> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/GitHub-alternatives-for-Bitcoin-Core

yes, this is it

it seems here was no progress, since then

Re: issue tracking in git

[Giovanni Biscuolo]

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

Hello Pjotr

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

> As a new initiative we are discussing/designing a gemini + git issue
> tracker.

please are there updates about this initiative?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[Pjotr Prins]

On Tue, Nov 22, 2022 at 06:57:59PM +0100, Giovanni Biscuolo wrote:
> Hello Pjotr
> 
> Giovanni Biscuolo <g@xelera.eu> writes:
> 
> [...]
> 
> > As a new initiative we are discussing/designing a gemini + git issue
> > tracker.
> 
> please are there updates about this initiative?

Yeah, issue tracker lives here: 

=> https://issues.genenetwork.org/

The actual issues are in gemini format and can be served with a gemini
server. The HTML parser+renderer is written in Guile by Arun

=> https://git.systemreboot.net/tissue

Pj.

Re: issue tracking in git

[Giovanni Biscuolo]

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

Hello Pjotr and Arun, 

thanks Pjotr for the information

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Tue, Nov 22, 2022 at 06:57:59PM +0100, Giovanni Biscuolo wrote:

[...]

>> please are there updates about this initiative?
>
> Yeah, issue tracker lives here: 
>
> => https://issues.genenetwork.org/
>
> The actual issues are in gemini format and can be served with a gemini
> server. The HTML parser+renderer is written in Guile by Arun
>
> => https://git.systemreboot.net/tissue

Homepage is https://tissue.systemreboot.net/

Wow!  Very interesting project, it deserves more visibility! (why did I
miss its existance?!? :-O )

Any other tissue user in this mailing list?

Please Arun is there a devel mailing list dedicated to tissue so we can
discuss details of the project?

I'm not a Guile developer but I would like to help with testing and (the
lack of) documentation, if I can.

I'd also like to understand and possibly discuss the overall
architecture design of tissue, in particular compared to git-issue
internals [1]

Last but not least: what about to have tissue packaged [2] in Guix? :-D

Thanks! Gio'

[1] https://github.com/dspinellis/git-issue#internals

[2] we could/sould add skribilo-latest in Guix

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[indieterminacy]

Hi Giovanni,

On 23-11-2022 11:29, Giovanni Biscuolo wrote:
> 
>>> please are there updates about this initiative?
>> 
>> Yeah, issue tracker lives here:
>> 
>> => https://issues.genenetwork.org/
>> 
>> The actual issues are in gemini format and can be served with a gemini
>> server. The HTML parser+renderer is written in Guile by Arun
>> 
>> => https://git.systemreboot.net/tissue
> 
> Homepage is https://tissue.systemreboot.net/
> 
> Wow!  Very interesting project, it deserves more visibility! (why did I
> miss its existance?!? :-O )
> 
> Any other tissue user in this mailing list?
> 

FWIW, Ive been working on Gemini and issue trackers in parrallel to 
Genenetwork.

Arun did such a great job with a minimalist setup that I thought it more 
proper to create a bigger ladder (given the reach of all the domains 
which Tissue provides(.

I have two main strands:

Firstly, I have been combining Gemtext's terse syntax with that of the 
Emacs-Hyperbole format, Koutliner, as well as the 
"recursive-modelling-language" I have been developing Qiuy.

https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/

As a consequence, it has grown into something different and more 
complex. I need to trim this, especially as the results of some sprints 
but once I refactor it it shall be a lot more solid.

Secondly, I have been returning to Gemtext from the perspective of Git 
diffs, with the idea to generate RDF perspectives one each revision per 
file and then use RDF calls to resolve more complex queries.

https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr

I shall be folding the logic of the first tool into the second 
(carefully). I need a bit more time to do this to be fully satisfied.

There are some other tools floating around my forge (concerning hash 
trees for different interpreters and rdf from the perspective of project 
management), its mainly in TXR, Gawk and eLisp (though I will be doing 
more with respect to Guile for these areas over time).

Kind regards,


-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: issue tracking in git

[Pjotr Prins]

On Wed, Nov 23, 2022 at 11:29:48AM +0100, Giovanni Biscuolo wrote:
> Homepage is https://tissue.systemreboot.net/
> 
> Wow!  Very interesting project, it deserves more visibility! (why did I
> miss its existance?!? :-O )

Ah well. We have just been using it and building it up over the last
year :). We wanted to get away from github issue trackers and that was
rather successful. All you need is a git repo and a guix package.

We also have ci and cd based on our own system containers in Guix.

=> https://ci.genenetwork.org/

It would be good to write a Guix blog about all this.

> Please Arun is there a devel mailing list dedicated to tissue so we can
> discuss details of the project?

Sounds like an idea. Though in the spirit of tissue we might as well
set up a repo.

> I'm not a Guile developer but I would like to help with testing and (the
> lack of) documentation, if I can.
> 
> I'd also like to understand and possibly discuss the overall
> architecture design of tissue, in particular compared to git-issue
> internals [1]

I did not know of that project, but it looks similar in concept. With
gemini support you get some other interesting features. And then Arun
has added powerful search. Also, when you see Jonathan's E-mail, we
are not done building on this.

> Last but not least: what about to have tissue packaged [2] in Guix? :-D

It is about time - and a package and system definition exists in a
channel.

Pj.

Re: issue tracking in git

[Giovanni Biscuolo]

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

Hello Jonathan,

nice to read you!

I saw your «L'Union Qiuy Fait La Force» presentation at Ten Years of
Guix [1] and I have to admit I still have to "digest" it, because I
still do not understand the overall architecture (see below).

indieterminacy <indieterminacy@libre.brussels> writes:

[...]

> FWIW, Ive been working on Gemini and issue trackers in parrallel to 
> Genenetwork.
>
> Arun did such a great job with a minimalist setup that I thought it more 
> proper to create a bigger ladder (given the reach of all the domains 
> which Tissue provides(.
>
> I have two main strands:
>
> Firstly, I have been combining Gemtext's terse syntax with that of the 
> Emacs-Hyperbole format, Koutliner, as well as the 
> "recursive-modelling-language" I have been developing Qiuy.
>
> https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/
>
> As a consequence, it has grown into something different and more 
> complex. I need to trim this, especially as the results of some sprints 
> but once I refactor it it shall be a lot more solid.
>
> Secondly, I have been returning to Gemtext from the perspective of Git 
> diffs, with the idea to generate RDF perspectives one each revision per 
> file and then use RDF calls to resolve more complex queries.

RDF representations of diffs (commits?) so we can combine this knowledge
with others (represented in RDF) AFAIU is great: (open) linked data for
knowledge management

IMHO RDF is still a little bit underestimated :-D

> https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr
>
> I shall be folding the logic of the first tool into the second 
> (carefully). I need a bit more time to do this to be fully satisfied.

what about gNife?

https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs
--8<---------------cut here---------------start------------->8---

gNife, an Emacs environment for high throughput issue-tracking and
knowledge-management - utilising GemText, Koutliner and Qiuy

--8<---------------cut here---------------end--------------->8---

is it still relevant or do you plan to substitute it with the tools
listed above?

> There are some other tools floating around my forge (concerning hash 
> trees for different interpreters and rdf from the perspective of project 
> management), its mainly in TXR, Gawk and eLisp (though I will be doing 
> more with respect to Guile for these areas over time).

Looking at the Icebreaker project descriptions:

1. https://nlnet.nl/project/Icebreaker/

2. https://portal.mozz.us/gemini/icebreaker.space

I can undertand the design principles of the tools you are developing
and I'm really impressed with the completeness of this approach with
knowledge management, unfortunately I miss the overall architecture and
some important detalils that allows me to completely understand how to
use (or try to contribute to, one day) this tools: do you plan to add
some more documentation soon?

Happy hacking! Gio'

>
> Kind regards,
>
>
> -- 
> Jonathan McHugh
> indieterminacy@libre.brussels


[1] https://10years.guix.gnu.org/video/l-union-qiuy-fait-la-force/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[Giovanni Biscuolo]

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

Pjotr Prins <pjotr.public12@thebird.nl> writes:

[...]

> We also have ci and cd based on our own system containers in Guix.
>
> => https://ci.genenetwork.org/
>
> It would be good to write a Guix blog about all this.

Yes: «How to leave useless forges and live happy» :-D

>> Please Arun is there a devel mailing list dedicated to tissue so we can
>> discuss details of the project?
>
> Sounds like an idea. Though in the spirit of tissue we might as well
> set up a repo.

Maybe a mailing-list is less intimidating for users (and MUAs have nicer
interfaces for this kind of communication workflows [1]), but I'll
follow the discussion "anywhere" you'll decide to go :-)

>> I'm not a Guile developer but I would like to help with testing and (the
>> lack of) documentation, if I can.
>> 
>> I'd also like to understand and possibly discuss the overall
>> architecture design of tissue, in particular compared to git-issue
>> internals [1]
>
> I did not know of that project, but it looks similar in concept. With
> gemini support you get some other interesting features. And then Arun
> has added powerful search.

yes, the xapian index is what I like most of tissue... but I'd prefer to
discuss such things in a proper official channel

> Also, when you see Jonathan's E-mail, we are not done building on
> this.

I'm just dreaming of you and Jonatan merging your projects for world
domination in knowledge and workflow management! B-)

>> Last but not least: what about to have tissue packaged [2] in Guix? :-D
>
> It is about time - and a package and system definition exists in a
> channel.

yes, please :-)

Thanks! Gio'


[1] and notmuch/xapian rules!

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

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

Re: issue tracking in git

[indieterminacy]

On 23-11-2022 15:19, Giovanni Biscuolo wrote:
> [...]
> I saw your «L'Union Qiuy Fait La Force» presentation at Ten Years of
> Guix [1] and I have to admit I still have to "digest" it, because I
> still do not understand the overall architecture (see below).
> 

As I (probably) mentioned it tha talk Qiuy is bourne from the desire to 
form a notation that sits between semantic and linguistic groups and is 
simultaneously positioned in the central position of the keyboard.

Here is a mail covering some pertinent themes
https://list.orgmode.org/a24dc6635138897d3fe978509be3a5cb@libre.brussels/

The problem is not to see the conception from the perspective of 
architectures but more in terms of a discipline or something akin to 
thermodynamics.

In any case, I have done other talks:

Classic Gemini presentation (evaluating it from the perspective of 
complexity - using Guix package details to demonstrate relative 
complexity)
https://www.youtube.com/watch?v=zyTC4QWGCQg

Impressionist talk detailing the tools and formats from the perspective 
of syntaxes
https://archive.fosdem.org/2022/schedule/event/minimalsyntaxes/

I gave multiple other talks this year but they need uploading.
I shall keep you informed.

> indieterminacy <indieterminacy@libre.brussels> writes:
> 
> [...]
> 
>> FWIW, Ive been working on Gemini and issue trackers in parrallel to
>> Genenetwork.
>> 
>> Arun did such a great job with a minimalist setup that I thought it 
>> more
>> proper to create a bigger ladder (given the reach of all the domains
>> which Tissue provides(.
>> 
>> I have two main strands:
>> 
>> Firstly, I have been combining Gemtext's terse syntax with that of the
>> Emacs-Hyperbole format, Koutliner, as well as the
>> "recursive-modelling-language" I have been developing Qiuy.
>> 
>> https://git.sr.ht/~indieterminacy/1q20hqh_oqo_parsing_qiuynonical/
>> 
>> As a consequence, it has grown into something different and more
>> complex. I need to trim this, especially as the results of some 
>> sprints
>> but once I refactor it it shall be a lot more solid.
>> 
>> Secondly, I have been returning to Gemtext from the perspective of Git
>> diffs, with the idea to generate RDF perspectives one each revision 
>> per
>> file and then use RDF calls to resolve more complex queries.
> 
> RDF representations of diffs (commits?) so we can combine this 
> knowledge
> with others (represented in RDF) AFAIU is great: (open) linked data for
> knowledge management
> 
> IMHO RDF is still a little bit underestimated :-D
> 

Indeed!

Qiuy should have a bright future in relation to RDF (a lot of grunt work 
however)

Im still sophomore in this domain but Im wrapping up enough of my other 
things to wade into this properly.

I have been liasing with somebody with regards to doing RDF activity 
during Guix Days 2023, Brussels (early February) - come join us!

>> https://git.sr.ht/~indieterminacy/1q20twt_oq_parsing-commits_txr
>> 
>> I shall be folding the logic of the first tool into the second
>> (carefully). I need a bit more time to do this to be fully satisfied.
> 
> what about gNife?
> 
> https://git.sr.ht/~indieterminacy/5q50jq_oq_configuring_emacs
> --8<---------------cut here---------------start------------->8---
> 
> gNife, an Emacs environment for high throughput issue-tracking and
> knowledge-management - utilising GemText, Koutliner and Qiuy
> 
> --8<---------------cut here---------------end--------------->8---
> 
Well spotted!

Ive positioned the Icebreaker architecture to have a strong interface 
end (Qiuy originated from packaging my complex Vim infrastructure).

It is integral to the project development but optional for users.

> is it still relevant or do you plan to substitute it with the tools
> listed above?
> 

Its a gestalt thing, just another viewpoint of the same discipline.

It remains untouched given some brutal family traumas.
Since switching to a modern and more secure laptop I havent had the 
chance to overcome some niggles.
I plan to develop this over time, though I would prefer to refactor it 
all within Guix Home (as well as my whole setup with regards to system 
crafting).

There are a lot of cool things which the Qiuy annotations are capable of 
doing when twinned with Emacs-Hyperbole - search for them in that repo 
for ideas.

>> There are some other tools floating around my forge (concerning hash
>> trees for different interpreters and rdf from the perspective of 
>> project
>> management), its mainly in TXR, Gawk and eLisp (though I will be doing
>> more with respect to Guile for these areas over time).
> 
> Looking at the Icebreaker project descriptions:
> 
> 1. https://nlnet.nl/project/Icebreaker/
> 
> 2. https://portal.mozz.us/gemini/icebreaker.space
> 
> I can undertand the design principles of the tools you are developing
> and I'm really impressed with the completeness of this approach with
> knowledge management, unfortunately I miss the overall architecture and
> some important detalils that allows me to completely understand how to
> use (or try to contribute to, one day) this tools: do you plan to add
> some more documentation soon?
> 
The lack of documentation has been my greatest weakness of this project.
Bear in mind that Qiuy is self descriptive in the same way which a 
pharmacist reads chemical symbols from a shelf.

Having made specific commitments to NLNet, which sponsored this work it 
transpired that the timeframe for completion was a lot shorter than I 
envisaged (in part given my desire to frame the project in a sustainable 
way with maximum utilitarian potential).

Given some very extreme personal circumstances thrown at me at different 
points in this year I am happy to have submitted for all my deliverables 
and the volume of my work recognised by my reviewers.

My family and I not imploding during this marathon of firefighting was a 
bonus too.... cutting carrots no longer feels weird.

As it stands, the fund which I joined was wound down and it is not clear 
whether what I have in mind concerning the future of Icebreaker in that 
enclave.

I have found a potential funding opportunity concerning documentation 
which would resolve this knowledge gap (for me 'Eureka' is currently 
more of a curse than a resolution), so we shall see....

and as mentioned in one of the earlier links, I see a strong 
assistive-technologies potential of what I am working on but this 
involves time and focus.

I will keep you uptodate with progress but its likely to be less 
frenetic (though more documentation heavy), while I return to a better 
equilibrium for me, my family and the communities I serve during Autumn.

I should try to pitch for Fosdem again, that was fun - hopefully I can 
nail the desciption of the architecture a bit better next time.

And I really need to update my Gemtext site, theres a lot to upload!
gemini://icebreaker.space

It is worth stating that I have a small matrix room for Icebreaker:
#xq_icebreaker:matrix.org
https://app.element.io/#/room/#xq_icebreaker:matrix.org

Kind regards,

-- 
Jonathan McHugh
indieterminacy@libre.brussels

Re: issue tracking in git

[Arun Isaac]

Hi Giovanni,

> Please Arun is there a devel mailing list dedicated to tissue so we can
> discuss details of the project?

There isn't one yet, but I will set up a public inbox soon.

> I'm not a Guile developer but I would like to help with testing and (the
> lack of) documentation, if I can.

Yes, please. Patches are always welcome. I can use all the help I can
get. Here are a list of issues and feature requests you can work on:
https://tissue.systemreboot.net/search Your ideas adding to these are
also very welcome.

> I'd also like to understand and possibly discuss the overall
> architecture design of tissue, in particular compared to git-issue
> internals [1]

Until the public inbox is ready, you can always mail me and/or Pjotr
directly.

> Last but not least: what about to have tissue packaged [2] in Guix?
> :-D

Yes, definitely. A tissue 0.1.0 release and a Guix package for it have
been long overdue.

I'm in the middle of uprooting and moving across continents for
work. So, my time is somewhat limited. But, I promise to work on
this. Pjotr suggested off-list that I might make a FOSDEM talk out of
all this. I think it's a good idea. I'll work towards that goal.

Cheers!
Arun

Re: issue tracking in git

[zimoun]

Hi Pjotr,

On Wed, 23 Nov 2022 at 14:18, Pjotr Prins <pjotr.public12@thebird.nl> wrote:

> We also have ci and cd based on our own system containers in Guix.
>
> => https://ci.genenetwork.org/

This is based on which CI code?  Your own or do you use an existing CI
framework/tools?


Cheers,
simon

Re: issue tracking in git

[Arun Isaac]

Hi zimoun,

>> We also have ci and cd based on our own system containers in Guix.
>>
>> => https://ci.genenetwork.org/
>
> This is based on which CI code?  Your own or do you use an existing CI
> framework/tools?

This CI is built using guix-forge documented at
https://guix-forge.systemreboot.net/manual/dev/en/
guix-forge uses the Laminar CI: https://laminar.ohwg.net/

The Guix container descriptions specific to ci.genenetwork.org are at
https://github.com/genenetwork/genenetwork-machines/

Regards,
Arun

Re: issue tracking in git

[zimoun]

Hi Arun,

On Fri, 25 Nov 2022 at 22:03, Arun Isaac <arunisaac@systemreboot.net> wrote:

[...]

> https://guix-forge.systemreboot.net/manual/dev/en/

[...]

> https://github.com/genenetwork/genenetwork-machines/

Cool!  Thanks for sharing.


Cheers,
simon