[9522] in Athena Bugs
Re: vax 7.4F: dotfiles locker
daemon@ATHENA.MIT.EDU (yandros@Athena.MIT.EDU)
Mon Jun 29 11:16:58 1992
From: yandros@Athena.MIT.EDU
Date: Mon, 29 Jun 92 11:16:42 -0400
To: bugs@Athena.MIT.EDU
Cc: dryfoo@Athena.MIT.EDU, jik@Athena.MIT.EDU
Reply-To: yandros@Athena.MIT.EDU
I'm forwarded a proposal to afsreq on the advice of Anne Salemme.
Here's a copy, for posterity:
NOTE: o Paul Boutin replied, saying something about being too busy
surfing to bother with Athena stuff anymore. :-)
o Matt Gray has volunteered to help maintain the locker also.
o I have not yet recieved any response from afsreq, although I
have been told that if a resolution is reached quickly, it
might have an effect on certain minicourses.
> To: afsreq, paul, tlyu, mkgray, mhpower, dryfoo
> Subject: dotfiles locker/contrib.dotfiles
> Reply-To: yandros@ATHENA.MIT.EDU
> X-Orgs: MIT SIPB IS-CSSC IS-DCNS
> --text follows this line--
>
> (Anna Salemme suggested I send this to afsreq)
>
> Currently, the dotfiles locker, orignially set up as a repository for
> various and sundry hacks pertaining to dotfiles, was set up with NFS's
> sticky-bit semantics to allow people to make contributions. As you
> can see from the backup file:
>
> hal-2000:/mit/dotfiles
> :->cat README.~1~
> This locker is a world-writeable repository for dotfiles of all sorts so that
> people can publicize and browse ideas for configuration.
> You can make new directories; please adhere to the format of using the
> filename as a directory name. Name the actual dotfiles anything you
> want. Files which are not dotfiles or something about them will be
> deleted, but please feel free to contribute any slight variations
> which you find or create. Some sort of explanatory text would help too.
>
> -Paul Boutin 9/20/90
> Athena Educational Initiatives
>
> WE APOLOGIZE FOR THE INCONVENIENCE: The locker is currently someplace
> where no one can write to it, but that should be fixed in the next couple of
> days! Sorry. Thursday Oct 4
>
> It's been more than a few days. :-) Currently, the SIPB is interested
> in managing such a project, but it would be better all around for the
> existing, known (if only barely) system to be re-instated instead. In
> this light, I'd like to suggest that the read-write copy of
> contrib.dotfiles be changed such that:
>
> o The volume quota be increased from 500K to 1 Meg, pending
> investigation into how heavily it is used.
>
> o A group/mailing list dotfiles-maintainers be created be creeated for
> admin purposes.
>
> o The entire tree should have:
> system:anyuser: rl
> system:expunge: ld except where otherwise noted.
> sytem:dotfiles-maintainers: all
>
> o The directory: submit be created in the read-write copy of the
> volume with extra permissions:
> system:anyuser rli
>
>
> Under this system, users would make contributions to the submit
> directory, and send mail to dotfiles-maintainers requesting that the
> submissions be entered in appropriate places in the tree. The user
> would then be given write permissions on the particular subtrees (of
> the read-write volume) so that they could maintain their submissions.
>
> For maintainers, Tom Yu and myself are willing to volunteer to begin,
> and there are several others who have expressed an interest.
>
>
> Any questions may be sent directly to either of us, if you wish.
> Thank you,
> Chad Brown,
> Tom Yu
-C
