[pkg-eucalyptus-maintainers] Updated euca2ools to version 1.2 in Debian.

[Dustin Kirkland]

On Sat, 2010-03-13 at 14:10 +0900, Charles Plessy wrote:
> Hi Dustin and everybody,
> 
> first, sorry for the mess with README.debian, I had removed it and then
> it slipped again in my final upload. I just checked the other files
> and apparently there are no other unwated reversions.

No problem ;-)

> About the Amazon public key and the uploads to Debian:
> 
> I share Steffen's concerns about distributing the Amazon public key in the
> euca2ools package. First, it is a divergence with upstream that is not
> necessarly obvious, and may give the impression that Eucalyptus distributes the
> key. Second, if we offer this key as a service to our users, then I think that
> we become responsible for keeping it up to date. Why not, but I am not sure if
> the euca2tools is the best place to keep such extras. How about cloud-utils or
> python-vm-builder-ec2 instead ? I think that we could benefit from a bit
> more coordination with the other packages that may need this key.

I can check if it would be acceptable for me to move it to cloud-utils.
But if not, Ubuntu will likely carry this as a diff against the Debian
package.

> Dustin, for the uploads to Debian, please go ahead and ask for your key to be
> added in the DM keyring. In the meantime, you can push your changes in the git
> repository, or provide ready-to-upload package in a place where the source
> package is dget-able. If needed, there is a simple command to push a posteriori
> a source package in our git repository, ‘git-import-dsc’. Please use normal
> version numbers when the package is indended for upload. We will send this
> straight to unstable. Since there is a commit list (please subscribe), there
> will be multiple pairs of eyes looking at the changes introduced at each
> upload.

Great, thanks, will do.

> Last comment about the Debhelper compatibility levels: if we delete
> debian/compat, then CDBS will pick a default one, usually the highest
> available. This will make backports easier. In general, I like to have use a
> level that corresponds to the highest available in Debian stable, in order to
> avoid tho have to suddenly review dozens of package when the compat. level they
> use get deprecated. But in case of Debian/Ubuntu collaborations, we can pick a
> lower common denominator if needed.

Sure, sounds fine.

Thanks, guys!

:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/attachments/20100313/d74ca921/attachment.pgp>