[Pkg-puppet-devel] Status for 0.25.5, patches in the BTS

[micah anderson]

On Wed, 09 Jun 2010 22:12:01 +0200, Stig Sandbeck Mathisen <ssm at debian.org> wrote:
> 
> I've fixed an issue in the master branch which prevented a neat upgrade
> of puppetmaster to 0.25.5, it has been uploaded to alioth.  I've still
> not cut a release, though.
> 
> There are a few patches in the BTS I'd like to include or reject for the
> next release:
> 
> 
> http://bugs.debian.org/571129
> -----------------------------
> 
>   Adds two directories: /etc/puppet/templates and /etc/puppet/modules
> 
> +1 from me.

+1 from me

> http://bugs.debian.org/573551
> -----------------------------
> 
>   Makes the provider for the "service" work on newer debian systems
>   using "insserv".
> 
> This would have to be restricted to debian (and ubuntu) releases using
> insserv.  The combination of update-rc.d and insserv does not use the
> arguments "stop" or "defaults", but rather "disable" and "enable".
> 
> ,----[ A warning from "update-rc.d" ]
> | The disable|enable API is not stable and might change in the future.
> `----
> 
> Not sure on this

Yeah, I'm not sure on this either, but I think maybe it should be taken
upstream. I'd say not for this release.


> http://bugs.debian.org/579643
> -----------------------------
> 
> Puppetd lock file persistence across reboots
> 
> We could perhaps also check for the presence of an "admin lock file" in
> the init scripts, in addition to the puppetd lock file.  However, this
> overrides the START=yes|no|whatever parameter in /etc/default/puppet

This one needs to be taken upstream too. No for this release

> http://bugs.debian.org/584480
> -----------------------------
> 
> Puppet test suites
> 
> +1 from me, looks like a good idea.
+1 from me

> 
> http://bugs.debian.org/584481
> -----------------------------
> 
> Better support for "upstart" jobs in the "init" provider in the
> "service" type.
> 
> Not sure on this, there should be an upstart provider, but I'm not sure
> puppet can dynamically choose a provider per service.

Has this been taken upstream?

> There's also a metric buttload of submitted patches regarding the puppet
> configuration language and behaviour itself, not necessarily related to
> packaging issues.  Should we blankly submit all of them upstream, and
> risk annoying the masters of puppet, or are any of them rejectable?

We should try to filter some of them I think.

Unfortunately, until the end of this month I'm not going to have any
additional time :(

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20100614/5a20641b/attachment.pgp>