You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Everett Toews <ev...@RACKSPACE.COM> on 2014/10/02 18:12:01 UTC
Releasing 1.8.1
Let's schedule the release of 1.8.1.
All code into 1.8.x by Monday, Oct. 6 EOD
Begin release on Tuesday, Oct. 7
Can someone volunteer to do the actual release steps?
I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
Thanks,
Everett
Re: Releasing 1.8.1
Posted by Adrian Cole <ad...@gmail.com>.
I'd like to help finish removing deprecated async stuff. I should be able
to get all of non-labs providers done, except rackspace legacy with I think
Jeremy is on.
-A
On Oct 2, 2014 9:12 AM, "Everett Toews" <ev...@rackspace.com> wrote:
> Let's schedule the release of 1.8.1.
>
> All code into 1.8.x by Monday, Oct. 6 EOD
> Begin release on Tuesday, Oct. 7
>
> Can someone volunteer to do the actual release steps?
>
> I'll be catching up with work stuff all next week after being on the road
> for a few weeks but I can do it if necessary.
>
> Thanks,
> Everett
>
>
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> ServiceMix is starting a bundle release later today or tomorrow. So
> the ETA for SMX4-1859 will be later this week or early next.
Thanks for the heads-up! I don't think we need to wait that long, but
I will check if the new bundle is available before the code freeze.
To allow any last PRs to be finished off, I suggest we freeze at 06:00
PDT/09:00 EDT/15:00 CET tomorrow morning.
Does that work for everyone?
ap
Re: Releasing 1.8.1
Posted by Chris Custine <ch...@gmail.com>.
ServiceMix is starting a bundle release later today or tomorrow. So the ETA for SMX4-1859 will be later this week or early next.
--
Chris Custine
On October 6, 2014 at 4:32:26 PM, Andrew Phillips (aphillips@qrmedia.com) wrote:
> >> If this works for others, I'll merge [1] and revert it again once
> >> we can merge [2] (which depends on SMX4-1859 [3]).
> >
> > I’m okay with this approach.
>
> I've committed the change to master and 1.8.x [1, 2] and updated the
> follow-up PR to revert [3] once we can.
>
> ap
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=53fc568743bb13a0001223b6c5f5cc549627296e
> [2]
> https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=7b7b54e0c7ec7f44b13c66402db09869b29f784e
> [3] https://github.com/jclouds/jclouds/pull/533
>
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
>> If this works for others, I'll merge [1] and revert it again once
>> we can merge [2] (which depends on SMX4-1859 [3]).
>
> I’m okay with this approach.
I've committed the change to master and 1.8.x [1, 2] and updated the
follow-up PR to revert [3] once we can.
ap
[1]
https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=53fc568743bb13a0001223b6c5f5cc549627296e
[2]
https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commit;h=7b7b54e0c7ec7f44b13c66402db09869b29f784e
[3] https://github.com/jclouds/jclouds/pull/533
Re: Releasing 1.8.1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Oct 6, 2014, at 4:17 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
> If this works for others, I'll merge [1] and revert it again once we can merge [2] (which depends on SMX4-1859 [3]).
I’m okay with this approach.
Everett
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> The approach has already been tested and worked, and even it is not
> the ideal solution, IMHO it's not a big deal.
Fine with me. Note that this is likely to leave karaf support for
agentproxy broken (I don't know if anyone ever used it, or even if it
works now!) since the necessary inclusions have not been made there.
But I think that's a potential Known Issue we can live with, indeed.
If this works for others, I'll merge [1] and revert it again once we
can merge [2] (which depends on SMX4-1859 [3]).
ap
[1] https://github.com/jclouds/jclouds/pull/525
[2] https://github.com/jclouds/jclouds/pull/533
[3] https://issues.apache.org/jira/browse/SMX4-1859
Re: Releasing 1.8.1
Posted by Ignasi Barrera <ig...@gmail.com>.
Regarding the ssh agent thing, there are two options:
* Exclude the conflicting transitive dependency.
* Upgrading the version to a newer one with a compatible license.
For the latter we need to wait for a karat fix, and the former has
already been tested and it works as expected. I propose to merge the
exclusion PR, and bump the version in a future release once the
pending karat think is unlocked. The approach has already been tested
and worked, and even it is not the ideal solution, IMHO it's not a big
deal.
On 6 October 2014 21:58, Andrew Phillips <ap...@qrmedia.com> wrote:
>> It would be great if someone with better knowledge could give some
>> light on this, and if LGPL dependencies can be used.
>
>
> That would be great, indeed. What I've been able to gather is the same as
> you: as jclouds, we shouldn't have any problem releasing this.
>
> The point Alex was originally trying to make when he raised this, though (as
> far as I understood) was a different one: if we suddenly include an LGPL
> lib, it becomes impossible for anyone to bundle jclouds in a product that is
> not LGPL-compliant.
>
> Of course, they could jump through some hoops to try to exclude it (like
> Brooklyn did), but my guess is that, if they know, they would simply skip
> 1.8.1 and future releases until this is fixed. Data on this point would be
> welcome, but the absence of more evidence I think we should be conservative
> and take the one datapoint that we have (from Alex) that this is a Real
> Problem.
>
> ap
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> It would be great if someone with better knowledge could give some
> light on this, and if LGPL dependencies can be used.
That would be great, indeed. What I've been able to gather is the same
as you: as jclouds, we shouldn't have any problem releasing this.
The point Alex was originally trying to make when he raised this,
though (as far as I understood) was a different one: if we suddenly
include an LGPL lib, it becomes impossible for anyone to bundle
jclouds in a product that is not LGPL-compliant.
Of course, they could jump through some hoops to try to exclude it
(like Brooklyn did), but my guess is that, if they know, they would
simply skip 1.8.1 and future releases until this is fixed. Data on
this point would be welcome, but the absence of more evidence I think
we should be conservative and take the one datapoint that we have
(from Alex) that this is a Real Problem.
ap
Re: Releasing 1.8.1
Posted by Ignasi Barrera <na...@apache.org>.
I can also take the release, so if you're too busy Andrew just ping me
and I'll step in.
Regarding the LGPL thing, I have some doubts. Reading the ASF legal
FAQ [1] it seems that we can't include LGPL licenses, but the point
here is that we are *not* distributing the LGPL licensed software. A
jclouds release consists *only* of the jclouds source code, and that
does not include any source files licensed under LGPL.
Using LGPL dependencies is not clear to me, though. I've searched the
archives and found this thread [2], where it seems to say that having
build/test dependencies might be OK from the ASF perspective, but it
is not clear to me. In the end, all what we distribute is Apache
licensed, but in order to be able to build/run this ASF licensed
software, one may need to download an external LGPL licensed library.
It would be great if someone with better knowledge could give some
light on this, and if LGPL dependencies can be used.
I.
[1] http://www.apache.org/legal/resolved.html#category-x
[2] http://markmail.org/message/5upamttl2uk7ywwm
On 6 October 2014 21:27, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Is there a volunteer for doing the release tomorrow?
>
>
> I can pick this up - week doesn't look too full so far for me, and I'm not
> on the road.
>
> But I would rather not release with the LGPL dependency issue [1] caused by
> JSch's agentproxy still open. Can we make a decision on [2] first?
>
> ap
>
> [1] http://apache.markmail.org/thread/qqzou2moxj5n5ibv
> [2] http://markmail.org/message/37atekexnvsxj37k
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Is there a volunteer for doing the release tomorrow?
I can pick this up - week doesn't look too full so far for me, and I'm
not on the road.
But I would rather not release with the LGPL dependency issue [1]
caused by JSch's agentproxy still open. Can we make a decision on [2]
first?
ap
[1] http://apache.markmail.org/thread/qqzou2moxj5n5ibv
[2] http://markmail.org/message/37atekexnvsxj37k
Re: Releasing 1.8.1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
Okay. Code cutoff EOD then.
Is there a volunteer for doing the release tomorrow?
If not, I’ll do it using AP’s Google Doc [1]. If I do wind up doing the release, you’ll be able to find me on #jclouds in an emotionally distressed state.
Everett
[1] https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit
On Oct 3, 2014, at 5:52 PM, Adrian Cole <ad...@gmail.com> wrote:
> Sounds fair. Thanks for standing up for regular releases :)
>
> -A
>
> On Fri, Oct 3, 2014 at 3:49 PM, Everett Toews
> <ev...@rackspace.com> wrote:
>> So it’s a pretty normal and natural thing that, when a release is called for, people put up their hands and say “hold off for just a bit, I’ve got one more thing I want to add!”
>>
>> If projects did hold off then nothing would ever get released because there’s always some good reason to put a hold on things.
>>
>> Users expect a release from us every 6 weeks because that’s the minor release cadence we’ve committed to. 1.8.1 is already 3 weeks late according to our minor release cadence. I propose we stick with the schedule below and anything not in by Monday EOD can simply wait until the next release. It’s only 6 weeks away.
>>
>> To prevent this from happening next time, I’ve been a little more specific on the Roadmap [1] based on our cadence. If people have more foreknowledge of when a release is going to happen, they can get that thing they want in there prior to the code freeze.
>>
>> I’m hoping this isn’t too much to ask for and we can just ship some code.
>>
>> Thanks,
>> Everett
>>
>>
>> On Oct 2, 2014, at 11:12 AM, Everett Toews <ev...@rackspace.com> wrote:
>>
>>> Let's schedule the release of 1.8.1.
>>>
>>> All code into 1.8.x by Monday, Oct. 6 EOD
>>> Begin release on Tuesday, Oct. 7
>>>
>>> Can someone volunteer to do the actual release steps?
>>>
>>> I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
>>>
>>> Thanks,
>>> Everett
>>>
>>
Re: Releasing 1.8.1
Posted by Adrian Cole <ad...@gmail.com>.
Sounds fair. Thanks for standing up for regular releases :)
-A
On Fri, Oct 3, 2014 at 3:49 PM, Everett Toews
<ev...@rackspace.com> wrote:
> So it’s a pretty normal and natural thing that, when a release is called for, people put up their hands and say “hold off for just a bit, I’ve got one more thing I want to add!”
>
> If projects did hold off then nothing would ever get released because there’s always some good reason to put a hold on things.
>
> Users expect a release from us every 6 weeks because that’s the minor release cadence we’ve committed to. 1.8.1 is already 3 weeks late according to our minor release cadence. I propose we stick with the schedule below and anything not in by Monday EOD can simply wait until the next release. It’s only 6 weeks away.
>
> To prevent this from happening next time, I’ve been a little more specific on the Roadmap [1] based on our cadence. If people have more foreknowledge of when a release is going to happen, they can get that thing they want in there prior to the code freeze.
>
> I’m hoping this isn’t too much to ask for and we can just ship some code.
>
> Thanks,
> Everett
>
>
> On Oct 2, 2014, at 11:12 AM, Everett Toews <ev...@rackspace.com> wrote:
>
>> Let's schedule the release of 1.8.1.
>>
>> All code into 1.8.x by Monday, Oct. 6 EOD
>> Begin release on Tuesday, Oct. 7
>>
>> Can someone volunteer to do the actual release steps?
>>
>> I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
>>
>> Thanks,
>> Everett
>>
>
Re: Releasing 1.8.1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
So it’s a pretty normal and natural thing that, when a release is called for, people put up their hands and say “hold off for just a bit, I’ve got one more thing I want to add!”
If projects did hold off then nothing would ever get released because there’s always some good reason to put a hold on things.
Users expect a release from us every 6 weeks because that’s the minor release cadence we’ve committed to. 1.8.1 is already 3 weeks late according to our minor release cadence. I propose we stick with the schedule below and anything not in by Monday EOD can simply wait until the next release. It’s only 6 weeks away.
To prevent this from happening next time, I’ve been a little more specific on the Roadmap [1] based on our cadence. If people have more foreknowledge of when a release is going to happen, they can get that thing they want in there prior to the code freeze.
I’m hoping this isn’t too much to ask for and we can just ship some code.
Thanks,
Everett
On Oct 2, 2014, at 11:12 AM, Everett Toews <ev...@rackspace.com> wrote:
> Let's schedule the release of 1.8.1.
>
> All code into 1.8.x by Monday, Oct. 6 EOD
> Begin release on Tuesday, Oct. 7
>
> Can someone volunteer to do the actual release steps?
>
> I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
>
> Thanks,
> Everett
>
Re: Releasing 1.8.1
Posted by Ignasi Barrera <na...@apache.org>.
I really want to have the CloudSigma v2 api in for 1.8.1 [1]. Its version 1
has been retired (and removed from jclouds), so we should ideally provide
support for v2 despite being in labs.
I volunteer to fix the remaining bits in the PR (I've helped in its
development) before Monday and to cut the release.
If no one says the opposite I'll take this one :)
I.
[1] https://github.com/jclouds/jclouds-labs/pull/70
El 02/10/2014 18:12, "Everett Toews" <ev...@rackspace.com> escribió:
> Let's schedule the release of 1.8.1.
>
> All code into 1.8.x by Monday, Oct. 6 EOD
> Begin release on Tuesday, Oct. 7
>
> Can someone volunteer to do the actual release steps?
>
> I'll be catching up with work stuff all next week after being on the road
> for a few weeks but I can do it if necessary.
>
> Thanks,
> Everett
>
>
Re: Releasing 1.8.1
Posted by Andrew Gaul <ga...@apache.org>.
I do not think we should perform clean-up tasks in minor releases,
especially breaking ones, even in labs. Of course on master this is a
desired and valuable change which recognizes the GCE as a high-quality
and blessed provider. I also do not think we should delay releases for
anything other than regressions -- we will have another minor release
soon enough.
On Fri, Oct 03, 2014 at 09:36:54AM -0600, Chris Custine wrote:
> I suppose this is a good opportunity to discuss gce and oauth (https://issues.apache.org/jira/browse/JCLOUDS-172).
>
> There was some debate over whether we should graduate labs projects in a patch release such as 1.8.1 (comments on JCLOUDS-172), but it seems like most everyone is ok with it and I want to make sure that this topic gets resolved.
>
> On the other hand, there have been some issues with GCE API in the last few weeks which have cast some doubt on graduating from labs right now. I think they are rather minor issues, but the versioned GCE API changing from the docs and previous return data makes this worthy of a discussion.
>
> For my 2 cents, I would say that fixing these issues, merging some stale PRs, and releasing this in jclouds 1.8.1 on Monday is pushing my sensibility. If we were to hold off on the release another week or so, my comfort level would be much better. I’m not arguing to push back the release at all, just putting out the options.
>
> Thoughts?
>
> Thanks,
> Chris
> --
> Chris Custine
>
>
> On October 2, 2014 at 10:12:29 AM, Everett Toews (everett.toews@rackspace.com) wrote:
>
> Let's schedule the release of 1.8.1.
>
> All code into 1.8.x by Monday, Oct. 6 EOD
> Begin release on Tuesday, Oct. 7
>
> Can someone volunteer to do the actual release steps?
>
> I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
>
> Thanks,
> Everett
>
--
Andrew Gaul
http://gaul.org/
Re: Releasing 1.8.1
Posted by Adrian Cole <ad...@gmail.com>.
Makes sense. We should see if those failures are still current and
kill them if so. I "watched" the issue. Thanks for the link!
On Fri, Oct 3, 2014 at 11:25 AM, Andrew Gaul <ga...@apache.org> wrote:
> Regarding openstack-swift in labs, it has many integration test failures
> and we should not promote it from labs until we fix them:
>
> https://issues.apache.org/jira/browse/JCLOUDS-641
>
> For comparison, all other blobstore providers run integration tests
> cleanly although flaky in some instances.
>
> On Fri, Oct 03, 2014 at 09:52:28AM -0700, Adrian Cole wrote:
>> I would suggest that since we are adding providers it makes more sense to
>> cut 1.9.x off the 1.8.x branch and release 1.9.0.
>>
>> Also, is there anything holding back openstack-swift in labs? It would be
>> fantastic to allow users to get off the legacy swift codebase onto
>> something not labs.
>>
>> -A
>> On Oct 3, 2014 8:37 AM, "Chris Custine" <ch...@gmail.com> wrote:
>>
>> > I suppose this is a good opportunity to discuss gce and oauth (
>> > https://issues.apache.org/jira/browse/JCLOUDS-172).
>> >
>> > There was some debate over whether we should graduate labs projects in a
>> > patch release such as 1.8.1 (comments on JCLOUDS-172), but it seems like
>> > most everyone is ok with it and I want to make sure that this topic gets
>> > resolved.
>> >
>> > On the other hand, there have been some issues with GCE API in the last
>> > few weeks which have cast some doubt on graduating from labs right now. I
>> > think they are rather minor issues, but the versioned GCE API changing from
>> > the docs and previous return data makes this worthy of a discussion.
>> >
>> > For my 2 cents, I would say that fixing these issues, merging some stale
>> > PRs, and releasing this in jclouds 1.8.1 on Monday is pushing my
>> > sensibility. If we were to hold off on the release another week or so, my
>> > comfort level would be much better. I’m not arguing to push back the
>> > release at all, just putting out the options.
>> >
>> > Thoughts?
>> >
>> > Thanks,
>> > Chris
>> > --
>> > Chris Custine
>> >
>> >
>> > On October 2, 2014 at 10:12:29 AM, Everett Toews (
>> > everett.toews@rackspace.com) wrote:
>> >
>> > Let's schedule the release of 1.8.1.
>> >
>> > All code into 1.8.x by Monday, Oct. 6 EOD
>> > Begin release on Tuesday, Oct. 7
>> >
>> > Can someone volunteer to do the actual release steps?
>> >
>> > I'll be catching up with work stuff all next week after being on the road
>> > for a few weeks but I can do it if necessary.
>> >
>> > Thanks,
>> > Everett
>> >
>> >
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Releasing 1.8.1
Posted by Andrew Gaul <ga...@apache.org>.
Regarding openstack-swift in labs, it has many integration test failures
and we should not promote it from labs until we fix them:
https://issues.apache.org/jira/browse/JCLOUDS-641
For comparison, all other blobstore providers run integration tests
cleanly although flaky in some instances.
On Fri, Oct 03, 2014 at 09:52:28AM -0700, Adrian Cole wrote:
> I would suggest that since we are adding providers it makes more sense to
> cut 1.9.x off the 1.8.x branch and release 1.9.0.
>
> Also, is there anything holding back openstack-swift in labs? It would be
> fantastic to allow users to get off the legacy swift codebase onto
> something not labs.
>
> -A
> On Oct 3, 2014 8:37 AM, "Chris Custine" <ch...@gmail.com> wrote:
>
> > I suppose this is a good opportunity to discuss gce and oauth (
> > https://issues.apache.org/jira/browse/JCLOUDS-172).
> >
> > There was some debate over whether we should graduate labs projects in a
> > patch release such as 1.8.1 (comments on JCLOUDS-172), but it seems like
> > most everyone is ok with it and I want to make sure that this topic gets
> > resolved.
> >
> > On the other hand, there have been some issues with GCE API in the last
> > few weeks which have cast some doubt on graduating from labs right now. I
> > think they are rather minor issues, but the versioned GCE API changing from
> > the docs and previous return data makes this worthy of a discussion.
> >
> > For my 2 cents, I would say that fixing these issues, merging some stale
> > PRs, and releasing this in jclouds 1.8.1 on Monday is pushing my
> > sensibility. If we were to hold off on the release another week or so, my
> > comfort level would be much better. I’m not arguing to push back the
> > release at all, just putting out the options.
> >
> > Thoughts?
> >
> > Thanks,
> > Chris
> > --
> > Chris Custine
> >
> >
> > On October 2, 2014 at 10:12:29 AM, Everett Toews (
> > everett.toews@rackspace.com) wrote:
> >
> > Let's schedule the release of 1.8.1.
> >
> > All code into 1.8.x by Monday, Oct. 6 EOD
> > Begin release on Tuesday, Oct. 7
> >
> > Can someone volunteer to do the actual release steps?
> >
> > I'll be catching up with work stuff all next week after being on the road
> > for a few weeks but I can do it if necessary.
> >
> > Thanks,
> > Everett
> >
> >
--
Andrew Gaul
http://gaul.org/
Re: Releasing 1.8.1
Posted by Adrian Cole <ad...@gmail.com>.
I would suggest that since we are adding providers it makes more sense to
cut 1.9.x off the 1.8.x branch and release 1.9.0.
Also, is there anything holding back openstack-swift in labs? It would be
fantastic to allow users to get off the legacy swift codebase onto
something not labs.
-A
On Oct 3, 2014 8:37 AM, "Chris Custine" <ch...@gmail.com> wrote:
> I suppose this is a good opportunity to discuss gce and oauth (
> https://issues.apache.org/jira/browse/JCLOUDS-172).
>
> There was some debate over whether we should graduate labs projects in a
> patch release such as 1.8.1 (comments on JCLOUDS-172), but it seems like
> most everyone is ok with it and I want to make sure that this topic gets
> resolved.
>
> On the other hand, there have been some issues with GCE API in the last
> few weeks which have cast some doubt on graduating from labs right now. I
> think they are rather minor issues, but the versioned GCE API changing from
> the docs and previous return data makes this worthy of a discussion.
>
> For my 2 cents, I would say that fixing these issues, merging some stale
> PRs, and releasing this in jclouds 1.8.1 on Monday is pushing my
> sensibility. If we were to hold off on the release another week or so, my
> comfort level would be much better. I’m not arguing to push back the
> release at all, just putting out the options.
>
> Thoughts?
>
> Thanks,
> Chris
> --
> Chris Custine
>
>
> On October 2, 2014 at 10:12:29 AM, Everett Toews (
> everett.toews@rackspace.com) wrote:
>
> Let's schedule the release of 1.8.1.
>
> All code into 1.8.x by Monday, Oct. 6 EOD
> Begin release on Tuesday, Oct. 7
>
> Can someone volunteer to do the actual release steps?
>
> I'll be catching up with work stuff all next week after being on the road
> for a few weeks but I can do it if necessary.
>
> Thanks,
> Everett
>
>
Re: Releasing 1.8.1
Posted by Chris Custine <ch...@gmail.com>.
I suppose this is a good opportunity to discuss gce and oauth (https://issues.apache.org/jira/browse/JCLOUDS-172).
There was some debate over whether we should graduate labs projects in a patch release such as 1.8.1 (comments on JCLOUDS-172), but it seems like most everyone is ok with it and I want to make sure that this topic gets resolved.
On the other hand, there have been some issues with GCE API in the last few weeks which have cast some doubt on graduating from labs right now. I think they are rather minor issues, but the versioned GCE API changing from the docs and previous return data makes this worthy of a discussion.
For my 2 cents, I would say that fixing these issues, merging some stale PRs, and releasing this in jclouds 1.8.1 on Monday is pushing my sensibility. If we were to hold off on the release another week or so, my comfort level would be much better. I’m not arguing to push back the release at all, just putting out the options.
Thoughts?
Thanks,
Chris
--
Chris Custine
On October 2, 2014 at 10:12:29 AM, Everett Toews (everett.toews@rackspace.com) wrote:
Let's schedule the release of 1.8.1.
All code into 1.8.x by Monday, Oct. 6 EOD
Begin release on Tuesday, Oct. 7
Can someone volunteer to do the actual release steps?
I'll be catching up with work stuff all next week after being on the road for a few weeks but I can do it if necessary.
Thanks,
Everett
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
Also, I guess we should pick one of the candidate fixes for the LGPL
issue with JNA before releasing:
* https://github.com/jclouds/jclouds/pull/533 (preferred, but not sure
if Karaf will work properly with agentproxies then)
* https://github.com/jclouds/jclouds/pull/525
ap
RE: Releasing 1.8.1
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
Let's add it to the wiki, so the documentation is tracked, and can be used as a starting point for adding more.
________________________________________
From: Everett Toews [everett.toews@RACKSPACE.COM]
Sent: Friday, December 05, 2014 4:06 PM
To: dev@jclouds.apache.org
Subject: Re: Releasing 1.8.1
On Dec 2, 2014, at 11:42 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Would you be interested in updating or completely replacing the current Releasing jclouds [1] with your reference [2]?
>
> If you think it makes sense to have a document that's phrased more in terms of a "this is what I did" vs. "this is what you need to do", then sure!
I think "this is what ap did" would be a significant improvement over what’s there right now. ;)
Everett
Re: Releasing 1.8.1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Dec 2, 2014, at 11:42 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Would you be interested in updating or completely replacing the current Releasing jclouds [1] with your reference [2]?
>
> If you think it makes sense to have a document that's phrased more in terms of a "this is what I did" vs. "this is what you need to do", then sure!
I think "this is what ap did" would be a significant improvement over what’s there right now. ;)
Everett
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Would you be interested in updating or completely replacing the
> current Releasing jclouds [1] with your reference [2]?
If you think it makes sense to have a document that's phrased more in
terms of a "this is what I did" vs. "this is what you need to do",
then sure! Hopefully we'll also finally be able to get rid of some of
the self-deps that currently add unnecessary steps to this process.
Regards
ap
Re: Releasing 1.8.1
Posted by Everett Toews <ev...@RACKSPACE.COM>.
Hey Andrew,
Would you be interested in updating or completely replacing the current Releasing jclouds [1] with your reference [2]?
Everett
[1] https://cwiki.apache.org/confluence/display/JCLOUDS/Releasing+jclouds
[2] https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit?usp=drive_web
On Oct 3, 2014, at 1:30 AM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Can someone volunteer to do the actual release steps?
>
> 1.8.0 release steps, for reference [1]. See also the recurring discussion about automating (more of) the release process [2].
>
> If we could get some of the improvement items done *before* 1.8.1, it should hopefully reduce the effort required for the release quite a bit.
>
> ap
>
> [1] https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit?usp=drive_web
> [2] http://markmail.org/message/m7znb54ns5vnhvdd
Re: Releasing 1.8.1
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Can someone volunteer to do the actual release steps?
1.8.0 release steps, for reference [1]. See also the recurring
discussion about automating (more of) the release process [2].
If we could get some of the improvement items done *before* 1.8.1, it
should hopefully reduce the effort required for the release quite a bit.
ap
[1]
https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit?usp=drive_web
[2] http://markmail.org/message/m7znb54ns5vnhvdd