16:04:33 <mmaslano> #startmeeting Env and Stacks (2014-03-11)
16:04:33 <zodbot> Meeting started Tue Mar 11 16:04:33 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:04:46 <mmaslano> #meetingname env-and-stacks
16:04:46 <zodbot> The meeting name has been set to 'env-and-stacks'
16:04:52 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
16:04:52 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
16:04:57 <mmaslano> #topic init process
16:05:20 <mmaslano> hi, anybody present?
16:05:44 <drieden> Hi, I'm here
16:05:47 <hhorak> Hi, I'm here
16:05:47 <hhorak> :)
16:07:09 * tjanez is sorry for being late
16:07:20 <mmaslano> no problem, lot of channel changes
16:07:47 <abadger1999> greetings
16:08:22 <drieden> We are on daylight savings time right now too.
16:08:40 <mmaslano> abadger1999: I wanted to verify with you technical proposals dealine
16:08:55 <mmaslano> abadger1999: we have time to work on proposals until April 7th, right?
16:09:25 <abadger1999> mmaslano: So there's two aspects -- (1) get information about proposals that *may* require coordination to fesco by last week.
16:09:43 <mmaslano> abadger1999: we missed that for sure
16:09:48 <abadger1999> mmaslano: (2) finish off those proposals and submit as CHange Requests by April 7th
16:10:01 <mmaslano> abadger1999: we may have change with this one
16:10:07 <mmaslano> chance
16:10:41 <abadger1999> mmaslano: at the fesco meeting from two weeks ago fesco said We don't want to have any brand new requests to change how we make fedora show up on April 7th
16:11:16 * pingou lurking
16:11:29 <abadger1999> So if there's anything more that we want to do for F21 that requires changes to how we make fedora, releng/infrastructure resources to make happen/etc, we need to get them to fesco ASAP
16:11:41 <mmaslano> abadger1999: fine by me. Other proposals can be done later or they don't interfere with "making of Fedora"
16:12:17 <abadger1999> Even if it's just -- "We want to do this for f21 but we are still discussing whether it will need hep from other people"
16:12:56 <tjanez> abadger1999, I would think the Playground repo belongs to the first category, namely a change about how we make Fedora
16:13:04 <abadger1999> tjanez: +1
16:13:10 <tjanez> though, it is not a blocker for F21
16:13:11 <abadger1999> We did submit that, though, didn't we?
16:14:42 <mmaslano> #info April 7th is deadline for Change proposals, no new big changes which means interaction of more projects/people or more releng work can be added
16:14:52 <mmaslano> abadger1999: um not yet
16:15:09 <abadger1999> https://fedorahosted.org/fesco/ticket/1221#comment:28  <= that's what I was remembering... not sure it's the right ticket.
16:15:10 <mmaslano> abadger1999: the proposal is far from ready
16:15:33 <abadger1999> mmaslano: doesn't matter -- what matters is that fesco is aware of it and that it requires coordination.
16:15:36 <mmaslano> abadger1999: that's it
16:16:13 <mmaslano> abadger1999: let's focus on https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
16:16:26 <tjanez> abadger1999, I don't think so (if you mean a FESCo ticket)?
16:16:29 <tjanez> I recall you sent an email that we should open up a FESCo ticket and I'm afraid it hasn't happened before the last week's FESCo meeting
16:16:42 <tjanez> abadger1999, so you think we should file a separate FESCo ticket or is that comment enough?
16:17:16 <abadger1999> tjanez: I'l talk to fesco at this week's meeting and see what we (fesco) need to do to keep track of all these things.
16:17:19 <tjanez> mmaslano, I wanted to break things down into smaller pieces and started new ML threads
16:17:31 <abadger1999> tjanez: I can file a separate fesco ticket based on that comment if needed.
16:17:39 <tjanez> but so far no replies/discussion yet
16:17:41 <mmaslano> abadger1999: thanks
16:17:52 <mmaslano> tjanez: yes, I saw, thanks for them
16:17:53 <tjanez> abadger1999, perfect
16:18:22 <tjanez> Maybe we could use the part of the Governance charter that speaks about if no one objects
16:18:43 <tjanez> in like 3 days then the things are "lazily" accepted
16:19:15 <mmaslano> fine
16:19:22 <abadger1999> tjanez: +1 to your mirroring proposal (ie: will not be mirrored initially)
16:19:43 <abadger1999> tjanez: +1 to your self-hosting proposal
16:20:22 <hhorak> tjanez: +1 for both as well
16:20:25 * tjanez is +1 on his own proposals regarding mirroring and self-hosting
16:20:38 <mmaslano> +1
16:20:53 <mmaslano> tjanez: but as you said we don't need to vote, it was auto-accepted ;-)
16:21:07 <mmaslano> #agreed Playground repo: mirroring - no mirroring at start accepted (+5,-0,0)
16:21:22 <mmaslano> #info Playground repo: mirroring https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-March/000288.html
16:21:32 <tjanez> mmaslano, I hope others also feel that way :-)
16:21:34 * mmaslano was +1 to both proposals
16:21:39 * abadger1999 edits wiki page with both of those decisions
16:21:53 <tjanez> abadger1999, thanks
16:22:29 <tjanez> ok, mirroring and self-hosting were "easy" open questions, let's move on to harder ones
16:22:32 <mmaslano> #agreed Playground repo: self-hosting - Playground must be selfhosted (passed, no-one objected on mailing list)
16:22:53 <mmaslano> #info Playground repo: self-hosting https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-March/000289.html
16:23:14 <mmaslano> tjanez: what would you like to discuss as next question?
16:23:37 <tjanez> mmaslano, I would go from the beginning and leave conflicts discussion until the end
16:23:48 <tjanez> #topic deltarpms for the Playground repo
16:24:36 <tjanez> I'm against deltarpms initially. I recall dgilmore saying at DevConf that they take 80% of the rawhide compose time
16:24:45 <tjanez> Something like they extend it by ~4 hours
16:25:02 <hhorak> I'd say the same, we can start without deltarpms
16:25:37 <tjanez> On the other hand, the generation will be fast initially, when we have a small amount of packages
16:25:42 <mmaslano> sounds fine if not many people are using it. Otherwise we will have non mirrored repos without delta downloaded by thousand people ;-)
16:26:27 <tjanez> mmaslano, do you have a rel-eng contact who we can ask if it sounds reasonable to start with that?
16:26:48 <mmaslano> dgilmore: ^
16:27:13 <tjanez> Also, COPR is not mirrored and does not use deltarpms AFAIK
16:28:11 <abadger1999> dgilmore is on vacation right now... I think until Wed.
16:29:06 <mmaslano> tjanez: as you said it will be few packages
16:32:04 <abadger1999> Proposal: deltarpms are Optional but nice to have.
16:32:11 <mmaslano> abadger1999: +1
16:32:32 <hhorak> +1 I don't think the demand for bits will be constantly big in the first months
16:32:35 <abadger1999> +1
16:32:38 <abadger1999> <nod>
16:32:49 <abadger1999> Fedora itself survived without deltarpms for many releases :-)
16:33:15 <mmaslano> #agreed deltarpms are Optional but nice to have.
16:33:30 <mmaslano> abadger1999: could you also add it on wiki?
16:33:33 <abadger1999> yep
16:34:00 <mmaslano> #topic signing packages for Playground
16:34:14 <mmaslano> #info implemenation of signing will take probably 4 monts
16:35:27 <mmaslano> I believe we should sign packages, but we would have additional repo after 4 months. Is it okay?
16:35:41 <abadger1999> Tough one :-(  This is very important but also takes a lot of effort.
16:36:37 <mmaslano> also I don't think we need to sign all packages, but only those who go into Playground
16:36:41 <hhorak> I'm wondering if there is some another "easy" way how to sign packages, what is so complicated to take 4 months?
16:37:04 <abadger1999> <nod>  I agree with that although I don't know if that makes the work easier.
16:37:07 * tjanez is on a bad 3g connection :-(
16:37:08 <mmaslano> hhorak: I guess msuchy count how much time since now
16:37:30 <mmaslano> because he has already what to do
16:38:24 <hhorak> mmaslano: fair enough, so it could be made faster if we have anybody to implement this, right?
16:39:08 <tjanez> do we want this to be implemented in COPR or separately?
16:39:38 <mmaslano> I thought it must be added into build system
16:39:48 <mmaslano> let's ask msuchy and not waste our time ;-)
16:39:50 <abadger1999> hhorak: also... copr wasn't designed for this (so there's no foundation in copr to start with) and keeping crypto keys safe is always a tricky business.
16:40:21 <mmaslano> #action mmaslano will investigate with msuchy if it can be signed outside of COPR, why it takes 4 months, how to sign only some packages, ....
16:40:33 <tjanez> mmaslano, ok, fine with me
16:40:45 <drieden> sounds good
16:40:48 <hhorak> mmaslano: thanks
16:40:52 <mmaslano> #topic will fedup support upgrades with packages there?
16:40:55 <abadger1999> This might be something to do outside of copr... but we don't have any scripts that handle that either.... rawhide isn't signed, for instance.
16:41:08 <mmaslano> #undo
16:41:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xadb03d0>
16:41:14 <abadger1999> It's fine to move on.
16:41:28 <mmaslano> #topic will fedup support upgrades with packages there?
16:41:50 <tjanez> I would say yes since it works also with 3rd party repositories such as rpmfusion
16:41:57 <tjanez> it is not supported though
16:42:10 <tjanez> so maybe there's a catch with the work "supported"
16:42:11 <tjanez> s/work/word
16:43:24 <abadger1999> <nod>
16:43:24 <mmaslano> I'd say nice to have...
16:44:15 <tjanez> So if the fedup upgrades would be supported we would have to make sure that a package's EVR in Fedora N+1 is always bigger than in Fedora N?
16:44:16 <abadger1999> tjanez: yeah -- if we wanted this to be seamless, we'd also need to make sure builds for the playground repo are targetting branched (ie, currently F21)
16:45:25 <abadger1999> tjanez: correct there too (although, that's something that comes and goes).
16:45:26 <tjanez> abadger1999, but I thought we are targeting each Fedora branch (i.e. 19, 20, 21 when branched and rawhide)?
16:46:12 <mmaslano> it has to magically rebuild for new Fedora or to be inherited with every new release
16:46:39 <abadger1999> tjanez: <nod> -- but we'd have to do more review -- right now copr owners can select which repositories to build for.
16:47:02 <mmaslano> yes, some packages might work only with some versions of software etc.
16:47:06 <abadger1999> tjanez: and when we add new fedora releases, the existing coprs won't automatically start building against those.
16:47:08 <mmaslano> so it's up to maintainers
16:47:47 <abadger1999> yeah
16:47:57 <tjanez> abadger1999, mmaslano, thanks for explaining
16:48:27 <tjanez> well, what happens when a Playground package does not existing in Fedora N+1's repo
16:49:00 <mmaslano> we could set it for automatical inheritance by default and mark the bad ones as dead?
16:49:08 <tjanez> it could remain installed on the system, but it could happen it depends on some library in the main repository which was updated to a new version
16:49:16 <abadger1999> if we wanted seamless updates, we'd have to make sure that the maintainers/someone was making builds for the new releases... otherwise users will have packages that can't be upgraded and may have deps on old versions (so once they go to F-N+1, Playground packages might not work and yum update might have unresolvable deps)
16:49:43 <tjanez> abadger1999, <nod>
16:49:44 <abadger1999> tjanez: Yep, that's exactly the issue.
16:50:16 <tjanez> So, I guess this decision is a policy one
16:51:00 <abadger1999> yeah, it's policy... we can punt on this and say "seamless updates are not yet a goal", for instance.
16:51:20 * tjanez is leaning towards setting a policy so that updates will work
16:51:55 <tjanez> my reasoning from the perspective of the user is to want updates to Fedora N+1 with the Playground repository to work
16:52:23 <tjanez> But I admit it might be technically challenging since we use COPR
16:52:26 <mmaslano> I'm not sure if it's doable
16:52:56 <tjanez> mmaslano, that's what I was afraid of
16:53:13 <hhorak> I'd say we don't have to be more strict than fedora stable is -- when someone bumps release in rawhide and some dependency stays non-rebuilt, users just need to remove the old package manually, correct?
16:53:31 <hhorak> *bumps soname
16:54:13 <abadger1999> hhorak: Sorta -- the answer to your question is yes but the situation is one where we yell at package maintainers.
16:54:31 <tjanez> hhorak, I thought that soname bumps have to be announced and coordinated
16:54:34 <abadger1999> hhorak: which I don't know if we want to do to the maintainers of packages in playground or not.
16:54:36 <tjanez> abadger1999, <nod>
16:56:00 <tjanez> I guess there will be even more problems when a package in the Playground repo depends on a library in the Playground repo and the soname bumping happens there
16:56:21 <abadger1999> yeah.
16:56:50 <abadger1999> by nature, playground can make api/abi changing updates.
16:57:08 <hhorak> tjanez: soname was just an example how to create issue in repository, there are bunch of others that can just happen, even without anyone notices
16:57:23 <tjanez> Also, this hints at another question to solve: Will there be co-maintainers, "proven packagers" in the Playground repo
16:57:39 <hhorak> So maybe we deal with a general question -- "what to do if the repo is broken?"
16:57:41 <tjanez> But let's not derail this too much
16:57:50 <tjanez> I can add the question to open questions
16:58:07 <mmaslano> because we don't have any dist-git (I guess it's still true), I don't see how to add provenpackagers ;-)
16:58:32 <tjanez> hhorak, good question
16:58:50 <abadger1999> tjanez: Yeah, that is an open question
16:59:00 <tjanez> I would be for notifying maintainers/COPR owners like ordinary Fedora packagers are notifies of broken dependencies
16:59:13 <abadger1999> mmaslano: I guess it would be someone who can build a new package for someone else's copr.
16:59:14 <hhorak> my proposal would be either let it broken (if it cause small  problems) or remove the broken package (obsolete it by something as we discussed the last time)
17:00:12 <hhorak> tjanez: right, we should have some sanity checkers
17:00:19 <tjanez> hhorak, can that really be solved by just obsoleting a problematic package?
17:00:47 <hhorak> tjanez: depends how bad it is broken :)
17:01:47 <tjanez> The more I think about not having a broken Playground repo, the more it seems we would have to sanitize the repo on every new package/updated package, but is that doable?
17:02:53 <tjanez> By sanitize I mean automatically check if the Repository (along with the main repositories) is still consistent (i.e. not broken) and reject updates/new packages which cause trouble
17:03:06 <hhorak> tjanez: definitely not completely. We can do our best, but there will still be ways how to break it.
17:03:54 <mmaslano> tjanez: we don't do it not even for Fedora
17:04:09 <abadger1999> probably not.... the main repo isn't currently immune.  There's plans to implement something to help there but that depends on taskotron tests integrating with bodhi.
17:04:16 <abadger1999> and we're not using bodhi here, so...
17:04:16 <hhorak> tjanez: I think we still have to depend on users in the end, that they try to keep their packages stable and working -- but I'm positive about that, in fedora it kinda works ;)
17:04:21 <mmaslano> broken dependencies are often seen in fedora-testing, which should be safer than playground
17:04:30 <tjanez> hhorak, mmaslano agreed. Maybe the need to "do our best" is of greater impact here since we expect more inexperienced packagers to do more mistakes here
17:06:02 <mmaslano> I'm sayin if we are not able to catch it in regular Fedora repositories, how could we catch it in playground
17:06:27 <abadger1999> I wonder if we even have that goal in the playground repo... I mean, people are going to want to use it to introduce newer/older versions of packages.  So that's going to lead to more dep breakage
17:06:35 <tjanez> mmaslano, agreed
17:07:59 <tjanez> So, we will encourage packagers (via documentation) to take care that their packages properly survive Fedora upgrades and that's it
17:08:21 <hhorak> tjanez: sounds fine for me
17:08:26 <tjanez> And also maybe bug them with automatic notifications about broken dependencies, etc.
17:08:41 <abadger1999> Works for me -- we can change policy later if we find it's not a good direction in the future.
17:08:51 <tjanez> And the 'etc.' could be gradually extended when we have more automation in place
17:10:01 <mmaslano> #agreed encourage packagers (via documentation) to take care that their packages properly survive Fedora upgrades
17:10:21 <mmaslano> next one or is there more?
17:11:40 <tjanez> #info we'll also implement a way to automatically notify the package owners about broken dependencies, etc.
17:12:10 <tjanez> mmaslano, let's continue with multilib support
17:12:18 <tflink> I've not been following playground much, but is there a plan for how to check deps in the repo?
17:12:31 <mmaslano> #topic multilib support in Playground
17:12:59 <mmaslano> tflink: no :) I thought we might use some tooling from Fedora QA
17:13:27 <tjanez> tflink, yes, we are hoping to leverage whatever you develop for the main repositories :-)
17:14:17 <tflink> ok, I have some questions about how the playground repo fits in with the other repos but I suspect that there are things I could read instead of asking in the middle of your meeting :)
17:14:20 * tjanez will need to leave in ~5 minutes
17:14:48 <tjanez> tflink, see: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29 for the state of the art
17:14:50 * hhorak too
17:15:15 <abadger1999> Last topic written up as the "Upgrades and broken deps" bullet point here: https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft)#How_the_repository_works
17:15:40 <abadger1999> I think multilib is not going to happen for F21.
17:16:11 <hhorak> abadger1999: that sounds interesting
17:16:16 <mmaslano> abadger1999: me too, it would be hard when some people run builds only for x86
17:16:20 <abadger1999> But it might be something we desire longer term.
17:16:23 <abadger1999> yeah.
17:16:30 <tflink> tjanez: thanks for the link
17:16:49 <tjanez> tflink, you're welcome
17:17:21 <tjanez> abadger1999, nicely written (upgrades and broken deps)
17:17:33 <abadger1999> thanks
17:18:08 <tjanez> I don't have enough knowledge/experience about the multilib stuff, so I'll trust others on this
17:19:53 <abadger1999> Has anyone talked to dgilmore about it?
17:20:34 <hhorak> I'd say if multilib is going to be dropped (timeframe doesn't matter here) from fedora, we don't have to care in playground much.
17:20:56 <abadger1999> Hmm... hhorak have you heard rumblings about that?
17:23:10 <hhorak> abadger1999: no, but now I'm wondering if I understood correctly what you meant by "I think multilib is not going to happen for F21." -- did you mean that fedora will change multilib politics somehow?
17:23:29 <abadger1999> hhorak: Nope -- I meant multilib support in the playground repo.
17:23:49 <abadger1999> sorry for hte confusion.
17:23:53 <hhorak> abadger1999: Oh, all right :)
17:24:21 <tjanez> I have to go. Thanks for the meeting!
17:24:27 <hhorak> tjanez: bye
17:24:38 <abadger1999> tjanez: See you later!
17:24:40 <mmaslano> conclusion: multilib is nice to have?
17:25:30 <abadger1999> mmaslano: +1
17:25:55 <abadger1999> or even "not in F21"
17:25:56 <hhorak> mmaslano: +1 I'd ise again the documentation way -- "try do your best"
17:26:12 <mmaslano> #agreed multilib is nice to have, just document it
17:26:29 <mmaslano> proposal: close the meeting today
17:26:47 <abadger1999> errr... it's something that has to be done in the scripts that compose the repository.
17:27:01 <abadger1999> so package maintainers can't make things multilib on their own.
17:27:10 <mmaslano> abadger1999: we should document it there?
17:27:21 <abadger1999> mmaslano: Yeah, I can document the lack of multilib for end users.
17:28:40 <abadger1999> One thing before closing meeting:  Daylight savings has occurred in the US.  I can make it one hour earlier (UTC one hour earlier... same local time for me).
17:29:29 <abadger1999> Not sure if it helps anyone else (and it may be just the same once Europe switches)
17:29:40 <mmaslano> abadger1999: we will switch in two weeks
17:30:05 <abadger1999> works for me
17:30:15 <mmaslano> I'm also not sure if it helps to someone
17:31:10 <drieden> There was a meeting just before ours, so it may not be possible.
17:31:23 <mmaslano> there are more fedora-meeting channels
17:31:40 <mmaslano> abadger1999: if you have proposal, please sent it to list. I can't speak for everyone
17:31:41 <pkovar1> abadger1999: are you going to document it in the official packaging guidelines on fedora wiki?
17:32:13 <abadger1999> pkovar1: Document what?
17:32:22 <pkovar1> abadger1999: mmaslano: Yeah, I can document the lack of multilib for end users.
17:32:26 <abadger1999> mmaslano: <nod>
17:32:33 <abadger1999> pkovar1: ah -- this is just for the playground repository.
17:32:41 <pkovar1> ah, i see
17:32:52 <abadger1999> pkovar1: which doesn't follow the packaging guidelines (necessarily)
17:33:02 <pkovar1> right, missed that, sorry
17:33:09 <abadger1999> no worries :-)
17:33:45 <mmaslano> end now!
17:33:48 <mmaslano> #endmeeting