From Fedora Project Wiki

< QA‎ | Meetings

(create initial page for 10-01 meeting)
 
(update page with the results of the meeting)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= Attendees =
= Attendees =
* adamw (203)
* tflink (76)
* Viking-Ice (58)
* dlehman (23)
* nirik (22)
* kparal (22)
* wwoods (13)
* akshayvyas (8)
* zodbot (4)
* jskladan (2)
* jreznik (2)
* Martix (1)
* mkrizek (1)
* jwb (1)
* pschindl (1)
* viking-ice (0)


= Agenda =
= Agenda =
* Previous meeting follow-up
* Previous meeting follow-up
* Release criteria
* Fedora 18 Beta status / mini blocker review
* Fedora 18 Beta status / mini blocker review
* Open floor
* Open floor


== Previous meeting follow-up ==
== Previous meeting follow-up ==
* ''adamw to refine alpha partitioning criterion''
* ''adamw to refine alpha partitioning criterion'' - this was done and would be discussed later in the meeting
* ''adamw to draft new partitioning criterion for Beta once we know what will be in anaconda''
* ''adamw to draft new partitioning criterion for Beta once we know what will be in anaconda'' - this was done and would be discussed later in the meeting
* ''adamw to consider revisions to 'kickstart delivery method' criterion''
* ''adamw to consider revisions to 'kickstart delivery method' criterion'' - not yet done
* ''tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down''
* ''tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down'' - not yet done, tim was waiting for the criteria proposals before sending it out
 
== Release criteria ==
 
=== Partitioning ===
* Pre-meeting proposals were [http://lists.fedoraproject.org/pipermail/test/2012-October/110494.html on the mailing list]
* The proposed Alpha criteria were approved without modification
* The proposed Beta criteria were approved with minor modifications to make the intent clearer and add a requirement that custom partitioning be able to destroy partitions
* Possible further criteria were discussed, including one covering the re-use of an existing /home partition, but it was agreed to propose this on the mailing list for further revision
 
=== Upgrade ===
* Pre-meeting proposals were [http://lists.fedoraproject.org/pipermail/test/2012-October/110512.html on the mailing list]
* The proposed criteria were approved, but with the agreement that the use of the word 'or' is ambiguous and should be improved to clarify the meaning
* To avoid confusion it was agreed that the intent of the criteria is that ''all three cases'' for upgrading - minimal package set, GNOME package set, and KDE package set - must work, not ''any one of the three''


== Fedora 18 Beta status / mini blocker review ==
== Fedora 18 Beta status / mini blocker review ==
* FESCo pre-freeze meeting is this week, so let's see whether we think current status is freezeable
 
=== Freeze readiness ===
* FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta, which was planned for 2012-10-09
* The code for the new upgrade tool was [http://github.com/wgwoods/fedup available], but it has not had any official release and we did not believe it was yet in a testable state
* The partitioning code in the latest available anaconda release at time of meeting did not yet support non-destructive automatic partitioning into free space
* wwoods affirmed that the new upgrade tool would be testable by the freeze deadline
* dlehman affirmed that the partitioning code would meet the Beta requirements by the freeze deadline
* We agreed that the state of Fedora 18 as of time of meeting was not good enough to freeze for Beta, but if the upgrade tool was testable and the partitioning code met the Beta requirements by the freeze date, then freezing would be acceptable
* We agreed to pass this evaluation on to the [http://fedorahosted.org/fesco/ticket/946 FESCo ticket]
 
=== Mini blocker review ===
* This was skipped as the meeting had already taken nearly two hours


== Open floor ==
== Open floor ==
N/A
== Action items ==
* adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta


== IRC Log ==
== IRC Log ==
{|
|- id="t15:01:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #startmeeting Fedora QA Meeting
|| [[#t15:01:22|15:01]]
|- id="t15:01:22"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Meeting started Mon Oct  1 15:01:22 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
|| [[#t15:01:22|15:01]]
|- id="t15:01:22"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Useful Commands: #action #agreed #halp #info #idea #link #topic.
|| [[#t15:01:22|15:01]]
|- id="t15:01:25"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #meetingname fedora-qa
|| [[#t15:01:25|15:01]]
|- id="t15:01:25"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | The meeting name has been set to 'fedora-qa'
|| [[#t15:01:25|15:01]]
|- id="t15:01:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic roll call
|| [[#t15:01:28|15:01]]
|- id="t15:01:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | morning folks! who's around for the qa meeting?
|| [[#t15:01:35|15:01]]
|- id="t15:01:38"
| colspan="2" | * pschindl is here
|| [[#t15:01:38|15:01]]
|- id="t15:01:40"
| colspan="2" | * mkrizek is here
|| [[#t15:01:40|15:01]]
|- id="t15:01:42"
| colspan="2" | * jskladan yay for meeting time (before party time)
|| [[#t15:01:42|15:01]]
|- id="t15:01:48"
| colspan="2" | * tflink is here
|| [[#t15:01:48|15:01]]
|- id="t15:01:48"
| colspan="2" | * nirik is lurking, ping if I can help with anything.
|| [[#t15:01:48|15:01]]
|- id="t15:01:54"
| colspan="2" | * kparal hails to the king
|| [[#t15:01:54|15:01]]
|- id="t15:01:57"
| colspan="2" | * akshayvyas is here
|| [[#t15:01:57|15:01]]
|- id="t15:02:00"
| colspan="2" | * Viking-Ice here
|| [[#t15:02:00|15:02]]
|- id="t15:02:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed all qa work to be done by nirik
|| [[#t15:02:06|15:02]]
|- id="t15:02:12"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: ping ^^^^
|| [[#t15:02:12|15:02]]
|- id="t15:02:12"
! style="background-color: #818144" | kparal
| style="color: #818144" | ack
|| [[#t15:02:12|15:02]]
|- id="t15:02:16"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack
|| [[#t15:02:16|15:02]]
|- id="t15:02:17"
! style="background-color: #488888" | tflink
| style="color: #488888" | ack
|| [[#t15:02:17|15:02]]
|- id="t15:02:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | :P
|| [[#t15:02:19|15:02]]
|- id="t15:02:22"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | :)
|| [[#t15:02:22|15:02]]
|- id="t15:02:26"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | I'll get right on it.
|| [[#t15:02:26|15:02]]
|- id="t15:02:32"
! style="background-color: #4b904b" | jskladan
| style="color: #4b904b" | patch: all work to be done by nirik
|| [[#t15:02:32|15:02]]
|- id="t15:02:54"
! style="background-color: #818144" | kparal
| style="color: #818144" | let's be realistic
|| [[#t15:02:54|15:02]]
|- id="t15:03:11"
! style="background-color: #818144" | kparal
| style="color: #818144" | all qa work is enough for one man
|| [[#t15:03:11|15:03]]
|- id="t15:03:30"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | only dwalsh can pull that off
|| [[#t15:03:30|15:03]]
|- id="t15:03:34"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | and that man is ??
|| [[#t15:03:34|15:03]]
|- id="t15:03:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | james bond?
|| [[#t15:03:45|15:03]]
|- id="t15:03:56"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | :)
|| [[#t15:03:56|15:03]]
|- id="t15:05:18"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okey dokey
|| [[#t15:05:18|15:05]]
|- id="t15:05:21"
! style="background-color: #488888" | tflink
| style="color: #488888" | bond is good at breaking stuff, I suppose but I think I'd rather have Q working on that :)
|| [[#t15:05:21|15:05]]
|- id="t15:05:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Previous meeting follow-up
|| [[#t15:05:50|15:05]]
|- id="t15:06:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info "adamw to refine alpha partitioning criterion" and "adamw to draft new partitioning criterion for Beta once we know what will be in anaconda" - the proposal's on the list, we'll come to it later
|| [[#t15:06:28|15:06]]
|- id="t15:06:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info "adamw to consider revisions to 'kickstart delivery method' criterion" - didn't get to that one yet, sorry
|| [[#t15:06:39|15:06]]
|- id="t15:06:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - anything from that?
|| [[#t15:06:47|15:06]]
|- id="t15:07:28"
| colspan="2" | * jreznik is here, sorry for being a little bit late
|| [[#t15:07:28|15:07]]
|- id="t15:07:32"
! style="background-color: #488888" | tflink
| style="color: #488888" | nothing yet, no. I was waiting for the partitioning criteria
|| [[#t15:07:32|15:07]]
|- id="t15:07:44"
! style="background-color: #488888" | tflink
| style="color: #488888" | I have a draft email that I'm planning to send out later today
|| [[#t15:07:44|15:07]]
|- id="t15:08:07"
| colspan="2" | * jwb is here for kernel stuffs
|| [[#t15:08:07|15:08]]
|- id="t15:08:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - tflink was waiting for the revised partitioning criteria before doing this, so will happen soon
|| [[#t15:08:16|15:08]]
|- id="t15:08:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | hi jwb
|| [[#t15:08:19|15:08]]
|- id="t15:09:32"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | I think we are missing one or more hd criteria for the storage spoke but other then that I just think we should be more or less on par what other OS are doing
|| [[#t15:09:32|15:09]]
|- id="t15:09:41"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | just a sec, let me topic up
|| [[#t15:09:41|15:09]]
|- id="t15:10:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Release criteria: partitioning criteria proposal
|| [[#t15:10:03|15:10]]
|- id="t15:10:31"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so, for anyone who missed it, I posted a rough proposal for partitioning criteria to the list last night: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html
|| [[#t15:10:31|15:10]]
|- id="t15:10:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info adamw proposed revised partition criteria for F18+ to the list: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html
|| [[#t15:10:46|15:10]]
|- id="t15:10:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | discuss away!
|| [[#t15:10:52|15:10]]
|- id="t15:11:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: 'one or more hd criteria for the storage spoke' - what do you mean exactly?
|| [[#t15:11:04|15:11]]
|- id="t15:11:31"
! style="background-color: #488888" | tflink
| style="color: #488888" | do we care about reuse of encrypted partitions?
|| [[#t15:11:31|15:11]]
|- id="t15:11:50"
! style="background-color: #488888" | tflink
| style="color: #488888" | ie reusing LUKS setup if /home is encrypted
|| [[#t15:11:50|15:11]]
|- id="t15:11:51"
! style="background-color: #818144" | kparal
| style="color: #818144" | ugh, I didn't get to that discussion today
|| [[#t15:11:51|15:11]]
|- id="t15:11:54"
| colspan="2" | * kparal reading it
|| [[#t15:11:54|15:11]]
|- id="t15:13:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: I think yeah we should cover that 'upgrade' scenario
|| [[#t15:13:20|15:13]]
|- id="t15:13:21"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, if you have one or more hd detected and install on to
|| [[#t15:13:21|15:13]]
|- id="t15:13:23"
! style="background-color: #818144" | kparal
| style="color: #818144" | that means fully custom partitioning should be just in Final, right?
|| [[#t15:13:23|15:13]]
|- id="t15:13:26"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i did miss that one out
|| [[#t15:13:26|15:13]]
|- id="t15:13:26"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | mena too
|| [[#t15:13:26|15:13]]
|- id="t15:13:33"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | mean mean frack!
|| [[#t15:13:33|15:13]]
|- id="t15:13:52"
! style="background-color: #818144" | kparal
| style="color: #818144" | I have one concern about that - it wouldn't be tested as well (as if we required it in Beta)
|| [[#t15:13:52|15:13]]
|- id="t15:14:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: the (rough) criteria proposal for partitioning is at https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html , if you didn't catch it yet
|| [[#t15:14:13|15:14]]
|- id="t15:14:25"
! style="background-color: #488888" | tflink
| style="color: #488888" | true but I think that reusing LUKS setup falls pretty well into the realm of custom partitioning
|| [[#t15:14:25|15:14]]
|- id="t15:14:40"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | kparal: the beta criteria i proposed require some specific abilities for the custom part code
|| [[#t15:14:40|15:14]]
|- id="t15:14:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the second criterion is all stuff you can only do in custom part, in newUI
|| [[#t15:14:52|15:14]]
|- id="t15:14:54"
! style="background-color: #818144" | kparal
| style="color: #818144" | adamw: oh, I have skipped one paragraph. now I see it
|| [[#t15:14:54|15:14]]
|- id="t15:15:03"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | for those that have not read it yet http://blog.linuxgrrl.com/2012/09/25/anaconda-bootloader-reusing-home-assigning-partitions-to-disks/
|| [[#t15:15:03|15:15]]
|- id="t15:15:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | and i'd agree with tflink that we should add 're-use existing /home' to that
|| [[#t15:15:10|15:15]]
|- id="t15:15:39"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | yeah re-use should be added to the criteria as well
|| [[#t15:15:39|15:15]]
|- id="t15:15:46"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | existing LUKS is absolutely custom. always has been.
|| [[#t15:15:46|15:15]]
|- id="t15:16:00"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: that's fine
|| [[#t15:16:00|15:16]]
|- id="t15:16:24"
! style="background-color: #488888" | tflink
| style="color: #488888" | yeah, it kind of branched into two discussions - reusing existing home and reusing existing encrypted home
|| [[#t15:16:24|15:16]]
|- id="t15:16:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: re-use existing /home is also custom partitioning.
|| [[#t15:16:35|15:16]]
|- id="t15:16:39"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | I added a comment there on the blog post what probably is the expected expectation in that regard
|| [[#t15:16:39|15:16]]
|- id="t15:17:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | well, now i think about it
|| [[#t15:17:02|15:17]]
|- id="t15:17:13"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | which criteria could be built upon
|| [[#t15:17:13|15:17]]
|- id="t15:17:15"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: yeah, but I thought that we were talking about adding that particular use case to what is needed for beta
|| [[#t15:17:15|15:17]]
|- id="t15:17:17"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if you have to use custom partitioning for something, then effectively, pre-f18, it was only required at final
|| [[#t15:17:17|15:17]]
|- id="t15:17:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | yeah
|| [[#t15:17:19|15:17]]
|- id="t15:17:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so if we add anything that required custom partitioning in oldUI to the beta criteria, we're setting the bar higher than previously
|| [[#t15:17:36|15:17]]
|- id="t15:18:25"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: good point, final is fine
|| [[#t15:18:25|15:18]]
|- id="t15:18:35"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | I tend to agree with kparal that custom partitioning fits in beta criteria ( alpha not required, beta required to work )
|| [[#t15:18:35|15:18]]
|- id="t15:18:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so we might want to re-word the final criterion a bit to be less vague, rather than adding to beta
|| [[#t15:18:35|15:18]]
|- id="t15:19:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: well i was going for a middle way, in which custom partitioning is required to not be hideously broken at beta, but not required to work entirely
|| [[#t15:19:03|15:19]]
|- id="t15:19:21"
| colspan="2" | * tflink smells another epicly long release criterion :)
|| [[#t15:19:21|15:19]]
|- id="t15:19:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | heh :)
|| [[#t15:19:39|15:19]]
|- id="t15:20:05"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | custom partitioning in anaconda has never work entirely at least not up to the extend kernel supports so I'm not following what you are getting at there?
|| [[#t15:20:05|15:20]]
|- id="t15:20:13"
| colspan="2" | * kparal is fine with almost-but-not-fully covered custom partitioning in Beta
|| [[#t15:20:13|15:20]]
|- id="t15:20:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: well 'completely' would be 'passes the Final criterion'
|| [[#t15:20:28|15:20]]
|- id="t15:21:11"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | just create what 15 partitions on a single drive and see how anaconda handles that ( insane but you know supported by the kernel )
|| [[#t15:21:11|15:21]]
|- id="t15:21:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, here's a modification...
|| [[#t15:21:16|15:21]]
|- id="t15:21:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | change "Creating and assigning" to "Creating, destroying and assigning"
|| [[#t15:21:36|15:21]]
|- id="t15:21:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | or 'removing', whatever
|| [[#t15:21:50|15:21]]
|- id="t15:22:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i'm looking at making sure the pre-18 *alpha* requirements are covered
|| [[#t15:22:04|15:22]]
|- id="t15:22:04"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | adamw: +1
|| [[#t15:22:04|15:22]]
|- id="t15:22:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | one of which was the 'existing Linux partition' autopart method, which wiped existing linux installs but left windows alone
|| [[#t15:22:20|15:22]]
|- id="t15:23:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: well that's not really anything new, since we're not proposing to change the final criterion...can we focus on the beta?
|| [[#t15:23:02|15:23]]
|- id="t15:23:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: is it that you want further requirements for custom part at beta beyond what's already proposed?
|| [[#t15:23:22|15:23]]
|- id="t15:23:49"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | does anaconda actually fail when disks contain the maximum number of partitions? if so, it's just because that never happens in real life (or in bugzilla AFAICT)
|| [[#t15:23:49|15:23]]
|- id="t15:24:21"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | in alpha only the autopart should be required to work and quite frankly I dont think we should be having multiboot support in our criteria et all unless the other OS support that as well
|| [[#t15:24:21|15:24]]
|- id="t15:25:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: well that's what the currently proposed alpha criterion does, so no problem there
|| [[#t15:25:13|15:25]]
|- id="t15:25:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | and we only have multiboot in final, and we're not talking about final right now...
|| [[#t15:25:22|15:25]]
|- id="t15:25:31"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: autopart-in-freespace. I'm not sure how binding this is. Do we need to specify things like "assuming the disk contains a valid disklabel and is bootable, &amp;c" ?
|| [[#t15:25:31|15:25]]
|- id="t15:25:59"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: eh, we don't _need_ to really, we can always clarify that at blocker review time, but maybe we could
|| [[#t15:25:59|15:25]]
|- id="t15:26:05"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | let me see how verbose it looks
|| [[#t15:26:05|15:26]]
|- id="t15:26:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: actually, i think the current wording works fine
|| [[#t15:26:46|15:26]]
|- id="t15:26:49"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | you guys have been good in the past at calling out dealbreaker variations so I'm willing to trust you based on that
|| [[#t15:26:49|15:26]]
|- id="t15:27:18"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, are we just talking about fixing the criteria for beta or fixing the criteria in general?
|| [[#t15:27:18|15:27]]
|- id="t15:27:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: well right now i'd like to focus on the specific partitioning criteria proposal on the list
|| [[#t15:27:34|15:27]]
|- id="t15:27:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: there's a topic later for 'general criteria revision ideas'
|| [[#t15:27:42|15:27]]
|- id="t15:27:50"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: in that free space case, are we supposed to not install any bootloader?
|| [[#t15:27:50|15:27]]
|- id="t15:28:08"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | no, I don't know what we used to do
|| [[#t15:28:08|15:28]]
|- id="t15:28:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: yeah, i was just pondering that when i went quiet there
|| [[#t15:28:10|15:28]]
|- id="t15:28:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: we used to install a bootloader, i would expect we still will. so the wording might need a bit of a change.
|| [[#t15:28:28|15:28]]
|- id="t15:28:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | although, strictly, the MBR isn't part of the 'existing partition table' or 'existing data', really. 'existing user data'?
|| [[#t15:28:54|15:28]]
|- id="t15:28:59"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | maybe add something about offering to access preexisting encrypted devices?
|| [[#t15:28:59|15:28]]
|- id="t15:29:01"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | help? :)
|| [[#t15:29:01|15:29]]
|- id="t15:29:03"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | (in custom)
|| [[#t15:29:03|15:29]]
|- id="t15:29:24"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | existing partitions or filesystems?
|| [[#t15:29:24|15:29]]
|- id="t15:29:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: well, access is needed only for re-use, right&gt;?
|| [[#t15:29:27|15:29]]
|- id="t15:29:30"
! style="background-color: #9b519b" | Martix
| style="color: #9b519b" | hi
|| [[#t15:29:30|15:29]]
|- id="t15:29:32"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | right
|| [[#t15:29:32|15:29]]
|- id="t15:29:38"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the one case we're specifically concerned about there is re-using an existing /home
|| [[#t15:29:38|15:29]]
|- id="t15:29:55"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but then we also considered that, per the pre-f18 criteria, that wasn't actually required to work until final
|| [[#t15:29:55|15:29]]
|- id="t15:30:06"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so if we add that to beta, we're _tightening_ the requirements
|| [[#t15:30:06|15:30]]
|- id="t15:30:10"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i mean we can do that, but it's a consideration
|| [[#t15:30:10|15:30]]
|- id="t15:30:12"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | I see
|| [[#t15:30:12|15:30]]
|- id="t15:30:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it's a bit tricky trying to strike a balance of exactly what we think really needs to be working in custom part by beta, given that custom part is obviously more important in newui since autopart is more restricted.
|| [[#t15:30:42|15:30]]
|- id="t15:31:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: so do you have anything you'd like to add to/remove from the beta criteria proposed?
|| [[#t15:31:19|15:31]]
|- id="t15:33:15"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: for the 'empty space' one..."The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"?
|| [[#t15:33:15|15:33]]
|- id="t15:33:16"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, I actually would like to move the whole custom partitioning from final to beta
|| [[#t15:33:16|15:33]]
|- id="t15:33:57"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: sounds okay to me
|| [[#t15:33:57|15:33]]
|- id="t15:34:05"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: what about /boot partitions?
|| [[#t15:34:05|15:34]]
|- id="t15:34:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: in relation to what?
|| [[#t15:34:16|15:34]]
|- id="t15:34:25"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | Viking-Ice: if you're going to do that you'll have to do so at the beginning of a cycle
|| [[#t15:34:25|15:34]]
|- id="t15:34:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if you mean the criterion me and dlehman are discussing, irrelevant, 'autopart into empty space' does not re-use any existing partitions, it'd create its own /boot
|| [[#t15:34:46|15:34]]
|- id="t15:34:48"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | dlehman, yup
|| [[#t15:34:48|15:34]]
|- id="t15:34:49"
! style="background-color: #488888" | tflink
| style="color: #488888" | 'leaving the pre-existing partitions and data untouched' - does that apply to any existing /boot partitions
|| [[#t15:34:49|15:34]]
|- id="t15:34:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: per the above, yeah.
|| [[#t15:34:58|15:34]]
|- id="t15:35:07"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | an install re-using an existing /boot would have to be done through custom part.
|| [[#t15:35:07|15:35]]
|- id="t15:35:12"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | dlehman, so it would not be subjected for F18 but F19 if we change it
|| [[#t15:35:12|15:35]]
|- id="t15:35:33"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: ok, so if you're not proposing that for f18, can we table it for now? since it's important that we nail down the f18 requirements
|| [[#t15:35:33|15:35]]
|- id="t15:35:41"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, ok
|| [[#t15:35:41|15:35]]
|- id="t15:35:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the reason i want to get this done now, btw, is that it feeds into the 'should we freeze beta' discussion
|| [[#t15:35:58|15:35]]
|- id="t15:36:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | whatever we decide the beta criteria need to be, that's what needs to be basically implemented before we freeze for beta
|| [[#t15:36:13|15:36]]
|- id="t15:36:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ditto for upgrade
|| [[#t15:36:28|15:36]]
|- id="t15:36:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so here's what we have so far, modified from the list proposal:
|| [[#t15:36:52|15:36]]
|- id="t15:37:00"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 1. "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"
|| [[#t15:37:00|15:37]]
|- id="t15:37:11"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 2. "The installer's custom partitioning mode must be capable of the following:"
|| [[#t15:37:11|15:37]]
|- id="t15:37:26"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 2a. "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"
|| [[#t15:37:26|15:37]]
|- id="t15:37:33"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 2b. "Creating encrypted partitions"
|| [[#t15:37:33|15:37]]
|- id="t15:37:41"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 2c. "Rejecting obviously invalid operations without crashing"
|| [[#t15:37:41|15:37]]
|- id="t15:37:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | any specific proposed revisions to those, to be enforced for f18 beta?
|| [[#t15:37:58|15:37]]
|- id="t15:38:14"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | does anyone reckon we should include a requirement for re-using an existing /home at beta rather than final?
|| [[#t15:38:14|15:38]]
|- id="t15:38:18"
! style="background-color: #488888" | tflink
| style="color: #488888" | we're leaving LVM for ginal?
|| [[#t15:38:18|15:38]]
|- id="t15:38:28"
! style="background-color: #488888" | tflink
| style="color: #488888" | final
|| [[#t15:38:28|15:38]]
|- id="t15:38:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: i left LVM on the basis that anaconda team say it's really going to be de-emphasized for newui.
|| [[#t15:38:34|15:38]]
|- id="t15:38:39"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | LVM is The Past, btr is The Future.
|| [[#t15:38:39|15:38]]
|- id="t15:38:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but we could change that if we think it's still important enough
|| [[#t15:38:50|15:38]]
|- id="t15:38:57"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: wdyt?
|| [[#t15:38:57|15:38]]
|- id="t15:39:18"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: LVM was kinda in the previous criteria because it was the Fedora default and we were very big on it for a while.
|| [[#t15:39:18|15:39]]
|- id="t15:39:20"
! style="background-color: #488888" | tflink
| style="color: #488888" | it's somewhat of a departure from previous requirements but yeah, btr seems like it will replace LVM at some point
|| [[#t15:39:20|15:39]]
|- id="t15:39:50"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | lvm still needed for encrypted tho right?
|| [[#t15:39:50|15:39]]
|- id="t15:39:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if fedora isn't so 'ra ra LVM' as it was, which kinda seems to be the case, it's probably not as important
|| [[#t15:39:52|15:39]]
|- id="t15:39:56"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: I'd say that reuse of /home is OK for final
|| [[#t15:39:56|15:39]]
|- id="t15:39:57"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: no? you can encrypt a regular partition.
|| [[#t15:39:57|15:39]]
|- id="t15:39:57"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | nirik: no
|| [[#t15:39:57|15:39]]
|- id="t15:40:08"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | "re-use" and "upgrade" criteria belong in the same milestone ( beta from my pov )
|| [[#t15:40:08|15:40]]
|- id="t15:40:22"
! style="background-color: #488888" | tflink
| style="color: #488888" | encryption + LVM == pain (from my experience)
|| [[#t15:40:22|15:40]]
|- id="t15:40:25"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | ok, cool. I thought it was tied to lvm at one point.
|| [[#t15:40:25|15:40]]
|- id="t15:40:34"
! style="background-color: #488888" | tflink
| style="color: #488888" | well, encrypting the VG == pain, anyways
|| [[#t15:40:34|15:40]]
|- id="t15:40:57"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | so btrfs is default now
|| [[#t15:40:57|15:40]]
|- id="t15:41:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | akshaysth: not right now no, still ext4
|| [[#t15:41:19|15:41]]
|- id="t15:41:20"
! style="background-color: #488888" | tflink
| style="color: #488888" | for F18? I thought that was still pending
|| [[#t15:41:20|15:41]]
|- id="t15:41:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but i think the plan is for btrfs as default in future
|| [[#t15:41:24|15:41]]
|- id="t15:41:34"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | F20+
|| [[#t15:41:34|15:41]]
|- id="t15:41:37"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: explicit inclusion of lvm in addition to plain partitions?
|| [[#t15:41:37|15:41]]
|- id="t15:42:00"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: i can see that, yeah, since the main use case for re-use is basically upgrading.
|| [[#t15:42:00|15:42]]
|- id="t15:42:11"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | yup
|| [[#t15:42:11|15:42]]
|- id="t15:42:31"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: well that's what we were just discussing - i left it out on the basis that you folks thought LVM isn't as important as it used to be, i remember us talking about that in #anaconda, but we can certainly add it back if you think we still should for now.
|| [[#t15:42:31|15:42]]
|- id="t15:42:43"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | adamw: pointed the wrong one :)
|| [[#t15:42:43|15:42]]
|- id="t15:43:11"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | akshaysth is someone else
|| [[#t15:43:11|15:43]]
|- id="t15:43:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: the counter-point to that is that we require upgrade to be in place for beta because upgrade is complex and so we want it in beta so people can test it and report bugs and they can get fixed for final
|| [[#t15:43:24|15:43]]
|- id="t15:43:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: re-use of /home isn't at all as complex an operation as an upgrade installation is
|| [[#t15:43:35|15:43]]
|- id="t15:43:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it doesn't really need months of testing, it just...either works or doesn't work
|| [[#t15:43:47|15:43]]
|- id="t15:44:08"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: reuse of non-encrypted home, sure
|| [[#t15:44:08|15:44]]
|- id="t15:44:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | true, encrypted home is a bit messier
|| [[#t15:44:23|15:44]]
|- id="t15:44:34"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | depends on how you look at it, that feature from my pov of view should be handled automatically from the storage spoke ( as opposed forcing the user having to go to custom partitioning and do all the necessary steps there )
|| [[#t15:44:34|15:44]]
|- id="t15:44:35"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyhow, we're now debating *strengthening* the proposed criteria, i don't hear anyone saying we should weaken them
|| [[#t15:44:35|15:44]]
|- id="t15:44:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so should we approve what's proposed now as a baseline at least? we can always tighten things from there
|| [[#t15:44:50|15:44]]
|- id="t15:44:50"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: I don't really know, to be honest. partitions are a must. lvm, md, btrfs, all debatable.
|| [[#t15:44:50|15:44]]
|- id="t15:45:26"
| colspan="2" | * tflink wonders about leaving md and btrfs for final, though
|| [[#t15:45:26|15:45]]
|- id="t15:45:28"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: i don't think that's gonna happen for 18 at least, aiui. re-use is something you'll definitely have to do through custom part (like it was in oldui)
|| [[#t15:45:28|15:45]]
|- id="t15:45:40"
! style="background-color: #488888" | tflink
| style="color: #488888" | seems like it could cause a lot of problems, no matter when it lands, I suppose
|| [[#t15:45:40|15:45]]
|- id="t15:45:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: we don't have them in the current beta proposal, dlehman was floating them,
|| [[#t15:45:49|15:45]]
|- id="t15:45:51"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | Viking-Ice: that amounts to a sizable RFE, so not going to add that for F18.
|| [[#t15:45:51|15:45]]
|- id="t15:46:39"
! style="background-color: #488888" | tflink
| style="color: #488888" | I'm not against the idea of requiring md and btrfs/lvm for beta as long as we're being reasonable
|| [[#t15:46:39|15:46]]
|- id="t15:47:01"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ok, so how bout this: we vote on approving the new criteria proposed above, then i'll send out a new mail proposing some kind of limited re-use of /home requirement for beta, to be discussed separately
|| [[#t15:47:01|15:47]]
|- id="t15:47:03"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, then it falls just under the general custom partitioning criteria
|| [[#t15:47:03|15:47]]
|- id="t15:47:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: it'd certainly be covered by the existing final criterion yes
|| [[#t15:47:16|15:47]]
|- id="t15:47:20"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: works for me
|| [[#t15:47:20|15:47]]
|- id="t15:47:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: but we could also add it to beta if we want it to work by beta
|| [[#t15:47:24|15:47]]
|- id="t15:47:25"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack
|| [[#t15:47:25|15:47]]
|- id="t15:47:42"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | to the limited beta criteria proposal surrounding re-use of /home
|| [[#t15:47:42|15:47]]
|- id="t15:47:48"
| colspan="2" | * tflink is +1 on the partitioning criteria as proposed above
|| [[#t15:47:48|15:47]]
|- id="t15:48:34"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: the biggest problems with btrfs and lvm are they are so overfull with options that requiring support for any existing config is quite a demand. creating what is supported in the installer, OTOH, it not.
|| [[#t15:48:34|15:48]]
|- id="t15:48:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | propose #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately
|| [[#t15:48:47|15:48]]
|- id="t15:48:56"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | dlack
|| [[#t15:48:56|15:48]]
|- id="t15:49:01"
! style="background-color: #488888" | tflink
| style="color: #488888" | ack
|| [[#t15:49:01|15:49]]
|- id="t15:49:01"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | mean ack
|| [[#t15:49:01|15:49]]
|- id="t15:49:06"
! style="background-color: #4d4d93" | akshayvyas
| style="color: #4d4d93" | ack
|| [[#t15:49:06|15:49]]
|- id="t15:49:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: right, hence the proposal for a 'limited' re-use criterion - i was thinking exactly along the lines of *not* needing any kind of massively complex encrypted-btrfs-on-encrypted-lv /home partition scenario to wrok :)
|| [[#t15:49:27|15:49]]
|- id="t15:49:28"
! style="background-color: #818144" | kparal
| style="color: #818144" | ack
|| [[#t15:49:28|15:49]]
|- id="t15:49:44"
! style="background-color: #488888" | tflink
| style="color: #488888" | dlehman: do you think it would be reasonable to require creating a new layout with btrfs/lvm/md @ beta would be reasonable, leaving reuse for final?
|| [[#t15:49:44|15:49]]
|- id="t15:50:05"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately
|| [[#t15:50:05|15:50]]
|- id="t15:50:16"
! style="background-color: #488888" | tflink
| style="color: #488888" | that gets hard to write out in any reasonable way, though
|| [[#t15:50:16|15:50]]
|- id="t15:50:36"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | dlehman, any particular reason we should be single out re-use as a special feature until you guys have though things through on how you would like to have it in the end ( which means we could just scrap any kind of criteria around it for F18 )
|| [[#t15:50:36|15:50]]
|- id="t15:50:37"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: not really, i could add it to the wording of 2a) easily enough
|| [[#t15:50:37|15:50]]
|- id="t15:50:53"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | tflink: probably, yes. I won't sign anything saying as much until I have time to reflect on it further, though.
|| [[#t15:50:53|15:50]]
|- id="t15:50:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | :P
|| [[#t15:50:58|15:50]]
|- id="t15:51:14"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it's not just whether it's reasonable, though, it's the basic question of 'does all that really need to work in a Fedora beta'.
|| [[#t15:51:14|15:51]]
|- id="t15:51:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyhoo, we have a baseline now at least
|| [[#t15:51:23|15:51]]
|- id="t15:51:26"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | and this is taking a while
|| [[#t15:51:26|15:51]]
|- id="t15:51:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | shall we move on to the upgrade criterion? which with any luck should be easier
|| [[#t15:51:36|15:51]]
|- id="t15:52:17"
! style="background-color: #488888" | tflink
| style="color: #488888" | dlehman: ok, I wasn't looking for anything definitive today - mostly wondering whether the idea was unreasonable
|| [[#t15:52:17|15:52]]
|- id="t15:52:33"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #action adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta
|| [[#t15:52:33|15:52]]
|- id="t15:52:33"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: yeah, that proposal has been pretty quiet as of late
|| [[#t15:52:33|15:52]]
|- id="t15:53:01"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info viking-ice suggests that for f19+, much more custom partitioning functionality should be required at Beta
|| [[#t15:53:01|15:53]]
|- id="t15:53:17"
| colspan="2" | * adamw trying to capture the major thoughts from the partitioning discussion for the record, any others?
|| [[#t15:53:17|15:53]]
|- id="t15:54:26"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: the idea of requiring new lvm/md/btrfs for beta while leaving the reuse/modification of existing layouts for final?
|| [[#t15:54:26|15:54]]
|- id="t15:54:28"
| colspan="2" | * jreznik is ok for now, a little bit harder to follow you here...
|| [[#t15:54:28|15:54]]
|- id="t15:54:30"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info there is some support for requiring creation of LVs/advanced btrfs partitions/RAID to work at beta
|| [[#t15:54:30|15:54]]
|- id="t15:54:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: did you want a definite #action or is it OK to leave it vague?
|| [[#t15:54:54|15:54]]
|- id="t15:55:14"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | I prefer vague
|| [[#t15:55:14|15:55]]
|- id="t15:55:24"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: I'm fine with it being vague as long as we don't forget entirely
|| [[#t15:55:24|15:55]]
|- id="t15:55:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: well it'll be in the meeting summary. only #actions are 'guaranteed' to get picked up on later though, in the sense that they get covered at the next meeting.
|| [[#t15:55:52|15:55]]
|- id="t15:55:57"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #chair tflink kparal viking-ice
|| [[#t15:55:57|15:55]]
|- id="t15:55:57"
! style="background-color: #42427e" | zodbot
| style="color: #42427e" | Current chairs: adamw kparal tflink viking-ice
|| [[#t15:55:57|15:55]]
|- id="t15:56:09"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | now you can #action yourself if you like :)
|| [[#t15:56:09|15:56]]
|- id="t15:56:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Release criteria: upgrade criteria proposal
|| [[#t15:56:36|15:56]]
|- id="t15:56:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info tflink quoted the current proposals at https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html
|| [[#t15:56:56|15:56]]
|- id="t15:57:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | basically, for beta it must be possible to upgrade with any 'officially recommended upgrade mechanism', at final they all have to work.
|| [[#t15:57:22|15:57]]
|- id="t15:57:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | as things stand i think we will only have one 'officially recommended upgrade mechanism' for f18 anyway, so it's kinda moot, but hey
|| [[#t15:57:49|15:57]]
|- id="t15:57:59"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone want to propose changes to it that haven't already been discussed?
|| [[#t15:57:59|15:57]]
|- id="t15:58:10"
| colspan="2" | * adamw +1 to the proposal
|| [[#t15:58:10|15:58]]
|- id="t15:58:21"
! style="background-color: #488888" | tflink
| style="color: #488888" | +1
|| [[#t15:58:21|15:58]]
|- id="t15:58:42"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | we kinda have to decide how far back we expect official upgrade is supposed to work
|| [[#t15:58:42|15:58]]
|- id="t15:59:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: as these are applied to f18, as I understand the current plan, it pretty much means 'upgrade has to work at beta'.
|| [[#t15:59:22|15:59]]
|- id="t15:59:29"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | which is what we had previously.
|| [[#t15:59:29|15:59]]
|- id="t15:59:53"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i think we have pretty solid agreement that that's what we want, a lot of the discussion was just covering loopholes and making the wording apply when it's not anaconda doing the upgrading.
|| [[#t15:59:53|15:59]]
|- id="t16:00:18"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | I'm ack on the proposal but we still need to add how far back release upgrades are supposed to be supported
|| [[#t16:00:18|16:00]]
|- id="t16:00:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh right
|| [[#t16:00:27|16:00]]
|- id="t16:00:29"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | iswym
|| [[#t16:00:29|16:00]]
|- id="t16:00:35"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | mean do we support upgrading from F1 to F18 beta?
|| [[#t16:00:35|16:00]]
|- id="t16:00:35"
! style="background-color: #488888" | tflink
| style="color: #488888" | I think that the current wording of "previous stable release" is pretty clear - Fn-1 to Fn only
|| [[#t16:00:35|16:00]]
|- id="t16:00:44"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | with the current proposal it's the same as the previous one: we only support F(n-1)
|| [[#t16:00:44|16:00]]
|- id="t16:00:57"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | as far as f18 is concerned it probably makes sense not to change that now
|| [[#t16:00:57|16:00]]
|- id="t16:01:05"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | if we want to support n-2 we should probably make that f19 stuff
|| [[#t16:01:05|16:01]]
|- id="t16:01:12"
! style="background-color: #488888" | tflink
| style="color: #488888" | agreed
|| [[#t16:01:12|16:01]]
|- id="t16:01:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but you're right we still need to determine that
|| [[#t16:01:13|16:01]]
|- id="t16:01:22"
! style="background-color: #488888" | tflink
| style="color: #488888" | that seems a bit much to change right before freeze
|| [[#t16:01:22|16:01]]
|- id="t16:01:36"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | and make other documentation consistent with whatever we ultimately agree development/qa will care about
|| [[#t16:01:36|16:01]]
|- id="t16:02:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info viking-ice points out that the question of the status of upgrades from older Fedora releases has still not been entirely settled
|| [[#t16:02:02|16:02]]
|- id="t16:02:43"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | I could have sworn we had a packager guideline about caring about N-2... but nothing saying what upgrades were "supported"
|| [[#t16:02:43|16:02]]
|- id="t16:03:08"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | perhaps we could have N-1 as blocker, and N-2 as NTH? :) (but perhaps thats f19 as you said)
|| [[#t16:03:08|16:03]]
|- id="t16:03:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: as far as QA is concerned we've had the criterion written as 'the previous release' ever since f12, and we've only enforced that (we have a test for n-2 but it's optional and rarely actually performed)
|| [[#t16:03:20|16:03]]
|- id="t16:03:31"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | yeah
|| [[#t16:03:31|16:03]]
|- id="t16:03:33"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | it makes sense we support N-2 as in F16 being supported to be upgraded to F18
|| [[#t16:03:33|16:03]]
|- id="t16:03:43"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | Viking-Ice: yeah, I agree with that too.
|| [[#t16:03:43|16:03]]
|- id="t16:04:23"
! style="background-color: #488888" | tflink
| style="color: #488888" | the counter to that is stuff like usrmove and if it would be a problem to support multiple upgrade vectors
|| [[#t16:04:23|16:04]]
|- id="t16:04:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: i'm kinda torn - i think it's probably correct that we should change and support N-2, but i'm not sure we should do it for F18 since it's pretty late now
|| [[#t16:04:24|16:04]]
|- id="t16:04:26"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, our lazyness not testing it is no excuse ;)
|| [[#t16:04:26|16:04]]
|- id="t16:04:49"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: i'd definitely be on board with supporting F17-F19 and onwards, but i'm a bit unsure about F16-F18
|| [[#t16:04:49|16:04]]
|- id="t16:05:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone else?
|| [[#t16:05:03|16:05]]
|- id="t16:05:06"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | could be a final upgrade criteria
|| [[#t16:05:06|16:05]]
|- id="t16:05:07"
! style="background-color: #488888" | tflink
| style="color: #488888" | either way, I'm against requiring n-2 upgrades for F18 - it's too late in the release cycle to be making changes like that
|| [[#t16:05:07|16:05]]
|- id="t16:05:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: ironic, usually you're the one saying we should only change for future cycles and i'm the one saying we should change now :)
|| [[#t16:05:24|16:05]]
|- id="t16:05:35"
! style="background-color: #818144" | kparal
| style="color: #818144" | I don't think upgrade from n-2 is a good idea at all, so I wouldn't definitely change that for F18
|| [[#t16:05:35|16:05]]
|- id="t16:06:12"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyway, again we can at least accept that we want *at least* the current proposal
|| [[#t16:06:12|16:06]]
|- id="t16:06:23"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | which is the important thing for the 'should we freeze' discussion
|| [[#t16:06:23|16:06]]
|- id="t16:06:25"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so...
|| [[#t16:06:25|16:06]]
|- id="t16:06:26"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | let's clarify that then for F19
|| [[#t16:06:26|16:06]]
|- id="t16:06:33"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack on the current proposal
|| [[#t16:06:33|16:06]]
|- id="t16:06:35"
| colspan="2" | * tflink is still +1 for current proposals
|| [[#t16:06:35|16:06]]
|- id="t16:06:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | propose #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted
|| [[#t16:06:45|16:06]]
|- id="t16:06:51"
! style="background-color: #488888" | tflink
| style="color: #488888" | ack
|| [[#t16:06:51|16:06]]
|- id="t16:06:53"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack
|| [[#t16:06:53|16:06]]
|- id="t16:07:07"
! style="background-color: #818144" | kparal
| style="color: #818144" | ack
|| [[#t16:07:07|16:07]]
|- id="t16:07:20"
| colspan="2" | * nirik re-reads
|| [[#t16:07:20|16:07]]
|- id="t16:07:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info there is some support for extending the criteria to support upgrades from the two previous stable releases, we will discuss that separately
|| [[#t16:07:27|16:07]]
|- id="t16:07:32"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | so is the 'or' in final intended?
|| [[#t16:07:32|16:07]]
|- id="t16:07:33"
! style="background-color: #488888" | tflink
| style="color: #488888" | wait, does that link point to the actual criterion proposal?
|| [[#t16:07:33|16:07]]
|- id="t16:07:46"
! style="background-color: #488888" | tflink
| style="color: #488888" | it contains them, nvm
|| [[#t16:07:46|16:07]]
|- id="t16:07:51"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: what 'or'?
|| [[#t16:07:51|16:07]]
|- id="t16:07:59"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh
|| [[#t16:07:59|16:07]]
|- id="t16:08:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | hm.
|| [[#t16:08:13|16:08]]
|- id="t16:08:14"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | minimal or blocking desktop
|| [[#t16:08:14|16:08]]
|- id="t16:08:19"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it's meant to mean 'all of these', not 'any of these'
|| [[#t16:08:19|16:08]]
|- id="t16:08:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 'or' is a bit ambiguous
|| [[#t16:08:24|16:08]]
|- id="t16:08:24"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | shouldn't that be 'minimal and all blocking desktops' ?
|| [[#t16:08:24|16:08]]
|- id="t16:08:47"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | the problem with 'and' is it makes it sound like 'you have to be able to upgrade a system which has both GNOME and KDE installed'
|| [[#t16:08:47|16:08]]
|- id="t16:09:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | making the wording completely clear seems a bit tricky, shall we agree with the intent and try to refine the wording later?
|| [[#t16:09:20|16:09]]
|- id="t16:09:33"
| colspan="2" | * tflink wonders if we should have some definition of 'release blocking package sets' elsewhere in the criteria
|| [[#t16:09:33|16:09]]
|- id="t16:09:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: we define 'release-blocking desktops' in the preamble
|| [[#t16:09:45|16:09]]
|- id="t16:10:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, iswym, that might work
|| [[#t16:10:02|16:10]]
|- id="t16:10:06"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | we should not be supporting multiple *de installs et al from my pov
|| [[#t16:10:06|16:10]]
|- id="t16:10:12"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: is that OK with you or do you want to nail down the wording now?
|| [[#t16:10:12|16:10]]
|- id="t16:10:22"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: yeah, that's not the intent here, which is why i don't just want to replace 'or' with 'and
|| [[#t16:10:22|16:10]]
|- id="t16:10:26"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | sure. I think we all agree on intent.
|| [[#t16:10:26|16:10]]
|- id="t16:10:40"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | yup
|| [[#t16:10:40|16:10]]
|- id="t16:10:53"
| colspan="2" | * kparal back in a few minutes
|| [[#t16:10:53|16:10]]
|- id="t16:10:54"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | the set of: minimal and (seperately) each release blocking desktop
|| [[#t16:10:54|16:10]]
|- id="t16:10:56"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | or something
|| [[#t16:10:56|16:10]]
|- id="t16:11:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | 'yeah, something like that, but more elegant :)
|| [[#t16:11:02|16:11]]
|- id="t16:11:20"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | right
|| [[#t16:11:20|16:11]]
|- id="t16:11:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted (but we note that the use of 'or' is slightly ambiguous and can be improved)
|| [[#t16:11:27|16:11]]
|- id="t16:11:33"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack
|| [[#t16:11:33|16:11]]
|- id="t16:11:42"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | ack
|| [[#t16:11:42|16:11]]
|- id="t16:11:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed the intent of the proposed criteria is that you must be able to upgrade all three of: a) a minimal install, b) a GNOME install, c) a KDE install
|| [[#t16:11:54|16:11]]
|- id="t16:11:58"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | (just so we have that clearly noted)
|| [[#t16:11:58|16:11]]
|- id="t16:12:14"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | alrighty!
|| [[#t16:12:14|16:12]]
|- id="t16:12:23"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: how can you have minimal, gnome and kde installed at the same time?
|| [[#t16:12:23|16:12]]
|- id="t16:12:26"
! style="background-color: #488888" | tflink
| style="color: #488888" | :-D
|| [[#t16:12:26|16:12]]
|- id="t16:12:28"
| colspan="2" | * tflink ducks
|| [[#t16:12:28|16:12]]
|- id="t16:12:31"
| colspan="2" | * adamw throws things at tflink
|| [[#t16:12:31|16:12]]
|- id="t16:12:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | d'oh, you're way ahead of me
|| [[#t16:12:34|16:12]]
|- id="t16:12:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ok, this is really dragging on, so let's move straight to the pre-freeze discussion
|| [[#t16:12:45|16:12]]
|- id="t16:12:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #topic Fedora 18 Beta status: freeze-worthy?
|| [[#t16:12:56|16:12]]
|- id="t16:13:13"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | nope
|| [[#t16:13:13|16:13]]
|- id="t16:13:43"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | we need to delay the freeze until the upgrade tool is in place
|| [[#t16:13:43|16:13]]
|- id="t16:13:43"
! style="background-color: #488888" | tflink
| style="color: #488888" | there's a bunch of stuff that I haven't even tried to poke at yet
|| [[#t16:13:43|16:13]]
|- id="t16:13:44"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta
|| [[#t16:13:44|16:13]]
|- id="t16:14:05"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info the idea is that we freeze only once the code required by the Beta criteria is broadly in place
|| [[#t16:14:05|16:14]]
|- id="t16:14:05"
! style="background-color: #488888" | tflink
| style="color: #488888" | but I would agree that without a testable upgrade tool, there's little point in entering freeze
|| [[#t16:14:05|16:14]]
|- id="t16:14:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | yeah, i agree with that too
|| [[#t16:14:13|16:14]]
|- id="t16:14:14"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | freeze is scheduled to start 2012-10-09 currently.
|| [[#t16:14:14|16:14]]
|- id="t16:14:22"
| colspan="2" | * nirik nods.
|| [[#t16:14:22|16:14]]
|- id="t16:14:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | it's noted on the FESCo ticket that the upgrade tool code technically exists: https://github.com/wgwoods/fedup
|| [[#t16:14:42|16:14]]
|- id="t16:14:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but afaik there has been no release yet, and i don't know if it's in working state.
|| [[#t16:14:50|16:14]]
|- id="t16:15:01"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: do you have any info there?
|| [[#t16:15:01|16:15]]
|- id="t16:15:02"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | wwoods, around?
|| [[#t16:15:02|16:15]]
|- id="t16:15:29"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | no idea about the upgrade tool
|| [[#t16:15:29|16:15]]
|- id="t16:16:02"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | nirik: fesco is looking at it this week right, though? since next week's meeting will be 10-10
|| [[#t16:16:02|16:16]]
|- id="t16:16:13"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | I think so... let me look
|| [[#t16:16:13|16:16]]
|- id="t16:16:42"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: the other thing that we just agreed, that i'm not sure of the status of: error handling
|| [[#t16:16:42|16:16]]
|- id="t16:16:54"
! style="background-color: #8c4a4a" | nirik
| style="color: #8c4a4a" | yes, it should be this week.
|| [[#t16:16:54|16:16]]
|- id="t16:17:05"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info the new upgrade tool code is at https://github.com/wgwoods/fedup , but as far as we are aware there has been no release and no indication that it is yet in testable state
|| [[#t16:17:05|16:17]]
|- id="t16:17:34"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: is error handling in yet? i.e. will anaconda still just crash if you do something wrong in custom part?
|| [[#t16:17:34|16:17]]
|- id="t16:17:43"
! style="background-color: #488888" | tflink
| style="color: #488888" | I would argue that we need ~ 24 hours to poke at any released upgrade tool before determining whether it's testable
|| [[#t16:17:43|16:17]]
|- id="t16:17:47"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: error handling is largely complete during configuration, but we haven't done much for errors that occur during actual install
|| [[#t16:17:47|16:17]]
|- id="t16:18:01"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | tflink, atleast 24 hours
|| [[#t16:18:01|16:18]]
|- id="t16:18:17"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: well the criterion covered partitioning specifically, so if we're handling errors during custom part that's probably okayish.
|| [[#t16:18:17|16:18]]
|- id="t16:18:44"
! style="background-color: #488888" | tflink
| style="color: #488888" | Viking-Ice: to determine whether it's testable or not? a week would be awesome but I'm not sure how practical any of that is
|| [[#t16:18:44|16:18]]
|- id="t16:18:50"
| colspan="2" | * wwoods is around
|| [[#t16:18:50|16:18]]
|- id="t16:18:56"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | dlehman: would you say that right now the partitioning code broadly covers the criteria we agreed earlier? i don't think 'autopart to empty space' was working in 18.10
|| [[#t16:18:56|16:18]]
|- id="t16:19:08"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | wwoods: what's the current state of fedup?
|| [[#t16:19:08|16:19]]
|- id="t16:19:39"
! style="background-color: #488888" | tflink
| style="color: #488888" | that seems rather unfortunately named, but as long as it works ...
|| [[#t16:19:39|16:19]]
|- id="t16:19:40"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | it's a work in progress. it'll be testable soon.
|| [[#t16:19:40|16:19]]
|- id="t16:19:50"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: i suspect humour
|| [[#t16:19:50|16:19]]
|- id="t16:19:57"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | wwoods: can you put a date on 'soon'?
|| [[#t16:19:57|16:19]]
|- id="t16:19:59"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | it's short for "Fedora Upgrader", obviously
|| [[#t16:19:59|16:19]]
|- id="t16:20:02"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | adamw: no.
|| [[#t16:20:02|16:20]]
|- id="t16:20:16"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | or: "before the freeze"
|| [[#t16:20:16|16:20]]
|- id="t16:20:16"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: yes, the criteria are largely covered as of now.
|| [[#t16:20:16|16:20]]
|- id="t16:20:26"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: as do I, but the meaning of "fed up" has other connotations which don't inspire confidence
|| [[#t16:20:26|16:20]]
|- id="t16:20:27"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | that kinda answers that
|| [[#t16:20:27|16:20]]
|- id="t16:20:59"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | we delay the freeze
|| [[#t16:20:59|16:20]]
|- id="t16:21:41"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | okay so here's more info.
|| [[#t16:21:41|16:21]]
|- id="t16:22:17"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | the CLI frontend is basically done, at least for a beta of a 1.0 release
|| [[#t16:22:17|16:22]]
|- id="t16:22:23"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | the GUI is coming along
|| [[#t16:22:23|16:22]]
|- id="t16:22:56"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | the actual upgrade part needs to be tested a bit to figure out whether we can reliably run the upgrade from system-update.target
|| [[#t16:22:56|16:22]]
|- id="t16:23:18"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | otherwise we'll run it from an external system image like anaconda used to
|| [[#t16:23:18|16:23]]
|- id="t16:24:09"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | I've been talking to mizmo a bit about a plymouth progress screen for the upgrade
|| [[#t16:24:09|16:24]]
|- id="t16:24:29"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | should have something testable.. sometime before the freeze, which I understand to be 10/10
|| [[#t16:24:29|16:24]]
|- id="t16:25:03"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | okay
|| [[#t16:25:03|16:25]]
|- id="t16:25:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info wwoods says fedup should be testable before freeze
|| [[#t16:25:16|16:25]]
|- id="t16:25:16"
! style="background-color: #488888" | tflink
| style="color: #488888" | is the decision to delay freeze being made @ FESCo on wednesday, or just discussed?
|| [[#t16:25:16|16:25]]
|- id="t16:25:20"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | wwoods: it's 10/9 not 10/10.
|| [[#t16:25:20|16:25]]
|- id="t16:25:25"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: not sure
|| [[#t16:25:25|16:25]]
|- id="t16:25:36"
! style="background-color: #539e9e" | wwoods
| style="color: #539e9e" | ah, yep. that's what I have on my calendar.
|| [[#t16:25:36|16:25]]
|- id="t16:25:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #info dlehman says current partitioning code covers the criteria as accepted earlier in the meeting
|| [[#t16:25:46|16:25]]
|- id="t16:26:04"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | so...i'd say we think the current state of things isn't freeze-able
|| [[#t16:26:04|16:26]]
|- id="t16:26:18"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | but if fedup is indeed testable by 10/9 we'd say that is freeze-able
|| [[#t16:26:18|16:26]]
|- id="t16:26:19"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: agreed
|| [[#t16:26:19|16:26]]
|- id="t16:26:21"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | right?
|| [[#t16:26:21|16:26]]
|- id="t16:26:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | anyone have any other areas they're worried about for beta freeze, any other requirements i missed?
|| [[#t16:26:46|16:26]]
|- id="t16:26:53"
! style="background-color: #488888" | tflink
| style="color: #488888" | PXE
|| [[#t16:26:53|16:26]]
|- id="t16:27:27"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | that can mean alot of things are you refering to kickstart installs ?
|| [[#t16:27:27|16:27]]
|- id="t16:27:30"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | oh, that's beta isn't it, what's the status of that?
|| [[#t16:27:30|16:27]]
|- id="t16:27:33"
! style="background-color: #97974f" | dlehman
| style="color: #97974f" | adamw: device encryption is still in development
|| [[#t16:27:33|16:27]]
|- id="t16:27:47"
! style="background-color: #488888" | tflink
| style="color: #488888" | adamw: not sure, haven't gotten around to trying it yet
|| [[#t16:27:47|16:27]]
|- id="t16:27:52"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: general topic, is anyone aware of any other major features of anaconda that would be required to be in place by the beta criteria but aren't yet written
|| [[#t16:27:52|16:27]]
|- id="t16:28:13"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | Viking-Ice: we're talking major features that aren't done yet, like the upgrade code, not just beta blocker bugs - it's fine for blockers to exist at freeze time, but we want the code to be at least _written_
|| [[#t16:28:13|16:28]]
|- id="t16:28:13"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | adamw, tflink mentioned PXE
|| [[#t16:28:13|16:28]]
|- id="t16:28:15"
! style="background-color: #488888" | tflink
| style="color: #488888" | how are we defining testable for upgrade - something that compiles and starts to run?
|| [[#t16:28:15|16:28]]
|- id="t16:28:16"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | yeah
|| [[#t16:28:16|16:28]]
|- id="t16:28:30"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink: my wibbly concept is 'the code is there'
|| [[#t16:28:30|16:28]]
|- id="t16:29:04"
! style="background-color: #818144" | kparal
| style="color: #818144" | PXE with http repo works
|| [[#t16:29:04|16:29]]
|- id="t16:29:16"
! style="background-color: #818144" | kparal
| style="color: #818144" | I couldn't test nfs repo yet
|| [[#t16:29:16|16:29]]
|- id="t16:29:29"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | that sounds freezeable to me
|| [[#t16:29:29|16:29]]
|- id="t16:29:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | (for pxe)
|| [[#t16:29:32|16:29]]
|- id="t16:29:35"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | yup
|| [[#t16:29:35|16:29]]
|- id="t16:29:52"
! style="background-color: #488888" | tflink
| style="color: #488888" | did nfs work for alpha?
|| [[#t16:29:52|16:29]]
|- id="t16:29:56"
! style="background-color: #818144" | kparal
| style="color: #818144" | no
|| [[#t16:29:56|16:29]]
|- id="t16:30:24"
! style="background-color: #818144" | kparal
| style="color: #818144" | there is a bug somewhere around I intend to verify
|| [[#t16:30:24|16:30]]
|- id="t16:30:25"
! style="background-color: #488888" | tflink
| style="color: #488888" | that would be another area of concern unless someone else has tried it
|| [[#t16:30:25|16:30]]
|- id="t16:30:36"
! style="background-color: #488888" | tflink
| style="color: #488888" | OK, it sounds addressed, at least
|| [[#t16:30:36|16:30]]
|- id="t16:30:37"
! style="background-color: #818144" | kparal
| style="color: #818144" | but I was sick for the last few days so I didn't get to it
|| [[#t16:30:37|16:30]]
|- id="t16:31:27"
! style="background-color: #488888" | tflink
| style="color: #488888" | serial console?
|| [[#t16:31:27|16:31]]
|- id="t16:31:45"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | i think that's in
|| [[#t16:31:45|16:31]]
|- id="t16:31:54"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ok so how about this
|| [[#t16:31:54|16:31]]
|- id="t16:32:46"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | propose #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space
|| [[#t16:32:46|16:32]]
|- id="t16:33:39"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ack
|| [[#t16:33:39|16:33]]
|- id="t16:33:49"
! style="background-color: #818144" | kparal
| style="color: #818144" | sounds good
|| [[#t16:33:49|16:33]]
|- id="t16:33:50"
! style="background-color: #488888" | tflink
| style="color: #488888" | that works
|| [[#t16:33:50|16:33]]
|- id="t16:36:24"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space
|| [[#t16:36:24|16:36]]
|- id="t16:36:27"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | ok, i have to run right now
|| [[#t16:36:27|16:36]]
|- id="t16:36:32"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | tflink/kparal, can you take over?
|| [[#t16:36:32|16:36]]
|- id="t16:36:40"
! style="background-color: #407a40" | adamw
| style="color: #407a40" | either wind things up or do a blocker review, whatever people feel like
|| [[#t16:36:40|16:36]]
|- id="t16:37:06"
! style="background-color: #488888" | tflink
| style="color: #488888" | yeah, can do
|| [[#t16:37:06|16:37]]
|- id="t16:37:36"
! style="background-color: #818144" | kparal
| style="color: #818144" | I would prefer leaving the blocker review to wednesday
|| [[#t16:37:36|16:37]]
|- id="t16:37:43"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | yup
|| [[#t16:37:43|16:37]]
|- id="t16:37:47"
! style="background-color: #488888" | tflink
| style="color: #488888" | we're already at 1.5 hours, do we really want to do a blocker review?
|| [[#t16:37:47|16:37]]
|- id="t16:37:52"
! style="background-color: #488888" | tflink
| style="color: #488888" | sounds like not so much :)
|| [[#t16:37:52|16:37]]
|- id="t16:37:56"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | ;)
|| [[#t16:37:56|16:37]]
|- id="t16:38:11"
! style="background-color: #488888" | tflink
| style="color: #488888" | but reviewing blocker bugs is _so_ much fun ...
|| [[#t16:38:11|16:38]]
|- id="t16:38:28"
! style="background-color: #488888" | tflink
| style="color: #488888" | if there are no objections, we can move on to open floor
|| [[#t16:38:28|16:38]]
|- id="t16:38:53"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | let's move to open floor
|| [[#t16:38:53|16:38]]
|- id="t16:39:04"
! style="background-color: #488888" | tflink
| style="color: #488888" | #topic Open Floor
|| [[#t16:39:04|16:39]]
|- id="t16:39:15"
| colspan="2" | * kparal moves to the dance floor
|| [[#t16:39:15|16:39]]
|- id="t16:39:34"
| colspan="2" | * Viking-Ice points out that nobody dances on monday's
|| [[#t16:39:34|16:39]]
|- id="t16:39:35"
! style="background-color: #488888" | tflink
| style="color: #488888" | Anything else before we finish up?
|| [[#t16:39:35|16:39]]
|- id="t16:40:01"
! style="background-color: #488888" | tflink
| style="color: #488888" | sounds like someone has a case of the "mondays"
|| [[#t16:40:01|16:40]]
|- id="t16:41:18"
| colspan="2" | * tflink will hopefully be sending out a testing request for the devel version of the blocker tracking app this week
|| [[#t16:41:18|16:41]]
|- id="t16:41:33"
! style="background-color: #854685" | Viking-Ice
| style="color: #854685" | do the countdown
|| [[#t16:41:33|16:41]]
|- id="t16:41:54"
! style="background-color: #488888" | tflink
| style="color: #488888" | if there's nothing else - I'm setting the fuse for [0,5] minutes
|| [[#t16:41:54|16:41]]
|- id="t16:44:07"
! style="background-color: #488888" | tflink
| style="color: #488888" | Thanks for coming everyone!
|| [[#t16:44:07|16:44]]
|- id="t16:44:10"
! style="background-color: #488888" | tflink
| style="color: #488888" | #endmeeting
|| [[#t16:44:10|16:44]]
|}
Generated by irclog2html.py 2.10.0 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!

Latest revision as of 00:50, 2 October 2012

Attendees

  • adamw (203)
  • tflink (76)
  • Viking-Ice (58)
  • dlehman (23)
  • nirik (22)
  • kparal (22)
  • wwoods (13)
  • akshayvyas (8)
  • zodbot (4)
  • jskladan (2)
  • jreznik (2)
  • Martix (1)
  • mkrizek (1)
  • jwb (1)
  • pschindl (1)
  • viking-ice (0)

Agenda

  • Previous meeting follow-up
  • Release criteria
  • Fedora 18 Beta status / mini blocker review
  • Open floor

Previous meeting follow-up

  • adamw to refine alpha partitioning criterion - this was done and would be discussed later in the meeting
  • adamw to draft new partitioning criterion for Beta once we know what will be in anaconda - this was done and would be discussed later in the meeting
  • adamw to consider revisions to 'kickstart delivery method' criterion - not yet done
  • tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down - not yet done, tim was waiting for the criteria proposals before sending it out

Release criteria

Partitioning

  • Pre-meeting proposals were on the mailing list
  • The proposed Alpha criteria were approved without modification
  • The proposed Beta criteria were approved with minor modifications to make the intent clearer and add a requirement that custom partitioning be able to destroy partitions
  • Possible further criteria were discussed, including one covering the re-use of an existing /home partition, but it was agreed to propose this on the mailing list for further revision

Upgrade

  • Pre-meeting proposals were on the mailing list
  • The proposed criteria were approved, but with the agreement that the use of the word 'or' is ambiguous and should be improved to clarify the meaning
  • To avoid confusion it was agreed that the intent of the criteria is that all three cases for upgrading - minimal package set, GNOME package set, and KDE package set - must work, not any one of the three

Fedora 18 Beta status / mini blocker review

Freeze readiness

  • FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta, which was planned for 2012-10-09
  • The code for the new upgrade tool was available, but it has not had any official release and we did not believe it was yet in a testable state
  • The partitioning code in the latest available anaconda release at time of meeting did not yet support non-destructive automatic partitioning into free space
  • wwoods affirmed that the new upgrade tool would be testable by the freeze deadline
  • dlehman affirmed that the partitioning code would meet the Beta requirements by the freeze deadline
  • We agreed that the state of Fedora 18 as of time of meeting was not good enough to freeze for Beta, but if the upgrade tool was testable and the partitioning code met the Beta requirements by the freeze date, then freezing would be acceptable
  • We agreed to pass this evaluation on to the FESCo ticket

Mini blocker review

  • This was skipped as the meeting had already taken nearly two hours

Open floor

N/A

Action items

  • adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta

IRC Log

adamw #startmeeting Fedora QA Meeting 15:01
zodbot Meeting started Mon Oct 1 15:01:22 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01
adamw #meetingname fedora-qa 15:01
zodbot The meeting name has been set to 'fedora-qa' 15:01
adamw #topic roll call 15:01
adamw morning folks! who's around for the qa meeting? 15:01
* pschindl is here 15:01
* mkrizek is here 15:01
* jskladan yay for meeting time (before party time) 15:01
* tflink is here 15:01
* nirik is lurking, ping if I can help with anything. 15:01
* kparal hails to the king 15:01
* akshayvyas is here 15:01
* Viking-Ice here 15:02
adamw #agreed all qa work to be done by nirik 15:02
adamw nirik: ping ^^^^ 15:02
kparal ack 15:02
Viking-Ice ack 15:02
tflink ack 15:02
adamw :P 15:02
nirik :) 15:02
nirik I'll get right on it. 15:02
jskladan patch: all work to be done by nirik 15:02
kparal let's be realistic 15:02
kparal all qa work is enough for one man 15:03
Viking-Ice only dwalsh can pull that off 15:03
akshayvyas and that man is ?? 15:03
adamw james bond? 15:03
akshayvyas :) 15:03
adamw okey dokey 15:05
tflink bond is good at breaking stuff, I suppose but I think I'd rather have Q working on that :) 15:05
adamw #topic Previous meeting follow-up 15:05
adamw #info "adamw to refine alpha partitioning criterion" and "adamw to draft new partitioning criterion for Beta once we know what will be in anaconda" - the proposal's on the list, we'll come to it later 15:06
adamw #info "adamw to consider revisions to 'kickstart delivery method' criterion" - didn't get to that one yet, sorry 15:06
adamw tflink: "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - anything from that? 15:06
* jreznik is here, sorry for being a little bit late 15:07
tflink nothing yet, no. I was waiting for the partitioning criteria 15:07
tflink I have a draft email that I'm planning to send out later today 15:07
* jwb is here for kernel stuffs 15:08
adamw #info "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - tflink was waiting for the revised partitioning criteria before doing this, so will happen soon 15:08
adamw hi jwb 15:08
Viking-Ice I think we are missing one or more hd criteria for the storage spoke but other then that I just think we should be more or less on par what other OS are doing 15:09
adamw just a sec, let me topic up 15:09
adamw #topic Release criteria: partitioning criteria proposal 15:10
adamw so, for anyone who missed it, I posted a rough proposal for partitioning criteria to the list last night: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html 15:10
adamw #info adamw proposed revised partition criteria for F18+ to the list: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html 15:10
adamw discuss away! 15:10
adamw Viking-Ice: 'one or more hd criteria for the storage spoke' - what do you mean exactly? 15:11
tflink do we care about reuse of encrypted partitions? 15:11
tflink ie reusing LUKS setup if /home is encrypted 15:11
kparal ugh, I didn't get to that discussion today 15:11
* kparal reading it 15:11
adamw tflink: I think yeah we should cover that 'upgrade' scenario 15:13
Viking-Ice adamw, if you have one or more hd detected and install on to 15:13
kparal that means fully custom partitioning should be just in Final, right? 15:13
adamw i did miss that one out 15:13
Viking-Ice mena too 15:13
Viking-Ice mean mean frack! 15:13
kparal I have one concern about that - it wouldn't be tested as well (as if we required it in Beta) 15:13
adamw dlehman: the (rough) criteria proposal for partitioning is at https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html , if you didn't catch it yet 15:14
tflink true but I think that reusing LUKS setup falls pretty well into the realm of custom partitioning 15:14
adamw kparal: the beta criteria i proposed require some specific abilities for the custom part code 15:14
adamw the second criterion is all stuff you can only do in custom part, in newUI 15:14
kparal adamw: oh, I have skipped one paragraph. now I see it 15:14
Viking-Ice for those that have not read it yet http://blog.linuxgrrl.com/2012/09/25/anaconda-bootloader-reusing-home-assigning-partitions-to-disks/ 15:15
adamw and i'd agree with tflink that we should add 're-use existing /home' to that 15:15
Viking-Ice yeah re-use should be added to the criteria as well 15:15
dlehman existing LUKS is absolutely custom. always has been. 15:15
adamw dlehman: that's fine 15:16
tflink yeah, it kind of branched into two discussions - reusing existing home and reusing existing encrypted home 15:16
adamw tflink: re-use existing /home is also custom partitioning. 15:16
Viking-Ice I added a comment there on the blog post what probably is the expected expectation in that regard 15:16
adamw well, now i think about it 15:17
Viking-Ice which criteria could be built upon 15:17
tflink adamw: yeah, but I thought that we were talking about adding that particular use case to what is needed for beta 15:17
adamw if you have to use custom partitioning for something, then effectively, pre-f18, it was only required at final 15:17
adamw yeah 15:17
adamw so if we add anything that required custom partitioning in oldUI to the beta criteria, we're setting the bar higher than previously 15:17
tflink adamw: good point, final is fine 15:18
Viking-Ice I tend to agree with kparal that custom partitioning fits in beta criteria ( alpha not required, beta required to work ) 15:18
adamw so we might want to re-word the final criterion a bit to be less vague, rather than adding to beta 15:18
adamw Viking-Ice: well i was going for a middle way, in which custom partitioning is required to not be hideously broken at beta, but not required to work entirely 15:19
* tflink smells another epicly long release criterion :) 15:19
adamw heh :) 15:19
Viking-Ice custom partitioning in anaconda has never work entirely at least not up to the extend kernel supports so I'm not following what you are getting at there? 15:20
* kparal is fine with almost-but-not-fully covered custom partitioning in Beta 15:20
adamw Viking-Ice: well 'completely' would be 'passes the Final criterion' 15:20
Viking-Ice just create what 15 partitions on a single drive and see how anaconda handles that ( insane but you know supported by the kernel ) 15:21
adamw oh, here's a modification... 15:21
adamw change "Creating and assigning" to "Creating, destroying and assigning" 15:21
adamw or 'removing', whatever 15:21
adamw i'm looking at making sure the pre-18 *alpha* requirements are covered 15:22
akshayvyas adamw: +1 15:22
adamw one of which was the 'existing Linux partition' autopart method, which wiped existing linux installs but left windows alone 15:22
adamw Viking-Ice: well that's not really anything new, since we're not proposing to change the final criterion...can we focus on the beta? 15:23
adamw Viking-Ice: is it that you want further requirements for custom part at beta beyond what's already proposed? 15:23
dlehman does anaconda actually fail when disks contain the maximum number of partitions? if so, it's just because that never happens in real life (or in bugzilla AFAICT) 15:23
Viking-Ice in alpha only the autopart should be required to work and quite frankly I dont think we should be having multiboot support in our criteria et all unless the other OS support that as well 15:24
adamw Viking-Ice: well that's what the currently proposed alpha criterion does, so no problem there 15:25
adamw and we only have multiboot in final, and we're not talking about final right now... 15:25
dlehman adamw: autopart-in-freespace. I'm not sure how binding this is. Do we need to specify things like "assuming the disk contains a valid disklabel and is bootable, &c" ? 15:25
adamw dlehman: eh, we don't _need_ to really, we can always clarify that at blocker review time, but maybe we could 15:25
adamw let me see how verbose it looks 15:26
adamw dlehman: actually, i think the current wording works fine 15:26
dlehman you guys have been good in the past at calling out dealbreaker variations so I'm willing to trust you based on that 15:26
Viking-Ice adamw, are we just talking about fixing the criteria for beta or fixing the criteria in general? 15:27
adamw Viking-Ice: well right now i'd like to focus on the specific partitioning criteria proposal on the list 15:27
adamw Viking-Ice: there's a topic later for 'general criteria revision ideas' 15:27
dlehman adamw: in that free space case, are we supposed to not install any bootloader? 15:27
dlehman no, I don't know what we used to do 15:28
adamw dlehman: yeah, i was just pondering that when i went quiet there 15:28
adamw dlehman: we used to install a bootloader, i would expect we still will. so the wording might need a bit of a change. 15:28
adamw although, strictly, the MBR isn't part of the 'existing partition table' or 'existing data', really. 'existing user data'? 15:28
dlehman maybe add something about offering to access preexisting encrypted devices? 15:28
adamw help? :) 15:29
dlehman (in custom) 15:29
dlehman existing partitions or filesystems? 15:29
adamw dlehman: well, access is needed only for re-use, right>? 15:29
Martix hi 15:29
dlehman right 15:29
adamw the one case we're specifically concerned about there is re-using an existing /home 15:29
adamw but then we also considered that, per the pre-f18 criteria, that wasn't actually required to work until final 15:29
adamw so if we add that to beta, we're _tightening_ the requirements 15:30
adamw i mean we can do that, but it's a consideration 15:30
dlehman I see 15:30
adamw it's a bit tricky trying to strike a balance of exactly what we think really needs to be working in custom part by beta, given that custom part is obviously more important in newui since autopart is more restricted. 15:30
adamw Viking-Ice: so do you have anything you'd like to add to/remove from the beta criteria proposed? 15:31
adamw dlehman: for the 'empty space' one..."The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"? 15:33
Viking-Ice adamw, I actually would like to move the whole custom partitioning from final to beta 15:33
dlehman adamw: sounds okay to me 15:33
tflink adamw: what about /boot partitions? 15:34
adamw tflink: in relation to what? 15:34
dlehman Viking-Ice: if you're going to do that you'll have to do so at the beginning of a cycle 15:34
adamw if you mean the criterion me and dlehman are discussing, irrelevant, 'autopart into empty space' does not re-use any existing partitions, it'd create its own /boot 15:34
Viking-Ice dlehman, yup 15:34
tflink 'leaving the pre-existing partitions and data untouched' - does that apply to any existing /boot partitions 15:34
adamw tflink: per the above, yeah. 15:34
adamw an install re-using an existing /boot would have to be done through custom part. 15:35
Viking-Ice dlehman, so it would not be subjected for F18 but F19 if we change it 15:35
adamw Viking-Ice: ok, so if you're not proposing that for f18, can we table it for now? since it's important that we nail down the f18 requirements 15:35
Viking-Ice adamw, ok 15:35
adamw the reason i want to get this done now, btw, is that it feeds into the 'should we freeze beta' discussion 15:35
adamw whatever we decide the beta criteria need to be, that's what needs to be basically implemented before we freeze for beta 15:36
adamw ditto for upgrade 15:36
adamw so here's what we have so far, modified from the list proposal: 15:36
adamw 1. "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched" 15:37
adamw 2. "The installer's custom partitioning mode must be capable of the following:" 15:37
adamw 2a. "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types" 15:37
adamw 2b. "Creating encrypted partitions" 15:37
adamw 2c. "Rejecting obviously invalid operations without crashing" 15:37
adamw any specific proposed revisions to those, to be enforced for f18 beta? 15:37
adamw does anyone reckon we should include a requirement for re-using an existing /home at beta rather than final? 15:38
tflink we're leaving LVM for ginal? 15:38
tflink final 15:38
adamw tflink: i left LVM on the basis that anaconda team say it's really going to be de-emphasized for newui. 15:38
adamw LVM is The Past, btr is The Future. 15:38
adamw but we could change that if we think it's still important enough 15:38
adamw dlehman: wdyt? 15:38
adamw tflink: LVM was kinda in the previous criteria because it was the Fedora default and we were very big on it for a while. 15:39
tflink it's somewhat of a departure from previous requirements but yeah, btr seems like it will replace LVM at some point 15:39
nirik lvm still needed for encrypted tho right? 15:39
adamw if fedora isn't so 'ra ra LVM' as it was, which kinda seems to be the case, it's probably not as important 15:39
tflink adamw: I'd say that reuse of /home is OK for final 15:39
adamw nirik: no? you can encrypt a regular partition. 15:39
dlehman nirik: no 15:39
Viking-Ice "re-use" and "upgrade" criteria belong in the same milestone ( beta from my pov ) 15:40
tflink encryption + LVM == pain (from my experience) 15:40
nirik ok, cool. I thought it was tied to lvm at one point. 15:40
tflink well, encrypting the VG == pain, anyways 15:40
akshayvyas so btrfs is default now 15:40
adamw akshaysth: not right now no, still ext4 15:41
tflink for F18? I thought that was still pending 15:41
adamw but i think the plan is for btrfs as default in future 15:41
Viking-Ice F20+ 15:41
dlehman adamw: explicit inclusion of lvm in addition to plain partitions? 15:41
adamw Viking-Ice: i can see that, yeah, since the main use case for re-use is basically upgrading. 15:42
Viking-Ice yup 15:42
adamw dlehman: well that's what we were just discussing - i left it out on the basis that you folks thought LVM isn't as important as it used to be, i remember us talking about that in #anaconda, but we can certainly add it back if you think we still should for now. 15:42
akshayvyas adamw: pointed the wrong one :) 15:42
akshayvyas akshaysth is someone else 15:43
adamw Viking-Ice: the counter-point to that is that we require upgrade to be in place for beta because upgrade is complex and so we want it in beta so people can test it and report bugs and they can get fixed for final 15:43
adamw Viking-Ice: re-use of /home isn't at all as complex an operation as an upgrade installation is 15:43
adamw it doesn't really need months of testing, it just...either works or doesn't work 15:43
tflink adamw: reuse of non-encrypted home, sure 15:44
adamw true, encrypted home is a bit messier 15:44
Viking-Ice depends on how you look at it, that feature from my pov of view should be handled automatically from the storage spoke ( as opposed forcing the user having to go to custom partitioning and do all the necessary steps there ) 15:44
adamw anyhow, we're now debating *strengthening* the proposed criteria, i don't hear anyone saying we should weaken them 15:44
adamw so should we approve what's proposed now as a baseline at least? we can always tighten things from there 15:44
dlehman adamw: I don't really know, to be honest. partitions are a must. lvm, md, btrfs, all debatable. 15:44
* tflink wonders about leaving md and btrfs for final, though 15:45
adamw Viking-Ice: i don't think that's gonna happen for 18 at least, aiui. re-use is something you'll definitely have to do through custom part (like it was in oldui) 15:45
tflink seems like it could cause a lot of problems, no matter when it lands, I suppose 15:45
adamw tflink: we don't have them in the current beta proposal, dlehman was floating them, 15:45
dlehman Viking-Ice: that amounts to a sizable RFE, so not going to add that for F18. 15:45
tflink I'm not against the idea of requiring md and btrfs/lvm for beta as long as we're being reasonable 15:46
adamw ok, so how bout this: we vote on approving the new criteria proposed above, then i'll send out a new mail proposing some kind of limited re-use of /home requirement for beta, to be discussed separately 15:47
Viking-Ice adamw, then it falls just under the general custom partitioning criteria 15:47
adamw Viking-Ice: it'd certainly be covered by the existing final criterion yes 15:47
tflink adamw: works for me 15:47
adamw Viking-Ice: but we could also add it to beta if we want it to work by beta 15:47
Viking-Ice ack 15:47
Viking-Ice to the limited beta criteria proposal surrounding re-use of /home 15:47
* tflink is +1 on the partitioning criteria as proposed above 15:47
dlehman adamw: the biggest problems with btrfs and lvm are they are so overfull with options that requiring support for any existing config is quite a demand. creating what is supported in the installer, OTOH, it not. 15:48
adamw propose #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately 15:48
Viking-Ice dlack 15:48
tflink ack 15:49
Viking-Ice mean ack 15:49
akshayvyas ack 15:49
adamw dlehman: right, hence the proposal for a 'limited' re-use criterion - i was thinking exactly along the lines of *not* needing any kind of massively complex encrypted-btrfs-on-encrypted-lv /home partition scenario to wrok :) 15:49
kparal ack 15:49
tflink dlehman: do you think it would be reasonable to require creating a new layout with btrfs/lvm/md @ beta would be reasonable, leaving reuse for final? 15:49
adamw #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately 15:50
tflink that gets hard to write out in any reasonable way, though 15:50
Viking-Ice dlehman, any particular reason we should be single out re-use as a special feature until you guys have though things through on how you would like to have it in the end ( which means we could just scrap any kind of criteria around it for F18 ) 15:50
adamw tflink: not really, i could add it to the wording of 2a) easily enough 15:50
dlehman tflink: probably, yes. I won't sign anything saying as much until I have time to reflect on it further, though. 15:50
adamw :P 15:50
adamw it's not just whether it's reasonable, though, it's the basic question of 'does all that really need to work in a Fedora beta'. 15:51
adamw anyhoo, we have a baseline now at least 15:51
adamw and this is taking a while 15:51
adamw shall we move on to the upgrade criterion? which with any luck should be easier 15:51
tflink dlehman: ok, I wasn't looking for anything definitive today - mostly wondering whether the idea was unreasonable 15:52
adamw #action adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta 15:52
tflink adamw: yeah, that proposal has been pretty quiet as of late 15:52
adamw #info viking-ice suggests that for f19+, much more custom partitioning functionality should be required at Beta 15:53
* adamw trying to capture the major thoughts from the partitioning discussion for the record, any others? 15:53
tflink adamw: the idea of requiring new lvm/md/btrfs for beta while leaving the reuse/modification of existing layouts for final? 15:54
* jreznik is ok for now, a little bit harder to follow you here... 15:54
adamw #info there is some support for requiring creation of LVs/advanced btrfs partitions/RAID to work at beta 15:54
adamw tflink: did you want a definite #action or is it OK to leave it vague? 15:54
Viking-Ice I prefer vague 15:55
tflink adamw: I'm fine with it being vague as long as we don't forget entirely 15:55
adamw tflink: well it'll be in the meeting summary. only #actions are 'guaranteed' to get picked up on later though, in the sense that they get covered at the next meeting. 15:55
adamw #chair tflink kparal viking-ice 15:55
zodbot Current chairs: adamw kparal tflink viking-ice 15:55
adamw now you can #action yourself if you like :) 15:56
adamw #topic Release criteria: upgrade criteria proposal 15:56
adamw #info tflink quoted the current proposals at https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html 15:56
adamw basically, for beta it must be possible to upgrade with any 'officially recommended upgrade mechanism', at final they all have to work. 15:57
adamw as things stand i think we will only have one 'officially recommended upgrade mechanism' for f18 anyway, so it's kinda moot, but hey 15:57
adamw anyone want to propose changes to it that haven't already been discussed? 15:57
* adamw +1 to the proposal 15:58
tflink +1 15:58
Viking-Ice we kinda have to decide how far back we expect official upgrade is supposed to work 15:58
adamw Viking-Ice: as these are applied to f18, as I understand the current plan, it pretty much means 'upgrade has to work at beta'. 15:59
adamw which is what we had previously. 15:59
adamw i think we have pretty solid agreement that that's what we want, a lot of the discussion was just covering loopholes and making the wording apply when it's not anaconda doing the upgrading. 15:59
Viking-Ice I'm ack on the proposal but we still need to add how far back release upgrades are supposed to be supported 16:00
adamw oh right 16:00
adamw iswym 16:00
Viking-Ice mean do we support upgrading from F1 to F18 beta? 16:00
tflink I think that the current wording of "previous stable release" is pretty clear - Fn-1 to Fn only 16:00
adamw with the current proposal it's the same as the previous one: we only support F(n-1) 16:00
adamw as far as f18 is concerned it probably makes sense not to change that now 16:00
adamw if we want to support n-2 we should probably make that f19 stuff 16:01
tflink agreed 16:01
adamw but you're right we still need to determine that 16:01
tflink that seems a bit much to change right before freeze 16:01
adamw and make other documentation consistent with whatever we ultimately agree development/qa will care about 16:01
adamw #info viking-ice points out that the question of the status of upgrades from older Fedora releases has still not been entirely settled 16:02
nirik I could have sworn we had a packager guideline about caring about N-2... but nothing saying what upgrades were "supported" 16:02
nirik perhaps we could have N-1 as blocker, and N-2 as NTH? :) (but perhaps thats f19 as you said) 16:03
adamw nirik: as far as QA is concerned we've had the criterion written as 'the previous release' ever since f12, and we've only enforced that (we have a test for n-2 but it's optional and rarely actually performed) 16:03
nirik yeah 16:03
Viking-Ice it makes sense we support N-2 as in F16 being supported to be upgraded to F18 16:03
nirik Viking-Ice: yeah, I agree with that too. 16:03
tflink the counter to that is stuff like usrmove and if it would be a problem to support multiple upgrade vectors 16:04
adamw Viking-Ice: i'm kinda torn - i think it's probably correct that we should change and support N-2, but i'm not sure we should do it for F18 since it's pretty late now 16:04
Viking-Ice adamw, our lazyness not testing it is no excuse ;) 16:04
adamw Viking-Ice: i'd definitely be on board with supporting F17-F19 and onwards, but i'm a bit unsure about F16-F18 16:04
adamw anyone else? 16:05
Viking-Ice could be a final upgrade criteria 16:05
tflink either way, I'm against requiring n-2 upgrades for F18 - it's too late in the release cycle to be making changes like that 16:05
adamw Viking-Ice: ironic, usually you're the one saying we should only change for future cycles and i'm the one saying we should change now :) 16:05
kparal I don't think upgrade from n-2 is a good idea at all, so I wouldn't definitely change that for F18 16:05
adamw anyway, again we can at least accept that we want *at least* the current proposal 16:06
adamw which is the important thing for the 'should we freeze' discussion 16:06
adamw so... 16:06
Viking-Ice let's clarify that then for F19 16:06
Viking-Ice ack on the current proposal 16:06
* tflink is still +1 for current proposals 16:06
adamw propose #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted 16:06
tflink ack 16:06
Viking-Ice ack 16:06
kparal ack 16:07
* nirik re-reads 16:07
adamw #info there is some support for extending the criteria to support upgrades from the two previous stable releases, we will discuss that separately 16:07
nirik so is the 'or' in final intended? 16:07
tflink wait, does that link point to the actual criterion proposal? 16:07
tflink it contains them, nvm 16:07
adamw nirik: what 'or'? 16:07
adamw oh 16:07
adamw hm. 16:08
nirik minimal or blocking desktop 16:08
adamw it's meant to mean 'all of these', not 'any of these' 16:08
adamw 'or' is a bit ambiguous 16:08
nirik shouldn't that be 'minimal and all blocking desktops' ? 16:08
adamw the problem with 'and' is it makes it sound like 'you have to be able to upgrade a system which has both GNOME and KDE installed' 16:08
adamw making the wording completely clear seems a bit tricky, shall we agree with the intent and try to refine the wording later? 16:09
* tflink wonders if we should have some definition of 'release blocking package sets' elsewhere in the criteria 16:09
adamw tflink: we define 'release-blocking desktops' in the preamble 16:09
adamw oh, iswym, that might work 16:10
Viking-Ice we should not be supporting multiple *de installs et al from my pov 16:10
adamw nirik: is that OK with you or do you want to nail down the wording now? 16:10
adamw Viking-Ice: yeah, that's not the intent here, which is why i don't just want to replace 'or' with 'and 16:10
nirik sure. I think we all agree on intent. 16:10
Viking-Ice yup 16:10
* kparal back in a few minutes 16:10
nirik the set of: minimal and (seperately) each release blocking desktop 16:10
nirik or something 16:10
adamw 'yeah, something like that, but more elegant :) 16:11
nirik right 16:11
adamw #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted (but we note that the use of 'or' is slightly ambiguous and can be improved) 16:11
Viking-Ice ack 16:11
nirik ack 16:11
adamw #agreed the intent of the proposed criteria is that you must be able to upgrade all three of: a) a minimal install, b) a GNOME install, c) a KDE install 16:11
adamw (just so we have that clearly noted) 16:11
adamw alrighty! 16:12
tflink adamw: how can you have minimal, gnome and kde installed at the same time? 16:12
tflink :-D 16:12
* tflink ducks 16:12
* adamw throws things at tflink 16:12
adamw d'oh, you're way ahead of me 16:12
adamw ok, this is really dragging on, so let's move straight to the pre-freeze discussion 16:12
adamw #topic Fedora 18 Beta status: freeze-worthy? 16:12
Viking-Ice nope 16:13
Viking-Ice we need to delay the freeze until the upgrade tool is in place 16:13
tflink there's a bunch of stuff that I haven't even tried to poke at yet 16:13
adamw #info FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta 16:13
adamw #info the idea is that we freeze only once the code required by the Beta criteria is broadly in place 16:14
tflink but I would agree that without a testable upgrade tool, there's little point in entering freeze 16:14
adamw yeah, i agree with that too 16:14
nirik freeze is scheduled to start 2012-10-09 currently. 16:14
* nirik nods. 16:14
adamw it's noted on the FESCo ticket that the upgrade tool code technically exists: https://github.com/wgwoods/fedup 16:14
adamw but afaik there has been no release yet, and i don't know if it's in working state. 16:14
adamw dlehman: do you have any info there? 16:15
Viking-Ice wwoods, around? 16:15
dlehman no idea about the upgrade tool 16:15
adamw nirik: fesco is looking at it this week right, though? since next week's meeting will be 10-10 16:16
nirik I think so... let me look 16:16
adamw dlehman: the other thing that we just agreed, that i'm not sure of the status of: error handling 16:16
nirik yes, it should be this week. 16:16
adamw #info the new upgrade tool code is at https://github.com/wgwoods/fedup , but as far as we are aware there has been no release and no indication that it is yet in testable state 16:17
adamw dlehman: is error handling in yet? i.e. will anaconda still just crash if you do something wrong in custom part? 16:17
tflink I would argue that we need ~ 24 hours to poke at any released upgrade tool before determining whether it's testable 16:17
dlehman adamw: error handling is largely complete during configuration, but we haven't done much for errors that occur during actual install 16:17
Viking-Ice tflink, atleast 24 hours 16:18
adamw dlehman: well the criterion covered partitioning specifically, so if we're handling errors during custom part that's probably okayish. 16:18
tflink Viking-Ice: to determine whether it's testable or not? a week would be awesome but I'm not sure how practical any of that is 16:18
* wwoods is around 16:18
adamw dlehman: would you say that right now the partitioning code broadly covers the criteria we agreed earlier? i don't think 'autopart to empty space' was working in 18.10 16:18
adamw wwoods: what's the current state of fedup? 16:19
tflink that seems rather unfortunately named, but as long as it works ... 16:19
wwoods it's a work in progress. it'll be testable soon. 16:19
adamw tflink: i suspect humour 16:19
adamw wwoods: can you put a date on 'soon'? 16:19
wwoods it's short for "Fedora Upgrader", obviously 16:19
wwoods adamw: no. 16:20
wwoods or: "before the freeze" 16:20
dlehman adamw: yes, the criteria are largely covered as of now. 16:20
tflink adamw: as do I, but the meaning of "fed up" has other connotations which don't inspire confidence 16:20
Viking-Ice that kinda answers that 16:20
Viking-Ice we delay the freeze 16:20
wwoods okay so here's more info. 16:21
wwoods the CLI frontend is basically done, at least for a beta of a 1.0 release 16:22
wwoods the GUI is coming along 16:22
wwoods the actual upgrade part needs to be tested a bit to figure out whether we can reliably run the upgrade from system-update.target 16:22
wwoods otherwise we'll run it from an external system image like anaconda used to 16:23
wwoods I've been talking to mizmo a bit about a plymouth progress screen for the upgrade 16:24
wwoods should have something testable.. sometime before the freeze, which I understand to be 10/10 16:24
adamw okay 16:25
adamw #info wwoods says fedup should be testable before freeze 16:25
tflink is the decision to delay freeze being made @ FESCo on wednesday, or just discussed? 16:25
adamw wwoods: it's 10/9 not 10/10. 16:25
adamw tflink: not sure 16:25
wwoods ah, yep. that's what I have on my calendar. 16:25
adamw #info dlehman says current partitioning code covers the criteria as accepted earlier in the meeting 16:25
adamw so...i'd say we think the current state of things isn't freeze-able 16:26
adamw but if fedup is indeed testable by 10/9 we'd say that is freeze-able 16:26
tflink adamw: agreed 16:26
adamw right? 16:26
adamw anyone have any other areas they're worried about for beta freeze, any other requirements i missed? 16:26
tflink PXE 16:26
Viking-Ice that can mean alot of things are you refering to kickstart installs ? 16:27
adamw oh, that's beta isn't it, what's the status of that? 16:27
dlehman adamw: device encryption is still in development 16:27
tflink adamw: not sure, haven't gotten around to trying it yet 16:27
adamw Viking-Ice: general topic, is anyone aware of any other major features of anaconda that would be required to be in place by the beta criteria but aren't yet written 16:27
adamw Viking-Ice: we're talking major features that aren't done yet, like the upgrade code, not just beta blocker bugs - it's fine for blockers to exist at freeze time, but we want the code to be at least _written_ 16:28
Viking-Ice adamw, tflink mentioned PXE 16:28
tflink how are we defining testable for upgrade - something that compiles and starts to run? 16:28
adamw yeah 16:28
adamw tflink: my wibbly concept is 'the code is there' 16:28
kparal PXE with http repo works 16:29
kparal I couldn't test nfs repo yet 16:29
adamw that sounds freezeable to me 16:29
adamw (for pxe) 16:29
Viking-Ice yup 16:29
tflink did nfs work for alpha? 16:29
kparal no 16:29
kparal there is a bug somewhere around I intend to verify 16:30
tflink that would be another area of concern unless someone else has tried it 16:30
tflink OK, it sounds addressed, at least 16:30
kparal but I was sick for the last few days so I didn't get to it 16:30
tflink serial console? 16:31
adamw i think that's in 16:31
adamw ok so how about this 16:31
adamw propose #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space 16:32
Viking-Ice ack 16:33
kparal sounds good 16:33
tflink that works 16:33
adamw #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space 16:36
adamw ok, i have to run right now 16:36
adamw tflink/kparal, can you take over? 16:36
adamw either wind things up or do a blocker review, whatever people feel like 16:36
tflink yeah, can do 16:37
kparal I would prefer leaving the blocker review to wednesday 16:37
Viking-Ice yup 16:37
tflink we're already at 1.5 hours, do we really want to do a blocker review? 16:37
tflink sounds like not so much :) 16:37
Viking-Ice ;) 16:37
tflink but reviewing blocker bugs is _so_ much fun ... 16:38
tflink if there are no objections, we can move on to open floor 16:38
Viking-Ice let's move to open floor 16:38
tflink #topic Open Floor 16:39
* kparal moves to the dance floor 16:39
* Viking-Ice points out that nobody dances on monday's 16:39
tflink Anything else before we finish up? 16:39
tflink sounds like someone has a case of the "mondays" 16:40
* tflink will hopefully be sending out a testing request for the devel version of the blocker tracking app this week 16:41
Viking-Ice do the countdown 16:41
tflink if there's nothing else - I'm setting the fuse for [0,5] minutes 16:41
tflink Thanks for coming everyone! 16:44
tflink #endmeeting 16:44

Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!