Why not make /tmp-public and /tmp-private?

Leave /tmp alone. Have all new branches made in one of the two new directories, and as /tmp branches are slowly whacked, we can (eventually) get rid of /tmp.

Tim

Jeff Squyres (jsquyres) wrote:
I thought about both of those (/tmp/private and /tmp/public), but couldn't think of a way to make them work.

1. If we do /tmp/private, we have to svn mv all the existing trees there which will annoy the developers (but is not a deal-breaker) and make /tmp publicly readable. But that makes the history of all the private branches public.

2. If we do /tmp/public, I'm not quite sure how to setup the perms in SH to do that - if we setup /tmp to be 'no read access' for * and /tmp/public to have 'read access' for *, will a non authenticated user be able to reach /tmp/private?

-jms

 -----Original Message-----
From:   Brian Barrett [mailto:bbarr...@lanl.gov]
Sent:   Friday, August 17, 2007 11:51 AM Eastern Standard Time
To:     Open MPI Developers
Subject:        Re: [OMPI devel] Public tmp branches

ugh, sorry, I've been busy this week and didn't see a timeout, so a response got delayed.

I really don't like this format. public doesn't have any meaning to it (tmp suggests, well, it's temporary). I'd rather have /tmp/ and / tmp/private or something like that. Or /tmp/ and /tmp/public/. Either way :/.

Brian


On Aug 17, 2007, at 6:21 AM, Jeff Squyres wrote:

 > I didn't really put this in RFC format with a timeout, but no one
 > objected, so I have created:
 >
 >       http://svn.open-mpi.org/svn/ompi/public
 >
 > Developers should feel free to use this tree for public temporary
 > branches.  Specifically:
 >
 > - use /tmp if your branch is intended to be private
 > - use /public if your branch is intended to be public
 >
 > Enjoy.
 >
 >
 > On Aug 10, 2007, at 9:50 AM, Jeff Squyres wrote:
 >
 >> Right now all branches under /tmp are private to the OMPI core group
 >> (e.g., to allow unpublished academic work).  However, there are
 >> definitely cases where it would be useful to allow public branches
 >> when there's development work that is public but not yet ready for
 >> the trunk.  Periodically, we go an assign individual permissions to /
 >> tmp branches (like I just did to /tmp/vt-integration), but it would
 >> be easier if we had a separate tree for public "tmp" branches.
 >>
 >> Would anyone have an objection if I added /public (or any better name
 >> that someone can think of) for tmp-style branches, but that are open
 >> for read-only access to the public?
 >>
 >> --
 >> Jeff Squyres
 >> Cisco Systems
 >>
 >> _______________________________________________
 >> devel mailing list
 >> de...@open-mpi.org
 >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
 >
 >
 > --
 > Jeff Squyres
 > Cisco Systems
 >
 > _______________________________________________
 > devel mailing list
 > de...@open-mpi.org
 > http://www.open-mpi.org/mailman/listinfo.cgi/devel

_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


------------------------------------------------------------------------

_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Reply via email to