19:00:07 <mattdm> #startmeeting Council (2018-08-22)
19:00:07 <zodbot> Meeting started Wed Aug 22 19:00:07 2018 UTC.
19:00:07 <zodbot> This meeting is logged and archived in a public location.
19:00:07 <zodbot> The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:07 <zodbot> The meeting name has been set to 'council_(2018-08-22)'
19:00:10 <mattdm> #meetingname council
19:00:10 <zodbot> The meeting name has been set to 'council'
19:00:12 <mattdm> #chair mattdm jkurik jwb langdon robyduck bexelbie dperpeet Amita dgilmore pbrobinson tyll bcotton
19:00:12 <zodbot> Current chairs: Amita bcotton bexelbie dgilmore dperpeet jkurik jwb langdon mattdm pbrobinson robyduck tyll
19:00:14 <mattdm> #topic Introductions, Welcomes
19:00:18 <mattdm> hi dennis!
19:00:35 <mattdm> bexelbie noted that he might be about five minutes late
19:00:51 <tyll> .hello till
19:00:52 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
19:01:27 * dgilmore is in another meeting today for a bit also
19:01:47 <bcotton> .hello2
19:01:48 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
19:01:54 <mattdm> hi bcotton and tyll
19:02:24 <mattdm> #topic What to do about Spins
19:02:29 <mattdm> #info not for the first time :)
19:02:39 <mattdm> #link https://pagure.io/Fedora-Council/tickets/issue/215
19:02:49 <mattdm> We can wait for more people to really get started.
19:02:56 <mattdm> I figured I'd just throw that out there :)
19:04:13 <bexelbie> .hello bex
19:04:14 <zodbot> bexelbie: bex 'Brian (bex) Exelbierd' <bexelbie@redhat.com>
19:04:16 <bcotton> is this where a make a subtle remark about how only 3 people ever filled out the "when should we meet" poll? :-)
19:04:46 <mattdm> bcotton: there was something confusing about timezones. I was gonna do it when I got back to US/Eastern
19:04:51 <dgilmore> bcotton: did I fail at that?
19:05:12 <bcotton> mattdm: timezones are hard :-(
19:05:22 <dgilmore> timezones suck
19:05:32 <mattdm> honestly also I can't cope with that UI
19:05:32 <bcotton> dgilmore: yes, only pbrobinson, bexelbie, and me are the good children
19:05:48 <mattdm> oh, calandar view is much better
19:05:56 <mattdm> sheesh, silly default.
19:06:01 <dgilmore> bcotton: I do not remeber seeing it :(
19:06:06 <bcotton> it is pretty terrible. i was going to use whenisgood, which i like a lot better, but it died
19:06:07 * dgilmore hangs head in shame
19:06:48 <mattdm> #topic all council members present take 3 minutes and fill that out please?
19:06:55 <bcotton> #link https://doodle.com/poll/8vmfe4kebfuqqbiz
19:08:18 <tyll> Is this a slot for all meetings or just the Objectives meeting?
19:08:27 <dgilmore> all
19:08:34 <dgilmore> I assume
19:08:38 <mattdm> ideally all
19:08:42 <bcotton> tyll: it's for all. started out as objectives, but expanded to all
19:08:46 <bcotton> let me see if i can edit the title
19:09:27 <bcotton> done!
19:09:34 <mattdm> I'm kinda thimnking "back to where we had it at 9am US/Eastern" is lookin' good
19:09:40 <bcotton> and the best part is it didn't reset everyone's answers
19:10:06 <mattdm> yay for small wins :)
19:10:13 <mattdm> okay, let's head back to the topic at hand....
19:10:18 <mattdm> #topic What to do about Spins
19:10:26 <mattdm> #link https://pagure.io/Fedora-Council/tickets/issue/215
19:10:59 <jwb> in a work meeting.  apologies
19:11:04 <dgilmore> the biggset issue with spins is really making sure they work and are maintained
19:11:22 <mattdm> Here's my basic framing: spins (and "labs") are *very* aligned with the mission. What can we do to enable and encourage them?
19:11:30 <langdon> .hello2
19:11:31 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
19:11:51 <langdon> sorry was getting a haircut.. It was kinda epic
19:12:01 <tyll> We need someone to work on them, therefore I still like the dead-person switch idea
19:12:04 <mattdm> jwb, langdon fill out the doodle for better meeting time
19:12:16 <langdon> k
19:12:19 <mattdm> tyll: me too, but maybe with a more positive name :)
19:12:44 <mattdm> I'd also like to float the idea that there should be some way to indicate "expected support commitment".
19:12:52 <jwb> mattdm, i will try.  "better time" is like a utopian concept
19:12:54 <tyll> We can also call it a "it's all good" switch
19:13:00 <mattdm> tyll: yes :)
19:13:02 <tyll> or "Everything is fine" ;-)
19:13:06 <mattdm> better
19:13:14 <tyll> actuall it was "This is fine"
19:13:36 <mattdm> Right now, if I want to make a fedora spin to, say, be used in my classroom this year
19:13:51 <mattdm> I set the expectation that I will maintain it forever
19:14:15 <mattdm> Maybe we could provide a way for spins to be *expected* to last for one release, unless renewed?
19:14:58 <tyll> I see how it pleases spin maintainers but it will also disappoint users who will miss a spin
19:14:58 <bexelbie> mattdm, perhaps we should set a policy that puts that in place and then make people specify otherwise
19:15:16 <bexelbie> i.e. you produce it lives for the life of that release, but won't be built for the next one without some human-based indication
19:15:19 <mattdm> tyll: yeah, but right now, they're disappointed _and just don't know in advance_
19:15:21 <tyll> And losing something that was there before is usually considered to be worse than not getting something that wasn't there
19:15:36 <bcotton> could we promote the bigger spins to editions (e.g. KDE) and drop the idea of spins?
19:15:38 <tyll> mattdm: true as well
19:15:53 <mattdm> bcotton: we _could_ do anything :)
19:15:58 <mattdm> bcotton: but, in seriousness...
19:16:14 <mattdm> the distinction with the editions is supposed to be that they're filling key target audience roles
19:16:20 <mattdm> rather than being technology showcases
19:16:28 <mattdm> that's why we don't have "Fedora GNOME Edition"
19:16:43 <dgilmore> notifications for when things do not work and automated workflows for testing would help a lot
19:16:56 <dgilmore> we just do not have either today
19:17:04 <mattdm> Personally, I think it'd be ideal if there were a Fedora GNOME Spin _in addition to_ Workstation
19:17:12 <bexelbie> dgilmore, isn't CI supposed to give us that? /me looks at dperpeet
19:17:20 <dgilmore> bexelbie: no
19:17:20 <bcotton> audience roles applies to a lot of our existing spins, so i'm not sure that's a meaningful distinction in practice
19:17:42 <dgilmore> bexelbie: CI has only be talked about for packages, not artifacts
19:17:44 <bexelbie> bcotton, I think editions are our signature items, it may be arbitrary, but it works from a marketing perspective
19:17:57 <bexelbie> perhaps consistently maintained and targetted spins should get bigger billing, but not be editions
19:18:04 <bexelbie> dgilmore, oh
19:18:16 <mattdm> bcotton: So -- and this definitely can be revisited, because I don't think it's clear to most people --
19:18:29 <mattdm> the current naming has different desktops as "spins"
19:18:48 <mattdm> and non-edition audience-focused deliverables as "editions"
19:18:51 <mattdm> uh,
19:18:53 <mattdm> strike thjat
19:18:57 <mattdm> as "LABS"
19:19:01 <mattdm> see i confused myself.
19:19:05 <dgilmore> desktops are spins, labs build upon spins to offer a targeted workload
19:19:12 <mattdm> dgilmore++
19:19:12 <zodbot> mattdm: Karma for ausil changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:19:16 <mattdm> see
19:19:19 <mattdm> https://spins.fedoraproject.org/\
19:19:26 <bexelbie> dgilmore, labs can also be built on editions, right ?
19:19:27 <mattdm> vs https://labs.fedoraproject.org/
19:19:35 <mattdm> bexelbie: yes
19:19:53 <dgilmore> bexelbie: yes, many are built upon workstation
19:20:00 <mattdm> A lot of labs are really just curated software sets. Like the Design Suite.
19:20:06 <bcotton> okay, so some of the issue then is that we're being inconsistent with our terminology (e.g. https://fedoraproject.org/wiki/Releases/29/Spins )
19:20:10 <dgilmore> python classroom
19:20:16 <mattdm> bcotton: probably :(
19:20:27 <bexelbie> bcotton, I was going to bring htat up :D
19:20:48 <mattdm> I'd like to find an alternative to the labs name
19:20:53 <bexelbie> one idea re: package load spins would be to see if we could make workstation's installer offer those loads instead ...
19:21:01 <bexelbie> s/spins/labs/
19:21:03 <bexelbie> ugh
19:21:14 <bexelbie> and yes, the labs name is pretty bad, but I haven't got a better one to offer :(
19:21:37 <bexelbie> It'd also be neat if labs could explore settings changes where it made sense ... I am not sure how hard htat is today
19:21:56 <mattdm> bexelbie: easier with the "label are variants" change
19:22:04 <mattdm> which I will work on after this meeting :)
19:22:33 <mattdm> I don't think workstation options is sufficient
19:22:47 <mattdm> look atthe python classroom lab's artifacts:
19:22:49 <mattdm> 1. live image
19:22:54 <dgilmore> bcotton: some of those labeled as spins are labs and ship as labs
19:22:54 <mattdm> 2. docker image
19:22:56 <bcotton> i think the naming, confusing as it may be, isn't really the issue (or maybe it's tangentially the issue). this came up because we got some coverage of the games spin which has basically been on autopilot for several releases
19:22:57 <bcotton> so whatever we call these, spins/labs/etc, we need to figure out a good way to decide when it should be dropped from our list
19:22:57 <mattdm> 3. vagrant
19:23:28 <mattdm> bcotton: okay, fair. So I think there are three things, really
19:23:30 <dgilmore> 4. Arm disk image
19:23:39 <mattdm> #info Three seaparate questions
19:23:56 <mattdm> #info How to make sure spins stay current or are dropped?
19:24:24 <bexelbie> mattdm, good point re: variants - and it was a bit of a push to help with build - I  actually prefer separate artifacts for the user experience
19:24:33 <mattdm> #info How to better present software-set deliverables like python classroom lab or design suite
19:24:54 <mattdm> #info How can we set people who want to do these things free so a thousand solutions bloom?
19:25:22 <mattdm> so maybe deal with those one at a time?
19:25:31 <tyll> Can we do something like COPR but for Spins/Labs?
19:25:39 <mattdm> tyll: that's for #3 :)
19:26:14 <mattdm> for the first, I think there's basically two viable paths:
19:26:28 <mattdm> A) Add a  "This is fine!" action / switch to the schedule
19:26:49 <mattdm> B) Add a retirement date to each deliverable, which can be extended
19:27:04 <bexelbie> I think we should do a hybrid
19:27:05 <bexelbie> :D
19:27:09 <mattdm> B is more drastic but I think opens up more options.
19:27:13 <mattdm> bexelbie: okay, let's hear it.
19:27:29 <bexelbie> each release the spin gets "re-authorized" which is a super lightweight "yep, we're doing it again" no votes, or anything
19:27:43 <bexelbie> each actual release, the spin has to choose wehter they are doing the full 13 months or something less
19:27:54 <bexelbie> that way we have an expiration date and an affirmation on the new one
19:28:04 <bexelbie> so a spin, could for example, only ever be available on the most current release
19:28:18 <bexelbie> or a spin my just do odd or even releases
19:28:21 <tyll> The spins do not do any special updates during the Fedora support timeframe AFAIK
19:28:35 <smooge> no they don't. they are install only tools
19:28:39 <bexelbie> I think they should be capable of being ... respun :D
19:28:46 <bexelbie> or at least being updated
19:28:48 <smooge> not by releng
19:28:50 <bexelbie> like a traditional install
19:29:33 <bexelbie> I don't think we should add to releng workload to fix them if they break, that is hte SIGs job - but I think releng should be capable of building bits -- we may need to wait for tooling to catch up ... but building should be possible
19:29:35 <mattdm> smooge: that gets into the "can something copr-like do it?"
19:29:39 <bexelbie> it makes me nervous when we have stuff not built in our infra
19:29:56 <smooge> bexelbie, that would be all the respins
19:30:12 <dgilmore> bexelbie: Fedora does not do anything with spins or labs post release
19:30:41 <dgilmore> tehy are built for rawhide daily, and as part of the compose, but once a release is GA there is no updates
19:31:00 <dgilmore> there is a unoffical group who do roll in updates and do respins
19:31:18 <bexelbie> my daydream is that spins/labs should get the same level of rebuild as editoins, but in an automated way where breakage is a sig problem, not a releng problem
19:31:29 <bexelbie> that makes it easier for us to be a platform for those groups to serve their communities
19:31:36 <bexelbie> that may not be practical today
19:31:43 <bcotton> i think this is veering into question #3
19:31:53 <mattdm> bexelbie: well, right now, *editions* don't get rebuilds either.
19:32:00 <mattdm> but yeah, question #3 :)
19:32:02 * bexelbie still likes his hybrid for #1
19:32:08 <bexelbie> then they are getting the same service :D
19:32:12 <bcotton> bexelbie: is this a fair summary of your suggestion? "spin owners must send a keepalive to <TBD: spins wrangler> by <TBD: schedule milestone> or they will be dropped from the release"
19:32:15 <bexelbie> so I am happy, and now I want moar service :D
19:32:17 <smooge> so I have several points: 1. Most spins seem to downloaded in a 'large' amount compared to other downloads. 2. spins take up a lot of space which can't be hardlinked to save space on mirrors 3. we don't have a way to really see who is installing them/using them other than basic mirror stats
19:32:49 <mattdm> smooge: can you put numbers on point #1?
19:32:52 <bexelbie> bcotton, yes, and they are automatically doing maintenance for the life of their underlying release unless they explicitly say otherwisd
19:32:57 <bexelbie> otherwise
19:33:22 <mattdm> bexelbie: can you put your proposal in the form of a #proposal?
19:33:26 <bexelbie> isn't #3 also true of editions (per smooge's numbering)
19:33:54 <bcotton> bexelbie: the "maintenace for the life of the release" doesn't seem to be relevant based on the current state of how we produce them
19:34:04 <dgilmore> bexelbie: editions do not get any extra rebuilding
19:34:32 <dgilmore> bexelbie: they are treated equally on the build side, where things lack for spins and labs is the testing and validation side
19:34:35 <bexelbie> #proposal Spins and Labs must send a request for being built in the next release (from a human) to the program manager as part of the release calendar or they will be dropped for that release.  Spins and Labs are automatically assumed to be maintained for the full 13 months of an underlying release unless they want a different end date (expiration date).  Spins and labs are allowed to skip releases and to do expire upon new releases.
19:34:51 <bexelbie> bcotton, it is from the perspective of package updates
19:35:29 <dgilmore> bexelbie: what does "Spins and Labs are automatically assumed to be maintained" mean
19:35:33 <bexelbie> bcotton, if a spin needs a package the SIG should work to make sure it stays current - think of packages hwere the packagers don't choose to build for the still current older release for unknown reasons where there is no upgrade in play
19:35:48 <bexelbie> dgilmore, maintained == get package udpates
19:36:14 <dgilmore> bexelbie: that will only happen if someone chooses to install that spin
19:36:18 <mattdm> what does "and do expire" mean?
19:36:34 <mattdm> I don't think we want to set the expectation that a KDE user cannot upgrade
19:36:47 <bcotton> so spin owners are requred to take over packages if the package owner doesn't want to update them on a release branch?
19:36:49 <bexelbie> dgilmore, if someone builds a spin/lab that uses package Foo version X ... then that package needs to be updated regularly for the life of that spin/lab (on that base version of Fedora)
19:37:02 <dgilmore> bexelbie: spins and labs today are a release artifact. they are a static snapshot of a set of packages as they were on release day
19:37:06 <bexelbie> mattdm, upgrade is different from continue to use on base build
19:37:17 <bexelbie> I don't have to move from F28 to F29 on the day F29 drops - I can stay on F29
19:37:22 <bexelbie> stay on F28
19:37:43 <bexelbie> I should be able to get package updates on my F28 system until it goes EOL
19:37:59 <bexelbie> if something goes from foo-1.0.1 to foo-1.0.2 my understanding is that I should get that update
19:38:04 <dgilmore> bexelbie: are you saying that we should produce updated livecds?
19:38:07 <bexelbie> I'd like spin SIGs to think about this for their spin/labs
19:38:21 <bexelbie> dgilmore, perhaps - but that doesn't feel like part of htis conversation
19:38:56 <dgilmore> bexelbie: I guess we have our wires crossed on what a spin/lab is
19:38:56 <mattdm> bexelbie: I'm sorry -- I really have no idea where you're going with this
19:39:24 <bexelbie> am I correct in understanding hta F28 will be receiving package updates after the release of F29?
19:39:31 <mattdm> bexelbie: yes.....
19:39:39 <mattdm> for about 7 months.
19:39:48 <bexelbie> if I have a spin/lab installed based on F28 shouldn't it also get updates after F29 is released?
19:39:54 <tyll> bexelbie: there are different opinions about how many package updates should be pushed to a stable release
19:39:56 <mattdm> yes.....
19:40:12 <mattdm> right, with that caveat. but we can expect security updates for example
19:40:18 <bexelbie> if my spin/lab has a non-traditionally installed package installed by default because of the spin, I think the SIG should make sure that keeps getting updates too
19:40:41 <tyll> what is a non-tradiotionally installed package?
19:40:49 <bexelbie> tyll, inkscape
19:40:53 <bexelbie> as an example for the design lab
19:41:18 <tyll> what is different there, is it a flatpak?
19:41:21 <bexelbie> we want to allow the spin to provide continuity for the users or set the expectation that they should upgrade when the new release happens by having their eol sooner
19:41:28 <bexelbie> tyll, then ledger-cli
19:41:29 <mattdm> bexelbie: okay, so.... you're way into question #4, I think :-/
19:41:35 * bexelbie doesn't want this to be a packaging conversation
19:41:52 * tyll did not know that they ship other content that installed RPMs
19:41:55 <bexelbie> I got asked what my proposal meant :D
19:41:56 <bcotton> so bexelbie let's say i owned the design lab and you owned the inkscape package. if you didn't want ot update the inkscape package on N-1, i should be required to force the upgrade?
19:41:58 <tyll> *than
19:42:08 * tyll is wondering what this other content is
19:42:35 <bexelbie> bcotton, it certainly sets up an interesting conversation that needs to happen.  My understanding is that packages are not owned, per se but tend to have a maintainer who watches them
19:42:40 <bexelbie> but we have other ways to get updates made
19:42:46 <bcotton> tyll: i think bexelbie means "package not traditionally installed by default"?
19:43:07 <bexelbie> bcotton, tyll yes - i.e. I make an accoutning spin that includes ledger-cli which is not installed by workstation by default
19:43:53 <tyll> bexelbie: ah, I see ... however the expectation for any Fedora RPM packaged package is that it will get updates, also when it is not installed by default regardless whether it is in a spin
19:43:56 <bcotton> bexelbie: nothing prevents me as the spin owner from asking you as the package maintainer to update mid-release. but i don't think we need to make it an affirmative responsibility of the spin owner to create potential conflict with package maintainers
19:44:34 <bexelbie> bcotton, then what does it mean to have a spin/lab if you don't care about watching it once it is released?
19:45:00 <bexelbie> bcotton, someone needs to make the request when a decision is made to not push an update to a stable release that normally would be
19:45:06 * bexelbie is not talking about major version jumps, etc.
19:45:07 <mattdm> bexelbie: I'm not sure putting *more* requirements on spin maintainers is the right direction
19:45:09 <smooge> mattdm I can give numbers
19:45:14 <mattdm> smooge: thanks :)
19:45:16 <smooge> sorry was working them out
19:45:20 <mattdm> smooge++
19:45:20 <smooge> mattdm, for #1. 72% of requests to download.fedoraproejct are workstation, 10% were server and 4% were KDE and it goes down from there. The first lab which shows up in requests accounts for 0.3% of requests
19:45:22 <tyll> bexelbie: I guess the bigger danger is for updates in Fedora to break something that was supposed to work in the spin
19:45:44 <bexelbie> mattdm, i'd be interested to know how the few spin/lab folks who answered an email feel .. as they are the people who would feel it .. the rest seem abandoned
19:45:45 <dgilmore> bexelbie: say you download the iso for design suite, you burn a bunch of copies and boot the computers from them to teach inkscape for instance
19:46:01 <dgilmore> bexelbie: you actually never get a single updated package
19:46:04 <bcotton> bexelbie: it means you curate the package set that gets installed in the deliverable. whether a packager gets overriden on a decision not to push a particular update is independent of spins
19:46:26 <bexelbie> dgilmore, yes, by choice - but that doesn't mean that is the only way we allow spins/labs to be used - they are allowed on live systems
19:46:49 <mattdm> bexelbie: I think you're saying that you'd like to open the possibilties for spins to have different *package* lifecycle expectations than the base os
19:47:00 <bcotton> maybe we should drop spins in favor of modules :-)
19:47:00 <bexelbie> bcotton, I am not giving spins veto - but I am saying they need to be voiced .. they need to be serving a community,
19:47:13 <mattdm> this is probably something we *could* do with modularity, assuming that multiple streams exist
19:47:17 <bexelbie> mattdm, not really, they can't change fedora ... but they can say "only latest release"
19:47:28 <bexelbie> that's about all I would offer ignoring modularity
19:47:48 <bexelbie> with modularity - they can use anything that is in lifecycle
19:47:59 <dgilmore> I think in many ways we are all in violent agreement. they are a complex problem with many use cases.
19:48:00 <langdon> modules don't really produce complete artifacts yet.. we would like to.. but it needs work..
19:48:09 <bexelbie> if a spin wants a lifecycle extended in package or modularity, ideally they become a packager :D
19:48:40 <mattdm> bexelbie: ohhhh, so going back to your proposal, is it really "spins are assumed to be maintained for the full 13 months of the fedora base cycle, but may opt for one release (7 months)?"
19:48:43 <dgilmore> in the cases of the security lab or likely the python classroom, many times updates are not possible
19:49:09 <bexelbie> mattdm, yep, and I could see someone even saying "X date" but that would require conversation (where X is < 13 months out)
19:49:11 <dgilmore> if a system is installed from a spin/lab it absoloutly must recieve updates
19:49:25 <mattdm> bexelbie: I'm actually more concerned with > 13 months.
19:49:38 <bexelbie> dgilmore, I want the updates available -- the user chooses whether to receive them
19:49:42 <bexelbie> mattdm, that isn't allowed, imho
19:49:52 <bexelbie> you have to upgrade to hte newer release
19:49:54 <bexelbie> just like normal
19:49:57 <dgilmore> bexelbie: they already are available
19:50:04 <bexelbie> if we want to do that mattdm we have a bigger fish to fry :D
19:50:24 <mattdm> bexelbie: I think we're talking about different things.
19:50:29 <bexelbie> dgilmore, there are packages I regularly run into that are not updated for all stable releases .. I'd like spins to think about this
19:50:39 <bexelbie> they may do nothing - but I want to set an expectation and model it
19:51:03 <bexelbie> mattdm, modularity is an exception to that .. but the other parts might expire ... aiui
19:51:04 <dgilmore> bexelbie: some will argue that is by design
19:51:19 <bcotton> i feel like the maintenance requirement is assuming that spin owners are package maintainers, and for the relevant packages, which may not be the case (particularly if we want to do more about question #3)
19:51:24 <dgilmore> bexelbie: but it is not anything specific to spins
19:51:28 <mattdm> I am saying "The thing called Matthew's Awesome Fedora Mix is something I'm committed to, at least as I'm in my current job, which I expect to be several years"
19:51:30 <bexelbie> dgilmore, I haven't heard that argument in a way I understand/agree with - but it isn't germane here, aiui
19:51:41 <mattdm> that's separate from setting a lifecycle for any particular release of Matthew's Awesome Fedora Mix
19:51:49 <dgilmore> bexelbie: if we update all packages to the latest stable we should go to a rolling release
19:51:57 <bexelbie> mattdm, ahh - I think you re-up with every release of Fedora
19:52:03 * dgilmore notes he is actually in favour of a rolling release model
19:52:13 <bexelbie> you don't set the life cycle of the whole spin upfront - you set expectations as you go
19:52:14 <tyll> bexelbie: maybe we can make spin maitainers automatically co-maintainers for the packages in their spin as a compromise
19:52:20 <smooge> I am having a hard time understanding what anyone is actually proposing anymore
19:52:23 <mattdm> And likewise, the problem we're trying to solve here (Q1) is to do with long-term maintainership, not worry about individual releases _per se_
19:52:38 <bexelbie> tyll, only if they are already packagers ... I think making spins/labs shouldn't require bieng a packager
19:52:44 <bexelbie> I want them to start conversations
19:52:50 <bexelbie> I want them looking at their success, etc.
19:52:53 <bexelbie> those are goals
19:52:56 <bexelbie> some may choose not to do it
19:53:03 <bexelbie> that's ok, but can lead to the abandoned spins issue
19:53:12 <smooge> as far as I know you have to be a packager to sponsor a spin
19:53:24 <dgilmore> the main issue with spins is that they sometimes frequently fail to build, sometimes missing the release for "Reasons" and there is currently no one making sure they build and are tested
19:53:30 <bexelbie> mattdm, then I didn't expcitly state someting in my proposal i thought was on the table already
19:53:39 <dgilmore> they fall outside of QA as they are not release blocking
19:53:49 <bexelbie> in my opinions spins/labs are not given a lifetime as a "project" but only on  a per release basis
19:53:59 <bcotton> the other question is if we set a rule that spin owners have to maintain their spins, 1. how is that defined (i.e. who and how decides a spin owner is violating that rule), and 2 what do we do about it? if the answer is basically "spin owners shouldn't do that" then i'd argue we shouldn't include the requirement
19:54:05 <bexelbie> just as we haven't promised to delivery workstation or server for the next N years ... we dopn't promise that with spins/labs
19:54:10 <mattdm> dgilmore: yeah, and then if they fail to build for no fault of the spins maintainer and then get dropped from the release, that sucks
19:54:52 <dgilmore> mattdm: yep
19:55:20 <mattdm> bexelbie: in other words, your "hybrid" is exactly "B) Add a retirement date to each deliverable"
19:55:33 <bexelbie> but with no assumed rebuild in the next release
19:55:33 <mattdm> and not really "hybrid"
19:55:37 <bexelbie> so it needs the other half too
19:55:40 <mattdm> yes, that's EXACTLY option B
19:55:50 <bexelbie> mattdm, that is not how I read an understand option B
19:56:00 <mattdm> because if that's the assumption, there's no need for option A
19:56:02 <bexelbie> so perhaps you need more words in B
19:56:27 <langdon> bcotton: sorry sidebar.. on the doodle.. these are days of the week not specific dates, right?
19:56:30 <bexelbie> that mattdm's awesome spin built on F27 expires in 13 months gives me no informatoin about whether there will be on built on F28
19:56:31 <mattdm> Okay, so, given the time, I will have to put those more words in the ticket
19:56:46 <bcotton> langdon: yes
19:56:50 <dgilmore> to detangle spins from the release is going to take significant resources and time in redoing tooling.  That will need to be scoped and funded
19:56:59 <dgilmore> It is work that I think is valuable
19:57:24 <dgilmore> its not work that the team working on those tools can just magically do
19:57:26 <mattdm> okay, so..... do we want to try to answer the first question without bigger picture things as bexelbie is proposing?
19:57:39 <mattdm> or should we try to come up with something more comprehensive?
19:57:51 <bcotton> i like the first sentence of bexelbie's proposal
19:57:55 <bcotton> "Spins and Labs must send a request for being built in the next release (from a human) to the program manager as part of the release calendar or they will be dropped for that release"
19:58:06 <mattdm> I think it'd certainly be interesting to talk to the copr devs to see if making spins is something they might be interested in adding
19:58:17 <bcotton> then we can let FESCo decide when that deadline should be
19:58:24 <mattdm> okay, two minutes left. does anyone *disagree* with that?
19:58:32 <mattdm> I'm +1 to it
19:59:19 <tyll> +1
19:59:47 <bexelbie> bcotton, +1 to that sentenece with fesco guideline
20:00:20 * stickster shows up for magazine meeting
20:00:43 <mattdm> okay, let's mark *that* as agreed and continue the conversation
20:00:49 <mattdm> and hand the floor over to magazine :)
20:00:52 <mattdm> #endmeeting