You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by Marcel Offermans <ma...@luminis.nl> on 2013/11/13 10:17:30 UTC
Towards a new release and baselining support...
Hey guys,
As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
One thing I would like to do is to upgrade to the latest Bndtools 2.2.2 version and enable support for baselining. Baselining will give us a lot of tool support to ensure our code (bundles and exported packages) is semantically versioned. To leverage baselining support there are a couple of things we need to do:
* We need the to start putting @ProviderType and @ConsumerType annotations on all our APIs. In fact, we need to “retrofit” this to our 1.0.0 release to ensure the baselining works correctly. These annotations are not magically available, but we can add them to the global build path (cnf/ext/defaults.bnd).
* We need to keep a copy of all released bundles (the latest version of each) in a repository to baseline against. Because we don’t want our build to break when we’re off-line I propose we put them in a local repository. We probably need to build those artifacts with the Eclipse compiler to prevent problems that will otherwise occur because of differences between ecj and javac so: checkout with Eclipse, build, collect all bundles from "generated" folders and publish them into the releaserepo in cnf. We also want to add them to the -deps artifact so people can easily get started with a release with baselining enabled.
If anybody else has input, speak up! :) WDYT?
Greetings, Marcel
Re: Towards a new release and baselining support...
Posted by Marcel Offermans <ma...@luminis.nl>.
Created https://issues.apache.org/jira/browse/ACE-429 to track progress on the migration to Bndtools 2.2.2 and I’ll start working on it right away.
On 14 Nov 2013, at 9:35 , christian.vogel@cvogel.com wrote:
> Hi Marcel,
>
>
> I have nothing to add here :)
>
>
> +1
>
>
> Cheers,
>
> Christian
>
>
> Marcel Offermans schrieb am 13.11.2013 10:17:
>> Hey guys,
>>
>> As you all know, a lot of things have happened recently within the ACE
>> project. We’ve rewritten the complete management agent, added quite a few
>> features to the server and squashed bugs. With all of this work done I feel
>> we should start working towards a new release now, but I’d like to get
>> everbody’s opinion and check if there are things we forgot about that
>> really need to make it into a new release.
>>
>> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2
>> version and enable support for baselining. Baselining will give us a lot of
>> tool support to ensure our code (bundles and exported packages) is
>> semantically versioned. To leverage baselining support there are a couple of
>> things we need to do:
>>
>> * We need the to start putting @ProviderType and @ConsumerType annotations
>> on all our APIs. In fact, we need to “retrofit” this to our 1.0.0
>> release to ensure the baselining works correctly. These annotations are not
>> magically available, but we can add them to the global build path
>> (cnf/ext/defaults.bnd).
>>
>> * We need to keep a copy of all released bundles (the latest version of
>> each) in a repository to baseline against. Because we don’t want our
>> build to break when we’re off-line I propose we put them in a local
>> repository. We probably need to build those artifacts with the Eclipse
>> compiler to prevent problems that will otherwise occur because of
>> differences between ecj and javac so: checkout with Eclipse, build, collect
>> all bundles from "generated" folders and publish them into the
>> releaserepo in cnf. We also want to add them to the -deps artifact so
>> people can easily get started with a release with baselining enabled.
>>
>> If anybody else has input, speak up! :) WDYT?
>>
>> Greetings, Marcel
>>
Re: Towards a new release and baselining support...
Posted by ch...@cvogel.com.
Hi Marcel,
I have nothing to add here :)
+1
Cheers,
Christian
Marcel Offermans schrieb am 13.11.2013 10:17:
> Hey guys,
>
> As you all know, a lot of things have happened recently within the ACE
> project. We’ve rewritten the complete management agent, added quite a few
> features to the server and squashed bugs. With all of this work done I feel
> we should start working towards a new release now, but I’d like to get
> everbody’s opinion and check if there are things we forgot about that
> really need to make it into a new release.
>
> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2
> version and enable support for baselining. Baselining will give us a lot of
> tool support to ensure our code (bundles and exported packages) is
> semantically versioned. To leverage baselining support there are a couple of
> things we need to do:
>
> * We need the to start putting @ProviderType and @ConsumerType annotations
> on all our APIs. In fact, we need to “retrofit” this to our 1.0.0
> release to ensure the baselining works correctly. These annotations are not
> magically available, but we can add them to the global build path
> (cnf/ext/defaults.bnd).
>
> * We need to keep a copy of all released bundles (the latest version of
> each) in a repository to baseline against. Because we don’t want our
> build to break when we’re off-line I propose we put them in a local
> repository. We probably need to build those artifacts with the Eclipse
> compiler to prevent problems that will otherwise occur because of
> differences between ecj and javac so: checkout with Eclipse, build, collect
> all bundles from "generated" folders and publish them into the
> releaserepo in cnf. We also want to add them to the -deps artifact so
> people can easily get started with a release with baselining enabled.
>
> If anybody else has input, speak up! :) WDYT?
>
> Greetings, Marcel
>
>
Re: Towards a new release and baselining support...
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/13/13 1:29 PM, Bram de Kruijff wrote:
>> As you all know, a lot of things have happened recently within
>> the ACE project. We’ve rewritten the complete management agent,
>> added quite a few features to the server and squashed bugs. With
>> all of this work done I feel we should start working towards a
>> new release now, but I’d like to get everbody’s opinion and check
>> if there are things we forgot about that really need to make it
>> into a new release.
>>>
> A big question is what we will do with the 'old' management agent.
> At present that code is still scattered throughout several
> projects. So.. will we keep supporting it, deprecate it until the
> next, or purge it? I think installed base is low en keeping it
> around surely will give a lot of overhead in maintaining the
> codebase and moving forward on interfaces. For that reason I would
> argue to purge it.
+1 for purging the old MA, as the left-overs of it still confuse me on
a daily basis (could also be due to the sleep deprivation I am
building up recently ;))
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
/My world is revolving around PulseOn and Amdatu/
Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK Apeldoorn
+31 88 586 46 30
http://www.luminis-technologies.com
http://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJShL4JAAoJEKF/mP2eHDc4MycP/A0+LZH1i34Ht9iFuGCRc1Y9
eDGXQt/DokTSVqLh0jdyphisvN9gznBd3+8NthggnH3NOlzElp+2JvzT2mi6fg+B
rcBMCUKAvqB5PtidJgynNUnqdTC8xRxzzj1yDp8uuDDHHAeI8OpzLalR0efpbveT
ZISeSUiEHkiaiGoRrdSUjikLYObBGLH5g1x1hM8WsYxR41YqGrk1aRnN1dSvuOut
s8A7EzL9TiSffmdg16aEv45+GKkKI/lNWGIc0yG7nPArgEQy482ue7BOwdRKkukH
242QYJjeQYyWN7jV7Y6hiblPmG2ql6dgoOIbhr+dr8CIiTW9swXYUQ83GAM3DPGg
vUUtkVpleE2QdKwpMFpE2gFTS6TDc8iuImArIPeCwUwidN9cWLez7qxl1VtVl+oj
94an2Lk8yjnU2IJXgAvmS6xPD5YCPsr7ZPnqK4/ewFsjHLeaKcNJ5kLeWMafmZ3S
bTC44BTyA+kaGi8GPqQWW4uQqOtwv70u+NWbkx8GS2rFE2FtsFvWEo0ew7GDG2m2
eKJOgjKM7GCdl/7shIyTiSsrJZhtrHFUDSKTtSbtuxqPOTk9pCfLKpYp6H3HgYKk
YZoHhJCgPX0QKAI5Kiea1xXM4vMg3B1zgefDWWcX3dnW5+WMdUms/GRN0PWhsjaf
o+xpV8/1DyqYTF50Z6S7
=rO36
-----END PGP SIGNATURE-----
Re: Towards a new release and baselining support...
Posted by Bram de Kruijff <bd...@gmail.com>.
On Wed, Nov 13, 2013 at 1:42 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> On 13 Nov 2013, at 13:29 , Bram de Kruijff <bd...@gmail.com> wrote:
>
>> On Wed, Nov 13, 2013 at 10:17 AM, Marcel Offermans
>> <ma...@luminis.nl> wrote:
>>> As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
>>
>> A big question is what we will do with the 'old' management agent. At
>> present that code is still scattered throughout several projects. So..
>> will we keep supporting it, deprecate it until the next, or purge it?
>> I think installed base is low en keeping it around surely will give a
>> lot of overhead in maintaining the codebase and moving forward on
>> interfaces. For that reason I would argue to purge it.
>
> I agree to purge it, as described in ACE-424 [1].
>
>> What will the (semantic) version of the release be? On the agent side
>> it feels like a major.. but that may depend on what we do with the old
>> one.
>
> First question is *do* we semantically version the release itself? I think we should as I see no reason to use a different versioning scheme.
>
> If so, I would be surprised if we don’t end up calling this 2.0.0 as I just broke an API in a backward incompatible way because I feel it was wrong (an interface extending ManagedService for no good reason).
>
Alright, agreed. So I guess we should think hard on what else we would
like to break within the foreseeable future :)
grz
Bram
> Greetings, Marcel
>
>
> [1] https://issues.apache.org/jira/browse/ACE-424
>
Re: Towards a new release and baselining support...
Posted by Paul Bakker <pa...@luminis.eu>.
+1 for purging the old MA
+1 for semantic versioning of the release itself. This should reflect the
largest change on the bundle level, which on itself should reflect the
largest change on package level.
Paul
On Wed, Nov 13, 2013 at 1:42 PM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> On 13 Nov 2013, at 13:29 , Bram de Kruijff <bd...@gmail.com> wrote:
>
> > On Wed, Nov 13, 2013 at 10:17 AM, Marcel Offermans
> > <ma...@luminis.nl> wrote:
> >> As you all know, a lot of things have happened recently within the ACE
> project. We’ve rewritten the complete management agent, added quite a few
> features to the server and squashed bugs. With all of this work done I feel
> we should start working towards a new release now, but I’d like to get
> everbody’s opinion and check if there are things we forgot about that
> really need to make it into a new release.
> >
> > A big question is what we will do with the 'old' management agent. At
> > present that code is still scattered throughout several projects. So..
> > will we keep supporting it, deprecate it until the next, or purge it?
> > I think installed base is low en keeping it around surely will give a
> > lot of overhead in maintaining the codebase and moving forward on
> > interfaces. For that reason I would argue to purge it.
>
> I agree to purge it, as described in ACE-424 [1].
>
> > What will the (semantic) version of the release be? On the agent side
> > it feels like a major.. but that may depend on what we do with the old
> > one.
>
> First question is *do* we semantically version the release itself? I think
> we should as I see no reason to use a different versioning scheme.
>
> If so, I would be surprised if we don’t end up calling this 2.0.0 as I
> just broke an API in a backward incompatible way because I feel it was
> wrong (an interface extending ManagedService for no good reason).
>
> Greetings, Marcel
>
>
> [1] https://issues.apache.org/jira/browse/ACE-424
>
>
Re: Towards a new release and baselining support...
Posted by Marcel Offermans <ma...@luminis.nl>.
On 13 Nov 2013, at 13:29 , Bram de Kruijff <bd...@gmail.com> wrote:
> On Wed, Nov 13, 2013 at 10:17 AM, Marcel Offermans
> <ma...@luminis.nl> wrote:
>> As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
>
> A big question is what we will do with the 'old' management agent. At
> present that code is still scattered throughout several projects. So..
> will we keep supporting it, deprecate it until the next, or purge it?
> I think installed base is low en keeping it around surely will give a
> lot of overhead in maintaining the codebase and moving forward on
> interfaces. For that reason I would argue to purge it.
I agree to purge it, as described in ACE-424 [1].
> What will the (semantic) version of the release be? On the agent side
> it feels like a major.. but that may depend on what we do with the old
> one.
First question is *do* we semantically version the release itself? I think we should as I see no reason to use a different versioning scheme.
If so, I would be surprised if we don’t end up calling this 2.0.0 as I just broke an API in a backward incompatible way because I feel it was wrong (an interface extending ManagedService for no good reason).
Greetings, Marcel
[1] https://issues.apache.org/jira/browse/ACE-424
Re: Towards a new release and baselining support...
Posted by Bram de Kruijff <bd...@gmail.com>.
Hi,
On Wed, Nov 13, 2013 at 10:17 AM, Marcel Offermans
<ma...@luminis.nl> wrote:
> Hey guys,
>
> As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
>
A big question is what we will do with the 'old' management agent. At
present that code is still scattered throughout several projects. So..
will we keep supporting it, deprecate it until the next, or purge it?
I think installed base is low en keeping it around surely will give a
lot of overhead in maintaining the codebase and moving forward on
interfaces. For that reason I would argue to purge it.
> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2 version and enable support for baselining. Baselining will give us a lot of tool support to ensure our code (bundles and exported packages) is semantically versioned. To leverage baselining support there are a couple of things we need to do:
>
> * We need the to start putting @ProviderType and @ConsumerType annotations on all our APIs. In fact, we need to “retrofit” this to our 1.0.0 release to ensure the baselining works correctly. These annotations are not magically available, but we can add them to the global build path (cnf/ext/defaults.bnd).
>
> * We need to keep a copy of all released bundles (the latest version of each) in a repository to baseline against. Because we don’t want our build to break when we’re off-line I propose we put them in a local repository. We probably need to build those artifacts with the Eclipse compiler to prevent problems that will otherwise occur because of differences between ecj and javac so: checkout with Eclipse, build, collect all bundles from "generated" folders and publish them into the releaserepo in cnf. We also want to add them to the -deps artifact so people can easily get started with a release with baselining enabled.
>
+1
> If anybody else has input, speak up! :) WDYT?
>
What will the (semantic) version of the release be? On the agent side
it feels like a major.. but that may depend on what we do with the old
one.
grz
Bram
> Greetings, Marcel
>
Re: Towards a new release and baselining support...
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello JB,
Thanks for the heads-up, and good luck with Karaf 3.0.0! If you have some time after that, could you please also look at a couple of “old” issues still on your name and decide what you want to do with those?
Greetings, Marcel
On 13 Nov 2013, at 10:21 , Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Marcel and the others,
>
> +1 about that.
>
> I'm pretty busy with Karaf 3.0.0, but I will take a look on latest changes tomorrow.
>
> Regards
> JB
>
> On 11/13/2013 10:17 AM, Marcel Offermans wrote:
>> Hey guys,
>>
>> As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
>>
>> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2 version and enable support for baselining. Baselining will give us a lot of tool support to ensure our code (bundles and exported packages) is semantically versioned. To leverage baselining support there are a couple of things we need to do:
>>
>> * We need the to start putting @ProviderType and @ConsumerType annotations on all our APIs. In fact, we need to “retrofit” this to our 1.0.0 release to ensure the baselining works correctly. These annotations are not magically available, but we can add them to the global build path (cnf/ext/defaults.bnd).
>>
>> * We need to keep a copy of all released bundles (the latest version of each) in a repository to baseline against. Because we don’t want our build to break when we’re off-line I propose we put them in a local repository. We probably need to build those artifacts with the Eclipse compiler to prevent problems that will otherwise occur because of differences between ecj and javac so: checkout with Eclipse, build, collect all bundles from "generated" folders and publish them into the releaserepo in cnf. We also want to add them to the -deps artifact so people can easily get started with a release with baselining enabled.
>>
>> If anybody else has input, speak up! :) WDYT?
>>
>> Greetings, Marcel
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Towards a new release and baselining support...
Posted by Paul Bakker <pa...@luminis.eu>.
Hi Marcel,
I agree about enabling baselining before the upcoming release. The
procedure you describe is similar to what my team is currently using, and
this works well.
It probably does mean we do have to change the ANT build as well to use the
Eclipse compiler, otherwise the build will fail on baselining errors. This
is possible, the compiler is available standalone and can be used from ANT.
Paul
On Wed, Nov 13, 2013 at 10:21 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>wrote:
> Hi Marcel and the others,
>
> +1 about that.
>
> I'm pretty busy with Karaf 3.0.0, but I will take a look on latest changes
> tomorrow.
>
> Regards
> JB
>
>
> On 11/13/2013 10:17 AM, Marcel Offermans wrote:
>
>> Hey guys,
>>
>> As you all know, a lot of things have happened recently within the ACE
>> project. We’ve rewritten the complete management agent, added quite a few
>> features to the server and squashed bugs. With all of this work done I feel
>> we should start working towards a new release now, but I’d like to get
>> everbody’s opinion and check if there are things we forgot about that
>> really need to make it into a new release.
>>
>> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2
>> version and enable support for baselining. Baselining will give us a lot of
>> tool support to ensure our code (bundles and exported packages) is
>> semantically versioned. To leverage baselining support there are a couple
>> of things we need to do:
>>
>> * We need the to start putting @ProviderType and @ConsumerType
>> annotations on all our APIs. In fact, we need to “retrofit” this to our
>> 1.0.0 release to ensure the baselining works correctly. These annotations
>> are not magically available, but we can add them to the global build path
>> (cnf/ext/defaults.bnd).
>>
>> * We need to keep a copy of all released bundles (the latest version of
>> each) in a repository to baseline against. Because we don’t want our build
>> to break when we’re off-line I propose we put them in a local repository.
>> We probably need to build those artifacts with the Eclipse compiler to
>> prevent problems that will otherwise occur because of differences between
>> ecj and javac so: checkout with Eclipse, build, collect all bundles from
>> "generated" folders and publish them into the releaserepo in cnf. We also
>> want to add them to the -deps artifact so people can easily get started
>> with a release with baselining enabled.
>>
>> If anybody else has input, speak up! :) WDYT?
>>
>> Greetings, Marcel
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Towards a new release and baselining support...
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Marcel and the others,
+1 about that.
I'm pretty busy with Karaf 3.0.0, but I will take a look on latest
changes tomorrow.
Regards
JB
On 11/13/2013 10:17 AM, Marcel Offermans wrote:
> Hey guys,
>
> As you all know, a lot of things have happened recently within the ACE project. We’ve rewritten the complete management agent, added quite a few features to the server and squashed bugs. With all of this work done I feel we should start working towards a new release now, but I’d like to get everbody’s opinion and check if there are things we forgot about that really need to make it into a new release.
>
> One thing I would like to do is to upgrade to the latest Bndtools 2.2.2 version and enable support for baselining. Baselining will give us a lot of tool support to ensure our code (bundles and exported packages) is semantically versioned. To leverage baselining support there are a couple of things we need to do:
>
> * We need the to start putting @ProviderType and @ConsumerType annotations on all our APIs. In fact, we need to “retrofit” this to our 1.0.0 release to ensure the baselining works correctly. These annotations are not magically available, but we can add them to the global build path (cnf/ext/defaults.bnd).
>
> * We need to keep a copy of all released bundles (the latest version of each) in a repository to baseline against. Because we don’t want our build to break when we’re off-line I propose we put them in a local repository. We probably need to build those artifacts with the Eclipse compiler to prevent problems that will otherwise occur because of differences between ecj and javac so: checkout with Eclipse, build, collect all bundles from "generated" folders and publish them into the releaserepo in cnf. We also want to add them to the -deps artifact so people can easily get started with a release with baselining enabled.
>
> If anybody else has input, speak up! :) WDYT?
>
> Greetings, Marcel
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Towards a new release and baselining support...
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/13/13 10:17 AM, Marcel Offermans wrote:
> Hey guys,
>
> As you all know, a lot of things have happened recently within the
> ACE project. We’ve rewritten the complete management agent, added
> quite a few features to the server and squashed bugs. With all of
> this work done I feel we should start working towards a new
> release now, but I’d like to get everbody’s opinion and check if
> there are things we forgot about that really need to make it into a
> new release.
>
> One thing I would like to do is to upgrade to the latest Bndtools
> 2.2.2 version and enable support for baselining. Baselining will
> give us a lot of tool support to ensure our code (bundles and
> exported packages) is semantically versioned. To leverage
> baselining support there are a couple of things we need to do:
>
> * We need the to start putting @ProviderType and @ConsumerType
> annotations on all our APIs. In fact, we need to “retrofit” this
> to our 1.0.0 release to ensure the baselining works correctly.
> These annotations are not magically available, but we can add them
> to the global build path (cnf/ext/defaults.bnd).
+1! It is a good thing that we've made our APIs easy recognizable ;)
> * We need to keep a copy of all released bundles (the latest
> version of each) in a repository to baseline against. Because we
> don’t want our build to break when we’re off-line I propose we put
> them in a local repository. We probably need to build those
> artifacts with the Eclipse compiler to prevent problems that will
> otherwise occur because of differences between ecj and javac so:
> checkout with Eclipse, build, collect all bundles from "generated"
> folders and publish them into the releaserepo in cnf. We also want
> to add them to the -deps artifact so people can easily get started
> with a release with baselining enabled.
+1. We need to include a version of ECJ in our build-repository for
off-line builds, but how do we include this in our source releases? We
cannot ship binaries with our source release, but can we use the same
approach as we currently have for the compile-time dependencies?
- --
Met vriendelijke groeten | Kind regards
Jan Willem Janssen | Software Architect
+31 631 765 814
/My world is revolving around PulseOn and Amdatu/
Luminis Technologies B.V.
J.C. Wilslaan 29
7313 HK Apeldoorn
+31 88 586 46 30
http://www.luminis-technologies.com
http://www.luminis.eu
KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJShL1vAAoJEKF/mP2eHDc4ClMP/RaOCrQXYV4zd2bcsgY6Ov0P
Iv6u7Kq8RZUwRVo8uFFIJu3cEdxlLTTuSe2PGoNlXgPLeOtpV+8wKf5a71F/2fkz
oWdfHLMp24Mt1dTjzkFlz0JX0hHbrs3S0Zf93EPn5AAHhkYEB7/7uR+BT5StECu7
NzJZSjeKRad0YWOo/TF+4w83Zt/r4gQFEt3udM9/GaPUI7OjZCit9omApxRoeO74
T9s+cC4syY1WkTfq3avRnq2fflekR6ySjdnX/C3deoqbbQccNxsnT7XRD87zrs3b
aNHHcJR6xOpc1c+CB9EnKWIrbD6ltEP/FnH8GOkO9f9JsSUkhQ4mMci172ocIB66
Y/TfY2mItT9zESrB58GeC+JRsyiOTU7YojXvLUUhe5BK9QitEZYA6lxJVzGw9wo+
2JEDz24EbZSeuHLwc19wf1mYwv+pb2Ws7n1ot701pTn+NbXF15EigoDsF5eGOsdf
22uBj66ZId4VPF3QTpZpqkk95I0SXEuJJ0vDhjOEmXLKe0rKpOaDG/dUmPXBRjl7
D6gtxIkMBAsb8q/TgqwcF7vGwiaL8Y2dxS0UJbT7snAzZx2KEAD7UE3pvR6GM4oz
IDwNdOPTIc7cv7EmbYcimdV/sVL4FVWemPXZWc/f3kshqV9Dj0VeWN04u5gtATIk
o610kc+T0NgEFCVwkLEE
=7eSU
-----END PGP SIGNATURE-----