This Week in OpenNMS: Season 1.6, Episode 36: Banning Scrum with Scrumban

It's time for This Week in OpenNMS. This week we did more SMS work, and
released a new stable version of OpenNMS.


Project Updates
---------------

- Stable: Current Release is 1.6.5

1.6.6 is the current stable release, tagged September 18th.  It fixes a
number of bugs, and adds a few features.  For a full list, see the
bugzilla 1.6.6 milestone.  This is a non-critical but recommended
upgrade for anyone on OpenNMS versions older than 1.6.6.

     http://tinyurl.com/opennms-166

- Unstable: Current Release is 1.7.6

1.7.6 is the current unstable release, tagged August 3rd.  Since 1.7.5,
there have been a ton of bugfixes, as well as updates to the RESTful
interfaces, inventory report updates, syslogd updates, collection
updates, new OpenManage and Cisco IP-SLA monitors, thresholding updates,
provisiond updates, map updates, and probably more stuff I'm missing.  A
1.7.x overview is available in the release notes on the site.

     http://tinyurl.com/opennms-17x

- Unstable: SMS Pinger/Request-Response API

We continued work on the SMS monitor, including wrapping up the basic
design of the sequence monitor, and are now working our way through bugs
and other minor feature additions.

- Unstable: DNS Import Handler

Dave did some refactoring of the DNS import handler and provisioner to
make it easier to get import data from different types of sources. (More
on that below.)

More on the DNS Provisioning Enhancements
-----------------------------------------

Dave sent me a little note describing more about some enhancements he
made to the provisioner, and the DNS provisioning process:

  A new enhancement was made to the Provisioning service of OpenNMS.
  In pursuit of version 1.8, the merger of Capsd and the Model Importer
  has resulted a new Provisioning Service daemon in OpenNMS
  (Provisiond).  Based on the Model Importer, XML encoded
  nodes/interfaces/services can be imported into the OpenNMS DB under
  the assumption that the source generating the XML would be make this
  XML available via a URL Resource (i.e. file:// or http://).  In 1.6
  and in 1.7, most often the source is a "file:" URL and is created
  with the OpenNMS WebUI.  For 1.8, this XML has been given the formal
  name of "Import Requisition" or simply "Requisition".

  A new protocol handler was developed last week allowing the
  specification of a the URL "dns://".  This new URL takes the form of
  "dns://<dns host>[:port]/<zone>" such as
  "dns://mydns.mydomain.com/myzone".  A zone transfer must be allowed
  from the OpenNMS server and the new protocol handler returns a to the
  Provisioner the XML requisition of nodes/interfaces/services based on
  each "A" record returned from the Zone.

  Additionally, the model-importer.properties configuration file where
  a single URL resource and a single Cron based import schedule could
  be defined, has been upgraded to an XML based configuration
  container.  The new container allows multiple URLs to be defined each
  with their own Cron schedule.


Getting a Bit More Agile
------------------------

As our team grows here at The OpenNMS Group, we've started needing to
manage our time better between paid development, community
contributions, and release management.  This week we're starting out on
a new agile/lean methodology called scrum-ban[1].  It's a combination of
agile development and the "kanban[2]" just-in-time methodology for doing
engineering production.  (If you're in any way interested in development
process stuff, I heartily recommend reading that last link, it's neat
stuff.)

I'm not sure how I feel about the idea that I'm actually excited about
introducing more structure into our development process, but I am.  My
hope is that what you will see come out of this is more regular
communication of features as they're implemented, better management of
branches and releases, and overall, smoother development.
One thing that will change from the point of view of people keeping up
with development is that our nightly builds will be based on more
up-to-date code.  When 1.6 went golden, we implemented a dual-branch
strategy.  We wanted it to be easy for anyone to make bugfixes to
stable, but wanted to make sure we had a peer review process so we're
less likely to put out changes that cause issues in the production
release.  So, we have 2 branches: 1.6, and 1.6-testing.  1.6-testing is
open season for anyone with a commit bit, if you see a bug, you can fix
it.  But, to get a fix into a release, we have 2 (simple) requirements:
1, before it can go into a future 1.6 release, the fix must have an
associated bug number in our bug tracking system, and 2, it must be
reviewed by someone other than the person who committed the fix.
The way this has worked so far is, before we do a release, we go through
bugzilla and look for anything that's marked[3] as the "future 1.6"
milestone, and has been closed but not verified.  For each bug, we look
at the commit in the 1.6-testing branch, test it if it's anything but a
trivial one-liner, and merge it to the 1.6 release branch, then mark it
as verified.  It's a bit tedious, but I love that we know everything
that's gone into a release[4].

As part of our scrum-ban process, merging will be another task that
we'll regular schedule in our backlog along with development work, so we
don't build up all that merging at release time.  Nightly 1.6 snapshots
will be more timely, and features should be pushed through the
development process faster, instead of trying to juggle too many things
simultaneously.

1. http://leansoftwareengineering.com/ksse/scrum-ban/
2. http://en.wikipedia.org/wiki/Kanban
3. http://tinyurl.com/laltht
4. http://www.opennms.org/wiki/New_and_Noteworthy


Upcoming Events
---------------

* October 28, 2009:
   Tarus Balog will be speaking at the Open Source Monitoring Conference
   2009 in Nuremberg.

   http://www.netways.de/en/osmc/y2009/referenten/

If you have anything to add to the events list, please let me know.


Until Next Week...
------------------

As always, if there's anything you'd like me to talk about in a future
TWiO, or you just have a comment, criticism, or whiteboard management
tools you'd like to share, don't hesitiate to say hi.


-- 
Benjamin Reed
The OpenNMS Group
http://www.opennms.org/

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf

_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq

opennms-announce mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-announce

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKt8TmUu+jZtP2Zf4RAl8mAJ93fWfhcR5Q6EuqLTMZeZx5gqQ5JACfbZSK
oTMxHs9Abqao+FRr4wWEdcU=
=SU2U
-----END PGP SIGNATURE-----