[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
umce linux meeting 3/23 minutes
Tueday, March 23, 2004
Attending:
Jane, Liam, Rodger, Andrew, Albert, Gabi, Sean, Tony, Martin, Marcus,
Willie, Patrick & Aaron
Agenda:
Agenda Review (2)
-------------------------------------------------------
OK
Announcements (5)
-------------------------------------------------------
Racks are here for the first round of IFS/IMAP
They are square hole racks
DSPAM globluser going out
Phase II starts 4/1
Dell hardware order
Martin is finishing testing, then order will go in
Martin has addressed the RAID 10 issue
Process Proposal (10 + 5) Willie (Jane facilitating this item)
-------------------------------------------------------
Proposal:
==============
We aim to accomplish a lot of work. This can be made easier with a
large group of people if we have common goals, and understand our
common expectations of how we can work within this group.
When we're meeting as a full group, it is the role of the facilitator
to:
- keep the group discussion focused on the topic being presented, or
identify when to take the current thread offline. This may be between
individuals, or even to form a sub-group to discuss it in further
detail. When subgroups are formed, it should be specified by the group
if the sub-group has the authority to make a decision, or if they need
to bring back a recommendation to make a proposal.
- seek to achieve the goal of the agenda item ( information,
discussion, or proposal )
- inspire people to state their point in an understandable fashion, and
to deliver it in an appropriate (brief) amount of time
- strive to maximize involvement by including everyone in the
discussion who wants to participate, and help to clarify details when
group members don't understand
- communicate with the group when time is running low, and decide
whether to cut off discussion of the topic, or to extend time so that
it can reach conclusion while the discussion is relevant
- the process of consensus consists of these steps:
a) clearly restate the question before asking for consensus
b) ask if the group if there are further viewpoints or questions we
haven't heard yet
c) ask if anyone stands aside*, and why they choose to do so
d) ask if anyone chooses to blocks the decision
* By choosing to stand aside, you're not necessarily supporting the
decision because you may have a reservation (hopefully you've expressed
it already), however you may feel that the decision benefits the group,
and don't feel that blocking is necessary.
* Blocking is a serious move, stating that you haven't been able to
negotiate a compromise during discussion, and this decision would go
against what we're trying to accomplish. Remember that blocking should
be used sparingly.
- after the meeting, review the minutes that have been taken,
clarifying details or adding comments, and then distribute them to the
group
Pros:
----------
- this clarifies the responsibilities of a facilitator, and the process
of a meeting
- this can work to prevent process misunderstandings
- allows for rotation of facilitation role
Cons:
--------
- more bureaucracy, could slow down decisions
- doesn't address how to reach understanding across different technical
skill levels
- doesn't address how subgroup meetings should operate
process/facilitation
- stay on topic
- offline
- individuals
- subgroups
- authority
- recommendation
- achieve goal
- info
- discussion
- proposal
- stay brief
- stay on time
- consensus process
- restate
- ask for other views
- stands aside
- blocks
- review and distribute notes
Concerns were brought up about the consensus structure of the group.
What is quorum? Can some members later 'veto' a decision made by the
group?
This could make collaborative decision making irrelevant.
Discuss consensus process at the next meeting when other key members of
the group are present, including quorum.
CVS Meeting Update (10)
-------------------------------------------------------
Reviewed previous tabled items.
Root access issues will have to be addressed.
Current plan is still eq w/ a raid
Things are moving along, although another copy of the notes from that
meeting should be sent out.
Whiteboard/package Update (10)
-------------------------------------------------------
packages split into following categories:
min, core, developer and other (overloads)
core will never get you multiuser, core is a 'cd' load
without cd specific stuff.
typical loadset would min, core, kernel, "personality" and rc.s
can we get one kernel?
boot cd process split off?
Do we need a new group for the boot cd? or special topic?
About the boot cd:
For Sites (desktop load), there will (may be) special boot cd
requirements. Desktop people should keep both roles in mind when
participating in boot cd discussions.
What is the goal for a LFS 2.0 Loadset?
At these early stages consensus building on foundational issues
is more important than forward movement.
Sites Desktop group is not waiting on 2.0 to move forward, but
are actively particpating in 2.0 with expectations of rolling it
out once it becomes available.
Next meeting Monday 2 pm
External Sharing of Loadsets (10)
-------------------------------------------------------
The people who expressed interest in meeting on this issue
at the last meeting did not apparently meet.
From the March 9th meeting:
Discuss External sharing of UMCE work - Kevin, Sean, Wes, Andrew,
Jane
- meet as a subgroup
Where are our secrets? (i.e. passwords) We should document them,
and decide
where is an appropriate place for them to live.
Gab worries about setting a precedent by including some people
in the ITCS group from outside, and later implementing some other
campus process.
Netfilters/IPtables (5)
-------------------------------------------------------
Not currently set up properly
Netfilters need to get turned on and IPtables need to be built
Once packet filtering is available, we should discuss what the
'default' setting
should be
If there are specific Netfiltering options/needs, please relay them
to Jane, Patrick, Sean, Martin
Kernel Config Delta/Sites (15) Patrick + Jane
-------------------------------------------------------
Goal: One kernel to rule them all
The Sites group has a list of things that need to change.
Is a subgroup necessary?
How detailed is the list, how much discussion is necessary?
What is the potential for hardware support causing kernel bloat.
Sites plans to keep hardware versions to a minimum
Not everything can be a module.
There are tradeoffs between maintaining a sole kernal and forking.
mstores now sends out RFP's that require identical internal hardware
across order
Marcus hypothesizes that server hardware may be more of a threat
to consistency than desktop hardware.
Sean wonders if we should spend a lot of time and energy trying
not to fork if forking is inevitable due to hardware bloat.
Namespace Collision (5)
-------------------------------------------------------
separating heimdal and MIT?
how can we avoid collisions on binaries like 'login'
Name space collision only applies only when you want both version
/usr/local is used for versioned software and existing namespace
collision
What about external users?
- /usr/local is managed, so it's not a place to install
Never install into /usr/local/bin, only use package name to avoid
possible name space collision
UMCE Linux Website (5)
-------------------------------------------------------
There: http://www.umich.edu/~umce/linux
gabi likes cvs
internal v. external distribution of information
add sexy web mail archive of our linux mail
Kevin is working on email -> html translation
UPDATE: Kevin has this working, and should announce it to the group.
Next meeting:
-------------------------------------------------------
Tuesday, April 6th, 3-4:30pm
Note the change of location due to booking constraints:
Conference Room 1330 in Building 3
This meeting will be facilitated by Gabi.