You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@redhat.com> on 2011/03/17 22:56:30 UTC
0.10 release update - RC1 and status
Hi, everyone. Using revision 1082154 from Wednesday, I have generated
our RC1 release artifacts:
http://people.apache.org/~nsantos/qpid-0.10-rc1/
As Gordon suggested we do, with this release I've removed the orphaned
dotnet and ruby tarballs from the artifacts. I've also verified that
the versions in the qmf and tools modules have been updated to 0.10.
The corresponding release script changes are here:
https://issues.apache.org/jira/browse/QPID-3151
Test results. I'm keen to get feedback about the quality of our
newest release. Gordon indicated at least some test failures, and in
my own testing the default java test profile is failing in acl tests.
I haven't yet been able to determine if that's something in my
environment.
In any case, I know that various contributors have CI setups, and I
invite you to give a brief report on what you're seeing on the 0.10
branch. Indeed, I still need to gather the test results I have and
report them here.
Bugs. There are 14 bugs in the 0.10 bug list:
http://bit.ly/gXkak9
Seven of them are unassigned. If you are either a component owner or
the bug's reporter, please see what you can do to assign those bugs
and also reevaluate the fix version. I've added a new link to the
release page[1] for unassigned bugs.
In my analysis, none of the bugs listed there are regressions, so they
would not block the upcoming release. If you have a different reading
of the facts, I'm eager to hear it.
On the other hand, the test failures that Gordon found are release
blockers. So from "go" we can say that this first release candidate
is not ready for release.
Finally, I've added a section to the release page for ad-hoc "changes
requiring user attention". This is a place where anyone can freely
add to the notes I will use (in addition to jiras) to compile the
release notes. It's a great place to describe API, configuration, or
behavior changes that deserve mention.
Thanks,
Justin
---
[1] http://cwiki.apache.org/confluence/display/qpid/0.10+release
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Continuous Integration Status
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Mar 22, 2011 at 5:53 PM, Andrew Kennedy <
andrewinternational@gmail.com> wrote:
>
> On 22 Mar 2011, at 21:42, Rajith Attapattu wrote:
>
>> * Second, where should the build status emails be sent? The current setup
>>> will check subversion every 1 minutes, which has the potential to generate a
>>> lot of traffic. I think creating a new mailing list specifically for build
>>> output would be most helpful, and I suggest 'build@qpid.apache.org' for
>>> this. There is also support for mailing the committer that checked in a
>>> change that breaks the build, if people think that would be useful?
>>>
>>
>> I am a little worried about running some of the builds for every checkin.
>> That has the potential to send a lot of traffic.
>>
>
> To clarify, Hudson is checking every 15 minutes if there have been any new
> check-ins, and then running a build. the maximum build rate is therefore
> this frequency. This is configurable using crontab syntax, and could be
> changed to hourly or half-hourly perhaps. Currently I set it to:
>
> */15 * * * * *
>
> The default profile itself (including system tests) takes around 15 minutes
> to run.
>
>
Hourly sounds good. But lets continue with the current setup and see how it
goes.
We could always change later if we need to.
>
> How about we run nightly builds (EST) and email the reports to dev list if
>> there is a failure.
>>
>
> I was thinking of both, the nightly being a full system test (all profiles)
> plus python test kit and release build, generating and publishing artefacts.
>
>
> That will ensure any issues get the attention it deserves immediately. I
>> am not so keen about yet another mailing list.
>>
>
>
> Andrew.
> --
> -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
> -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
>
Re: Continuous Integration Status
Posted by Andrew Kennedy <an...@gmail.com>.
On 22 Mar 2011, at 21:42, Rajith Attapattu wrote:
>> * Second, where should the build status emails be sent? The
>> current setup will check subversion every 1 minutes, which has the
>> potential to generate a lot of traffic. I think creating a new
>> mailing list specifically for build output would be most helpful,
>> and I suggest 'build@qpid.apache.org' for this. There is also
>> support for mailing the committer that checked in a change that
>> breaks the build, if people think that would be useful?
>
> I am a little worried about running some of the builds for every
> checkin. That has the potential to send a lot of traffic.
To clarify, Hudson is checking every 15 minutes if there have been
any new check-ins, and then running a build. the maximum build rate
is therefore this frequency. This is configurable using crontab
syntax, and could be changed to hourly or half-hourly perhaps.
Currently I set it to:
*/15 * * * * *
The default profile itself (including system tests) takes around 15
minutes to run.
> How about we run nightly builds (EST) and email the reports to dev
> list if there is a failure.
I was thinking of both, the nightly being a full system test (all
profiles) plus python test kit and release build, generating and
publishing artefacts.
> That will ensure any issues get the attention it deserves
> immediately. I am not so keen about yet another mailing list.
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Continuous Integration Status
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Mar 22, 2011 at 5:06 PM, Andrew Kennedy <
andrewinternational@gmail.com> wrote:
> On 17 Mar 2011, at 21:56, Justin Ross wrote:
>
>> Test results. I'm keen to get feedback about the quality of our
>> newest release. Gordon indicated at least some test failures, and in
>> my own testing the default java test profile is failing in acl tests.
>> I haven't yet been able to determine if that's something in my
>> environment.
>>
>> In any case, I know that various contributors have CI setups, and I
>> invite you to give a brief report on what you're seeing on the 0.10
>> branch. Indeed, I still need to gather the test results I have and
>> report them here.
>>
>
>
> All,
>
> I have now set up a CI build using the existing 0.10 subversion branch (no
> failures!) which may be helpful during the release process. Currently it
> only tests using the default Java profile, though, but I am working on the
> rest, and C++ too. You can view the output here:
>
> https://builds.apache.org/hudson/job/qpid-java-0.10-build/
>
> The full list of (two, currently) jobs is viewable here:
>
> https://builds.apache.org/hudson/view/M-R/view/Qpid/
>
> I've documented the CI configuration and current status in more detail on a
> wiki page, linked to from QPID-3149, so please refer to that if you want to
> find out more about what is being worked on. I'd like to get some feedback
> on this, and also have a couple of particular questions:
>
First of all a big thank you for doing this.
>
> * Firstly, is the list of profiles adequate, bearing in mind that I will
> be setting up the system test jobs to run all available profiles, and I hope
> to get clustered C++ testing working at some point, given a bit of help. Any
> suggestions welcome.
>
> * Second, where should the build status emails be sent? The current setup
> will check subversion every 1 minutes, which has the potential to generate a
> lot of traffic. I think creating a new mailing list specifically for build
> output would be most helpful, and I suggest 'build@qpid.apache.org' for
> this. There is also support for mailing the committer that checked in a
> change that breaks the build, if people think that would be useful?
>
>
I am a little worried about running some of the builds for every checkin.
That has the potential to send a lot of traffic.
How about we run nightly builds (EST) and email the reports to dev list if
there is a failure.
That will ensure any issues get the attention it deserves immediately. I am
not so keen about yet another mailing list.
> Another question occurs to me - the JMX tests all fail on Solaris 10, does
> anyone know why? Send your answers to QPID-3161, please.
>
> Thanks,
> Andrew.
> --
> -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
> -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Continuous Integration Status
Posted by Andrew Kennedy <an...@gmail.com>.
On 17 Mar 2011, at 21:56, Justin Ross wrote:
> Test results. I'm keen to get feedback about the quality of our
> newest release. Gordon indicated at least some test failures, and in
> my own testing the default java test profile is failing in acl tests.
> I haven't yet been able to determine if that's something in my
> environment.
>
> In any case, I know that various contributors have CI setups, and I
> invite you to give a brief report on what you're seeing on the 0.10
> branch. Indeed, I still need to gather the test results I have and
> report them here.
All,
I have now set up a CI build using the existing 0.10 subversion
branch (no failures!) which may be helpful during the release
process. Currently it only tests using the default Java profile,
though, but I am working on the rest, and C++ too. You can view the
output here:
https://builds.apache.org/hudson/job/qpid-java-0.10-build/
The full list of (two, currently) jobs is viewable here:
https://builds.apache.org/hudson/view/M-R/view/Qpid/
I've documented the CI configuration and current status in more
detail on a wiki page, linked to from QPID-3149, so please refer to
that if you want to find out more about what is being worked on. I'd
like to get some feedback on this, and also have a couple of
particular questions:
* Firstly, is the list of profiles adequate, bearing in mind that I
will be setting up the system test jobs to run all available
profiles, and I hope to get clustered C++ testing working at some
point, given a bit of help. Any suggestions welcome.
* Second, where should the build status emails be sent? The current
setup will check subversion every 1 minutes, which has the potential
to generate a lot of traffic. I think creating a new mailing list
specifically for build output would be most helpful, and I suggest
'build@qpid.apache.org' for this. There is also support for mailing
the committer that checked in a change that breaks the build, if
people think that would be useful?
Another question occurs to me - the JMX tests all fail on Solaris 10,
does anyone know why? Send your answers to QPID-3161, please.
Thanks,
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 0.10 release update - RC1 and status
Posted by Alan Conway <ac...@redhat.com>.
On 03/17/2011 05:56 PM, Justin Ross wrote:
> Hi, everyone. Using revision 1082154 from Wednesday, I have generated
> our RC1 release artifacts:
>
> http://people.apache.org/~nsantos/qpid-0.10-rc1/
>
> As Gordon suggested we do, with this release I've removed the orphaned
> dotnet and ruby tarballs from the artifacts. I've also verified that
> the versions in the qmf and tools modules have been updated to 0.10.
>
> The corresponding release script changes are here:
>
> https://issues.apache.org/jira/browse/QPID-3151
>
> Test results. I'm keen to get feedback about the quality of our
> newest release. Gordon indicated at least some test failures, and in
> my own testing the default java test profile is failing in acl tests.
> I haven't yet been able to determine if that's something in my
> environment.
>
> In any case, I know that various contributors have CI setups, and I
> invite you to give a brief report on what you're seeing on the 0.10
> branch. Indeed, I still need to gather the test results I have and
> report them here.
>
> Bugs. There are 14 bugs in the 0.10 bug list:
>
> http://bit.ly/gXkak9
https://issues.apache.org/jira/browse/QPID-3147 is now fixed on trunk.
Permission to merge to 0.10?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 0.10 release update - RC1 and status
Posted by Alan Conway <ac...@redhat.com>.
On 03/17/2011 05:56 PM, Justin Ross wrote:
> Hi, everyone. Using revision 1082154 from Wednesday, I have generated
> our RC1 release artifacts:
>
> http://people.apache.org/~nsantos/qpid-0.10-rc1/
>
> As Gordon suggested we do, with this release I've removed the orphaned
> dotnet and ruby tarballs from the artifacts. I've also verified that
> the versions in the qmf and tools modules have been updated to 0.10.
>
> The corresponding release script changes are here:
>
> https://issues.apache.org/jira/browse/QPID-3151
>
> Test results. I'm keen to get feedback about the quality of our
> newest release. Gordon indicated at least some test failures, and in
> my own testing the default java test profile is failing in acl tests.
> I haven't yet been able to determine if that's something in my
> environment.
>
> In any case, I know that various contributors have CI setups, and I
> invite you to give a brief report on what you're seeing on the 0.10
> branch. Indeed, I still need to gather the test results I have and
> report them here.
>
> Bugs. There are 14 bugs in the 0.10 bug list:
>
> http://bit.ly/gXkak9
>
https://issues.apache.org/jira/browse/QPID-3116 - this is fixed on trunk, it is
a trivial fix. Permission to merge to 0.10?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained components
(was Re: 0.10 release update - RC1 and status)
Posted by Carl Trieloff <cc...@redhat.com>.
On 03/31/2011 01:36 PM, Gordon Sim wrote:
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
+1 for all 3.
They have all been superseded with better versions
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained components
(was Re: 0.10 release update - RC1 and status)
Posted by Alan Conway <ac...@redhat.com>.
On 03/31/2011 01:36 PM, Gordon Sim wrote:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10 release (please
> list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release (please list
> changes it includes to support this vote)
>
+1 for removing all 3
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained components
(was Re: 0.10 release update - RC1 and status)
Posted by Gordon Sim <gs...@redhat.com>.
On 03/31/2011 06:36 PM, Gordon Sim wrote:
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes
> made[1] (this would also have the benefit of identifying possible
> maintainers for those components to whom questions of support could be
> directed). I.e. I think that a vote will be required to keep them in,
> and it would be unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on this
> is important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
I make that 10 +1s for all removals, with no objections... in the
interests of keeping the release moving, I'd like to call this vote
closed and note that we have agreed to remove those artefacts from the
published list.
I will also commit the change to the Downloads page and Chuck was going
to update some developer docs accordingly.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 for all 3.
I am in favour of removing all three components.
As Rob mentioned we could just moved it to some designated location in the
source tree.
Julian Cadet did some work on this along with Aidan Skinner. So I assume
Julian is probably using this client.
Leaving the code intact in some location clearly marked as deprecated allows
any user to continue using it albeit at their own risk.
Regards,
Rajith
On Thu, Mar 31, 2011 at 3:08 PM, Robert Godfrey <ro...@gmail.com>wrote:
> On 31 March 2011 21:06, Robert Godfrey <ro...@gmail.com> wrote:
>
> >
> >
> > On 31 March 2011 19:36, Gordon Sim <gs...@redhat.com> wrote:
> >
> >> On 03/18/2011 03:56 PM, Justin Ross wrote:
> >>
> >>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
> >>>
> >>> I know Gordon said:
> >>>>
> >>>>
> >>>> "Specifically I'd suggest that unless anyone has specific updates to
> the
> >>>> following artefacts - and volunteers to verify the artefact for the
> >>>> release
> >>>> - we remove them from the published list:
> >>>>
> >>>> qpid-dotnet-0-8-0.10-beta.zip
> >>>> qpid-dotnet-0-10-0.10-beta.
> >>>> zip
> >>>> qpid-ruby-0.10-beta.tar.gz
> >>>>
> >>>> This will avoid giving false impressions about ongoing maintenance for
> >>>> these
> >>>> clients"
> >>>>
> >>>> But I think that if we are going to actually do this, we should
> formally
> >>>> vote for it, and move the codebases for these artefacts into an
> "attic"
> >>>> directory or similar.
> >>>>
> >>>> I'm not against removing unloved and unmaintained code... but I do
> >>>> feel that
> >>>> we should vote before adding or removing artefacts to/from the
> release.
> >>>>
> >>>
> >>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
> >>>
> >>
> >> I would find it hard to vote for a new release that contained those
> >> artefacts unless someone could justify it through a list of changes
> made[1]
> >> (this would also have the benefit of identifying possible maintainers
> for
> >> those components to whom questions of support could be directed). I.e. I
> >> think that a vote will be required to keep them in, and it would be
> >> unfortunate to stall the whole release.
> >>
> >> However I do agree that some more explicit 'consensus gathering' on this
> >> is important since my previous mail did not result in any comments or
> >> responses. Therefore...
> >>
> >> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each
> >> of the cases below:
> >>
> >> (a)
> >>
> >>
> >
> >> [X] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> >>
> >> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release
> >> (please list changes it includes to support this vote)
> >>
> >> (b)
> >>
> >> [X] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> >>
> >> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release
> >> (please list changes it includes to support this vote)
> >>
> >> (c)
> >>
> >> [X] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> >>
> >> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> >> (please list changes it includes to support this vote)
> >>
> >>
> >>
> >
> > I'm generally +1 with removing all three. Is there any documentation
> that
> > needs to be altered though?
> >
> >
> Also, I forgot to add, should we not move the code into an "attic" or
> something. If we're not going to support the codebase, lets be very clear
> about it?
>
> -- Rob
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Gordon Sim <gs...@redhat.com>.
On 04/01/2011 03:22 PM, Robert Godfrey wrote:
> but as long as the things are removed from trunk, I'm happy
Likewise!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robert Godfrey <ro...@gmail.com>.
On 1 April 2011 16:11, Gordon Sim <gs...@redhat.com> wrote:
> On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
>
>> By deleting, it becomes more of a pain for people to
>> inspect the old code (which they may actually be using a version of even
>> if
>> we don't support it) or create patches against it etc should they want to
>> without actually reviving the whole lot back to trunk. Things may never be
>> truly deleted from the repo, but 'deleting' them does make it more of a
>> pain
>> to ever do anything with it again.
>>
>
> The code will still be available on release branches. So e.g. in this case
> the 0.8 release branch will have the 'last released' code for those
> components, and should be as easy to read as it would in an attic...
>
>
I guess the argument is that by placing all "dead" code in the attic you
don;t have to remember precisely the version in which it became dead. Like
I said before, I'm pretty relaxed about it (though I have a slight
preference for keeping an attic - I see arguments for the attic such as new
people coming to the code and wondering why we don't have X - we say "we
did, but no-one maintained it, go look in the attic")... but as long as the
things are removed from trunk, I'm happy
-- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Apr 1, 2011 at 3:47 PM, Alan Conway <ac...@redhat.com> wrote:
> On 04/01/2011 02:03 PM, Steve Huston wrote:
>
>> Hi Rob,
>>
>> On 1 April 2011 18:19, Steve Huston<sh...@riverace.com> wrote:
>>>
>>> You have to ask yourself, "How much time and effort am I willing to
>>>> put into a component that's dead?" If it's something significant,
>>>> leave it in an attic-type thing. If not, delete it.
>>>>
>>>>
>>> I'm not sure that's really the question... the idea of an
>>> attic is that it would be frozen. The balance is really
>>> between effort up front to move it there now, vs. potential
>>> effort expended in trying to locate it again if it gets
>>> brought back from the dead / if anyone is interested in looking at it.
>>>
>>> I'm not sure that in either case we are really talking about
>>> a sizeable effort.
>>>
>>
>> Right, probably not sizeable as in days of effort. But you need to think
>> about responses to people who email the list with questions on it. If
>> the pieces are deleted, the answer is "it's gone; if you want to dredge
>> up the past instead of using the updated, supported stuff that works,
>> please justify why someone should spend a few hours getting it back.
>> Better yet, donate a bag of cash to ASF."
>>
>> If it's in the attic (or whatever place it's named) it's going to
>> generate more questions because it's visible. Even if it's just "why is
>> the .NET stuff gone? Are you MS haters?" that will need someone to
>> respond to it. Or to continually explain why it's in the attic.
>>
>>
> Delete it. Nobody's maintaining it and we have better alternatives on the
> project. If someone wants to work on these areas of functionality they
> should be working on the new stuff, keeping the old stuff is just confusing.
> If someone has a historical interest in the old stuff they can grab a 0.8
> tarball, no effort required. If they want to track the history more closely,
> that's what SVN is for. However I don't think we should spend a lot more
> time thinking about how to cater to these hypothetical people of the future.
> One thing that's clear from this thread is that nobody is interested in this
> code now.
>
> Having read all the comments I am also thinking that removing is the best
option.
I actually tried to do this about an year ago and didn't find enough
support.
http://www.mail-archive.com/dev@qpid.apache.org/msg09638.html
My suggestion to remove at the time was promoted by yet another question
from a user about the unmaintained and unsupported 0.10 and 0-8 .NET
clients.
On a different thread I did suggest that Rob's idea of moving to an attic
maybe a good compromise. But that was purely taking into consideration the
work done by Julian and Aidan.
Seems like there has been no activity from either of them for a while now.
So lets remove this code and move on with it.
Rajith
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Alan Conway <ac...@redhat.com>.
On 04/01/2011 02:03 PM, Steve Huston wrote:
> Hi Rob,
>
>> On 1 April 2011 18:19, Steve Huston<sh...@riverace.com> wrote:
>>
>>> You have to ask yourself, "How much time and effort am I willing to
>>> put into a component that's dead?" If it's something significant,
>>> leave it in an attic-type thing. If not, delete it.
>>>
>>
>> I'm not sure that's really the question... the idea of an
>> attic is that it would be frozen. The balance is really
>> between effort up front to move it there now, vs. potential
>> effort expended in trying to locate it again if it gets
>> brought back from the dead / if anyone is interested in looking at it.
>>
>> I'm not sure that in either case we are really talking about
>> a sizeable effort.
>
> Right, probably not sizeable as in days of effort. But you need to think
> about responses to people who email the list with questions on it. If
> the pieces are deleted, the answer is "it's gone; if you want to dredge
> up the past instead of using the updated, supported stuff that works,
> please justify why someone should spend a few hours getting it back.
> Better yet, donate a bag of cash to ASF."
>
> If it's in the attic (or whatever place it's named) it's going to
> generate more questions because it's visible. Even if it's just "why is
> the .NET stuff gone? Are you MS haters?" that will need someone to
> respond to it. Or to continually explain why it's in the attic.
>
Delete it. Nobody's maintaining it and we have better alternatives on the
project. If someone wants to work on these areas of functionality they should be
working on the new stuff, keeping the old stuff is just confusing. If someone
has a historical interest in the old stuff they can grab a 0.8 tarball, no
effort required. If they want to track the history more closely, that's what SVN
is for. However I don't think we should spend a lot more time thinking about how
to cater to these hypothetical people of the future. One thing that's clear from
this thread is that nobody is interested in this code now.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing release artefacts for unmaintained components (was Re: 0.10 release update - RC1 and status))
Posted by Steve Huston <sh...@riverace.com>.
Hi Rob,
> On 1 April 2011 18:19, Steve Huston <sh...@riverace.com> wrote:
>
> > You have to ask yourself, "How much time and effort am I willing to
> > put into a component that's dead?" If it's something significant,
> > leave it in an attic-type thing. If not, delete it.
> >
>
> I'm not sure that's really the question... the idea of an
> attic is that it would be frozen. The balance is really
> between effort up front to move it there now, vs. potential
> effort expended in trying to locate it again if it gets
> brought back from the dead / if anyone is interested in looking at it.
>
> I'm not sure that in either case we are really talking about
> a sizeable effort.
Right, probably not sizeable as in days of effort. But you need to think
about responses to people who email the list with questions on it. If
the pieces are deleted, the answer is "it's gone; if you want to dredge
up the past instead of using the updated, supported stuff that works,
please justify why someone should spend a few hours getting it back.
Better yet, donate a bag of cash to ASF."
If it's in the attic (or whatever place it's named) it's going to
generate more questions because it's visible. Even if it's just "why is
the .NET stuff gone? Are you MS haters?" that will need someone to
respond to it. Or to continually explain why it's in the attic.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robert Godfrey <ro...@gmail.com>.
On 1 April 2011 18:19, Steve Huston <sh...@riverace.com> wrote:
> You have to ask yourself, "How much time and effort am I willing to put
> into a component that's dead?" If it's something significant, leave it
> in an attic-type thing. If not, delete it.
>
I'm not sure that's really the question... the idea of an attic is that it
would be frozen. The balance is really between effort up front to move it
there now, vs. potential effort expended in trying to locate it again if it
gets brought back from the dead / if anyone is interested in looking at it.
I'm not sure that in either case we are really talking about a sizeable
effort.
-- Rob
>
> > -----Original Message-----
> > From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> > Sent: Friday, April 01, 2011 11:38 AM
> > To: dev@qpid.apache.org
> > Subject: Re: "Attic" area in svn; any ideas? (was Re: [VOTE]
> > Stop publishing release artefacts for unmaintained components
> > (was Re: 0.10 release update - RC1 and status))
> >
> >
> > I guess an alternative would be introducing an attic area
> > under branches/tags that you make a copy of the entire trunk
> > in at the point just before removing a particular component,
> > thus giving a single place to point people at if needed and
> > keeping a suitable record of whats removed when. Best of both worlds?
> >
> > On 1 April 2011 15:23, Robbie Gemmell
> > <ro...@gmail.com> wrote:
> >
> > > True enough, if you know its there...it does mean that in future as
> > > things get sent to the attic you would need to know when it
> > happened
> > > in order to find the code again as there would be no single
> > place you
> > > might expect to find such things. Going with /attic achieves the
> > > 'remove it from trunk' goal just as effectively, without
> > making life
> > > difficult for anyone who wants/needs to go looking for such
> > things in
> > > future.
> > >
> > > For what its worth, the above route is also how many sites operate
> > > their sandbox environments etc and so would match up well
> > with things
> > > like that (yet another discussion...)
> > >
> > > Robbie
> > >
> > >
> > > On 1 April 2011 15:11, Gordon Sim <gs...@redhat.com> wrote:
> > >
> > >> On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
> > >>
> > >>> By deleting, it becomes more of a pain for people to
> > inspect the old
> > >>> code (which they may actually be using a version of even if
> > >>> we don't support it) or create patches against it etc
> > should they want to
> > >>> without actually reviving the whole lot back to trunk.
> > Things may never
> > >>> be
> > >>> truly deleted from the repo, but 'deleting' them does
> > make it more of a
> > >>> pain
> > >>> to ever do anything with it again.
> > >>>
> > >>
> > >> The code will still be available on release branches. So
> > e.g. in this case
> > >> the 0.8 release branch will have the 'last released' code for those
> > >> components, and should be as easy to read as it would in
> > an attic...
> > >>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> Apache Qpid - AMQP Messaging Implementation
> > >> Project: http://qpid.apache.org
> > >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > >>
> > >>
> > >
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing release artefacts for unmaintained components (was Re: 0.10 release update - RC1 and status))
Posted by Steve Huston <sh...@riverace.com>.
You have to ask yourself, "How much time and effort am I willing to put
into a component that's dead?" If it's something significant, leave it
in an attic-type thing. If not, delete it.
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: Friday, April 01, 2011 11:38 AM
> To: dev@qpid.apache.org
> Subject: Re: "Attic" area in svn; any ideas? (was Re: [VOTE]
> Stop publishing release artefacts for unmaintained components
> (was Re: 0.10 release update - RC1 and status))
>
>
> I guess an alternative would be introducing an attic area
> under branches/tags that you make a copy of the entire trunk
> in at the point just before removing a particular component,
> thus giving a single place to point people at if needed and
> keeping a suitable record of whats removed when. Best of both worlds?
>
> On 1 April 2011 15:23, Robbie Gemmell
> <ro...@gmail.com> wrote:
>
> > True enough, if you know its there...it does mean that in future as
> > things get sent to the attic you would need to know when it
> happened
> > in order to find the code again as there would be no single
> place you
> > might expect to find such things. Going with /attic achieves the
> > 'remove it from trunk' goal just as effectively, without
> making life
> > difficult for anyone who wants/needs to go looking for such
> things in
> > future.
> >
> > For what its worth, the above route is also how many sites operate
> > their sandbox environments etc and so would match up well
> with things
> > like that (yet another discussion...)
> >
> > Robbie
> >
> >
> > On 1 April 2011 15:11, Gordon Sim <gs...@redhat.com> wrote:
> >
> >> On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
> >>
> >>> By deleting, it becomes more of a pain for people to
> inspect the old
> >>> code (which they may actually be using a version of even if
> >>> we don't support it) or create patches against it etc
> should they want to
> >>> without actually reviving the whole lot back to trunk.
> Things may never
> >>> be
> >>> truly deleted from the repo, but 'deleting' them does
> make it more of a
> >>> pain
> >>> to ever do anything with it again.
> >>>
> >>
> >> The code will still be available on release branches. So
> e.g. in this case
> >> the 0.8 release branch will have the 'last released' code for those
> >> components, and should be as easy to read as it would in
> an attic...
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project: http://qpid.apache.org
> >> Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >>
> >>
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robbie Gemmell <ro...@gmail.com>.
I guess an alternative would be introducing an attic area under
branches/tags that you make a copy of the entire trunk in at the point just
before removing a particular component, thus giving a single place to point
people at if needed and keeping a suitable record of whats removed when.
Best of both worlds?
On 1 April 2011 15:23, Robbie Gemmell <ro...@gmail.com> wrote:
> True enough, if you know its there...it does mean that in future as things
> get sent to the attic you would need to know when it happened in order to
> find the code again as there would be no single place you might expect to
> find such things. Going with /attic achieves the 'remove it from trunk' goal
> just as effectively, without making life difficult for anyone who
> wants/needs to go looking for such things in future.
>
> For what its worth, the above route is also how many sites operate their
> sandbox environments etc and so would match up well with things like that
> (yet another discussion...)
>
> Robbie
>
>
> On 1 April 2011 15:11, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
>>
>>> By deleting, it becomes more of a pain for people to
>>> inspect the old code (which they may actually be using a version of even
>>> if
>>> we don't support it) or create patches against it etc should they want to
>>> without actually reviving the whole lot back to trunk. Things may never
>>> be
>>> truly deleted from the repo, but 'deleting' them does make it more of a
>>> pain
>>> to ever do anything with it again.
>>>
>>
>> The code will still be available on release branches. So e.g. in this case
>> the 0.8 release branch will have the 'last released' code for those
>> components, and should be as easy to read as it would in an attic...
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robbie Gemmell <ro...@gmail.com>.
True enough, if you know its there...it does mean that in future as things
get sent to the attic you would need to know when it happened in order to
find the code again as there would be no single place you might expect to
find such things. Going with /attic achieves the 'remove it from trunk' goal
just as effectively, without making life difficult for anyone who
wants/needs to go looking for such things in future.
For what its worth, the above route is also how many sites operate their
sandbox environments etc and so would match up well with things like that
(yet another discussion...)
Robbie
On 1 April 2011 15:11, Gordon Sim <gs...@redhat.com> wrote:
> On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
>
>> By deleting, it becomes more of a pain for people to
>> inspect the old code (which they may actually be using a version of even
>> if
>> we don't support it) or create patches against it etc should they want to
>> without actually reviving the whole lot back to trunk. Things may never be
>> truly deleted from the repo, but 'deleting' them does make it more of a
>> pain
>> to ever do anything with it again.
>>
>
> The code will still be available on release branches. So e.g. in this case
> the 0.8 release branch will have the 'last released' code for those
> components, and should be as easy to read as it would in an attic...
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Gordon Sim <gs...@redhat.com>.
On 04/01/2011 03:10 PM, Robbie Gemmell wrote:
> By deleting, it becomes more of a pain for people to
> inspect the old code (which they may actually be using a version of even if
> we don't support it) or create patches against it etc should they want to
> without actually reviving the whole lot back to trunk. Things may never be
> truly deleted from the repo, but 'deleting' them does make it more of a pain
> to ever do anything with it again.
The code will still be available on release branches. So e.g. in this
case the 0.8 release branch will have the 'last released' code for those
components, and should be as easy to read as it would in an attic...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robbie Gemmell <ro...@gmail.com>.
/attic outside of trunk gets my vote
The whole point is to remove items from the normal checkout, but I'm happy
to leave them in a place where people could still see and get them easily
enough if they wanted. By deleting, it becomes more of a pain for people to
inspect the old code (which they may actually be using a version of even if
we don't support it) or create patches against it etc should they want to
without actually reviving the whole lot back to trunk. Things may never be
truly deleted from the repo, but 'deleting' them does make it more of a pain
to ever do anything with it again.
Robbie
On 1 April 2011 14:02, Robert Godfrey <ro...@gmail.com> wrote:
> On 1 April 2011 10:30, Gordon Sim <gs...@redhat.com> wrote:
>
> > On 03/31/2011 08:08 PM, Robert Godfrey wrote:
> >
> >> Also, I forgot to add, should we not move the code into an "attic" or
> >> something. If we're not going to support the codebase, lets be very
> clear
> >> about it?
> >>
> >
> > Yes, we should also modify the svn directory structure in some way to
> make
> > it obvious that the code for those components is no longer being actively
> > maintained.
> >
> > However for 0-10 my most immediate concern is simply not publishing
> > obviously stale artefacts as I believe that gives a very misleading
> picture
> > to users. I'd like to go ahead with the vote for that aspect and then
> have a
> > separate debate resulting in some proposals for an attic area or
> > alternatives.
> >
> > Anyone with thoughts or preferences on the ideal changes to svn
> structure,
> > please respond.
> >
>
>
> So my suggestion would probably be to have attic as a sibling to the
> current
> trunk
>
> i.e. as
>
> http://svn.apache.org/repos/asf/qpid/attic
>
> to move the current trunk versions of the retired modules there, along with
> a README explaining what the attic is
>
> -- Rob
>
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
RE: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing release artefacts for unmaintained components (was Re: 0.10 release update - RC1 and status))
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
> Sent: Friday, April 01, 2011 10:38 AM
>
> On 04/01/2011 10:27 AM, Andrew Stitcher wrote:
> >> > +1, just delete them.
> > Considering what everyone else has said, I'd vote to just
> delete them.
>
> +1
+1, especially since the components under immediate consideration have
already been replaced with better alternatives.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Carl Trieloff <cc...@redhat.com>.
On 04/01/2011 10:27 AM, Andrew Stitcher wrote:
>> > +1, just delete them.
> Considering what everyone else has said, I'd vote to just delete them.
+1
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop
publishing release artefacts for unmaintained components (was Re: 0.10
release update - RC1 and status))
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2011-04-01 at 10:03 -0400, Alan Conway wrote:
> ...
> >> There was some discussion previously about having an attic where things are
> >> "frozen" unless anyone wants to bring them in again. I'm fairly relaxed
> >> about not having an attic and just deleting... but I don;t really see the
> >> point of moving them somewhere else in trunk and then deleting.
> >
> > Yes, my preference would just be to delete them.
> >
>
> +1, just delete them.
Considering what everyone else has said, I'd vote to just delete them.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Alan Conway <ac...@redhat.com>.
On 04/01/2011 09:53 AM, Gordon Sim wrote:
> On 04/01/2011 02:53 PM, Robert Godfrey wrote:
>> On 1 April 2011 15:44, Andrew Stitcher<as...@redhat.com> wrote:
>>
>>> On Fri, 2011-04-01 at 15:02 +0200, Robert Godfrey wrote:
>>>
>>>> So my suggestion would probably be to have attic as a sibling to the
>>> current
>>>> trunk
>>>>
>>>> i.e. as
>>>>
>>>> http://svn.apache.org/repos/asf/qpid/attic
>>>>
>>>> to move the current trunk versions of the retired modules there, along
>>> with
>>>> a README explaining what the attic is
>>>>
>>>> -- Rob
>>>
>>> This could quickly devolve into a "bikeshed" discussion so I'll get some
>>> thoughts in early before it does!
>>>
>>> * If we are going to move these subdirectories out of the main source
>>> controlled area we might as well just delete them, as for most people
>>> that is what it'll look like and the whole point of source control is
>>> that nothing is really lost and you can "go back in time" and recover
>>> the artefacts anyway.
>>>
>>> * Putting them outside the main trunk/branch/tag makes the code
>>> invisible to the git mirror which an increasing number of us use.
>>> Incidentally this wouldn't be an objection to creating self contained
>>> new projects there as we'd get infrastructure to mirror those
>>> separately.
>>>
>>> * So I suggest just adding a sibling directory at the very top level of
>>> trunk etc called obsolete and keep things in this for 1 release and
>>> delete it.
>>>
>>> -- So we'd end up with
>>> .../asf/qpid/trunk/qpid&
>>> .../asf/qpid/trunk/obsolete
>>>
>>>
>> I think rather than doing that I would just remove the directories
>> immediately. There seems little point on leaving them under trunk if they
>> are orphans and no-one is going to care for them... And the historic
>> releases which include them are still available through svn's history (in
>> particular under the tagged directories representing releases).
>>
>> There was some discussion previously about having an attic where things are
>> "frozen" unless anyone wants to bring them in again. I'm fairly relaxed
>> about not having an attic and just deleting... but I don;t really see the
>> point of moving them somewhere else in trunk and then deleting.
>
> Yes, my preference would just be to delete them.
>
+1, just delete them.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update
- RC1 and status))
Posted by Gordon Sim <gs...@redhat.com>.
On 04/01/2011 02:53 PM, Robert Godfrey wrote:
> On 1 April 2011 15:44, Andrew Stitcher<as...@redhat.com> wrote:
>
>> On Fri, 2011-04-01 at 15:02 +0200, Robert Godfrey wrote:
>>
>>> So my suggestion would probably be to have attic as a sibling to the
>> current
>>> trunk
>>>
>>> i.e. as
>>>
>>> http://svn.apache.org/repos/asf/qpid/attic
>>>
>>> to move the current trunk versions of the retired modules there, along
>> with
>>> a README explaining what the attic is
>>>
>>> -- Rob
>>
>> This could quickly devolve into a "bikeshed" discussion so I'll get some
>> thoughts in early before it does!
>>
>> * If we are going to move these subdirectories out of the main source
>> controlled area we might as well just delete them, as for most people
>> that is what it'll look like and the whole point of source control is
>> that nothing is really lost and you can "go back in time" and recover
>> the artefacts anyway.
>>
>> * Putting them outside the main trunk/branch/tag makes the code
>> invisible to the git mirror which an increasing number of us use.
>> Incidentally this wouldn't be an objection to creating self contained
>> new projects there as we'd get infrastructure to mirror those
>> separately.
>>
>> * So I suggest just adding a sibling directory at the very top level of
>> trunk etc called obsolete and keep things in this for 1 release and
>> delete it.
>>
>> -- So we'd end up with
>> .../asf/qpid/trunk/qpid&
>> .../asf/qpid/trunk/obsolete
>>
>>
> I think rather than doing that I would just remove the directories
> immediately. There seems little point on leaving them under trunk if they
> are orphans and no-one is going to care for them... And the historic
> releases which include them are still available through svn's history (in
> particular under the tagged directories representing releases).
>
> There was some discussion previously about having an attic where things are
> "frozen" unless anyone wants to bring them in again. I'm fairly relaxed
> about not having an attic and just deleting... but I don;t really see the
> point of moving them somewhere else in trunk and then deleting.
Yes, my preference would just be to delete them.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robert Godfrey <ro...@gmail.com>.
On 1 April 2011 15:44, Andrew Stitcher <as...@redhat.com> wrote:
> On Fri, 2011-04-01 at 15:02 +0200, Robert Godfrey wrote:
>
> > So my suggestion would probably be to have attic as a sibling to the
> current
> > trunk
> >
> > i.e. as
> >
> > http://svn.apache.org/repos/asf/qpid/attic
> >
> > to move the current trunk versions of the retired modules there, along
> with
> > a README explaining what the attic is
> >
> > -- Rob
>
> This could quickly devolve into a "bikeshed" discussion so I'll get some
> thoughts in early before it does!
>
> * If we are going to move these subdirectories out of the main source
> controlled area we might as well just delete them, as for most people
> that is what it'll look like and the whole point of source control is
> that nothing is really lost and you can "go back in time" and recover
> the artefacts anyway.
>
> * Putting them outside the main trunk/branch/tag makes the code
> invisible to the git mirror which an increasing number of us use.
> Incidentally this wouldn't be an objection to creating self contained
> new projects there as we'd get infrastructure to mirror those
> separately.
>
> * So I suggest just adding a sibling directory at the very top level of
> trunk etc called obsolete and keep things in this for 1 release and
> delete it.
>
> -- So we'd end up with
> .../asf/qpid/trunk/qpid &
> .../asf/qpid/trunk/obsolete
>
>
I think rather than doing that I would just remove the directories
immediately. There seems little point on leaving them under trunk if they
are orphans and no-one is going to care for them... And the historic
releases which include them are still available through svn's history (in
particular under the tagged directories representing releases).
There was some discussion previously about having an attic where things are
"frozen" unless anyone wants to bring them in again. I'm fairly relaxed
about not having an attic and just deleting... but I don;t really see the
point of moving them somewhere else in trunk and then deleting.
-- Rob
>
> Andrew
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop
publishing release artefacts for unmaintained components (was Re: 0.10
release update - RC1 and status))
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2011-04-01 at 09:44 -0400, Andrew Stitcher wrote:
> * So I suggest just adding a sibling directory at the very top level of
> trunk etc called obsolete and keep things in this for 1 release and
> delete it.
>
Making my own bikeshed: I wasn't clear enough in this last paragraph, I
meant to say keep obsoleted items in this area for 1 release then delete
_them_ (these items have been obsolete in truth somewhat longer than 1
release already).
The logic being that if someone does come forward to maintain an item
it's easier to recover the code (somewhat) if it's still in the tree,
but if there's no interest after another release cycle then deleting
unused code promotes tidiness, and it can still be recovered from the
SCM.
> -- So we'd end up with
> .../asf/qpid/trunk/qpid &
> .../asf/qpid/trunk/obsolete
>
>
> Andrew
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop
publishing release artefacts for unmaintained components (was Re: 0.10
release update - RC1 and status))
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2011-04-01 at 15:02 +0200, Robert Godfrey wrote:
> So my suggestion would probably be to have attic as a sibling to the current
> trunk
>
> i.e. as
>
> http://svn.apache.org/repos/asf/qpid/attic
>
> to move the current trunk versions of the retired modules there, along with
> a README explaining what the attic is
>
> -- Rob
This could quickly devolve into a "bikeshed" discussion so I'll get some
thoughts in early before it does!
* If we are going to move these subdirectories out of the main source
controlled area we might as well just delete them, as for most people
that is what it'll look like and the whole point of source control is
that nothing is really lost and you can "go back in time" and recover
the artefacts anyway.
* Putting them outside the main trunk/branch/tag makes the code
invisible to the git mirror which an increasing number of us use.
Incidentally this wouldn't be an objection to creating self contained
new projects there as we'd get infrastructure to mirror those
separately.
* So I suggest just adding a sibling directory at the very top level of
trunk etc called obsolete and keep things in this for 1 release and
delete it.
-- So we'd end up with
.../asf/qpid/trunk/qpid &
.../asf/qpid/trunk/obsolete
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: "Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing
release artefacts for unmaintained components (was Re: 0.10 release update -
RC1 and status))
Posted by Robert Godfrey <ro...@gmail.com>.
On 1 April 2011 10:30, Gordon Sim <gs...@redhat.com> wrote:
> On 03/31/2011 08:08 PM, Robert Godfrey wrote:
>
>> Also, I forgot to add, should we not move the code into an "attic" or
>> something. If we're not going to support the codebase, lets be very clear
>> about it?
>>
>
> Yes, we should also modify the svn directory structure in some way to make
> it obvious that the code for those components is no longer being actively
> maintained.
>
> However for 0-10 my most immediate concern is simply not publishing
> obviously stale artefacts as I believe that gives a very misleading picture
> to users. I'd like to go ahead with the vote for that aspect and then have a
> separate debate resulting in some proposals for an attic area or
> alternatives.
>
> Anyone with thoughts or preferences on the ideal changes to svn structure,
> please respond.
>
So my suggestion would probably be to have attic as a sibling to the current
trunk
i.e. as
http://svn.apache.org/repos/asf/qpid/attic
to move the current trunk versions of the retired modules there, along with
a README explaining what the attic is
-- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
"Attic" area in svn; any ideas? (was Re: [VOTE] Stop publishing release
artefacts for unmaintained components (was Re: 0.10 release update - RC1
and status))
Posted by Gordon Sim <gs...@redhat.com>.
On 03/31/2011 08:08 PM, Robert Godfrey wrote:
> Also, I forgot to add, should we not move the code into an "attic" or
> something. If we're not going to support the codebase, lets be very clear
> about it?
Yes, we should also modify the svn directory structure in some way to
make it obvious that the code for those components is no longer being
actively maintained.
However for 0-10 my most immediate concern is simply not publishing
obviously stale artefacts as I believe that gives a very misleading
picture to users. I'd like to go ahead with the vote for that aspect and
then have a separate debate resulting in some proposals for an attic
area or alternatives.
Anyone with thoughts or preferences on the ideal changes to svn
structure, please respond.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Robert Godfrey <ro...@gmail.com>.
On 31 March 2011 21:06, Robert Godfrey <ro...@gmail.com> wrote:
>
>
> On 31 March 2011 19:36, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 03/18/2011 03:56 PM, Justin Ross wrote:
>>
>>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>>>
>>> I know Gordon said:
>>>>
>>>>
>>>> "Specifically I'd suggest that unless anyone has specific updates to the
>>>> following artefacts - and volunteers to verify the artefact for the
>>>> release
>>>> - we remove them from the published list:
>>>>
>>>> qpid-dotnet-0-8-0.10-beta.zip
>>>> qpid-dotnet-0-10-0.10-beta.
>>>> zip
>>>> qpid-ruby-0.10-beta.tar.gz
>>>>
>>>> This will avoid giving false impressions about ongoing maintenance for
>>>> these
>>>> clients"
>>>>
>>>> But I think that if we are going to actually do this, we should formally
>>>> vote for it, and move the codebases for these artefacts into an "attic"
>>>> directory or similar.
>>>>
>>>> I'm not against removing unloved and unmaintained code... but I do
>>>> feel that
>>>> we should vote before adding or removing artefacts to/from the release.
>>>>
>>>
>>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>>>
>>
>> I would find it hard to vote for a new release that contained those
>> artefacts unless someone could justify it through a list of changes made[1]
>> (this would also have the benefit of identifying possible maintainers for
>> those components to whom questions of support could be directed). I.e. I
>> think that a vote will be required to keep them in, and it would be
>> unfortunate to stall the whole release.
>>
>> However I do agree that some more explicit 'consensus gathering' on this
>> is important since my previous mail did not result in any comments or
>> responses. Therefore...
>>
>> ...please reply with your +1 / -1 vote, or cross one of the boxes for each
>> of the cases below:
>>
>> (a)
>>
>>
>
>> [X] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
>>
>> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10 release
>> (please list changes it includes to support this vote)
>>
>> (b)
>>
>> [X] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
>>
>> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10 release
>> (please list changes it includes to support this vote)
>>
>> (c)
>>
>> [X] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
>>
>> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
>> (please list changes it includes to support this vote)
>>
>>
>>
>
> I'm generally +1 with removing all three. Is there any documentation that
> needs to be altered though?
>
>
Also, I forgot to add, should we not move the code into an "attic" or
something. If we're not going to support the codebase, lets be very clear
about it?
-- Rob
Change to Getting Started page (was Re: [VOTE] Stop publishing release
artefacts for unmaintained components (was Re: 0.10 release update - RC1
and status))
Posted by Gordon Sim <gs...@redhat.com>.
On 03/31/2011 08:06 PM, Robert Godfrey wrote:
> I'm generally +1 with removing all three. Is there any documentation that
> needs to be altered though?
Yes, good point. There are a couple of links on the 'Getting Started'
page that should be removed (pointing at examples for the 0-10 .net &
ruby clients).
The getting started page could actually do with a bit of work in
general, but attached is a patch that removes these. I think this would
be worth doing in any event (i.e. regardless of the outcome of the vote)
as at present we are really inviting people to get started with stale
components. Any objections to committing this?
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Robert Godfrey <ro...@gmail.com>.
On 31 March 2011 19:36, Gordon Sim <gs...@redhat.com> wrote:
> On 03/18/2011 03:56 PM, Justin Ross wrote:
>
>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>>
>> I know Gordon said:
>>>
>>>
>>> "Specifically I'd suggest that unless anyone has specific updates to the
>>> following artefacts - and volunteers to verify the artefact for the
>>> release
>>> - we remove them from the published list:
>>>
>>> qpid-dotnet-0-8-0.10-beta.zip
>>> qpid-dotnet-0-10-0.10-beta.
>>> zip
>>> qpid-ruby-0.10-beta.tar.gz
>>>
>>> This will avoid giving false impressions about ongoing maintenance for
>>> these
>>> clients"
>>>
>>> But I think that if we are going to actually do this, we should formally
>>> vote for it, and move the codebases for these artefacts into an "attic"
>>> directory or similar.
>>>
>>> I'm not against removing unloved and unmaintained code... but I do
>>> feel that
>>> we should vote before adding or removing artefacts to/from the release.
>>>
>>
>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>>
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes made[1]
> (this would also have the benefit of identifying possible maintainers for
> those components to whom questions of support could be directed). I.e. I
> think that a vote will be required to keep them in, and it would be
> unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on this is
> important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for each
> of the cases below:
>
> (a)
>
>
> [X] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (b)
>
> [X] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (c)
>
> [X] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release (please
> list changes it includes to support this vote)
>
>
>
I'm generally +1 with removing all three. Is there any documentation that
needs to be altered though?
-- Rob
Re: [VOTE] Stop publishing release artefacts for unmaintained components
(was Re: 0.10 release update - RC1 and status)
Posted by Ted Ross <tr...@redhat.com>.
On 03/31/2011 01:36 PM, Gordon Sim wrote:
> On 03/18/2011 03:56 PM, Justin Ross wrote:
>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>>
>>> I know Gordon said:
>>>
>>>
>>> "Specifically I'd suggest that unless anyone has specific updates to
>>> the
>>> following artefacts - and volunteers to verify the artefact for the
>>> release
>>> - we remove them from the published list:
>>>
>>> qpid-dotnet-0-8-0.10-beta.zip
>>> qpid-dotnet-0-10-0.10-beta.
>>> zip
>>> qpid-ruby-0.10-beta.tar.gz
>>>
>>> This will avoid giving false impressions about ongoing maintenance for
>>> these
>>> clients"
>>>
>>> But I think that if we are going to actually do this, we should
>>> formally
>>> vote for it, and move the codebases for these artefacts into an "attic"
>>> directory or similar.
>>>
>>> I'm not against removing unloved and unmaintained code... but I do
>>> feel that
>>> we should vote before adding or removing artefacts to/from the release.
>>
>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes
> made[1] (this would also have the benefit of identifying possible
> maintainers for those components to whom questions of support could be
> directed). I.e. I think that a vote will be required to keep them in,
> and it would be unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on
> this is important since my previous mail did not result in any
> comments or responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
>
> [1] My JIRA query may be at fault, but I can't see any JIRA for any of
> those components fixed for 0.9/0.10
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
+1 for all 3
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Andrew Stitcher <as...@redhat.com>.
On Thu, 2011-03-31 at 18:36 +0100, Gordon Sim wrote:
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
+3 (3x +1)
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 31 March 2011 18:36, Gordon Sim <gs...@redhat.com> wrote:
> On 03/18/2011 03:56 PM, Justin Ross wrote:
>
>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>>
>> I know Gordon said:
>>>
>>>
>>> "Specifically I'd suggest that unless anyone has specific updates to the
>>> following artefacts - and volunteers to verify the artefact for the
>>> release
>>> - we remove them from the published list:
>>>
>>> qpid-dotnet-0-8-0.10-beta.zip
>>> qpid-dotnet-0-10-0.10-beta.
>>> zip
>>> qpid-ruby-0.10-beta.tar.gz
>>>
>>> This will avoid giving false impressions about ongoing maintenance for
>>> these
>>> clients"
>>>
>>> But I think that if we are going to actually do this, we should formally
>>> vote for it, and move the codebases for these artefacts into an "attic"
>>> directory or similar.
>>>
>>> I'm not against removing unloved and unmaintained code... but I do
>>> feel that
>>> we should vote before adding or removing artefacts to/from the release.
>>>
>>
>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>>
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes made[1]
> (this would also have the benefit of identifying possible maintainers for
> those components to whom questions of support could be directed). I.e. I
> think that a vote will be required to keep them in, and it would be
> unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on this is
> important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for each
> of the cases below:
>
> (a)
>
> [ X ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (b)
>
> [ X ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
> (c)
>
> [ X ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release (please
> list changes it includes to support this vote)
>
>
> [1] My JIRA query may be at fault, but I can't see any JIRA for any of
> those components fixed for 0.9/0.10
>
>
Robbie
RE: [VOTE] Stop publishing release artefacts for unmaintained components (was Re: 0.10 release update - RC1 and status)
Posted by Steve Huston <sh...@riverace.com>.
+1
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
> Sent: Thursday, March 31, 2011 1:37 PM
> To: dev@qpid.apache.org
> Subject: [VOTE] Stop publishing release artefacts for
> unmaintained components (was Re: 0.10 release update - RC1 and status)
>
>
> On 03/18/2011 03:56 PM, Justin Ross wrote:
> > On Fri, 18 Mar 2011, Robert Godfrey wrote:
> >
> >> I know Gordon said:
> >>
> >>
> >> "Specifically I'd suggest that unless anyone has specific
> updates to
> >> the following artefacts - and volunteers to verify the
> artefact for
> >> the release
> >> - we remove them from the published list:
> >>
> >> qpid-dotnet-0-8-0.10-beta.zip
> >> qpid-dotnet-0-10-0.10-beta.
> >> zip
> >> qpid-ruby-0.10-beta.tar.gz
> >>
> >> This will avoid giving false impressions about ongoing maintenance
> >> for these clients"
> >>
> >> But I think that if we are going to actually do this, we should
> >> formally vote for it, and move the codebases for these
> artefacts into
> >> an "attic" directory or similar.
> >>
> >> I'm not against removing unloved and unmaintained code... but I do
> >> feel that we should vote before adding or removing
> artefacts to/from
> >> the release.
> >
> > Okay. I'll restore these to RC2 unless there's a vote to
> remove them.
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes
> made[1] (this would also have the benefit of identifying possible
> maintainers for those components to whom questions of support
> could be
> directed). I.e. I think that a vote will be required to keep them in,
> and it would be unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus
> gathering' on this
> is important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10
> release [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed
> from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the
> 0.10 release [ ] -1, qpid-dotnet-0-10-0.10 should NOT be
> removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10
> release [ ] -1, qpid-ruby-0.10 should NOT be removed from
> the 0.10 release
> (please list changes it includes to support this vote)
>
>
> [1] My JIRA query may be at fault, but I can't see any JIRA
> for any of
> those components fixed for 0.9/0.10
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Chuck Rolke <cr...@redhat.com>.
+1 +1 +1
When this is approved I'll fix the picture in qpid/doc/dev-readme
-Chuck
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: dev@qpid.apache.org
> Sent: Thursday, March 31, 2011 1:36:37 PM
> Subject: [VOTE] Stop publishing release artefacts for unmaintained components (was Re: 0.10 release update - RC1 and
> status)
> On 03/18/2011 03:56 PM, Justin Ross wrote:
> > On Fri, 18 Mar 2011, Robert Godfrey wrote:
> >
> >> I know Gordon said:
> >>
> >>
> >> "Specifically I'd suggest that unless anyone has specific updates
> >> to the
> >> following artefacts - and volunteers to verify the artefact for the
> >> release
> >> - we remove them from the published list:
> >>
> >> qpid-dotnet-0-8-0.10-beta.zip
> >> qpid-dotnet-0-10-0.10-beta.
> >> zip
> >> qpid-ruby-0.10-beta.tar.gz
> >>
> >> This will avoid giving false impressions about ongoing maintenance
> >> for
> >> these
> >> clients"
> >>
> >> But I think that if we are going to actually do this, we should
> >> formally
> >> vote for it, and move the codebases for these artefacts into an
> >> "attic"
> >> directory or similar.
> >>
> >> I'm not against removing unloved and unmaintained code... but I do
> >> feel that
> >> we should vote before adding or removing artefacts to/from the
> >> release.
> >
> > Okay. I'll restore these to RC2 unless there's a vote to remove
> > them.
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes
> made[1] (this would also have the benefit of identifying possible
> maintainers for those components to whom questions of support could be
> directed). I.e. I think that a vote will be required to keep them in,
> and it would be unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on
> this
> is important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
>
> [1] My JIRA query may be at fault, but I can't see any JIRA for any of
> those components fixed for 0.9/0.10
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Stop publishing release artefacts for unmaintained
components (was Re: 0.10 release update - RC1 and status)
Posted by Ken Giusti <kg...@redhat.com>.
+1 x 3
-K
----- Original Message -----
> On 03/18/2011 03:56 PM, Justin Ross wrote:
> > On Fri, 18 Mar 2011, Robert Godfrey wrote:
> >
> >> I know Gordon said:
> >>
> >>
> >> "Specifically I'd suggest that unless anyone has specific updates
> >> to the
> >> following artefacts - and volunteers to verify the artefact for the
> >> release
> >> - we remove them from the published list:
> >>
> >> qpid-dotnet-0-8-0.10-beta.zip
> >> qpid-dotnet-0-10-0.10-beta.
> >> zip
> >> qpid-ruby-0.10-beta.tar.gz
> >>
> >> This will avoid giving false impressions about ongoing maintenance
> >> for
> >> these
> >> clients"
> >>
> >> But I think that if we are going to actually do this, we should
> >> formally
> >> vote for it, and move the codebases for these artefacts into an
> >> "attic"
> >> directory or similar.
> >>
> >> I'm not against removing unloved and unmaintained code... but I do
> >> feel that
> >> we should vote before adding or removing artefacts to/from the
> >> release.
> >
> > Okay. I'll restore these to RC2 unless there's a vote to remove
> > them.
>
> I would find it hard to vote for a new release that contained those
> artefacts unless someone could justify it through a list of changes
> made[1] (this would also have the benefit of identifying possible
> maintainers for those components to whom questions of support could be
> directed). I.e. I think that a vote will be required to keep them in,
> and it would be unfortunate to stall the whole release.
>
> However I do agree that some more explicit 'consensus gathering' on
> this
> is important since my previous mail did not result in any comments or
> responses. Therefore...
>
> ...please reply with your +1 / -1 vote, or cross one of the boxes for
> each of the cases below:
>
> (a)
>
> [ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (b)
>
> [ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
> release (please list changes it includes to support this vote)
>
> (c)
>
> [ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
> [ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
> (please list changes it includes to support this vote)
>
>
> [1] My JIRA query may be at fault, but I can't see any JIRA for any of
> those components fixed for 0.9/0.10
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[VOTE] Stop publishing release artefacts for unmaintained components
(was Re: 0.10 release update - RC1 and status)
Posted by Gordon Sim <gs...@redhat.com>.
On 03/18/2011 03:56 PM, Justin Ross wrote:
> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>
>> I know Gordon said:
>>
>>
>> "Specifically I'd suggest that unless anyone has specific updates to the
>> following artefacts - and volunteers to verify the artefact for the
>> release
>> - we remove them from the published list:
>>
>> qpid-dotnet-0-8-0.10-beta.zip
>> qpid-dotnet-0-10-0.10-beta.
>> zip
>> qpid-ruby-0.10-beta.tar.gz
>>
>> This will avoid giving false impressions about ongoing maintenance for
>> these
>> clients"
>>
>> But I think that if we are going to actually do this, we should formally
>> vote for it, and move the codebases for these artefacts into an "attic"
>> directory or similar.
>>
>> I'm not against removing unloved and unmaintained code... but I do
>> feel that
>> we should vote before adding or removing artefacts to/from the release.
>
> Okay. I'll restore these to RC2 unless there's a vote to remove them.
I would find it hard to vote for a new release that contained those
artefacts unless someone could justify it through a list of changes
made[1] (this would also have the benefit of identifying possible
maintainers for those components to whom questions of support could be
directed). I.e. I think that a vote will be required to keep them in,
and it would be unfortunate to stall the whole release.
However I do agree that some more explicit 'consensus gathering' on this
is important since my previous mail did not result in any comments or
responses. Therefore...
...please reply with your +1 / -1 vote, or cross one of the boxes for
each of the cases below:
(a)
[ ] +1, qpid-dotnet-0-8-0.10 SHOULD be removed from the 0.10 release
[ ] -1, qpid-dotnet-0-8-0.10 should NOT be removed from the 0.10
release (please list changes it includes to support this vote)
(b)
[ ] +1, qpid-dotnet-0-10-0.10 SHOULD be removed from the 0.10 release
[ ] -1, qpid-dotnet-0-10-0.10 should NOT be removed from the 0.10
release (please list changes it includes to support this vote)
(c)
[ ] +1, qpid-ruby-0.10 SHOULD be removed from the 0.10 release
[ ] -1, qpid-ruby-0.10 should NOT be removed from the 0.10 release
(please list changes it includes to support this vote)
[1] My JIRA query may be at fault, but I can't see any JIRA for any of
those components fixed for 0.9/0.10
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 0.10 release update - RC1 and status
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Mar 20, 2011 at 5:49 AM, Robbie Gemmell <ro...@gmail.com>wrote:
> Your attachments were stripped (you need to link to items of any
> significant
> size) so it wasn't clear which broker you were discussing, but I ran the
> test against the Java broker anyway and have identified an issue which
> would
> present itself particularly badly in this scenario (create consumer,
> receive
> one message from a queue containing many more messages, close consumer,
> repeat). The problem is not actually related to the number of connections
> but the number of consumers created combined with the fact that the queue
> has a backlog of messages.
>
I am using the java message broker. In our environment there are a lot of
consumers.
thanks,
Amila.
>
>
>
> I have raised a JIRA to track this and have initially classed it as a
> release blocker: https://issues.apache.org/jira/browse/QPID-3157
>
>
>
> Robbie
>
>
>
> From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
> Sent: 19 March 2011 07:57
> To: dev@qpid.apache.org
> Cc: Justin Ross
> Subject: Re: 0.10 release update - RC1 and status
>
>
>
> I tried to simulate a memory leak with occur in our environment by using
> the
> following program.
>
> public static void main(String[] args) {
> try {
>
> Properties properties = new Properties();
> properties.put("connectionfactory.qpidConnectionfactory",
>
> "amqp://admin:admin@clientID/test?brokerlist='tcp://localhost:5672'");
> properties.put("queue.queueName", "myQueue");
> properties.put("java.naming.factory.initial",
> "org.apache.qpid.jndi.PropertiesFileInitialContextFactory");
> final Context context = new InitialContext(properties);
>
> Runnable messageReceiver = new Runnable() {
>
> public void run() {
> while (true) {
> try {
> ConnectionFactory connectionFactory =
> (ConnectionFactory) context.lookup("qpidConnectionfactory");
> Connection connection =
> connectionFactory.createConnection();
> connection.start();
>
> Session session =
> connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> Destination destination = (Destination)
> context.lookup("queueName");
> MessageConsumer messageConsumer =
> session.createConsumer(destination);
> TextMessage textMessage = (TextMessage)
> messageConsumer.receive();
> System.out.println(textMessage.getText());
> messageConsumer.close();
> session.close();
> connection.stop();
> connection.close();
> } catch (JMSException e) {
> e.printStackTrace();
> } catch (NamingException e) {
> e.printStackTrace();
> }
>
> }
> }
> };
>
> Thread messageReceiveThread = new Thread(messageReceiver);
> messageReceiveThread.start();
>
> // let consumer to start first.
> Thread.sleep(2000);
>
> for (int i = 0; i < 10000; i++) {
> ConnectionFactory connectionFactory = (ConnectionFactory)
> context.lookup("qpidConnectionfactory");
> Connection connection =
> connectionFactory.createConnection();
> connection.start();
>
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
>
> Destination destination = (Destination)
> context.lookup("queueName");
>
> MessageProducer messageProducer =
> session.createProducer(destination);
>
> TextMessage message = session.createTextMessage("Hello world
> message to test the qpid " + i);
> messageProducer.send(message);
>
> messageProducer.close();
> session.close();
> connection.stop();
> connection.close();
>
> Thread.sleep(50);
>
> }
>
> } catch (Exception exp) {
>
> exp.printStackTrace();
>
> }
> }
>
> After running this for about 7000 messages, Qpid server goes out of memory.
> Please see the attachments.
>
> I think this is a problem with connection removing when creating a lot of
> connections.
>
> thanks,
> Amila.
>
>
>
>
> On Sat, Mar 19, 2011 at 12:25 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>
> I tried to create a durable queue like this
>
> queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
> True}}");
> QueueSender queueSender = queueSession.createSender(queue);
> queueSender.send(textMessage);
>
> and getting this exception.
>
> Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast
> to
> java.lang.String
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.getDurability(Address
> Helper.java:237)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(
> AddressHelper.java:222)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(Addre
> ssHelper.java:215)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(Address
> Helper.java:254)
> at
>
> org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestina
> tion.java:888)
> at
>
> org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.ja
> va:1272)
>
> thanks,
> Amila.
>
>
>
> On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
>
> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>
> I know Gordon said:
>
>
> "Specifically I'd suggest that unless anyone has specific updates to the
> following artefacts - and volunteers to verify the artefact for the release
> - we remove them from the published list:
>
> qpid-dotnet-0-8-0.10-beta.zip
> qpid-dotnet-0-10-0.10-beta.
> zip
> qpid-ruby-0.10-beta.tar.gz
>
> This will avoid giving false impressions about ongoing maintenance for
> these
> clients"
>
> But I think that if we are going to actually do this, we should formally
> vote for it, and move the codebases for these artefacts into an "attic"
> directory or similar.
>
> I'm not against removing unloved and unmaintained code... but I do feel
> that
> we should vote before adding or removing artefacts to/from the release.
>
>
>
> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>
> Justin
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
RE: 0.10 release update - RC1 and status
Posted by Robbie Gemmell <ro...@gmail.com>.
Your attachments were stripped (you need to link to items of any significant
size) so it wasn't clear which broker you were discussing, but I ran the
test against the Java broker anyway and have identified an issue which would
present itself particularly badly in this scenario (create consumer, receive
one message from a queue containing many more messages, close consumer,
repeat). The problem is not actually related to the number of connections
but the number of consumers created combined with the fact that the queue
has a backlog of messages.
I have raised a JIRA to track this and have initially classed it as a
release blocker: https://issues.apache.org/jira/browse/QPID-3157
Robbie
From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
Sent: 19 March 2011 07:57
To: dev@qpid.apache.org
Cc: Justin Ross
Subject: Re: 0.10 release update - RC1 and status
I tried to simulate a memory leak with occur in our environment by using the
following program.
public static void main(String[] args) {
try {
Properties properties = new Properties();
properties.put("connectionfactory.qpidConnectionfactory",
"amqp://admin:admin@clientID/test?brokerlist='tcp://localhost:5672'");
properties.put("queue.queueName", "myQueue");
properties.put("java.naming.factory.initial",
"org.apache.qpid.jndi.PropertiesFileInitialContextFactory");
final Context context = new InitialContext(properties);
Runnable messageReceiver = new Runnable() {
public void run() {
while (true) {
try {
ConnectionFactory connectionFactory =
(ConnectionFactory) context.lookup("qpidConnectionfactory");
Connection connection =
connectionFactory.createConnection();
connection.start();
Session session =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Destination destination = (Destination)
context.lookup("queueName");
MessageConsumer messageConsumer =
session.createConsumer(destination);
TextMessage textMessage = (TextMessage)
messageConsumer.receive();
System.out.println(textMessage.getText());
messageConsumer.close();
session.close();
connection.stop();
connection.close();
} catch (JMSException e) {
e.printStackTrace();
} catch (NamingException e) {
e.printStackTrace();
}
}
}
};
Thread messageReceiveThread = new Thread(messageReceiver);
messageReceiveThread.start();
// let consumer to start first.
Thread.sleep(2000);
for (int i = 0; i < 10000; i++) {
ConnectionFactory connectionFactory = (ConnectionFactory)
context.lookup("qpidConnectionfactory");
Connection connection =
connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
Destination destination = (Destination)
context.lookup("queueName");
MessageProducer messageProducer =
session.createProducer(destination);
TextMessage message = session.createTextMessage("Hello world
message to test the qpid " + i);
messageProducer.send(message);
messageProducer.close();
session.close();
connection.stop();
connection.close();
Thread.sleep(50);
}
} catch (Exception exp) {
exp.printStackTrace();
}
}
After running this for about 7000 messages, Qpid server goes out of memory.
Please see the attachments.
I think this is a problem with connection removing when creating a lot of
connections.
thanks,
Amila.
On Sat, Mar 19, 2011 at 12:25 PM, Amila Suriarachchi
<am...@gmail.com> wrote:
I tried to create a durable queue like this
queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
True}}");
QueueSender queueSender = queueSession.createSender(queue);
queueSender.send(textMessage);
and getting this exception.
Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to
java.lang.String
at
org.apache.qpid.client.messaging.address.AddressHelper.getDurability(Address
Helper.java:237)
at
org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(
AddressHelper.java:222)
at
org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(Addre
ssHelper.java:215)
at
org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(Address
Helper.java:254)
at
org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestina
tion.java:888)
at
org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.ja
va:1272)
thanks,
Amila.
On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
On Fri, 18 Mar 2011, Robert Godfrey wrote:
I know Gordon said:
"Specifically I'd suggest that unless anyone has specific updates to the
following artefacts - and volunteers to verify the artefact for the release
- we remove them from the published list:
qpid-dotnet-0-8-0.10-beta.zip
qpid-dotnet-0-10-0.10-beta.
zip
qpid-ruby-0.10-beta.tar.gz
This will avoid giving false impressions about ongoing maintenance for these
clients"
But I think that if we are going to actually do this, we should formally
vote for it, and move the codebases for these artefacts into an "attic"
directory or similar.
I'm not against removing unloved and unmaintained code... but I do feel that
we should vote before adding or removing artefacts to/from the release.
Okay. I'll restore these to RC2 unless there's a vote to remove them.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: 0.10 release update - RC1 and status
Posted by Amila Suriarachchi <am...@gmail.com>.
I tried to simulate a memory leak with occur in our environment by using the
following program.
public static void main(String[] args) {
try {
Properties properties = new Properties();
properties.put("connectionfactory.qpidConnectionfactory",
"amqp://admin:admin@clientID
/test?brokerlist='tcp://localhost:5672'");
properties.put("queue.queueName", "myQueue");
properties.put("java.naming.factory.initial",
"org.apache.qpid.jndi.PropertiesFileInitialContextFactory");
final Context context = new InitialContext(properties);
Runnable messageReceiver = new Runnable() {
public void run() {
while (true) {
try {
ConnectionFactory connectionFactory =
(ConnectionFactory) context.lookup("qpidConnectionfactory");
Connection connection =
connectionFactory.createConnection();
connection.start();
Session session =
connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Destination destination = (Destination)
context.lookup("queueName");
MessageConsumer messageConsumer =
session.createConsumer(destination);
TextMessage textMessage = (TextMessage)
messageConsumer.receive();
System.out.println(textMessage.getText());
messageConsumer.close();
session.close();
connection.stop();
connection.close();
} catch (JMSException e) {
e.printStackTrace();
} catch (NamingException e) {
e.printStackTrace();
}
}
}
};
Thread messageReceiveThread = new Thread(messageReceiver);
messageReceiveThread.start();
// let consumer to start first.
Thread.sleep(2000);
for (int i = 0; i < 10000; i++) {
ConnectionFactory connectionFactory = (ConnectionFactory)
context.lookup("qpidConnectionfactory");
Connection connection =
connectionFactory.createConnection();
connection.start();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
Destination destination = (Destination)
context.lookup("queueName");
MessageProducer messageProducer =
session.createProducer(destination);
TextMessage message = session.createTextMessage("Hello world
message to test the qpid " + i);
messageProducer.send(message);
messageProducer.close();
session.close();
connection.stop();
connection.close();
Thread.sleep(50);
}
} catch (Exception exp) {
exp.printStackTrace();
}
}
After running this for about 7000 messages, Qpid server goes out of memory.
Please see the attachments.
I think this is a problem with connection removing when creating a lot of
connections.
thanks,
Amila.
On Sat, Mar 19, 2011 at 12:25 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
> I tried to create a durable queue like this
>
> queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
> True}}");
> QueueSender queueSender = queueSession.createSender(queue);
> queueSender.send(textMessage);
>
> and getting this exception.
>
> Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast
> to java.lang.String
> at
> org.apache.qpid.client.messaging.address.AddressHelper.getDurability(AddressHelper.java:237)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:222)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:215)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:254)
> at
> org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:888)
> at
> org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1272)
>
> thanks,
> Amila.
>
>
> On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
>
>> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>>
>> I know Gordon said:
>>>
>>>
>>> "Specifically I'd suggest that unless anyone has specific updates to the
>>> following artefacts - and volunteers to verify the artefact for the
>>> release
>>> - we remove them from the published list:
>>>
>>> qpid-dotnet-0-8-0.10-beta.zip
>>> qpid-dotnet-0-10-0.10-beta.
>>> zip
>>> qpid-ruby-0.10-beta.tar.gz
>>>
>>> This will avoid giving false impressions about ongoing maintenance for
>>> these
>>> clients"
>>>
>>> But I think that if we are going to actually do this, we should formally
>>> vote for it, and move the codebases for these artefacts into an "attic"
>>> directory or similar.
>>>
>>> I'm not against removing unloved and unmaintained code... but I do feel
>>> that
>>> we should vote before adding or removing artefacts to/from the release.
>>>
>>
>> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>>
>> Justin
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: 0.10 release update - RC1 and status
Posted by Rajith Attapattu <ra...@gmail.com>.
Re: The addressing issue.
I have worked out a fix for this and is testing it out.
However I am not sure if we need to fix this for the upcoming release or
not.
I did have a test case for the durable case, but alas it was using 'true'
instead of 'True'.
It's not a critical issue as there is clearly a way to get it working.
On the other hand it's a bit of a nuisance and an embarrassing slip on our
side.
How about I attach a patch and then we make a decision ?
If the majority feels it should be included I am quite happy to include it.
If not we should definitely release note it.
Regards,
Rajith.
On Mon, Mar 21, 2011 at 2:01 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
> On Sun, Mar 20, 2011 at 5:04 AM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > It appears you need to use 'true' instead of the documented 'True' for
> the
> > value to make this work.
> >
>
> that worked.
>
> thanks,
> Amila.
>
> >
> > I'm not sure which is expected to be correct, but I don't see why we
> can't
> > accept both in future. I have raised a JIRA
> > (https://issues.apache.org/jira/browse/QPID-3156) to track the issue
> > either
> > way.
> >
> >
> > Robbie
> >
> > -----Original Message-----
> > From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
> > Sent: 19 March 2011 06:56
> > To: dev@qpid.apache.org
> > Cc: Justin Ross
> > Subject: Re: 0.10 release update - RC1 and status
> >
> > I tried to create a durable queue like this
> >
> > queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
> > True}}");
> > QueueSender queueSender = queueSession.createSender(queue);
> > queueSender.send(textMessage);
> >
> > and getting this exception.
> >
> > Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast
> > to
> > java.lang.String
> > at
> >
> >
> org.apache.qpid.client.messaging.address.AddressHelper.getDurability(Address
> > Helper.java:237)
> > at
> >
> >
> org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(
> > AddressHelper.java:222)
> > at
> >
> >
> org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(Addre
> > ssHelper.java:215)
> > at
> >
> >
> org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(Address
> > Helper.java:254)
> > at
> >
> >
> org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestina
> > tion.java:888)
> > at
> >
> >
> org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.ja
> > va:1272)
> >
> > thanks,
> > Amila.
> >
> > On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
> >
> > > On Fri, 18 Mar 2011, Robert Godfrey wrote:
> > >
> > > I know Gordon said:
> > >>
> > >>
> > >> "Specifically I'd suggest that unless anyone has specific updates to
> > >> the following artefacts - and volunteers to verify the artefact for
> > >> the release
> > >> - we remove them from the published list:
> > >>
> > >> qpid-dotnet-0-8-0.10-beta.zip
> > >> qpid-dotnet-0-10-0.10-beta.
> > >> zip
> > >> qpid-ruby-0.10-beta.tar.gz
> > >>
> > >> This will avoid giving false impressions about ongoing maintenance
> > >> for these clients"
> > >>
> > >> But I think that if we are going to actually do this, we should
> > >> formally vote for it, and move the codebases for these artefacts into
> an
> > "attic"
> > >> directory or similar.
> > >>
> > >> I'm not against removing unloved and unmaintained code... but I do
> > >> feel that we should vote before adding or removing artefacts to/from
> > >> the release.
> > >>
> > >
> > > Okay. I'll restore these to RC2 unless there's a vote to remove them.
> > >
> > > Justin
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Apache Qpid - AMQP Messaging Implementation
> > > Project: http://qpid.apache.org
> > > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> > >
> > >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
Re: 0.10 release update - RC1 and status
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Mar 20, 2011 at 5:04 AM, Robbie Gemmell <ro...@gmail.com>wrote:
> It appears you need to use 'true' instead of the documented 'True' for the
> value to make this work.
>
that worked.
thanks,
Amila.
>
> I'm not sure which is expected to be correct, but I don't see why we can't
> accept both in future. I have raised a JIRA
> (https://issues.apache.org/jira/browse/QPID-3156) to track the issue
> either
> way.
>
>
> Robbie
>
> -----Original Message-----
> From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
> Sent: 19 March 2011 06:56
> To: dev@qpid.apache.org
> Cc: Justin Ross
> Subject: Re: 0.10 release update - RC1 and status
>
> I tried to create a durable queue like this
>
> queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
> True}}");
> QueueSender queueSender = queueSession.createSender(queue);
> queueSender.send(textMessage);
>
> and getting this exception.
>
> Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast
> to
> java.lang.String
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.getDurability(Address
> Helper.java:237)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(
> AddressHelper.java:222)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(Addre
> ssHelper.java:215)
> at
>
> org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(Address
> Helper.java:254)
> at
>
> org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestina
> tion.java:888)
> at
>
> org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.ja
> va:1272)
>
> thanks,
> Amila.
>
> On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
>
> > On Fri, 18 Mar 2011, Robert Godfrey wrote:
> >
> > I know Gordon said:
> >>
> >>
> >> "Specifically I'd suggest that unless anyone has specific updates to
> >> the following artefacts - and volunteers to verify the artefact for
> >> the release
> >> - we remove them from the published list:
> >>
> >> qpid-dotnet-0-8-0.10-beta.zip
> >> qpid-dotnet-0-10-0.10-beta.
> >> zip
> >> qpid-ruby-0.10-beta.tar.gz
> >>
> >> This will avoid giving false impressions about ongoing maintenance
> >> for these clients"
> >>
> >> But I think that if we are going to actually do this, we should
> >> formally vote for it, and move the codebases for these artefacts into an
> "attic"
> >> directory or similar.
> >>
> >> I'm not against removing unloved and unmaintained code... but I do
> >> feel that we should vote before adding or removing artefacts to/from
> >> the release.
> >>
> >
> > Okay. I'll restore these to RC2 unless there's a vote to remove them.
> >
> > Justin
> >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
RE: 0.10 release update - RC1 and status
Posted by Robbie Gemmell <ro...@gmail.com>.
It appears you need to use 'true' instead of the documented 'True' for the
value to make this work.
I'm not sure which is expected to be correct, but I don't see why we can't
accept both in future. I have raised a JIRA
(https://issues.apache.org/jira/browse/QPID-3156) to track the issue either
way.
Robbie
-----Original Message-----
From: Amila Suriarachchi [mailto:amilasuriarachchi@gmail.com]
Sent: 19 March 2011 06:56
To: dev@qpid.apache.org
Cc: Justin Ross
Subject: Re: 0.10 release update - RC1 and status
I tried to create a durable queue like this
queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
True}}");
QueueSender queueSender = queueSession.createSender(queue);
queueSender.send(textMessage);
and getting this exception.
Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to
java.lang.String
at
org.apache.qpid.client.messaging.address.AddressHelper.getDurability(Address
Helper.java:237)
at
org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(
AddressHelper.java:222)
at
org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(Addre
ssHelper.java:215)
at
org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(Address
Helper.java:254)
at
org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestina
tion.java:888)
at
org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.ja
va:1272)
thanks,
Amila.
On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>
> I know Gordon said:
>>
>>
>> "Specifically I'd suggest that unless anyone has specific updates to
>> the following artefacts - and volunteers to verify the artefact for
>> the release
>> - we remove them from the published list:
>>
>> qpid-dotnet-0-8-0.10-beta.zip
>> qpid-dotnet-0-10-0.10-beta.
>> zip
>> qpid-ruby-0.10-beta.tar.gz
>>
>> This will avoid giving false impressions about ongoing maintenance
>> for these clients"
>>
>> But I think that if we are going to actually do this, we should
>> formally vote for it, and move the codebases for these artefacts into an
"attic"
>> directory or similar.
>>
>> I'm not against removing unloved and unmaintained code... but I do
>> feel that we should vote before adding or removing artefacts to/from
>> the release.
>>
>
> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>
> Justin
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 0.10 release update - RC1 and status
Posted by Amila Suriarachchi <am...@gmail.com>.
I tried to create a durable queue like this
queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
True}}");
QueueSender queueSender = queueSession.createSender(queue);
queueSender.send(textMessage);
and getting this exception.
Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to
java.lang.String
at
org.apache.qpid.client.messaging.address.AddressHelper.getDurability(AddressHelper.java:237)
at
org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:222)
at
org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:215)
at
org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:254)
at
org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:888)
at
org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1272)
thanks,
Amila.
On Fri, Mar 18, 2011 at 9:26 PM, Justin Ross <jr...@redhat.com> wrote:
> On Fri, 18 Mar 2011, Robert Godfrey wrote:
>
> I know Gordon said:
>>
>>
>> "Specifically I'd suggest that unless anyone has specific updates to the
>> following artefacts - and volunteers to verify the artefact for the
>> release
>> - we remove them from the published list:
>>
>> qpid-dotnet-0-8-0.10-beta.zip
>> qpid-dotnet-0-10-0.10-beta.
>> zip
>> qpid-ruby-0.10-beta.tar.gz
>>
>> This will avoid giving false impressions about ongoing maintenance for
>> these
>> clients"
>>
>> But I think that if we are going to actually do this, we should formally
>> vote for it, and move the codebases for these artefacts into an "attic"
>> directory or similar.
>>
>> I'm not against removing unloved and unmaintained code... but I do feel
>> that
>> we should vote before adding or removing artefacts to/from the release.
>>
>
> Okay. I'll restore these to RC2 unless there's a vote to remove them.
>
> Justin
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: 0.10 release update - RC1 and status
Posted by Justin Ross <jr...@redhat.com>.
On Fri, 18 Mar 2011, Robert Godfrey wrote:
> I know Gordon said:
>
>
> "Specifically I'd suggest that unless anyone has specific updates to the
> following artefacts - and volunteers to verify the artefact for the release
> - we remove them from the published list:
>
> qpid-dotnet-0-8-0.10-beta.zip
> qpid-dotnet-0-10-0.10-beta.
> zip
> qpid-ruby-0.10-beta.tar.gz
>
> This will avoid giving false impressions about ongoing maintenance for these
> clients"
>
> But I think that if we are going to actually do this, we should formally
> vote for it, and move the codebases for these artefacts into an "attic"
> directory or similar.
>
> I'm not against removing unloved and unmaintained code... but I do feel that
> we should vote before adding or removing artefacts to/from the release.
Okay. I'll restore these to RC2 unless there's a vote to remove them.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 0.10 release update - RC1 and status
Posted by Robert Godfrey <ro...@gmail.com>.
On 17 March 2011 21:56, Justin Ross <jr...@redhat.com> wrote:
> Hi, everyone. Using revision 1082154 from Wednesday, I have generated
> our RC1 release artifacts:
>
> http://people.apache.org/~nsantos/qpid-0.10-rc1/
>
> As Gordon suggested we do, with this release I've removed the orphaned
> dotnet and ruby tarballs from the artifacts. I've also verified that
> the versions in the qmf and tools modules have been updated to 0.10.
>
I know Gordon said:
"Specifically I'd suggest that unless anyone has specific updates to the
following artefacts - and volunteers to verify the artefact for the release
- we remove them from the published list:
qpid-dotnet-0-8-0.10-beta.zip
qpid-dotnet-0-10-0.10-beta.
zip
qpid-ruby-0.10-beta.tar.gz
This will avoid giving false impressions about ongoing maintenance for these
clients"
But I think that if we are going to actually do this, we should formally
vote for it, and move the codebases for these artefacts into an "attic"
directory or similar.
I'm not against removing unloved and unmaintained code... but I do feel that
we should vote before adding or removing artefacts to/from the release.
-- Rob