Re: BuGit

[Stefan Monnier]

>> For those curious about what I've been upto lately, one of the things
>> I've been working on is a new distributed issue tracking system which
>> I call BuGit:
>> https://gitlab.com/monnier/bugit
>> It's still primitive (only the command-line UI and the email
>> notification system are more or less complete: the web UI is still
>> read-only, and there is no email UI at all).
> I like the offline work+sync later feature.  This looks really
> interesting.  I see in the source you have code to import debbugs
> issues.  Do you have an emacs-bugit repo?

I wrote the debbugs conversion code in order to see how the system
scales to largish databases (using debbugs.gnu.org as the largish
database).  So yes, I have an "emacs-bugit" repo (actually it contains
a bit more since debbugs.gnu.org is used for more than just Emacs).

But the debbugs conversion code doesn't know anything about MIME, so the
result is not really usable: the majority of messages are OK, but many
appear as base64 line-noise, and none of the attachments are recognized
as attachments.

My next goal is to add an email UI so it can be used "as
a mailing-list", just like we do for debbugs (the "address@hidden" part
of debbugs's UI is of lesser importance to me).  Once that code works,
it should be easy to improve the debbugs conversion so as to make an
actually usable "emacs-bugit" repo (since the email UI will have to
deal with MIME).

But that'd only be of interest if Emacs wants to switch to BuGit, which
seems unlikely in the short term.  Again, the only reason for this
debbugs conversion code was to get a realistic database to play with.

> How does querying for say open bugs work?

"bugit list" or click on "list all issues" in the web UI.

> Do you think it can scale to emacs bugs database?

My tests on the emacs-repo so far indicate that it should be possible to
make it scale to that kind of size.  There are a few cases where it
currently gets slow at such sizes, tho.  We may need to add caching of
some sort at a few places.

> The web and especially the email UI are going to be a PITA to write
> but they are essential so keep up the good work!

The code is currently written 100% in /bin/sh, which was great for the
command-line UI (I very quickly managed to get something usable), and
indeed handling MIME with /bin/sh is a PITA.

So I'll probably use Python for that (I actually expect most of the code
to be rewritten in Python over time), where it should actually be fairly
easy to write the email UI.  All we really need is, give a single
email:
- figure out if it's a new bug or a reply.
- find the corresponding issue id.
- split it into "body + attachments" (that's where sh sucks compared to
  something like Python's mail library).
- pass the result to Git.
- that's about it, tho afterwards we'll want to add support for things like
  closing-via-email and things like that, but these should also be easy.

I don't foresee any real PITA on the web UI side either, actually (tho
I'm very much unversed in web technologies, so I might be
underestimating the problems).

Any help welcome, of course.


        Stefan