Summary from last Sunday's SIG meeting
Thorsten Leemhuis
fedora at leemhuis.info
Tue Mar 20 19:00:24 UTC 2007
= Meeting 20070318 =
[[TableOfContents]]
== Attending ==
* entr0py
* nirik
* quaid
* thimm
* thl
== Summary ==
* Some discussions about the meeting time; seems to be quite important
for some people to make sure the current main EPEL drivers can make the
meeting; But Sundays on the other hand are bad for some people
(especially people that might get payed for packaging stuff in EPEL) and
we try to check for alternative times by using the wiki page:
http://fedoraproject.org/wiki/EPEL/NewMeetingTime ; if you would be
interested to join the SIG meetings times please fill that table out! tia!
* RHEL5 on the builders -- there are some issues getting RHEL5 in
place, but they hopefully sort out soon; the current plan is to use a
merged tree for building (as agreed on in the past)
* we probably need to split the repo up for different users like
CentOS, RHEL5 Desktop (4 flavours afaics: Client, VT, Workstation,
WOrkstation + VT) and Server (2 flavours) to make sure yum doesn't run
into missing-dep situations; maybe this can be done with a yum plugin,
needs to be investigated. Anyone interested to help? thl will look into
this, but that might take some days as he has others things on this plate
* Some discussions on
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates
* thimm wants to allow kernel modules, but thl and nirik would like
to avoid them for now
* some discussions how to push packages to the different repos and
tested pacakge to the stable repo ; it was suggested to use three repos:
* stable -- main repo
* stable-testing -- test packages there for a short time period
before they get *moved* to stable
* devel/testing/updates-nextrel -- packages get queued up here; this
becomes stable with the next quarterly update
The current proposal works with just two repos and suggested to build
packages for devel/testing (against the latest updates that might become
the next quarterly update) and then build the pacakge anew for stable if
everything looks fine
Please discuss on the list!
* thimm urges to have a "Voting body & fesco mandate" (btw, we have a
fesco mandate, but it's not actually clearly written down). thl will
write something up and present it to the world and FESCo
Note: there are some takes on the schedule at
http://fedoraproject.org/wiki/EPEL/Schedule
that could need some help.
== Full log ==
{{{
17:00 --- | thl has changed the topic to: EPEL SIG meeting
17:00 < thl> | ping EPEL SIG members
17:00 < thl> | who's around?
17:00 * | quaid is here
17:00 * | thimm is
17:00 < entr0py> | bjohnson here
17:00 * | nirik is here.
17:00 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule
17:01 < thl> | hi everyone
17:01 * | kanarip is here
17:01 < thl> | dgilmore mentioned it would be likely that he
could not join us today
17:01 < thimm> | :/
17:01 < thimm> | Isn't he the only one that insists on Sunday
meetings?
17:02 < nirik> | yeah, sunday or off business hours during the week...
17:02 < thl> | nirik, yes, something like that was what dgilmore
wants
17:03 < thl> | and even if someone asks for this is doesn't mean
that he has free time each week ;-)
17:03 < nirik> | true...
17:03 < thimm> | So, how about we move the meeting time into the
work week?
17:03 < thl> | I pinged mmcgrath in #fedora-devel
17:03 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- meeting time
17:04 < thl> | thimm, well, "off business hours" in the US means
probably middle of the night for us europeans
17:04 < nirik> | thimm: where was the link to that wiki
timeschedule page you made? I was meaning to look at it and add, perhaps
we could see what time works best based on that?
17:04 < thimm> | Isn't he down-under?
17:04 < thimm> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime
17:04 < thl> | thimm, dgilmore? no
17:04 < thimm> | But noone entered anything in there
17:04 < thl> | he comes from down under iirc, but is in the US
for some years now
17:05 < nirik> | do we have any west coast people at all? perhaps
we could use that time as well?
17:05 < nirik> | (for now)
17:05 < nirik> | yeah, I think he's in MN.us.
17:05 < thl> | quaid, are you on the west coast?
17:05 < quaid> | I am
17:06 < nirik> | ah, sorry, thought there weren't any west coast
folks. :) My mistake
17:07 < quaid> | we used this to figure out likely slots for our
far-flung FDSCo members:
17:07 < quaid> | http://fedoraproject.org/wiki/BobJensen/MeetingTimes
17:07 < thl> | well, I stated my preferred times on the list in
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00203.html
17:07 < quaid> | each person put in their unavailability by their
initial, and we looked for the ligthest coverage
17:07 < thimm> | similar to what we did with FPC
17:07 < quaid> | thl: right, we tried that for a while, but it
failed to make it obvious when the best times were
17:08 < quaid> | so, if passing ideas back and forth doesn't help,
me may need a matrix like this
17:08 < thimm> | See
http://fedoraproject.org/wiki/Packaging/NewMeetingTime
17:08 < thimm> | This is what I used as a template for
http://fedoraproject.org/wiki/EPEL/NewMeetingTime
17:08 < nirik> | I would prefer to have dgilmore around, since he
is dealing with so much of the infrastructure, but most times are ok
with me otherwise.
17:09 < nirik> | thimm: sundays are usually bad for you?
17:09 < thl> | nirik, +1, we need to make sure the certain key
driers so far can join the meeting normally
17:09 < thimm> | Yes
17:09 < thimm> | Sundays seems to be bad for many people including
@RH.com
17:09 < nirik> | yeah, true...
17:10 < nirik> | from dgilmore's email to the list: " It would
need to be between 23:00-3:00 UTC or 11:30-12:30 UTC or on the weekends."
17:10 < thimm> | We'd like more participation from the enterprise
world and people with jobs like to work on Mo-Fr
17:10 --> | che (Rudolf Kastl) has joined #fedora-meeting
17:10 < thl> | thimm, we fist need to lift of...
17:10 < nirik> | thimm: agreed.
17:11 < thimm> | thl: If we close doors, how will we lift off?
17:11 < thl> | anyway, can somebody fill out
http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what we know so far
17:11 < thl> | then we can ask the others to put up their time
17:11 < thl> | and then we can look further
17:11 < thl> | thimm, it's not that bad currently
17:12 < thl> | and those that showed most interested seems to
agree on sunday
17:12 < thl> | for now
17:12 * | thimm looks around
17:12 < nirik> | I think we are left with sunday or not having
dgilmore available at the meetings.
17:12 < thl> | nirik, +1
17:12 < thimm> | nirik: Or both like today ...
17:13 < thimm> | I won't be able to make it on other Sundays
17:13 < thimm> | This is my first Sunday I could make it anyway
17:13 < nirik> | what about saturday?
17:13 < thimm> | Well, weekends in general are bad, but Saturday
early (in UTC speech) are the lesser evil
17:14 < nirik> | perhaps we can propose that to dgilmore. Or just
pick a weekday meeting time and move on.
17:15 --> | engwnbie (Leo Canale) has joined #fedora-meeting
17:15 * | thl still votes that somebody that pre-fills
http://fedoraproject.org/wiki/EPEL/NewMeetingTime with what is
publically known; then we ask others to add their info, and then we'll
look at it next week
17:15 < thimm> | It would make sense for everyone interested to
fill out his own slots
17:15 < thimm> | That's how it worked at the FPC
17:16 < thimm> | Cross out what you can't attend and ++ the lsots
you prefer
17:16 < thl> | thimm, go ahead and to it
17:16 < thimm> | s/lsots/slots/
17:16 < thl> | thimm, somebody needs to start
17:16 < thl> | so others know how it shall look like
17:16 < thl> | add mine and dglimores times, too
17:16 < thl> | and others will join
17:16 < nirik> | in my case as long as it's not fesco and at times
I am awake it's ok with me. ;)
17:17 < thl> | let's fill out the form until next week and then
look at it?
17:17 < thl> | and move on now?
17:18 < nirik> | ok
17:18 < thl> | somebody just needs to start afaics
17:18 * | thl will move on
17:18 --> | glezos (Dimitris Glezos) has joined #fedora-meeting
17:18 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- RHEL5 on the builders
17:19 < thl> | we have some issues getting RHEL5 in place
17:19 < thl> | but they hopefully sort out soon
17:19 < nirik> | I think dgilmore was working on that. ;)
17:19 < thl> | dgilmore, yes, he and mmcgrath are working on it
17:19 < nirik> | FYI, centos has a 4.92 beta out to test with...
17:19 < thl> | the big problem is:
17:19 < thl> | do we need one merged tree
17:20 < thl> | or different ones for Client and server
17:20 < thl> | I'd say:
17:20 < thimm> | thl: OK, my part is done
17:20 < nirik> | I think we agreed on one merged tree in the past.
I think Client and Server would make things too complicated.
17:20 < thl> | nirik, +1
17:20 < thl> | nirik, neertheless we need to split stuff somehow
17:20 < thl> | otherwise Client users will run into missing dep
issues
17:20 < nirik> | split how?
17:21 < thl> | if a pacakge requires something from the server
17:21 < thl> | split the repo into Client (Desktop, VT,
Workstation, VT+Workstation) and Server
17:21 < thl> | or use a yum plugin
17:22 < thl> | that prevents that people run into missing dep issues
17:22 < thimm> | yum plugin sounds nicer
17:22 < thl> | thimm, +1
17:22 < thl> | that's my plan, too
17:22 < nirik> | yuck. Yeah, yum plugin would be better...
17:22 < thl> | as we would hae just one repo
17:22 < thimm> | It will deal with any furture layering of RHEL
products, too
17:22 < thl> | and centos users simply could use all
17:22 < nirik> | but who is going to write it? :)
17:22 < thl> | nirik, that's the problem...
17:22 < thimm> | Well, is it really a plugin?
17:23 < che> | thl, well but the plugin cant just ignore missing
deps
17:23 < thimm> | Maybe it is yum core functionality
17:23 < thl> | che, we'd need to ship list of packages
17:23 < thimm> | Like a switch to deal with missing/broekn deps
17:23 < thl> | where we know that deps will be missing
17:23 < thl> | well, or something like that...
17:23 < thimm> | This switch would be usefull for rawhide as well
17:23 < thl> | I'll try to look into this during the week
17:23 < thl> | and post to the list
17:24 < thl> | but well, if somebody else is interested in
solving this I won't mind :)
17:24 < thl> | is anyone?
17:24 < nirik> | didn't someone post a list of packages that were
just in server/client? I can't find the list now...
17:24 < thimm> | I did on epel and rhelv5 lists
17:24 < thl> | nirik, is more complicated then just server vs client
17:25 < thimm> | Just grep for evolution in the body
17:25 < thl> | nirik, there are different client versions
17:25 < nirik> | thl: in 4, but not 5, right?
17:25 < thimm> | thl: sure?
17:25 < nirik> | 5 just has a since client/workstation I thought.
17:25 < thimm> | thl: difference in premium etc is support, not
content
17:25 < thl> | only RHEL5-Client-Workstation for example ships
PHP and eclipse
17:26 < thl> | thimm, not 100% sure, but quite sure, yes
17:26 < thl> | you have a isntall-number
17:26 < nirik> | ah, found the list... it's pretty small...
17:26 < thl> | you have to fill in during install
17:26 < thl> | and that decides about the package set you can
install
17:26 < thimm> | I see
17:27 < quaid> | are the "not available" packages not oon RHN for
those install types?
17:27 < thimm> | so one media, several outputs
17:27 < thl> | well, as I said, I'll try to look at this closer
during the week
17:27 < thl> | thimm, yes
17:27 < thl> | quaid, are they?
17:27 < quaid> | I don't know
17:27 < thimm> | Makes organisation quite messy
17:27 * | thl has no RHEL5 at hand ATM
17:27 < quaid> | this is a bit unexpected thinking to me ...
17:27 < thimm> | quaid: It wouldn't make much sense, or not?
17:27 < quaid> | well
17:28 < quaid> | from a support perspective, sure, if you have
Server and call about Eclipse on it ...
17:28 < quaid> | but does that mean there is no way to get the
package?
17:28 < quaid> | I'm thinking about dep resoling in particular
17:28 < thl> | let's stop here
17:28 < thl> | and further investigate during the week
17:28 < quaid> | and not being to replace packages i nthe distro, etc.
17:28 < quaid> | ok
17:28 < thimm> | If the install number prohibit installtion of
eclipse from the media they should also do so from the channels
17:28 < thl> | does that sound sane?
17:28 < nirik> | yeah, I think further investigation would be good.
17:29 < nirik> | I would really prefer to just have one repo per
release of epel... otherwise it's getting very complex for maintainers.
17:29 < thl> | nirik, +1
17:29 < thl> | and for us, too
17:29 * | thl will move on soon if nobody yells
17:29 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule --
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates
17:30 < thl> | do we all agree on that this is the way forward?
17:30 * | nirik re-reads it again quickly
17:30 < thl> | not much changed in the past week
17:31 < thl> | actually, the changes since the initial posting
were quite small in general
17:31 < thimm> | I disagree on kernel module policy
17:32 < thl> | thimm, suggestions please :)
17:32 < thl> | this was discussed on the list, wasn#t it?
17:32 < thl> | did you speak up there? (/me wonders if he missed
that)
17:32 < thimm> | I did
17:32 < thimm> | And you replied
17:32 < thimm> | But I still disagree :)
17:32 < nirik> | kernel modules are a nice can of worms. I think
we want to at least avoid them until everything else is up...
17:32 < thl> | nirik, +100 :)
17:33 < thimm> | Also: why rebuild packages?
17:33 < che> | from a usability point of view i like the dkms
approach
17:33 < thl> | thimm, ?
17:33 < thimm> | From testing to stable transition
17:33 < thimm> | Doesn't that defeat any testing/QA done?
17:33 < thl> | thimm, that's not written there afaics
17:34 < thl> | the testing branch simply becomes the stable
branch when the quarterly update happens
17:34 < thimm> | "go to a testing branch for a short time period
and then build a second time for the stable branch"
17:34 < nirik> | yeah, shouldn't need to do that... since ABI/API
should keep stable in minor releases of RHEL, right?
17:34 < thl> | thimm, that's something different
17:34 < thl> | that's more a: "updates-testing" meachnism
17:34 < thl> | and only for those rare cases where updates to
stable are needed
17:34 < thimm> | Yes, and this should be rebuilt as well
17:35 < thimm> | Otherwise the "testing" part gets reset
17:35 < nirik> | isn't that more "there were problems in testing,
so a new release was needed to fix them before pushing to stable" ?
17:35 < thimm> | That's different
17:35 < thimm> | If the package has a bug it needs to get fixed in
testng
17:35 < nirik> | agreed.
17:35 < thl> | thimm, can you please outline your thoughts on
the list
17:35 < thimm> | And when the bugs are off move the final testing
package to stable
17:35 < thl> | I think that would be the better place
17:36 < thimm> | Well, these are no "thoughts", just general pratice
17:36 < thl> | thimm, don#t forget that packages in testing
might get build agianst something else then the ones in stable
17:36 < nirik> | thimm: I agree, perhaps we need to clarify the
document in that?
17:36 < thl> | stable=rh-latest
17:36 < thimm> | thl: that should not happen
17:37 < thl> | testing=rh-what-becomes-next-quarterly-update
17:37 < thl> | thimm, let's move this to the list
17:37 < thl> | it becomes to complicated here on IRC in my opinion
17:37 < thimm> | thl: There are two concepts mixes up then
17:37 < nirik> | The only time I would think that would happen is
if there were several packages in epel that depended on each other and
needed to be pushed at once.
17:37 < thimm> | You want "rawhide" and "updates-testing" in one repo
17:37 < thimm> | That won't wokr
17:38 < thimm> | For development we need to separate them, just
like FC does
17:38 < thl> | development is fedora
17:38 < thimm> | security and major bugfxies go to the
"updates-testing"
17:38 < thl> | security and major bugfxies go to the
"updates-testing" +1
17:38 < thimm> | Any the prepeation for quarterly go to epel's
"rawhide"
17:39 < thl> | no
17:39 * | thl stopps here, this doens't lead to anything
17:39 < thl> | lets move it to the list
17:39 < thimm> | Why?
17:39 < nirik> | security and major bugfixes go to
"updates-testing" for a short time only and then get pushed to fix the
security/major bug, right?
17:39 < thimm> | Yes
17:39 < thimm> | W/o rebuilding
17:39 < thimm> | Otherwise the QA gets lost
17:39 < nirik> | the minor updates/versions just keep sitting in
updates-testing until the next minor
17:40 < thl> | I'd say with rebuilding
17:40 < thimm> | Yes, but that needs to be a separate repo
17:40 < nirik> | thimm: +1 to no rebuild.
17:40 < thl> | at leat if we build against
rhel-what-becomes-update soon
17:40 < thimm> | E.g. one for quarterly long-term updates and one
for near-term updates to the current minor
17:40 < nirik> | updates-testing and updates-nextrel ?
17:41 <-- | engwnbie has left #fedora-meeting ( "I'm Done")
17:41 < thl> | thimm, then we'd need to have 3 repos
17:41 * | thl thinks that's to much
17:41 < thimm> | Whch three?
17:41 < thl> | that will fail just as updates-testing fail
17:41 * | thl repeats: let's discuss it on the list
17:41 < thl> | we don#t understnad each other here
17:41 < thimm> | Let's talk in FC naming:
17:41 * | thl votes for moving on
17:42 < thl> | and reisiting this next week and on the list
17:42 < thl> | revisit
17:42 < thl> | stupid keyboard
17:42 < nirik> | so for each release, say RHEL5... there is a "5"
repo with main packages, stable, pushed out. A 'updates-testing' thats
usually empty, but sometimes has major security/bugfix packages, and a
'updates-nextrel' that has the packge updates for 5.1 waiting in it.
17:42 < nirik> | thl: ok.
17:43 < thimm> | nirik: something like that, yes
17:43 < thimm> | Where the two latter repo are consdiered our
development repos
17:43 < thimm> | Not development as in == rawhide, but development
as in where we do QA and shape packages for the next quarterly
17:43 < thimm> | Anyway, let's move on
17:44 --- | thl has changed the topic to: EPEL SIG meeting --
http://fedoraproject.org/wiki/EPEL/Schedule -- what else?
17:44 < nirik> | right. I think thats all doable, and mostly
autopmagically so maintainers don't need to mess with it too much.
17:44 < thl> | anything else for today?
17:44 < thl> | repotag?
17:44 < thimm> | Voting body & fesco mandate?
17:44 < thl> | thimm, was discussed last week
17:44 --> | ChitleshGoorah (Chitlesh GOORAH) has joined
#fedora-meeting
17:44 < thl> | but we can bring it up again
17:44 < thimm> | I'm sure it wasn't voted on ;)
17:45 < thimm> | repotag, fedr-ausrmgmt etc need a final voting
somewhere
17:45 < thl> | sure, because we'd need to ask FESCo first how to
set up a voting body
17:45 < nirik> | thimm: so what are you looking for? voting on
tech issues where there is no consensus?
17:45 < thimm> | It's either the sig or fesco
17:45 < thl> | and the fest members around just said "try to
continue without a oting body"
17:45 --> | lancelan (Lance Davis) has joined #fedora-meeting
17:45 < thimm> | thl: we need to suggest something and get iot
ratified
17:45 < thl> | thimm, seems a lot of people disagreed last week
17:46 < thimm> | Last week?
17:46 < thl> | last meeting
17:46 < thimm> | On this irc?
17:46 < nirik> | I think repotag should fall under packaging...
17:46 < thl> | nirik, +1
17:46 < thimm> | Where less than half of the sig can participate?
17:46 < thl> | the summaries get send to the list
17:46 < thl> | so people can look at it
17:46 < thl> | and yell if they don#t like something
17:46 < thl> | nobody yelled
17:47 < thimm> | That's not to be deducted into everybody agrees
17:47 < quaid> | fwiw, we aren't near ready to be a formal project
17:47 < thl> | thimm, see
https://www.redhat.com/archives/epel-devel-list/2007-March/msg00210.html
17:47 < quaid> | so it is SIG or nothing , afaict
17:47 < nirik> | I would much rather get to some tech consensus
than brute force voting on issues where everyone gets unhappy in the end.
17:47 < thimm> | Well, every sig does have to make decisions, right?
17:47 < thl> | thimm, "some discussion about steering issues
that got discussed on the list"
17:48 < thl> | nirik, +1
17:48 < quaid> | right, a SIG can vote, can't it? I mean, anyone
can hjold a vote, unless they are somewhere they will get shot for doing
it :/
17:49 < thl> | quaid, well, yes, but who is allowed to vote
17:49 < thimm> | So the N people mentioned on the SIg list already
form a voting body, is that what you're saying?
17:49 < thl> | that can quickly become confusing if people just
join the sig just to be able to vote
17:49 < thl> | and how many votes does something need to get
accepted
17:49 < thimm> | 50%
17:49 < thimm> | >50%
17:50 < thl> | to much
17:50 < thl> | that will deadlock soon
17:50 < thimm> | That's how voting works
17:50 < nirik> | so this is all for fedora-usermgmt banning? or ?
17:50 < thimm> | No, its for everything
17:50 < thl> | I'd say a group that decides about how epel moves
forward should be 5 or 7 people
17:50 < thl> | not more
17:50 < thimm> | Then make a suggestion and have fesco ratify the list
17:50 < nirik> | well, what I mean is what "everything" do we need
voting for now? aside from usermgmt?
17:51 < thimm> | repotag?
17:51 < thimm> | repo layout?
17:51 < thimm> | guidelines?
17:51 < thimm> | policies?
17:51 < thl> | thimm, we just do it the "if nobody yells it's
okay" way currently
17:51 < thl> | and that was what FESCo members in the last
meeting prefered
17:51 < thimm> | Which means 100% consensus or people are not
paing attention
17:51 < thl> | and non-FESCo members, too afaics
17:51 < thl> | thimm, yes
17:51 < thimm> | That's not a healthy way of a project
17:52 < thl> | it worked so far
17:52 < thl> | sure, if we grow
17:52 < thimm> | It depends on the view I guess
17:52 < thl> | then we need a committee
17:52 < thimm> | so how do you deal with disagreement?
17:52 < thl> | we try to avoid it for now
17:53 < thimm> | Discuss until RHEL6?
17:53 < thl> | or move it to FESCo
17:53 < thimm> | Burry it under the carpet?
17:53 < thimm> | Oh fesco will be grateful for esalating any
decision to them
17:53 < thimm> | For example repotag
17:53 < thimm> | I would agree that pushing it to FPc is the right
thing to do
17:54 < nirik> | well, I would prefer to avoid the overhead, but
if you want voting on issues, how about: anyone with a EPEL package can
vote... voting to take place on a wiki page somewhere on each issue?
17:54 < thimm> | At least not w/o a preference form EPEL
17:54 < thl> | thimm, just out of interest, what's your opinion
on repotag?
17:54 < thl> | nirik, that has other disadantages
17:54 < thl> | okay, I'll write something up for FESCo
17:54 < thimm> | I don't really care, I would like to see one, but
I wopuld rather see it decided upon either way before it gets an
infininte thread
17:54 < thl> | I'll of course send it to the list beforehand
17:55 < thimm> | thl: thanks! :)
17:55 < thl> | anything else?
17:55 < thimm> | Off the meeting: How do I import all my packages
to EPEL?
17:55 * | thl will be afk soon anyway
17:56 < thimm> | (All but a few non-EPELizable)
17:56 < thimm> | Can someone here do a mass branching for me?
17:56 < thl> | thimm, I asked last week for people to write a
script to simplyfy mass-branching in cvs
17:56 < thimm> | Who's doing the branches for EPEL, dgilmore?
17:56 < thl> | thimm, I'll do this script properly myself later
as no one showed interest
17:57 < nirik> | might be best to generate a list and mail
cvsadmins at fedoraproject.org?
17:57 < thl> | thimm, cvsadmins, that includes dgilmore
17:57 < thimm> | OK, I will try cvsadmins, thanks
17:57 < thl> | anything else?
17:57 * | thl will close the meeting in 30
17:58 < thimm> | bye all!
17:58 * | thl will close the meeting in 10
17:58 < thl> | -- MARK -- Meeting end
}}}
More information about the epel-devel-list
mailing list