You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2011/04/01 10:30:57 UTC
"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))
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: "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
>
>