17:00:07 <paragan> #startmeeting FESCO (2016-04-08)
17:00:07 <zodbot> Meeting started Fri Apr  8 17:00:07 2016 UTC.  The chair is paragan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:07 <zodbot> The meeting name has been set to 'fesco_(2016-04-08)'
17:00:07 <paragan> #meetingname fesco
17:00:07 <zodbot> The meeting name has been set to 'fesco'
17:00:07 <paragan> #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh
17:00:07 <paragan> #topic init process
17:00:07 <zodbot> Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh
17:00:11 <sgallagh> .hello sgallagh
17:00:12 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:00:17 <number80> .hello hguemar
17:00:18 <zodbot> number80: hguemar 'Haïkel Guémar' <karlthered@gmail.com>
17:00:23 <paragan> .hello pnemade
17:00:24 <zodbot> paragan: pnemade 'Parag Nemade' <pnemade@redhat.com>
17:00:33 <nirik> .hello kevin
17:00:34 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
17:00:53 <maxamillion> .hello maxamillion
17:00:54 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:01:46 <paragan> we got quorum :)
17:02:08 <paragan> not sure if remaining members will be available today
17:03:05 <paragan> let's take old business ticket first
17:03:11 <paragan> #topic #1518 Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled
17:03:12 <paragan> .fesco 1518
17:03:12 <paragan> https://fedorahosted.org/fesco/ticket/1518
17:03:15 <zodbot> paragan: #1518 (Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled) – FESCo - https://fedorahosted.org/fesco/ticket/1518
17:04:04 <paragan> what is remaining here to be addressed? I think fixed firefox is in Fedora and there are no plans to add any alternative package to firefox
17:04:36 <nirik> well, we already do have icecat in the collection.
17:04:56 <paragan> right we have icecat already
17:05:03 <sgallagh> Proposal: FESCo asserts that Firefox in its current incarnation meets its standard for Free Software for inclusion in Fedora. Other packages may be proposed on a case-by-case basis.
17:06:36 <nirik> +1 I suppose...
17:06:38 <maxamillion> +1
17:07:16 <paragan> okay +1
17:08:01 <paragan> number80, your vote please?
17:08:01 <sgallagh> nirik: What's your reservation?
17:08:06 <nirik> I guess it comes down to if "you" in the Free software definitions means "anyone" or "anyone who is admin of a machine/instance"
17:08:50 <sgallagh> My perspective is that as long as Fedora isn't making it impossible for a user to run an alternate browser, it's not violating the user's freedom
17:09:21 <sgallagh> The Free Software definition explicitly doesn't require that the software conform to the user's requirements.
17:09:37 <number80> +1
17:10:30 <sgallagh> +1 from me, to be clear
17:10:38 <paragan> cool
17:11:47 <paragan> #agreed  FESCo asserts that Firefox in its current incarnation meets its standard for Free Software for inclusion in Fedora. Other packages may be proposed on a case-by-case basis (5, 0, 0)
17:12:03 <paragan> I think with above resolution we can close this ticket?
17:12:12 <sgallagh> Yes
17:12:13 <dgilmore> hi all
17:12:15 <nirik> yep. (although I suspect it may be re-opened)
17:12:31 <paragan> okay
17:12:47 <paragan> let's move to next ticket
17:12:55 <sgallagh> If it gets reopened again, I'm just closing it summarily.
17:12:58 <sgallagh> I'll say that right now
17:13:10 <paragan> thanks
17:13:10 <nirik> sure, it could go to the council if they like...
17:13:32 <paragan> #topic #1565 Fedora schedule must continue to track core library ABI or risk serious ABI implications
17:13:33 <paragan> .fesco 1565
17:13:33 <paragan> https://fedorahosted.org/fesco/ticket/1565
17:13:37 <zodbot> paragan: #1565 (Fedora schedule must continue to track core library ABI or risk serious ABI implications.) – FESCo - https://fedorahosted.org/fesco/ticket/1565
17:14:02 <nirik> I lost track of any action we should be taking here...
17:14:22 <sgallagh> nirik: I think they essentially want a promise that we won't let the Fedora schedule get too far out of sync with glibc
17:14:30 <paragan> right
17:14:40 <nirik> well, we can surely try...
17:14:42 <dgilmore> I do not think that they ever communicated before now taht they had lined up releases to our schedule
17:14:52 <nirik> so perhaps it was more FYI
17:15:18 <maxamillion> nirik: +1
17:15:24 <sgallagh> dgilmore: Maybe not widely, but it's fairly well-known among the platform group at RHT at least.
17:15:38 <dgilmore> sgallagh: I never knew
17:15:40 <sgallagh> Which is not a complete communication
17:15:47 <dgilmore> not taht I know everything
17:16:15 <paragan> yes its looks FYI
17:16:16 <dgilmore> but its teh kinda thing that you should communicate if you want us to consider you when doing schedules
17:16:21 <number80> as long as glibc keeps a predictible schedule, wfm
17:16:28 <sgallagh> Essentially, glibc for the last five years at least has been in a symbiotic relationship with Fedora
17:16:40 <sgallagh> dgilmore: Right, which is why they opened this ticket, I expect
17:17:11 <sgallagh> glibc upstream settled on approximately the same six-month schedule Fedora had at that point, since a lot of the upstream developers are on our platform
17:17:30 <sgallagh> So their various dev phases lined up at that time very well.
17:17:40 <paragan> So do we need to ask PM (jkurik) to consider glibc release schedule while preparing Fedora release schedules?
17:17:46 <sgallagh> The erratic schedules we've had over the last few years have made that difficult at times
17:17:56 <number80> we need to write it down
17:18:06 <sgallagh> So I think they want us to realize that this *very core* piece of the ecosystem needs to be part of the scheduling plan
17:18:22 <paragan> yes it should be
17:18:37 <sgallagh> So yes, I think they're asking us to codify it as "law" that glibc schedule is a primary consideration on the schedule
17:18:54 <sgallagh> (The fact that the same schedule lines up well with GNOME is a bonus)
17:19:17 <nirik> sounds fine to me. make sure we collect that info when making schedules and keep it in mind
17:19:42 * codonell waves
17:20:23 <paragan> Proposal: Fedora PM to consider glibc release schedule while preparing Fedora release schedules
17:20:38 <sgallagh> paragan: I think we want that to be a stronger statement.
17:20:52 <paragan> can you please propose one?
17:20:57 <sgallagh> codonell: What do the glibc phases look like?
17:21:11 <sgallagh> I think we probably want to line Alpha and Beta up with key dates of glibc.
17:21:29 <sgallagh> Or make sure they have appropriate "not earlier than"/"not later than" relationships
17:22:47 <codonell> For the sake of core ABI assurances provided by upstream (engineers working from IBM, SUSE, Intel, Red Hat, Linaro etc.) a "not earlier than" and "not later than" relationship is important.
17:23:09 <sgallagh> codonell: Right, so "not earlier than"... what?
17:23:27 <sgallagh> Meaning, what are the key dev dates in glibc?
17:23:33 <number80> ABI change in GLibc also implies coordinating mass rebuilds too ...
17:23:49 <codonell> For glibc the key date is the release.
17:23:55 <codonell> That is when you get the ABI guarantees locked in.
17:24:18 <codonell> Mass rebuilds should happen no earlier than the glibc release.
17:24:33 <number80> makes sense
17:24:44 <codonell> I indicated that Alpha should happen no earlier than the glibc release.
17:24:55 <codonell> But that was just guidance.
17:25:17 <sgallagh> Right, and if we're going to do a mass-rebuild, that means it has to happen before we get to Branch
17:25:44 <sgallagh> Unless there's a better time to coordinate that.
17:25:51 <sgallagh> Like a beta release or such
17:26:11 <nirik> doing mass rebuilds after branch means we have to do two of them...
17:26:13 <nirik> way more work
17:26:33 <sgallagh> Right, so I'm asking if we need to do the mass rebuild after the final release or if there's an earlier time we can
17:27:14 <nirik> I would think anytime... only constraint might be releng time if they are all busy with branched milestone...
17:27:37 <paragan> so if I take a example of this https://fedoraproject.org/wiki/Releases/25/Schedule then next glibc release should happen before  2016-07-05
17:28:27 <codonell> It does not. Which is part of the reason I filed the FPC to talk about this.
17:28:42 <codonell> The Fedora glibc team is carefully sheparding the release to make sure it goes smoothly.
17:29:06 <codonell> And when I say "release" I talk only about glibc.
17:29:19 <codonell> Upstream, and Fedora updates, and ABI/API conservation.
17:29:45 <codonell> The glibc release comes out 2016-08-01.
17:30:04 <sgallagh> codonell: Right, so I'm asking if there's a pre-release that would be safe for us to mass-rebuild against.
17:30:07 <codonell> However, because glibc enters freeze at 2016-07-01, the ABI is effectively frozen at that point.
17:30:20 <sgallagh> OK, so *that's* the piece I was looking for.
17:30:35 <codonell> Yes, we have a 30 day ABI/API stability window before release.
17:30:42 <codonell> That doesn't mean a reversion won't occur though.
17:30:48 <number80> so current schedule is tight but should work
17:30:49 <sgallagh> OK, so it seems to me that's the optimal time for the mass-rebuild
17:31:03 <sgallagh> Since it helps us do it before Branch and helps you shake out the bugs
17:31:12 <codonell> Yes.
17:31:46 <sgallagh> Proposal: Fedora Schedule should always plan to run the mass rebuild as soon after glibc final freeze as possible each cycle.
17:32:16 <number80> +1
17:32:22 <sgallagh> We already have rules dictating the length of the mass-rebuild cleanup before branching
17:32:34 <number80> (well, GCC can be a troublemaker too, but we can sort it out)
17:32:35 <sgallagh> If we hit those rare reversions, we can deal with it at the time.
17:32:40 <nirik> (well, if a mass rebuild is required)
17:32:52 <sgallagh> number80: GCC is once a year, not twice and they stay close to glibc IIRC
17:33:03 <maxamillion> +1
17:33:04 <sgallagh> So I suspect it'll be a margin-of-error problem
17:33:09 <paragan> looks good +1
17:33:17 <number80> ack
17:33:29 <sgallagh> +1
17:33:53 <nirik> sure, +1 but note sometimes we may not do one.
17:33:55 <sgallagh> nirik: I think we're basically asserting that it's always required.
17:34:04 <sgallagh> I guess maybe we should clarify that part.
17:34:06 <nirik> we are? that seems... poor
17:34:20 <sgallagh> Well, ok. Maybe not.
17:34:23 <nirik> especially since we said already we were not going to do one for f25
17:34:30 <sgallagh> I guess a mass-rebuild is only strictly required if ABI changes.
17:34:40 <codonell> Correct.
17:34:52 <sgallagh> codonell: Which part is correct?
17:35:54 <sgallagh> I'll amend my previous proposal: Proposal: Fedora Schedule should always plan to run the mass rebuild as soon after glibc final freeze as possible each cycle. If no mass-rebuild is scheduled, then Alpha Freeze must be after the glibc final freeze.
17:35:58 <codonell> A mass-rebuild is required only if the ABI is modified in such a way that requires rebuilding all impacted packages. Such a rebuild should occur in the 30-day freeze window before the glibc release, as this assures maximum likelihood of being finally correct.
17:36:53 <sgallagh> codonell: Well, we also have the case where a mass-rebuild is necessitated by something else, like GCC. In which case, we'll still aim for having it within that 30-day window.
17:37:18 <codonell> sgallagh, Having the mass rebuild in that 30-day window buys you the lowest risk.
17:37:19 <nirik> or rpm or other sutff
17:37:31 <codonell> Lowest risk from a core ABI perspective.
17:38:06 <sgallagh> codonell: Undestood. I think the way I phrased it (combined with other rules relating to when a mass-rebuild is run) accounts for that.
17:38:14 <codonell> sgallagh, Agreed.
17:38:45 <sgallagh> Votes on the modified proposal?
17:38:45 <paragan> I guess we all agree with sgallagh new proposal
17:38:50 <sgallagh> +1
17:38:50 <dgilmore> we will do the mass rebuild as we do, when everything is ready
17:39:15 <dgilmore> if one of the things is a glibc ABI change, then that will be a consideration
17:39:28 <sgallagh> dgilmore: Right, this basically codifies "glibc feature freeze" as one of the things that must be ready.
17:39:54 <nirik> +1
17:40:03 <number80> we need to write it down, it's also a matter of transparency
17:40:22 <dgilmore> sgallagh: I would rather not do that. but whatever
17:40:43 <sgallagh> dgilmore: OK, state your reasons so we understand them :)
17:41:27 <dgilmore> just because that then puts it in releng's court to chase up glibc to see if it needs to be considered, rather than putting the onus on glibc to let us know
17:41:50 <dgilmore> it also sets a precident for others to follow and get releng to take on teh burden
17:42:41 <dgilmore> I would rather us say we plan to rebuild on this date, let us know if you have something we need to consider
17:42:44 <sgallagh> dgilmore: Well, I think it puts it in Fedora PM's court to look those schedules up before forming the Fedora schedule
17:42:55 <codonell> Exactly.
17:43:00 <paragan> right
17:43:11 <dgilmore> sgallagh: no
17:43:12 <sgallagh> If it's falling to rel-eng, I think that means a mistake happened in scheduling
17:43:26 <sgallagh> And we should try *really hard* not to let that happen
17:44:03 <sgallagh> Perhaps having a check-in scheduled 7-14 days ahead of those key dates
17:44:29 <codonell> I certainly see it as my responsibility to communicate ABI/API issues to Fedora PM regarding schedule.
17:44:36 <codonell> Similarly with gcc.
17:44:49 <codonell> Open communication is the only way we solve scheduling problems.
17:45:04 <codonell> glibc follows a time boxed release.
17:46:03 <codonell> The Fedora schedule considerations are designed to reduce the ABI/API risk for glibc.
17:46:31 <codonell> Sorry, I should phrase that better.
17:46:57 <codonell> The Fedora glibc team should be actively communicating with Fedora PM on the schedule to ensure a stable ABI/API is the baseline for the upcoming Fedora release.
17:47:30 <codonell> There is no need to check with glibc regarding the schedule.
17:47:36 * nirik nods. This really all just boils down to everyone talking to each other and deciding things based on all the data.
17:47:51 <sgallagh> OK, if glibc is committing to "push" that information to us, I think that's fantastic.
17:48:02 <sgallagh> nirik: Oh... well then we're screwed ;-)
17:48:02 <codonell> Absolutely.
17:48:32 <codonell> When I learned F25 was out and the schedule, I filed the FPC to discuss the schedule and ABI implications.
17:48:45 <dgilmore> FPC?
17:48:59 <dgilmore> what ticket with FPC?
17:49:04 <sgallagh> FESCo, he meant
17:49:06 <dgilmore> thats different to fESco
17:49:11 <sgallagh> The one we're covering right now
17:49:37 <codonell> Sorry, yes FESCo.
17:49:49 <paragan> dgilmore, do you want to modify sgallagh new proposal above? or want to vote on it?
17:50:06 <nirik> codonell: is the current f25 schedule ok for your needs? or do we need to revisit it?
17:50:22 <dgilmore> my proposal would be to keep in mind the glibc schedule when setting the fedora schedule
17:50:33 <dgilmore> I do not like that langauge in it about mass rebuilds
17:50:52 <dgilmore> that should all be decided based on changes happening in glibc at the time
17:51:04 <codonell> nirik, The current F25 schedule is good. The F25 branch happens during the glibc 30-day ABI/API stability window, and the Alpha happens *after* the glibc release. So it lines up well.
17:51:17 <paragan> cool
17:51:18 <sgallagh> dgilmore: Would it be okay if I modified it to refer to "a mass-rebuild necessitated by glibc"
17:51:18 <nirik> great. ;)
17:51:24 <sgallagh> Rather than an unqualified mass-rebuild?
17:51:36 <dgilmore> sgallagh: i would rather no mention of mass-rebuild
17:51:59 <sgallagh> dgilmore: I think leaving it out is an invitation to get into a situation where the mass-rebuild isn't timed properly and we end up slipping
17:52:03 <sgallagh> (again)
17:52:09 <dgilmore> that should be figured out as part of the communication when setting up the schedule
17:52:24 <dgilmore> sgallagh: you are free to think that
17:53:11 <dgilmore> sgallagh:  that would be communications failing
17:53:33 <dgilmore> sgallagh: at which point we can get that even with mentioning it
17:53:38 * nirik sees a mass rebuild in f25 schedule. thats not right.
17:53:52 <dgilmore> nirik: right, its not supposed to have one
17:56:02 <sgallagh> Did we ever vote on the F25 schedule?
17:56:08 <sgallagh> Or is that an early draft?
17:56:12 <nirik> proposal: glibc release dates should be taken into account when scheduling any mass rebuild or fedora release
17:56:14 <sgallagh> /me can't recall
17:56:21 <nirik> we decided it when we did the f24 one
17:56:24 <sgallagh> ok
17:56:34 <sgallagh> nirik: I'd still like stronger language.
17:56:35 <dgilmore> nirik: +1
17:56:43 <dgilmore> sgallagh: thats why they file a change
17:56:46 <maxamillion> nirik: +1
17:56:49 <number80> +1
17:57:01 <dgilmore> that says hey we have foo coming that needs a mass rebuild
17:57:07 <dgilmore> it is good enough for gcc
17:57:42 <dgilmore> we have spent a lot of time on this
17:58:00 <sgallagh> dgilmore: The problem with that is that the Change proposal deadline is well after the schedule is made.
17:58:10 <dgilmore> sgallagh: so
17:58:22 <dgilmore> they file a change as soon as they know something is coming
17:58:23 <sgallagh> So are we suggesting that a new Change deadline be created for things that have mass-rebuild impact?
17:58:35 <dgilmore> sgallagh: we already have said that
17:58:40 <sgallagh> Where?
18:00:37 <dgilmore> it was in the recent discussions around setting the f25 schedule
18:00:57 <paragan> we discussed f25 schedule in https://fedorahosted.org/fesco/ticket/1519
18:01:43 <sgallagh> dgilmore: If it's not written down on the Change Process page, it's not useful
18:01:51 <sgallagh> No one reads the FESCo minutes...
18:03:56 <paragan> I still see sgallagh new proposal for this ticket here, can you all please provide your vote? or anyone want to propose new proposal?
18:04:15 <dgilmore> i am -1 to sgallagh and +1 to nirik
18:04:25 <sgallagh> I am -1 to nirik and +1 to my own
18:04:26 <dgilmore> paragan: nirik made a proposal
18:04:31 <paragan> ouch I missed that
18:04:40 <dgilmore> 17:56 < nirik> proposal: glibc release dates should be taken into account when scheduling any mass rebuild or fedora release
18:04:45 <paragan> thanks
18:05:10 <nirik> sgallagh: what stronger than that do you want?
18:05:51 <dgilmore> sgallagh: and help us to understand why its not good enough
18:05:52 <sgallagh> nirik: Like I said, I want it to be clear that a mass-rebuild involving glibc must be after the final freeze of glibc
18:06:03 <sgallagh> dgilmore: Because we are terrible at coordinating.
18:06:08 <sgallagh> We forget things; we're human
18:06:19 <sgallagh> Having a specific thing we need to check written down makes sense.
18:06:28 <sgallagh> It reduces the likelihood that we will screw up again
18:06:41 <dgilmore> we have not screwed this up in teh past
18:06:48 <codonell> :-)
18:06:52 <dgilmore> I seriosuly do not know where you are coming from here
18:07:10 <dgilmore> I epxect glibc to tell us when tehy expect change
18:07:31 <codonell> I can do that. But if the Fedora schedule moves earlier than a critical date we're in trouble.
18:07:33 <codonell> Always.
18:07:36 <nirik> Proposal: Fedora Schedule should always schedule mass rebuilds (if needed) after glibc final freeze.
18:07:42 <dgilmore> and if we keep their schedule in mind when making our schedule cover the bases
18:07:59 <sgallagh> nirik: That's fine by me
18:08:00 <sgallagh> +1
18:08:06 <paragan> +1
18:08:08 <dgilmore> we keep the burden on glibc to keep us in teh loop and not us to chase them down
18:08:14 <number80> +1
18:08:21 <dgilmore> 0
18:08:22 <nirik> dgilmore: I think he's trying to add in some knowlege about glibc's release cycle so we don't have to learn it each new fesco?
18:08:32 <dgilmore> I am going to abstain
18:08:32 <sgallagh> nirik: Yes, exactly
18:08:36 <nirik> but really this is something the PM needs to know.
18:08:50 <paragan> yes
18:08:56 <codonell> How else do we keep institutional knowledge but to write it down?
18:09:29 <codonell> I promise you I check each and every Fedora schedule when it comes out.
18:09:43 <codonell> Were I to make an ABI/API mistake it's costly, so I look at it all the time.
18:09:48 <paragan> maxamillion, your vote please
18:09:52 <dgilmore> problem is we do not read what we write, particullary when we add complexity to it
18:10:04 <maxamillion> +1
18:10:07 <dgilmore> hence my desire to keep it simple
18:10:12 <maxamillion> paragan: apologies
18:10:18 <paragan> np
18:10:25 <paragan> I see 5 +1's here now
18:11:19 <paragan> #agreed Fedora Schedule should always schedule mass rebuilds (if needed) after glibc final freeze. (5, 0, 0)
18:11:23 <nirik> sure, lets move on, we have been talking about this a while. ;)
18:11:30 <paragan> yes :)
18:11:30 <dgilmore> paragan: voting is wrong
18:11:37 <dgilmore> I voted 0
18:11:43 <paragan> ah right
18:11:47 <paragan> sorry
18:11:48 <paragan> #undo
18:11:48 <zodbot> Removing item from minutes: AGREED by paragan at 18:11:19 : Fedora Schedule should always schedule mass rebuilds (if needed) after glibc final freeze. (5, 0, 0)
18:12:15 <paragan> it will be (5, 1, 0) right?
18:12:26 <dgilmore> yes
18:12:27 <number80> yes
18:12:30 <paragan> #agreed Fedora Schedule should always schedule mass rebuilds (if needed) after glibc final freeze. (5, 1, 0)
18:12:34 <paragan> thanks
18:13:00 <codonell> I hate to be a stickler for details. But such a proposal doesn't actually address the original problem.
18:13:18 <paragan> I think that is what we had for today's agenda
18:13:18 <sgallagh> codonell: How so?
18:13:32 <paragan> codonell, what is missing in that proposal?
18:13:36 <number80> mass rebuilds are tied to fedora schedule
18:13:58 <number80> we don't do mass rebuilds before branching
18:14:00 <codonell> My point in the original ticket was: Fedora Alpha should be *after* glibc release.
18:14:04 <number80> erm after
18:14:15 <codonell> If we do no mass rebuild that's OK.
18:14:17 <number80> yes, that's implied
18:14:21 <codonell> But the the schedule constraint is still there?
18:14:36 <number80> yup, indirectly but it's still here
18:14:40 <nirik> well, there has been talk from dgilmore of dropping alpha as a thing
18:14:50 <sgallagh> Ah right. My earlier proposal specifically mentioned that the Alpha freeze had to be after the glibc final freeze
18:15:15 <sgallagh> nirik: Well, as a separate deliverable
18:15:21 <dgilmore> I am planning to drop alpha in f25 or f26
18:15:28 <sgallagh> But I assume that basically just means that "Alpha" is just "post-branch"
18:15:30 <dgilmore> and only do Beta and Final
18:16:27 <codonell> Yes, I could reword my suggestion to "Fedora should branch rawhide after glibc enters ABI/API freeze, optimally after glibc releases."
18:16:41 <sgallagh> Right, so if we do that, should we just s/Alpha Freeze/Branch Date/ everywhere?
18:17:20 <dgilmore> codonell: I would rather not
18:17:34 <dgilmore> because then we have to chase you up to know that
18:17:40 <dgilmore> I would rather you tell us
18:17:55 <nirik> well, for f24 and in the past we had several weeks between branch and alpha freeze
18:17:57 <codonell> OK, so let me rephrase that.
18:18:32 <dgilmore> codonell: I am happy to have PM check with you, when setting the schedule.
18:18:47 <dgilmore> but the onus has to be on you post that to keep us informed
18:18:49 <codonell> dgilmore, How do I get that on a checklist?
18:18:57 <codonell> dgilmore, I fully agree with you.
18:19:20 <codonell> dgilmore, That's all I want to achieve, an item on a checklist, and it's fine if the onus is on me to notify Fedora PM.
18:19:47 <dgilmore> codonell: 7:56 < nirik> proposal: glibc release dates should be taken into account when scheduling any mass rebuild or fedora release
18:19:52 <dgilmore> gahh
18:19:56 <dgilmore> sorry
18:20:20 <codonell> That worked for me, because it said "fedora release" :-)
18:20:41 <nirik> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
18:20:59 <dgilmore> codonell: thats what I thought but sgallagh was against it
18:21:18 <codonell> I think we wanted a slightly tighter langauge on the rebuilds.
18:21:51 <dgilmore> codonell: I do not want taht because that tehn puts the onus on releng to follow up with you
18:22:17 <sgallagh> dgilmore: Why is that so terrible? If the mass-rebuild happened too early, rel-eng would be stuck running a second one.
18:22:30 <sgallagh> So it seems like taking five minutes to ask a question is a lot less effort.
18:23:09 <codonell> I expect communication to work effectively at all times, but having belt-and-suspenders is better IMO.
18:23:10 <dgilmore> sgallagh: its often more than 5 minutes to ask a question
18:23:49 <codonell> Whoever is in charge of the schedule has to ask these questions?
18:24:09 <dgilmore> codonell: no.
18:24:09 <codonell> Then Fedora glibc team follows the schedule.
18:24:35 <dgilmore> codonell: when we are prepping for a mass rebuild releng needs to know everything that needs to be ready
18:24:42 <sgallagh> codonell: Sure, until a CVE/serious bugfix slips your freeze date :)
18:25:07 <codonell> sgallagh, No such thing happens. We just do a point release update.
18:25:08 <dgilmore> we assume everything we are not explictly told needs to be ready is ready
18:25:25 <sgallagh> codonell: What dgilmore wants is that glibc proactively alerts all relevant people if something happened that changed the schedule
18:25:33 <dgilmore> so gcc files a Change that says we need a mass rebuild, and that is communicated
18:25:42 <dgilmore> then we know we need to track gcc
18:26:05 <dgilmore> I do not want to chase glibc, but have you tell us when we have something to consider
18:26:30 <codonell> I file a Change every fedora release for glibc.
18:26:36 <codonell> I could add it to that?
18:26:45 <codonell> "Do not move branch before date X"
18:27:36 <dgilmore> codonell: that is fine
18:27:37 <codonell> I'd rather though that we talk about the schedule and the impact to core library ABIs.
18:27:45 <codonell> Just so we're all on board.
18:28:03 <dgilmore> codonell: tahts part of yoru discussion with PM when setting the schedule
18:28:04 <codonell> I will put that note into the next Change for F25.
18:28:21 <dgilmore> we have wasted too much time on this already
18:28:26 <paragan> I think we should move
18:28:46 <paragan> #topic Next week's chair
18:28:46 <paragan> Who want to chair for next week meeting?
18:29:51 <nirik> I can do it.
18:29:58 <paragan> thanks
18:30:10 <paragan> #info nirik to chair next week meeting
18:30:22 <paragan> #topic Open Floor
18:30:23 <paragan> anything here to discuss?
18:31:08 <sgallagh> I'm sure I had something come up about an hour ago that I wanted to ask about, but I've completely forgotten it.
18:31:47 <sgallagh> So, no
18:32:50 <paragan> if nothing to be discussed, let's close the meeting in 2 minutes
18:34:44 <paragan> thanks everyone coming for this meeting.
18:34:44 <paragan> #endmeeting