[6392] in Release_7.7_team
Release Team meeting today, 2pm, N42-203
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Jul 21 10:55:20 2009
Message-Id: <E06BD987-E037-49EA-8494-CBECFD0E8ADF@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: "release-team@mit.edu" <release-team@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 21 Jul 2009 10:53:14 -0400
X-Spam-Flag: NO
X-Spam-Score: 0.00
We are meeting today at 2pm in N42-203.
I know Evan has to leave early, so we will adjust the meeting schedule
accordingly and try and get through things quickly.
-Jon
1) -thirdparty and -extra-software
a) What goes in these packages? What are the criteria? Do we have an
obligation to keep -extra-software streamlined?
b) The current criteria of "If someone asks for it, we add it" is not
sustainable. It makes sense for something like Linerva, but less so
for all the -cluster machines. I propose that we trim thirdparty (and
possibly -extra-software), and adopt criteria for adding packages to
those metapackages. For example, if one person asks for, say, xmcd, I
think we say "Here is how you install software on cluster machines".
If 50 people ask for xmcd, then it gets added to debathena-
thirdparty. Such a policy would also reduce overall disk space
requirements and installation time.
1.5a) Should we allow users to store their password in the Thunderbird
profile?
2) Can we punt the default umask of 077 and standardize on 022, which
seems to be the upstream default on modern {Li,U}nixes these days?
What are the implications? The primary concern is people who want to
maintain local homedirs for a number of people, for which the umask is
not appropriate. Telling all users of such a machine to set their
own umask may not be feasible. Should we/can we provide a way for
system administrators to change the default umask for machines they
maintain?
debathena / -login / ghudson 13:38 (Steel and circuits will make
me whole)
It's not entirely inapplicable today (it means files you create
in
/tmp or /var/tmp on a cluster machine aren't readable to other
users), but I can't bring myself to care much about it.
3) Hesiod, IMAP and Exchange, oh my!
a) Do we care about Athena 9? Should we?
b) "from" and "mailquota" in the default dotfiles barf on Exchange
Hesiod information.
c) Do we/should we try to care about NMH and mitmailutils?
** Whatever we decide will require coordination with ops to deploy it
on the dialups.
4) Cluster updates and remaining deployments
5) Brief discussion of potential changes for documentation, etc.
a) Pocket Ref probably going away to be replaced by the Trifold of
Awesomeness
