15:41:03 <dgilmore> #startmeeting RELENG (2014-09-08)
15:41:03 <zodbot> Meeting started Mon Sep  8 15:41:03 2014 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:41:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:41:11 <dgilmore> #meetingname releng
15:41:11 <zodbot> The meeting name has been set to 'releng'
15:41:17 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
15:41:17 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
15:41:35 * nirik is here
15:41:44 * tyll too
15:41:48 * sharkcz IS HERE
15:41:51 * masta is here
15:41:52 * bochecha is here
15:41:57 * pingou 
15:42:52 <dgilmore> #topic init process
15:42:58 <dgilmore> hey all
15:43:03 * pbrobinson waves
15:43:32 <dgilmore> we have a ton of tickets to get through
15:44:10 <tyll> I added a lot where it was unclear to me what the next action is or whether they are already done, if it is too much, we can skip some
15:44:11 <dgilmore> #topic #1107 auto-cleanup rawhide trees
15:44:20 <dgilmore> https://fedorahosted.org/rel-eng/ticket/1107
15:44:43 <dgilmore> this needs a script written that will keep the last 14 trees
15:44:56 <tyll> #info < dgilmore> this needs a script written that will keep the last 14 trees
15:45:13 <tyll> which path needs to be cleaned on which system?
15:45:17 <dgilmore> we could run it via cron or buildbranched/buildrawhide
15:45:32 <tyll> #info < dgilmore> we could run it via cron or buildbranched/buildrawhide
15:45:35 <dgilmore> though updates trees need cleaned up also as bodhi just leaves them there
15:45:48 <tyll> #info < dgilmore> though updates trees need cleaned up also as bodhi just leaves them there
15:46:08 <dgilmore> this one could be an easyfix
15:46:23 <dgilmore> shouldnt take too long to write a script to do it
15:46:52 <dgilmore> I do not think it needs to keep the meeting keyword
15:46:55 * nirik likes the idea of build* scripts cleaning up the old ones...
15:46:59 <tyll> which path needs to be cleaned on which system?
15:47:02 <dgilmore> we should update the ticket and remove the meeting keyword
15:47:19 <masta> hrm... yeah, looks easy. Keep N tree around.
15:47:22 <dgilmore> /mnt/koji/mash and /mnt/koji/mash/updates
15:47:23 <nirik> tyll: /mnt/fedora_koji/koji/mash/rawhide* and branched*
15:47:25 <tyll> yes, this sounds good
15:47:42 * pingou notes: I'll have to go in ~25minutes, so if we to discuss the new-branch/pkg processes it should be before :)
15:47:45 <dgilmore> nirik: dont forget updates
15:47:51 <nirik> yeah, and updates/
15:48:13 <tyll> #info affected paths /mnt/koji/mash and /mnt/koji/mash/updates
15:48:17 <masta> what  is the priority on that?
15:48:40 <masta> we low  on space?
15:48:46 <dgilmore> pingou: its not on the list of tickets so it wont be discussed unless it comes up in openfloor
15:49:06 <tyll> masta: it is a very old ticket
15:49:10 <dgilmore> masta: making sure we dont fill up the storage
15:49:26 <pingou> dgilmore: cool, we can do an update in 3 weeks then
15:49:31 <nirik> we have been cleaning them manually when we notice.
15:49:38 <dgilmore> usually nirik or I clean it up when there is 3 or 4 months worth of composes
15:50:12 <sharkcz> and same applies to secondary hubs, s automation is good idea
15:50:45 <dgilmore> right
15:50:49 <masta> ok, I'll take the cleanup task.
15:50:56 <dgilmore> so lets move on
15:51:04 <tyll> #action masta  I'll take the cleanup task.
15:51:08 <dgilmore> #topic #1501 repomd.xml signing in bodhi
15:51:55 <dgilmore> so i still do not think we can really do this
15:52:06 <tyll> Is caching the sigul credentials still a no-go, considering that it also happens for the autosigner?
15:52:09 <nirik> it would be a big pain. ;) more work, etc.
15:52:39 <dgilmore> tyll: autosigner box is sperate with more limited access than the releng boxes
15:53:24 <dgilmore> tyll: it would be a massive amount of work. and some of it depends on what would cache teh signature
15:53:54 <dgilmore> I would be more willing to revisit with concrete proposal
15:54:03 <dgilmore> not just we should do this
15:54:14 <tyll> #info < dgilmore> I would be more willing to revisit with concrete proposal
15:54:20 <dgilmore> i.e. how would we implements it
15:54:23 <tyll> #info  dgilmore> tyll: autosigner box is sperate with more limited access than the releng boxes
15:54:34 <nirik> I'm not sure it gets us that much really either now that we have metalinks.
15:54:49 <tyll> which systems are used to prepare updates?
15:55:00 <nirik> releng04 and relepel01
15:56:00 <dgilmore> pingou: i failed your ticket is next
15:56:12 <tyll> ok, I guess we can defer this ticket then
15:56:27 <tyll> #info  releng04 and relepel01 used to prepare updates
15:56:36 * pingou is there for still 10min
15:57:21 <dgilmore> lets nmove on
15:57:30 <tyll> it seems to me that access restrictions are the same for these hosts and autosigner
15:57:52 <dgilmore> tyll: I do not believe so
15:57:59 <dgilmore> we would need to double check
15:58:01 <tyll> sysadmin-releng allows access to both
15:58:22 <dgilmore> tyll: yes. but afaik other groups have access to relepel01 and releng04
15:58:42 <dgilmore> sysadmin-noc for instance
15:58:46 <tyll> I see
16:00:15 <dgilmore> #action someone come up witha concrete implementation plan and we can revisit
16:00:23 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
16:00:31 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5931
16:00:40 <dgilmore> pingou: you're up
16:01:11 <pingou> ok, so I started the discussion on devel about the new processes
16:01:23 <pingou> based on it, I have 2 questions:
16:01:38 <pingou> - Do we really want to populate the branch when we create them?
16:02:00 <pingou> we could just create the epel8 branch and let the packager merge in whatever branch he thinks will work
16:02:31 <tyll> It needs to be populated with something in GIT, because there needs to be a commit that is pointed to for a branch to exist
16:02:36 * nirik would be fine with letting them do it, we would need to announce/document it tho as it's different.
16:02:56 <dgilmore> pingou: afaik its not possible to make a branch and have it be empty
16:03:15 <bochecha> the creation could just add the acls for the branch, then packagers create it where they want it?
16:03:25 <dgilmore> if we can then it would be an option. but would need a lot of work
16:03:53 <dgilmore> bochecha: many if not most maintainers wouldnt know how to
16:03:55 <pingou> I can double-check if we actually can, but basically, we're in favor of this?
16:03:56 <tyll> it could point to the first commit in master
16:04:05 <dgilmore> pingou: im not opposed
16:04:12 <dgilmore> i wouldnt say I am in favour
16:04:50 <pingou> the point came up on devel@ so we can also continue the discussion there about if it's feasible/desirable
16:04:58 <bochecha> dgilmore, you mean, just using the usual « fedpkg switch-branch » and « fedpkg push » ? :-/
16:05:12 <dgilmore> bochecha: ?
16:05:16 <tyll> I would be in favor of pointing it to the initial commit, which should be easy and avoids accidently creating the wrong branches
16:05:31 <bochecha> dgilmore, that's all it would take for a maintainer to create a new branch, if the acls already are open for it
16:05:41 <bochecha> tyll, that's a nice solution as well
16:05:51 <dgilmore> bochecha: not really
16:05:59 <pingou> tyll: mind bringing it up on devel@?
16:06:07 <nirik> perhaps someone could do a proof of concept on stg?
16:06:39 <tyll> it is afaik already what we do for initial packages
16:06:40 <pingou> should be duable :)
16:07:05 <pingou> the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is a packager?
16:07:05 <dgilmore> tyll: we init a bare repo then make the branches from master
16:07:43 <tyll> http://paste.fedoraproject.org/131843/41019240
16:07:48 <nirik> pingou: there was talk about us only allowing those from people with acls on the package
16:07:51 <dgilmore> tyll: they could then do a git megre <branch> in the new one and it should just work
16:08:08 <tyll> dgilmore: it is an empty .gitignore and sources file as initial commit
16:08:22 <dgilmore> pingou: that the person is in the acls
16:09:03 <pingou> dgilmore: nirik so nothing outside pkgdb? so if the person satisfies the conditions, we could just automatically grant *fedora* branch request, right?
16:09:05 <dgilmore> pingou: and if its an epel package that the maintainer has opted out of epel and if not that they know and are okay with the other person making epel branches
16:09:21 <dgilmore> pingou: in theory we could be completely hands off for new branches
16:09:26 * nirik nods
16:09:30 <dgilmore> pingou: we just do not have the tooling to do it
16:10:01 * bochecha has to go
16:10:02 <pingou> dgilmore: for epel branch I agree, that's why I'm here only speaking about new fedora branches
16:10:25 <nirik> yeah, epel is more complex, but we could even automate it with some more work, IMHO
16:10:42 <dgilmore> pingou: if the personal has commit access to an existing fedora branch and requests a new one then that could be done without intervention
16:10:52 <dgilmore> pingou: epel could be automated also
16:10:55 <pingou> dgilmore: cool, so I'll do that in pkgdb :)
16:11:02 <dgilmore> it would just take some coding
16:11:13 <dgilmore> we could have the fedora maintainer ack the epel branch
16:11:31 <dgilmore> if we do one we should do both
16:11:39 <pingou> I've started working on a pkgdb-admin CLI part of pkgdb-cli https://git.fedorahosted.org/cgit/packagedb-cli.git/tree/pkgdb2client/admin.py?h=pkgdb_admin
16:12:03 <pingou> this way, admins can list pending action, process a specific action and update its status
16:12:21 <dgilmore> okay
16:13:02 <pingou> process being, grant a new branch <- we can add more checks there, create the new package or unretire a package <- doesn't do anything atm
16:13:42 * pingou has to go
16:13:51 <pingou> but this is basically where I am at atm
16:13:56 <pingou> code wise it's working on pkgdb
16:14:05 <tyll> #info < pingou> - Do we really want to populate the branch when we create them?
16:14:09 <dgilmore> okayt thanks for the update
16:14:20 <pingou> we "just" need to define what we want to fully automate and what we still want to check "manually"
16:14:33 <pingou> see you later/tomorrow people :)
16:14:35 <tyll> info < pingou> the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is  a packager?
16:14:40 <tyll> #info < pingou> the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is  a packager?
16:14:59 <tyll> #info < pingou> we "just" need to define what we want to fully automate and what we still want to check "manually"
16:15:26 <tyll> #info < pingou> I've started working on a pkgdb-admin CLI part of pkgdb-cli  https://git.fedorahosted.org/cgit/packagedb-cli.git/tree/pkgdb2client/admin.py?h=pkgdb_admin
16:16:11 <dgilmore> going to move on
16:16:16 <tyll> #info for new branches, check whether the person is a packager and has commit ACLs for at least on Fedora branch
16:16:18 <dgilmore> #topic #5967 Enable source repo generation
16:16:26 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5967
16:16:42 <dgilmore> this comes at a massive cost
16:17:11 <nirik> it's just another newrepo right? well, x buildroots
16:17:17 <dgilmore> nirik: yep
16:17:29 <tyll> #info < dgilmore> this comes at a massive cost
16:17:30 * nirik shrugs. I think we have pretty good capacity now...
16:17:39 <dgilmore> every newRepo task will have an extra arch
16:18:26 <nirik> we could try it and see if it causes too much load ?
16:18:44 <dgilmore> it will be next to impoosible to turn off if we enable it
16:19:10 <tyll> #info < dgilmore> it will be next to impoosible to turn off if we enable it
16:19:19 <nirik> bummer.
16:19:28 <dgilmore> I really do not understand what the perceived gain is either
16:19:35 <nirik> in any case I wouldn't want to do it in freeze.
16:19:45 <nirik> perhaps ask the reporter to come to the next meeting?
16:19:51 <dgilmore> lets ask for some more info in the ticket
16:20:10 <tyll> #action dgilmore ask for some more info in the ticket
16:20:27 <tyll> #info < dgilmore> I really do not understand what the perceived gain is either
16:20:36 <tyll> #info < nirik> in any case I wouldn't want to do it in freeze.
16:20:40 * nirik has a hard stop in about 10min, FYI.
16:21:18 <dgilmore> the meeting is either going ot go way over or leave a lot of things untouched
16:21:35 <dgilmore> we are not even a quarter into the tickets
16:21:47 * nirik nods
16:22:04 <tyll> IMHO there are probably no time-critical tickets, so we can do them next meeting
16:23:03 <dgilmore> with a few people dropping off lets end at the half hour
16:23:34 <dgilmore> #topic #5959 Enable keep-alive connections for koji (primary and secondaries)
16:23:40 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5959
16:23:51 <dgilmore> pbrobinson: did you enable this on arm.koji?
16:26:44 <masta> I'm on the hub, what does the config look like?
16:27:14 <masta> nothing jumps out as looking like a keep alive
16:27:37 <tyll> KeepAlive On
16:28:05 <masta> ok, that is not present in the kojid.conf on the arm hub.
16:28:18 <tyll> should be in the apache config
16:28:32 <dgilmore> masta: its an apache config option
16:28:47 <tyll> but it is not enabled according to curl
16:28:54 * nirik has to run, will read back on logs later.
16:29:00 <tyll> $ curl -skI https://arm.koji.fedoraproject.org | grep Connection
16:29:01 <tyll> Connection: close
16:29:07 <dgilmore> ng to make sure nothing breaks
16:29:15 <dgilmore> #action pbrobinson to enable and do testing to make sure nothing breaks
16:31:33 * pbrobinson is back and I'll do that this evening
16:31:44 <dgilmore> if nothing else important lets wrap up
16:32:08 <tyll> ok
16:33:10 <dgilmore> #endmeeting