On Thu, Apr 25, 2013 at 11:44:35AM -0400, Paul Tagliamonte wrote: > On Thu, Apr 25, 2013 at 05:34:03PM +0200, Daniel Pocock wrote: > > On 25/04/13 13:50, Simon Chopin wrote: > > > Hi, > > > > > > Nicolas Dandrimont and I are currently working on a project proposal for > > > the Google Summer of Code to use the messaging system written by Fedora, > > > fedmsg[0][1], within the Debian infrastructure (some of you might have > > > seen > > > the various ITPs related to that on -devel). > > > > > > Tollef kindly pointed out to us that Debian service administrators would > > > probably have something to say about all this, so here we are. > > > > > > As a premise, please note that we obviously plan to make fedmsg > > > distro-agnostic before anything else (than packaging). The original > > > upstream author seems very enthousiastic about the project, which makes > > > it probable that we won't have to carry those patches on our own. > > > > > > The thing itself is based on the ZeroMQ protocol. > > > > > > To quote Nicolas: > > >> One of the key outcomes of getting such a system in place, is that > > >> everyone, > > >> everywhere, can start listening to the messages and using them, opening > > >> up lots > > >> of doors for people to make amazing services based on Debian. > > >> > > >> A few ideas: > > >> - getting a signal from the archive on an accepted package (I'm > > >> confusing > > >> binaries and sources for the sake of brevity): > > >> → Trigger a piuparts run > > >> → Trigger lintian checks > > >> → Let any derivative intent a rebuild > > >> → Signal ports to rebuild > > >> → Trigger a jenkins job on specific package uploads > > >> → Post to pump.io/identi.ca/twitter > > >> → get a notification on your desktop > > >> → ... > > >> - one of your pet packages gets a git commit > > >> → try a rebuild > > >> → run QA checks > > >> → ... > > >> > > >> (boy, that escalated quickly) > > >> > > >> I think the possibilities are quite nice, and, as the fedmsg webpage > > >> says, that > > >> "gives new meaning to open infrastructure". > > > Two features I'd like to implement during this GSoC that are not AFAICT > > > already present in fedmsg are GPG support and some kind of playback > > > mechanism for the systems where it is important that all messages are > > > sent and received (there are some others where the information would > > > have value only at the time of emitting, I suppose). > > > > > > Questions, comments? > > > > ZeroMQ is a very lightweight solution - it is brokerless (like > > multicast) so won't necessarily support the requirement for durable > > subscriptions (keeping messages queued up for clients that are disconnected) > > http://www.zeromq.org/topics:requirements-for-reliability > > > > Some things that are worth looking at: > > > > - do we want to use an AMQP broker? In theory, this is an open standard > > like SMTP: the clients and brokers are interchangeable > > > > - as an alternative, could we use something like SIP or XMPP as a > > messaging platform? Then people can receive messages in their chat > > client. In this case it doesn't appear to be the optimal solution, but > > these protocols are quite good for systems that are very widely > > distributed over public networks. > > > > - then again, there are plenty of examples of systems like Apache Camel > > that can take a message from a traditional broker and deliver it to just > > about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200 > > other possible destinations: > > http://camel.apache.org/components.html > > and it can use Java or XML to describe various filters and transforms > > > > > > > > -- > > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > > listmas...@lists.debian.org > > Archive: http://lists.debian.org/51794ceb....@pocock.com.au > > > > Guys, we're *days* into student applications. We should have had this > nailed down weeks ago. > > Pick something, go with it, or let's stop this early. Really; we should > be fielding students now, now bikesheading over this stuff.
OK. It's not Bikesheading, I read the rest of the thread. I'm a bit out of order. I'm still not pleased it's still up for discussion, this puts slot allocation into a funny place where the GSoC team has to decide if we can bet on a project with a huge payout but is ill defined. I'll shut up and get out of this thread, but we should *really* nail this down, like, in the next few days. > > Cheers, > Paul > Sorry! Paul -- .''`. Paul Tagliamonte <paul...@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
