Differences between revisions 6 and 7
Revision 6 as of 2013-04-26 08:47:48
Size: 4453
Comment:
Revision 7 as of 2013-05-08 11:05:01
Size: 4943
Editor: SimonChopin
Comment: More detailed schedule.
Deletions are marked like this. Additions are marked like this.
Line 46: Line 46:
 * '''Project schedule''': (proposal)
   * May 'til June 17th: packaging of fedmsg and its dependencies
   * -> July 8th: PoC of emitting messages from $piece_of_infrastructure (to be determined), without much features
   * -> August 11: Secured emission
   * -> Rest of the summer: Patches to different pieces of the infrastructure to emit/use messages.
   
   I'd like to patch, in order, the following:
   1. mentors.debian.net
   2. dak
   3. whatever the buildds use (still have to research that)
   4. jenkins.debian.net
   5. wiki.debian.org
 * '''Project schedule''':
   I expect to be able to keep the following schedule:
   * June 17th: all packaging done and uploaded to unstable, also backported to wheezy and squeeze.
   * July 1st: Patch to Debexpo to emit a message when a new package is uploaded. There will be no signing nor message caching.
   * July 4th: Setup a listener on another machine, preferably hosted in another location than mentors.debian.net
   * July 8th: Report on the behaviour of fedmsg on this testrun.
   * July 15th: First draft of a caching mechanism in fedmsg
   * July 23th: Finalized caching mechanism (hopefully) with help from upstream
   * July 30th: First draft for GPG-backed signed messages
   * August 5th: Finalized GPG signed messages.
   * August 19th: Patch against dak for fedmsg-ization of uploads and migration to testing
   * August 30th: Patch against wanna-build to send messages whenever a package changes status.
   * Rest of the summer: further fedmsg-ization of buildd's and dak, fedmsgization of jenkins.d.n and wiki.d.o
  • Name: Simon Chopin

  • Contact/Email: chopin.simon@gmail.com or laarmen on IRC at OFTC (#debian-python or #debian-mentors would be your best bet)

  • Background: I'm a 2nd year CS student at the University of Rennes 1, in France, after studying abroad for three years in Dresden and Potsdam. I'm currently in the process of becoming DM to ease my maintaining of several Python applications and modules in Debian. I'm thus pretty familiar with this language, as well as others such as C, C++, Lua, Scheme. On the upstream front, I'm mainly involved with the Pioneer projet. I've always been interested in how the Debian infrastructure works, particularly the way QA collects its data, and this project is a good opportunity to be able to improve it.

  • Project title: Implementation of message passing in the Debian infrastructure

  • Project details: (shameless mashup of olasd's and my ML posts) The Debian infrastructure is huge. Really huge. Lots of different service interface with each others, be it to build the uploaded packages, collect metrics, run static analysis, close bugs, etc... Each service has its own set of interfaces and schedules, and writing a new service would be a nightmare if you need data from more than one existing service.

    Fedora has recently started to solve this problem by creating FedMsg, a messaging infrastructure written in Python on top of the ZeroMQ messaging system. It is a decentralized system, which suits our infrastructure, and it aims at solving very similar issues. This project would be about implementing FedMsg message emission in various pieces of the infrastructure and start transitionning the current known clients of those services.

    Also, see the ML archive

  • Synopsis: This project aims at leveraging the existing FedMsg software to emit various messages when events occur in our infrastructure.

  • Benefits to Debian: Quoting Nicolas Dandrimont:

    • 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
        • ...
      I think the possibilities are quite nice, and, as the fedmsg webpage says, that "gives new meaning to open infrastructure".
  • Deliverables: Debian packages for fedmsg and its dependencies, patches upstream for features we need (ie GPG integration), patches to the Debian infratructure.

  • Project schedule:

    • I expect to be able to keep the following schedule:
    • June 17th: all packaging done and uploaded to unstable, also backported to wheezy and squeeze.
    • July 1st: Patch to Debexpo to emit a message when a new package is uploaded. There will be no signing nor message caching.
    • July 4th: Setup a listener on another machine, preferably hosted in another location than mentors.debian.net
    • July 8th: Report on the behaviour of fedmsg on this testrun.
    • July 15th: First draft of a caching mechanism in fedmsg
    • July 23th: Finalized caching mechanism (hopefully) with help from upstream
    • July 30th: First draft for GPG-backed signed messages
    • August 5th: Finalized GPG signed messages.
    • August 19th: Patch against dak for fedmsg-ization of uploads and migration to testing
    • August 30th: Patch against wanna-build to send messages whenever a package changes status.
    • Rest of the summer: further fedmsg-ization of buildd's and dak, fedmsgization of jenkins.d.n and wiki.d.o
  • Mentor: NicolasDandrimont

  • Exams and other commitments: I might have to retake some exams in June if I fail the ones in April.

  • Other summer plans: I intend to go to DebConf and maybe DebCamp, and I might take another week off for the Interceltic Festival of Lorient.

  • Why Debian?: Debian is the first big FOSS community I felt cumfortable in, and the Debian OS is the one I use on my servers, laptops and desktop. Furthermore, I know I would work on Debian during the summer, why not do it full time and get paid for it?

  • Are you applying for other projects in SoC? I am not yet planning to.