On 2007-03-08 10:22:43 +0000, Dave Shield wrote:
> On 07/03/07, Marcus Rueckert <[EMAIL PROTECTED]> wrote:
> >On 2007-03-07 10:34:47 +0000, Dave Shield wrote:
> >> In particular, I propose the following:
>
> >> b) Move the following to a new directory ('closed')
> >> V3-line
> >> V4-0-line
> >> V4-1-1-patches,
> >> V4-2-patches,
> >> V5-0-patches
> >
> >just delete them. you can undo the deletion if needed in
> >one svn merge cmdline.
>
> I'd rather keep them immediately accessible Just In Case.
> I've been told that the SVN view is Branches are Cheap, and
> the More the Merrier.
> Certainly for the last two - the earlier ones are probably
> less important.
than leave them where they are atm.
> >can we leave that open for a bit more time. i could at least
> >put all the our patches for 5.1 into it.
>
> The 5.1.x line is officially closed so it ought to be treated
> in the same way as the 4.2.x and 5.0.x lines.
> It might be sensible to apply those patches (maybe to
> 5.0.x as well?), although we wouldn't normally expect
> to make another release on either of these lines.
we can discuss that case by case. :)
as the patches have to go through someone with the commit bits anyway.
> >> b') Move the following to either b) or c):
> >> V-5-0-10-patches (rename to V5-0-10-patches?)
> >> V-5-2-1-patches (rename to V5-2-1-patches?)
> >> V5-1-3-patches
> >> V5-3-0-patches
> >
> >what makes those branches different to the branches in a) ?
>
> The branches listed in a) are the current end points
> of the lines that are still being actively developed.
> So we're working with them on an (almost) daily basis.
>
> The branches listed in b) are the current end points
> of lines that have been closed. We wouldn't normally
> expect to do anything more on these branches, but
> they would be the starting point if we ever did decide
> to make another release of those lines.
>
> I believe that these branches listed as b') are spurs,
> relating to a particular release. I'm not quite sure of
> the exact history - which is why I listed them separately,
> with a choice of treating them as either b) or c)
i think the directories in b' are tags and should be removed from
branches.
> >> 2) tags:
> >> a) Retain all [full-release] tags... as currently
> >> b) Move[/Delete] all [pre-release] tags
> >> c[/d]) Move[/Delete] all remaining tags
>
> >many of those "tags" seems to be kind of release branches.
> >i would just delete them.
>
> I'm hestitant to delete the tags for full releases.
> We don't often need to refer to a particular release,
> but it's not unheard-of. And if SVN tags are as cheap
> as I'm led to believe, why not keep them?
true true ... from the technical standpoint we could leave the setup as
is. but i am sure you are looking for a bit cleanup
and really who needs tags for pre releases?:) (maybe me as i packaged on
of them... but i will just write down the revision of it.)
> >I doubt anyone is interested in tags for some prerelease
> >stuff.
>
> That's my feeling too. (See below)
> Perhaps keep the most recent set of pre-release snapshots
> for each line, but I don't see the need to keep all the earlier ones.
agreed.
> >> I'm also inclined to drop all the pre-release tags
> >> once the corresponding full release has been made.
> >> But separating these out from the full releases
> >> would be a reasonable compromise, if it was felt
> >> worth keeping them.
> >
> >what arguments do you have for keeping them?
>
> Me?
> I don't have any arguments for keeping them at all!
> I'm trying to anticipate possible objections from
> elsewhere.....
>
> Does anyone else have any thoughts on any of this?
i added a few more. :)
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
