qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
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))
Date Fri, 01 Apr 2011 16:36:48 GMT
On 1 April 2011 18:19, Steve Huston <shuston@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
> > <robbie.gemmell@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 <gsim@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message