Upstart Development

[Scott James Remnant]

Hey folks,

There's been a lot of confusion, fear, uncertainty and doubt over what's
going on with Upstart Development over the past couple of years.  As the
lead developer, I obviously have to accept the blame for this.

I started developing Upstart what seems like an age ago now, but really
was less than three years.  At the time I hadn't expected to do it as
anything more than a hobby project, but was delighted when I was able to
sell the idea of writing an init replacement to my employers
(Canonical).

My entire reason for writing a new one, rather than using an exisiting
system like init-ng, was simple: I don't think a dependency-based system
is the right design.  Modern Linux is fundamentally event-based, and I
thus believe that the init system must be too.

So, with Canonical's backing, I developed the first few series of
Upstart (up to 0.3.x) as part of my day job, with Ubuntu as the primary
target user.

For the next release, I planned a set of major improvements and these
would have been released for Ubuntu 7.04

But I had a major change of circumstances, I became a manager.  My work
time for coding went away, and I continued developing Upstart only in my
spare time.  This is why 0.5 sucked.

At the same time, Linux plumbing underwent some big changes and Upstart
needed to be rethought to account for these.  One of the most
fundamental shifts was using D-Bus as the central hub of communication.
This was why 0.5 took so long.  

Now I wasn't a great manager, so I've stepped down and returned to a
full-time development role.  The one, in fact, that I had vacated before
and that was never filled in in the meantime.  So my job again is to
develop the Ubuntu boot sequence, and maintain the plumbing layer.  And
this includes developing Upstart, I'll be working full time on
development (alongside other things like udev).


So onto the future of Upstart.

I'd like to change the mail I sent out earlier this month.  I've been
working on a few different streams of code:

Firstly a rewrite of the D-Bus binding code, fixing a massive number of
bugs including memory leaks and suchlike.  This is taking place on the
libnih trunk, and the code is on Launchpad right now.

Secondly I've been rewriting the main loop code to use better available
syscalls like signalfd() and timerfd_create() rather than the current
mechanism.  This doesn't build (or even work), so I haven't pushed it
anywhere yet.  As soon as the D-Bus stuff is done, I'll push this on top
to a separate branch and it'll move to trunk once it builds.

Thirdly there is some code to follow forking/daemon processes.  This is
not attached to any other project, it's not a modification of Upstart,
etc. it's simply a prototype/play on my laptop.  As I've said above, I
don't intend to release this _just_ yet - I'm feeling a bit protective
over it ;-)

I haven't begun work on the Upstart code yet, other than keeping it
up-to-date with the libnih changes.  I'm still targetting June to work
on that, with a release sometime in June.


As to the work on changes to Upstart, the first and most important thing
you could do to help is to comment and discuss on my plans.  Go watch
the video of the FOSDEM talk I gave earlier this year:

http://ftp.heanet.ie/mirrors/fosdem-video/2009/maintracks/upstart.xvid.avi

From that, it should start to become obvious how to modify the code -
and we can split that work up if people are willing.


But we do need to establish one fundamental ground rule, which I know
there's been controversy about.

Canonical own the copyright to Upstart, and require Copyright Assignment
for all contributions.  This is for many reasons, but chiefly so that
Canonical can persue licence violation claims without needing to contact
all contributors, so Canonical can offer its patent indemnity on code
that has been contributed directly to it, and so you need not be
involved should Canonical itself be litigated against.  The agreement
liberally licences back your contributions to you, and we would never be
evil and make Upstart closed source.

The process is pretty simple, the first time you plan to a patch, or
actually send it, get in touch with me and I'll send you a PDF back
which you need to reply to.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20090522/43198099/attachment.pgp