On Tue, Mar 24, 2020, at 21:51, clime wrote:
> On Tue, 24 Mar 2020 at 20:40, Nicolas Dandrimont <ol...@debian.org> wrote:
> >
> > Hi!
> >
> > On Sun, Mar 22, 2020, at 13:06, clime wrote:
> > > Hello!
> > >
> > > Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html -
> > > fedmsg usage in Debian.
> > >
> > > There is a note: "it seems that people actually like parsing emails"
> >
> > This was just a way to say that fedmsg never got much of a user base in the 
> > services that run on Debian infra, and that even the new services 
> > introduced at the time kept parsing emails.
> 
> Hello Nicolas!
> 
> Do you remember some such service and how it used email parsing specifically?

I believe that tracker.debian.org was introduced around that time.

At the point it was created, tracker.d.o was mostly consuming emails from 
packages.debian.org to update its data. These days tracker.d.o has replaced 
packages.d.o as "email router", in that it receives all the mails from services 
(e.g. the BTS, the archive maintenance software, buildds, salsa webhooks, ...) 
and forwards them to the public.

> I am still a bit unclear how email parsing is used in Debian
> infrastructure, don't get me wrong, I find it elegant

Ha. I find that it's a big mess.

Here's the set of headers of a message I received today from tracker.d.o, which 
are supposed to make parsing these emails better:

X-PTS-Approved: yes
X-Distro-Tracker-Package: facter
X-Distro-Tracker-Keyword: derivatives
X-Remote-Delivered-To: dispa...@tracker.debian.org
X-Loop: dispa...@tracker.debian.org
X-Distro-Tracker-Keyword: derivatives
X-Distro-Tracker-Package: facter
List-Id: <facter.tracker.debian.org>
X-Debian: tracker.debian.org
X-Debian-Package: facter
X-PTS-Package: facter
X-PTS-Keyword: derivatives
Precedence: list
List-Unsubscribe: <mailto:cont...@tracker.debian.org?body=unsubscribe%20facter>

I'll leave you to judge whether this makes sense or not.

(and it turns out that the actual useful payload was just plaintext with no 
real chance of automated parsing)

> but from what I have found (e.g. reportbug), in the beginning there is an
> email being sent by some human which will then trigger some automatic
> action (e.g. putting the bug into db). So it's like you could do all
> your work simply by sending emails (some of them machine-parsable).
> 
> So do you have the opposite? I do some clicking action somewhere and
> it will send an email to a certain mailing list to inform human
> beings? Or let's not just clicking but e.g. `git push` (something that
> you can still do from command line).
> 
> Do you have: I do some clicking action somewhere and it will send an
> email to a certain mailing list where the email is afterward parsed by
> another service which will do an action (e.g. launch a build) based on
> it?

Both of these are somewhat true.

Some examples of email-based behaviors:
 - Our bug tracking system is fully controlled by email.
 - Closing a bug in reaction to an upload is done by an email from the archive 
maintenance system (dak) to the bug tracking system.
 - Salsa has a webhook service that react to UI clicks (e.g. "clicking the 
merge button") by sending an email to the BTS (e.g. to tag bugs as pending), or 
to tracker.d.o (for new commit notifications).
 - Some of our IRC bots are triggered by procmail rules.
 - At some point mentors.debian.net depended on a NNTP gateway to the 
debian-devel-changes mailing list to trigger removal of superseded packages 
(...)
 - etc. etc.

I'm still not sure where your trail of questions is going? fedmsg in Debian has 
been dead for years at this point, and there still doesn't seem to be much 
interest to implement anything beyond email parsing in some of our core 
systems. 

Bye,
-- 
Nicolas Dandrimont

Reply via email to