(docs/meeting-logs) Add agenda and log from 2016-09-18 meeting master
authorKristian Fiskerstrand <k_f@gentoo.org>
Mon, 19 Sep 2016 18:55:32 +0000 (20:55 +0200)
committerKristian Fiskerstrand <k_f@gentoo.org>
Mon, 19 Sep 2016 18:55:32 +0000 (20:55 +0200)
docs/meeting-logs/2016-09-18-agenda.txt [new file with mode: 0644]
docs/meeting-logs/2016-09-18-wg-meeting.txt [new file with mode: 0644]

diff --git a/docs/meeting-logs/2016-09-18-agenda.txt b/docs/meeting-logs/2016-09-18-agenda.txt
new file mode 100644 (file)
index 0000000..dc5e3be
--- /dev/null
@@ -0,0 +1,40 @@
+Metadata
+================================================
+Gentoo Stable WG Meeting
+Date: 2016-09-18
+Time: 19:00 UTC
+Location: #gentoo-wg-stable @ FreeNode
+
+Agenda
+================================================
+1. General discussion about the report so far
+   Structure: The document is currently structured based on a simplified
+   Y-model in strategy, whereby the (i) current situation, (ii) a wanted
+   situation, and (iii) the steps to migrate between them are being
+   described. Should this be extended in any way? For instance the full
+   X model used to describe each of (i) and (ii) includes a set of (a)
+   person-resources (b) person results (c) workflow (d) case-resources
+   (e) case-results
+   
+2. Kernel stabilisation
+   Kernel stabilisation is likely one of the points that is most complete and
+   in line with what has already been discussed previously. Is the section of
+   how we want kernel stabilisation to work (Section 3.2) reaching completion?
+
+3. Documentation of current stabilisation policy and practice
+   Section 4.1 - Who can work on writing up the description of the current
+   state of arch testing policy. In particular documenting GLEP 40, various
+   council decisions, mailing list discussions that end up with self-
+   stabilisation etc. Documentation of the current state is needed in order to
+   write a replacement GLEP in the event we recommend changes to stabilisation
+   efforts (or likely in order to continue the current practice)
+
+4. Discussion regarding feedback from arch teams
+
+5. Stabilisation process
+   Section 5.3
+
+7. Bugzilla workflow
+   Section 5.2
+
+8. Open floor
diff --git a/docs/meeting-logs/2016-09-18-wg-meeting.txt b/docs/meeting-logs/2016-09-18-wg-meeting.txt
new file mode 100644 (file)
index 0000000..830495a
--- /dev/null
@@ -0,0 +1,602 @@
+2016-09-18 00:34:05-!- Irssi: #gentoo-wg-stable: Total of 16 nicks [7 ops, 0 halfops, 4 voices, 5 normal]
+2016-09-18 00:35:18-!- Irssi: Join to #gentoo-wg-stable was synced in 79 secs
+2016-09-18 03:43:10-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
+2016-09-18 08:09:00-!- mode/#gentoo-wg-stable [+v graaff] by ChanServ
+2016-09-18 09:06:37-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
+2016-09-18 14:40:46-!- mode/#gentoo-wg-stable [+v K_F] by ChanServ
+2016-09-18 15:42:58-!- mode/#gentoo-wg-stable [+o K_F] by ChanServ
+2016-09-18 16:06:31-!- mode/#gentoo-wg-stable [+v WilliamH] by ChanServ
+2016-09-18 17:09:01<@jmorgan> might want to put something about today's meeting in topic
+2016-09-18 17:49:25-!- K_F changed the topic of #gentoo-wg-stable to: Next meeting: Today @ 1900 UTC: Agenda: https://download.sumptuouscapital.com/gentoo/wg-stable/2016-09-18-agenda.txt
+2016-09-18 17:49:42-!- K_F changed the topic of #gentoo-wg-stable to: Next meeting: Today @ 1900 UTC: Draft agenda: https://download.sumptuouscapital.com/gentoo/wg-stable/2016-09-18-agenda.txt
+2016-09-18 19:58:23<@K_F> 1h warning
+2016-09-18 19:59:02<@jmorgan> its not starting now, but an hour?
+2016-09-18 19:59:48<@K_F> correct
+2016-09-18 20:00:14<@jmorgan> stupid daylight savings time mixed me up ;)
+2016-09-18 20:00:22<@K_F> jmorgan: :)
+2016-09-18 20:00:22<+graaff> date -u helped me out
+2016-09-18 20:00:59<@jmorgan> nice, i'm going to use that (date -u)
+2016-09-18 20:03:36<+graaff> K_F: for the agenda: perhaps include a feedback round on the document so far?
+2016-09-18 20:04:20<@K_F> graaff: sounds good to me, early , late..?
+2016-09-18 20:04:47<+graaff> I'd do it early, but probably needs timeboxing.
+2016-09-18 20:04:49<@K_F> can start off with it
+2016-09-18 20:05:46<+graaff> Yes, that way we can collect things that are still missing before going into more detailed discussion.
+2016-09-18 21:00:01<@K_F> Roll Call
+2016-09-18 21:00:20 * K_F here
+2016-09-18 21:00:45 * graaff present
+2016-09-18 21:00:50<@jmorgan> jmorgan (ia64,sparc,ppc*)
+2016-09-18 21:00:54 * dilfridge mostly present
+2016-09-18 21:01:34 * WilliamH here, but not actually a member of the wg
+2016-09-18 21:02:04<@K_F> WilliamH: thats better than the opposite (not here and member)
+2016-09-18 21:02:14<+WilliamH> heh
+2016-09-18 21:03:07<@K_F> so we have 3 members + 2 non-members present so far
+2016-09-18 21:03:46<@rich0> I'm semi-here :)
+2016-09-18 21:03:52< dwfreed> I'm around, though I count for even less
+2016-09-18 21:04:15<@K_F> ok good, 4+3 
+2016-09-18 21:04:30<@K_F> I've put up a rough agenda at https://download.sumptuouscapital.com/gentoo/wg-stable/2016-09-18-agenda.txt
+2016-09-18 21:04:49<@K_F> to have something to try to focus the disussion around, but feel free to propose other items to discuss as well
+2016-09-18 21:05:22<@K_F> the main reason for the meeting is after a period of less structured approach, and trying to bring up new ideas informally the participation was somewhat restricted.
+2016-09-18 21:06:12<@K_F> so going forwards will try a bit new approach, that will likely involve more specific discussions on the alias, but also some brainstorming sessions on scheduled time since the discussion in the channel hasn't involved too many
+2016-09-18 21:06:24<@K_F> so Item 1 on agenda is 1. General discussion about the report so far
+2016-09-18 21:06:43<@K_F> rendered PDF of the draft report so far is at https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf
+2016-09-18 21:07:35<@K_F> opening floor up for discussion on structure and suggestions for additional content, although I note the more specific items following in particular case 2,3,5,7
+2016-09-18 21:07:46<+graaff> I have one additional developer complaint not listed yet: pending stable bugs may prevent additional dependent stable bugs from being filed, leading to even more delays.
+2016-09-18 21:07:48<@dilfridge> actually, I think we can mostly ignore the kernels. it's a distinct subset of packages which can have its own rules.
+2016-09-18 21:08:11<@dilfridge> graaff++ (see the perl mess)
+2016-09-18 21:08:46<@K_F> dilfridge: that is much of what is being done, however the last time kernel team proposed a change it was shut down by some other devs so including it will give them backing for it, so I believe it should be included for completeness
+2016-09-18 21:08:55<@dilfridge> ok
+2016-09-18 21:08:59<@dilfridge> wfm
+2016-09-18 21:09:02<+graaff> K_F: +1
+2016-09-18 21:09:25< dwfreed> agree
+2016-09-18 21:10:02<@K_F> graaff: can you elaborate a bit more on that point
+2016-09-18 21:10:17<@K_F> i.e pending stable bugs preventing additional stabilization requests
+2016-09-18 21:10:19< dwfreed> K_F: I agree with the common user complaint, and I've seen the common developer complaint many times
+2016-09-18 21:10:47<+graaff> Sure. Within ruby packages depend on each other (e.g. the testing framework rspec is needed by other packages).
+2016-09-18 21:11:15<@K_F> graaff: i.e it sounds like a background description on why we would like timely stabilization, so could go into description of current state perhaps?
+2016-09-18 21:11:50<+graaff> So we file a stable bug for rspec first, but we can't really file additional stable bugs at the time. So now we wait until rspec is stable (everywhere), and then we can file a stable bug.
+2016-09-18 21:11:50<@K_F> or wanted state for that matter (and/or both on some level)
+2016-09-18 21:12:06<+graaff> K_F: yes, second paragraph starting with "A common developer complaint"
+2016-09-18 21:12:36<@K_F> graaff: Gotcha, can you file a pull request or format-patch with suggested text?
+2016-09-18 21:12:36<+graaff> The problem with this specific situation is that it is a multiplier for the stable delays.
+2016-09-18 21:12:44<@jmorgan> let's sections for clearity, IE section 4,
+2016-09-18 21:12:54<@jmorgan> let's add sections..
+2016-09-18 21:12:58 * graaff should use that trick in his own meetings...
+2016-09-18 21:13:00<+graaff> ok
+2016-09-18 21:14:11<@jmorgan> on section 4, i think it would be interesting to look at bugzilla filed (defects) vs stablreq and keywrodreq per arch
+2016-09-18 21:14:49<+WilliamH> jmorgan: ?
+2016-09-18 21:14:55<@K_F> jmorgan: for Table 1 you mean?
+2016-09-18 21:14:59<@jmorgan> yes
+2016-09-18 21:15:26<+graaff> jmorgan: in my view these numbers are not reliable anyway. For example, I'm easily sitting on 20-30 stable bugs right now that I can't really file.
+2016-09-18 21:15:46<+WilliamH> I'm not sure it really matters how many defects are filed against a stable version of a package if there is a newer version with a stable request opened.
+2016-09-18 21:16:10< dwfreed> see openrc, for example
+2016-09-18 21:16:24< dwfreed> still waiting on x86 to stable 0.21.7
+2016-09-18 21:16:38< dwfreed> bug 588786 for reference
+2016-09-18 21:16:41<@jmorgan> WilliamH: it would tell you if that package is getting run time tested on a specific arch
+2016-09-18 21:16:58<+WilliamH> jmorgan: not necessarily
+2016-09-18 21:17:22 * dilfridge inserts random remark about gentoostats and buggers off again...
+2016-09-18 21:17:23<@jmorgan> unless its a build only bugzilla
+2016-09-18 21:18:38<+WilliamH> jmorgan: I'm not following?
+2016-09-18 21:18:45<@K_F> well, if a package is working perfectly fine it wouldn't have defects listed for it :)
+2016-09-18 21:19:01<@jmorgan> bugzilla is a tool to track defects (traditionally)
+2016-09-18 21:19:21<@jmorgan> gentoo uses it to also track tasks (stablereq/keywordreq for example)
+2016-09-18 21:19:33<@K_F> and I guess there can be reasonable expectation for higher defect count on non-standard arches as it has had less testing in development (presumably), in particular if memory alignment issues and endieaness is concerned
+2016-09-18 21:20:13<@jmorgan> so if we look at actual defects (build only test failures - will not compile/merge or run time failures) this would tell us which arch is getting tested
+2016-09-18 21:20:30<@jmorgan> which was pointed out a problem in the last paragraph of 5.3
+2016-09-18 21:21:14<@jmorgan> so i think it would be interesting to know if we look at actual real defects in bugzilla per arch, this would tell us something of our community
+2016-09-18 21:21:37<+WilliamH> jmorgan: not necessarily, that assumes that everyone files bugs on bugzilla.
+2016-09-18 21:21:57<@K_F> WilliamH: if its not on bugzilla it doesn't exist
+2016-09-18 21:22:06<+WilliamH> jmorgan: what you really want, like dilfridge  says is gentoo-stats.
+2016-09-18 21:22:08<@jmorgan> WilliamH: well we can't work of of undocumented things ;)
+2016-09-18 21:22:47<+WilliamH> K_F: that could also mean that the testing is going fine on the arches. :-)
+2016-09-18 21:22:49<@K_F> jmorgan: I'm having a bit difficulty thinking of how we can get useful statistics for it, but if you have some script-fu to create it I'd certainly be willing to discuss it. Maybe bring it up as a thread on the alias?
+2016-09-18 21:23:08<@jmorgan> sure, let's move on
+2016-09-18 21:23:15<+WilliamH> K_F: using that logic if things are going fine we aren't testing.
+2016-09-18 21:24:01<@K_F> what would be interesting, although likely not feasable, is actually to see number of defects filed after a package hits stable
+2016-09-18 21:24:17<@K_F> that'd be an indication of lack of runtime testing
+2016-09-18 21:24:35<@K_F> but the point here isn't to put arches up against each other etc
+2016-09-18 21:24:49<+WilliamH> K_F: that also assumes that everyone puts the correct version in the bugs. :-)
+2016-09-18 21:25:00<@K_F> we just want the process to be better, and propose ways for that. So I'm not sure if it is worthwhile to spend too much time trying to figure out the arch specific things
+2016-09-18 21:25:28<+WilliamH> K_F: I tend to agree.
+2016-09-18 21:27:05<@K_F> But overall, do you agree with the structure of the report?
+2016-09-18 21:27:35<+WilliamH> K_F: It seems to be ok to me.
+2016-09-18 21:27:41<@K_F> (it will of course need extending as more data gets added)
+2016-09-18 21:27:49<+graaff> The one thing I find missing is the topic of manpower
+2016-09-18 21:28:11<+WilliamH> graaff: it is briefly mentioned...
+2016-09-18 21:28:13<+graaff> When we try to do things more efficiently it still doesn't matter if nobody does the work.
+2016-09-18 21:28:14<@K_F> graaff: yes, we can likely be more specific to that
+2016-09-18 21:28:50<@K_F> including if we have suggestions for recruiting (i) other devs to become arch testers, and (ii) users to become ATs (but if (i) is low that is a conditional dependency)
+2016-09-18 21:29:25<@K_F> I don't necessarily have any good suggestions yet for how we can do it, so have spent more time on the technical questions so far
+2016-09-18 21:30:30<@dilfridge> if an arch has someone who is interested, we could publicise more that arch testing is a good way of becoming dev
+2016-09-18 21:30:36<@K_F> it would be interesting to see number of devs active in stabilisation.. maybe it'd be possible to parse git log or something to get it?
+2016-09-18 21:30:42<@dilfridge> since you become familiar with portage workings etc bla bla
+2016-09-18 21:31:08<@K_F> dwfreed: any suggestions for how we could get some reasonable figures on it?
+2016-09-18 21:31:18<+graaff> We may also enlist users to work on keywording bugs by providing build logs for those bugs.
+2016-09-18 21:31:34<+graaff> As a maintainer I'd be happy to add the keyword in that case.
+2016-09-18 21:31:51<@dilfridge> K_F: I could check my Perl inbox :P
+2016-09-18 21:31:58<@dilfridge> not many
+2016-09-18 21:32:18< dwfreed> K_F: git log would be pretty simple; 99% of devs put 'stable for arch wrt bug 123456' oslt in their commit messages when stabilizing
+2016-09-18 21:32:59<@K_F> graaff: we might expand a bit on that later, in particular whether to rely on user testing.. I agree it'd differ a bit between keywordreq and stablereq in the case, but not all arches want random packages being keyworded without involvement from the arch
+2016-09-18 21:33:33<@K_F> graaff: for stablreq we don't have sufficient info on the users ability to give a stability criteria consideration at least, unless they are ATs and have been through some training
+2016-09-18 21:33:54<+WilliamH> I'm not as concerned about keyword as I am stabilization.
+2016-09-18 21:33:58<@K_F> for keywords.. maybe, unless it is needed by some dependency it is rather contextual whether it makes sense
+2016-09-18 21:34:19<@K_F> dwfreed: that'd be my thinking as well
+2016-09-18 21:34:20<+graaff> I'd be happy if this was just for _re_keywording (e.g. dropped keywords due to new dependencies)
+2016-09-18 21:34:41<@K_F> graaff: yes, that'd be a difference as well
+2016-09-18 21:35:08<@jmorgan> i don't think we have a man power problem (yeah, sure more help would be good), our tools and process make it very difficult to do stablereq
+2016-09-18 21:36:01<@K_F> jmorgan: please elaborate a bit on that, I think it is an interesting thought
+2016-09-18 21:36:39<@jmorgan> take myself as an example, i have 6 arch systems to do testing, i have time and desire to do it and there is a need
+2016-09-18 21:37:15<@jmorgan> byt my process i was using before is broken, i need to spend a lot of time to do testing on the arch i support
+2016-09-18 21:37:25<@jmorgan> its a very labor intensive effort
+2016-09-18 21:37:53<@K_F> jmorgan: indeed, but so is most testing unless we can improve unit/functionality tests
+2016-09-18 21:38:02<@jmorgan> if you make the process easy  by good tools (scripts), documentation and help on process, you would see alot more people doing it
+2016-09-18 21:38:30<@jmorgan> there are even arch specific hardware any gentoo dev can use to do arch testing
+2016-09-18 21:38:31<@K_F> I see a surprising amount of applications that are being stabilized despite failing tests for instance
+2016-09-18 21:38:41<@K_F> and not being fixed upstream
+2016-09-18 21:38:55<@K_F> and an even scarier number of packages being stabilized without unit tests at all
+2016-09-18 21:39:18<@jmorgan> what is the impact?
+2016-09-18 21:39:21<+WilliamH> K_F: I'm not sure it is up to us to write those unit tests.
+2016-09-18 21:39:45<@K_F> WilliamH: helping to write them helps ourselves, and if we can get the tests upstreamed it is even better
+2016-09-18 21:39:54<@jmorgan> for example, build only testing as process to stablization
+2016-09-18 21:40:06<@K_F> WilliamH: so although I'd expect upstream to write them themselves, they want patches and help themselves
+2016-09-18 21:40:47<@K_F> WilliamH: so it can be a win-win to provide them back upstream if we write it for our stabilisation purposes
+2016-09-18 21:40:48<+WilliamH> K_F: sometimes, e.g. kmod, upstream tells us specifically that the test suite is for people working on the package so we shouldn't use it.
+2016-09-18 21:41:35<@K_F> WilliamH: that is actually interesting, can you provide some link to ML threads etc to that regard?
+2016-09-18 21:42:07<@K_F> graaff: thanks
+2016-09-18 21:42:13<+WilliamH> K_F: Not right away. I just talked to the kmod author in the chat channel a while back and that's what I was told.
+2016-09-18 21:42:29<+WilliamH> K_F: that's why kmod has RESTRICT="test"
+2016-09-18 21:42:53<@dilfridge> K_F: in dev-perl/* sometimes packages have tests that only make sense for the maintainer, so when kent\n finds them they get whacked
+2016-09-18 21:44:11 * kent\n arrives about an hour late, but in my defense, I just woke up :D 
+2016-09-18 21:44:29<@K_F> kent\n: welcome
+2016-09-18 21:45:03<+WilliamH> kent\n: heh
+2016-09-18 21:45:34<@K_F> dilfridge: yes, it'd normally be maintainer food, but if it does some aritmetic in assembly it needs to be tested arch specificly
+2016-09-18 21:45:42<@K_F> as an example
+2016-09-18 21:46:06<@K_F> so unit tests are normally useful for more than upstream/maintainer.. 
+2016-09-18 21:48:03<@K_F> but we can bring that up for discussion on alias as well, think it is useful to discuss more different scenarios and brainstorm a bit in this meeting than specifics
+2016-09-18 21:49:55<@K_F> if we move on to point 2 on agenda, we already touched a bit on that earlier in the meeting
+2016-09-18 21:50:03<@K_F> 2. Kernel stabilisation
+2016-09-18 21:50:03<@K_F>    Kernel stabilisation is likely one of the points that is most complete and
+2016-09-18 21:50:03<@K_F>    in line with what has already been discussed previously. Is the section of 
+2016-09-18 21:50:03<@K_F>    how we want kernel stabilisation to work (Section 3.2) reaching completion?
+2016-09-18 21:50:37< dwfreed> I have no objections to that section
+2016-09-18 21:50:40<@K_F> as mentioned earlier, even though it is a separate process, I believe it makes sense to include a section on it, but treat it otherwise separate. In order to give backing the the kernel team suggestion
+2016-09-18 21:50:55< dwfreed> it may make sense to spell out the packages we want stabilized
+2016-09-18 21:51:18<@K_F> dwfreed: so far I've mentioned gentoo-sources and a reference to others referenced in the handbook
+2016-09-18 21:51:28<@K_F> as that is what new users will encounter
+2016-09-18 21:51:35<@kent\n> An example of a test one might find in a source tree that makes sense for maintainers to run, but don't make sense to have as tests which block installation: Spelling tests
+2016-09-18 21:51:50<@K_F> more advanced users, maybe including hardened, will know how to set proper masks and allow testing packages
+2016-09-18 21:51:53<@kent\n> Lint tests. etc.
+2016-09-18 21:52:01<@K_F> although we might write something to that extent as point of process
+2016-09-18 21:52:23-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
+2016-09-18 21:52:31<+WilliamH> I will ask again about unrestricting the tests for kmod.
+2016-09-18 21:53:15<@kent\n> but yeah, "disable all the tests" is undesirable if you can simply "disable the tests that don't make sense here" and "retain the ones that do"
+2016-09-18 21:53:24<@K_F> kent\n: exactly
+2016-09-18 21:53:27<+graaff> kent\n: on ruby we always strip coverage and code quality tests but keep all the rest
+2016-09-18 21:53:56<+graaff> K_F: the kernel policy was already discussed on the mailing list I think, and there was consensus at the time that this was the right way to handle it.
+2016-09-18 21:53:56<@kent\n> like, sometimes you'll find packages where half the tests require networking, its dumb to leave those there, but its dumb to disable testing entirely as well
+2016-09-18 21:54:17 * WilliamH is fine with the kernel stuff
+2016-09-18 21:54:17<@K_F> graaff: it was, and it was started, but got backlash, so now we provide coverage
+2016-09-18 21:54:34<+graaff> What kind of backlash?
+2016-09-18 21:54:53<@K_F> graaff: complaints about lack of testing / automation of it
+2016-09-18 21:54:57<@kent\n> ( and in Perl, and probably ruby, dumb tests have dumb dependencies and dumb dependency graphs which create headaches for portage and pain for stabilization, so there's extra impetus to nuke them )
+2016-09-18 21:54:59<+WilliamH> What I would be more interested in is how many people were involved in the backlash?
+2016-09-18 21:55:22<+WilliamH> Gentoo tends to have very small groups who can be very vocal.
+2016-09-18 21:55:30<+graaff> WilliamH: +1
+2016-09-18 21:55:37<+WilliamH> and create the sense that there is a lot more backlash than there is.
+2016-09-18 21:55:44< dwfreed> K_F: looking at Kernel/Overview, I'm not sure some of those listed as supported are really things we want there
+2016-09-18 21:55:50<@K_F> WilliamH: I don't think it matters, we can propose it as a way to go and have a council approval of it down the line presumably
+2016-09-18 21:56:10<@K_F> dwfreed: in the handbook that is?
+2016-09-18 21:56:26< dwfreed> K_F: the handbook says 'use gentoo-sources, but here's this page with all the kernels'
+2016-09-18 21:56:41<@K_F> dwfreed: ok, we might need to be more specific then, indeed
+2016-09-18 21:56:47< dwfreed> which is Kernel/Overview
+2016-09-18 21:57:27<@K_F> dwfreed: thanks for that note, will rewrite it to be more restrictive
+2016-09-18 21:58:16<@K_F> likely just gentoo-sources then and a "or other LTS kernels the kernel project recommends" or something
+2016-09-18 21:58:35< dwfreed> K_F: I would list specifically gentoo-sources and hardened-sources, and perhaps specifically exclude vanilla-sources
+2016-09-18 21:59:09<+WilliamH> Why specifically exclude vanilla-sources? After all that is what upstream is calling lts
+2016-09-18 21:59:27<@K_F> vanilla sources isn't stabilised today, if the kernel team think it makes sense to do so I'm not sure we have good reasons not to
+2016-09-18 21:59:33< dwfreed> WilliamH: kernel team does not stabilize vanilla sources
+2016-09-18 21:59:36< dwfreed> only gentoo sources
+2016-09-18 21:59:56<+WilliamH> dwfreed: Sure, but I don't think we should block them from stabilizing it if they decide to.
+2016-09-18 22:00:16< dwfreed> they're the ones that decided to stop, and give good reasons for doing so
+2016-09-18 22:00:31<+WilliamH> dwfreed: leave it up to them.
+2016-09-18 22:00:31< dwfreed> besides, gentoo sources generally does not lag too far behind vanilla sources these days, as the gentoo patchset is minimal anymore
+2016-09-18 22:00:38< dwfreed> s/give/gave/
+2016-09-18 22:01:11<@K_F> dwfreed: I don't actually believe there is a conflict in what we mean here.. so will try to update the text a bit and we can look at it later
+2016-09-18 22:01:17< dwfreed> k
+2016-09-18 22:01:31<+WilliamH> dwfreed: In other words, I would be for saying that we stabilize gentoo-sources, but not for excluding vanilla-sources.
+2016-09-18 22:01:47< dwfreed> okay, word it as "at the time of this writing, vanilla-sources is excluded from stabilization by kernel team policy" oslt
+2016-09-18 22:02:03<@K_F> dwfreed: I think whitelisting makes more sense
+2016-09-18 22:02:23<@K_F> i.e only kernels the kernel team says should be stable should be stabilised
+2016-09-18 22:02:36<@K_F> but it needs to be a superset of gentoo-sources (and maybe hardened)
+2016-09-18 22:03:49 * WilliamH agrees with K_F 
+2016-09-18 22:03:50<@K_F> anyhow, lets move on to item 3
+2016-09-18 22:04:02<@K_F> 3. Documentation of current stabilisation policy and practice  
+2016-09-18 22:04:27<@K_F> kent\n: we talked a bit about this earlier, can you write a bit on documenting the current policies etc?
+2016-09-18 22:04:31<@kent\n> Somebody tried to get me to do #3, but my brain got confused about how to write anything, and where to put it
+2016-09-18 22:04:55 * kent\n sucks at open-ended things 
+2016-09-18 22:04:55<@jmorgan> kent\n: jusst start an email discusion to alias
+2016-09-18 22:05:15<@K_F> its not as much a matter of discussion, but documenting history at this point
+2016-09-18 22:05:24 * graaff has to go
+2016-09-18 22:05:30<@K_F> just to get a sense of what the current policy is as we can't even agree to that at all times
+2016-09-18 22:05:48<@K_F> so mainly looking into council meeting logs, searching through some mailing list archives etc and finding cross-references etc
+2016-09-18 22:05:58<@K_F> starting off with GLEP 40
+2016-09-18 22:06:05<@K_F> there already is section 4.1
+2016-09-18 22:06:09<@K_F> but it needs to be extended
+2016-09-18 22:06:20<@K_F> and documented/references
+2016-09-18 22:06:37<@jmorgan> AT howto will be helpful too
+2016-09-18 22:07:21<@K_F> jmorgan: i.e https://wiki.gentoo.org/wiki/Project:X86/Arch_Testers_FAQ etc
+2016-09-18 22:07:22<@K_F> ?
+2016-09-18 22:08:13<@kent\n> I think the AT howto should be generalised with toggles/notes for "And if you're working on XARCH do this also"
+2016-09-18 22:08:21<@kent\n> as opposed to every arch having their own testing FAQ
+2016-09-18 22:08:37<@jmorgan> https://wiki.gentoo.org/wiki/Arch_testing_guide, https://wiki.gentoo.org/wiki/Project:SPARC/Arch_tester and https://wiki.gentoo.org/wiki/Project:SPARC/Arch_tester/Procedures
+2016-09-18 22:08:39<@K_F> kent\n: likely makes sense
+2016-09-18 22:09:10<@K_F> jmorgan: maybe you and kent\n can look into it together?
+2016-09-18 22:09:12<@jmorgan> the last procedures link being the most helpful on process
+2016-09-18 22:09:29<@jmorgan> K_F: sure
+2016-09-18 22:09:56<@K_F> I'll set up gitolite with access to your keys in ldap later on then
+2016-09-18 22:10:16<@kent\n> when you ask me to look into it, my autism kicks in and doesn't know what you're talking about any more:p
+2016-09-18 22:11:21<@jmorgan> next topic?
+2016-09-18 22:11:31<@K_F> yeah, we can move on to next
+2016-09-18 22:11:50<@K_F> jmorgan: push access will be at git+ssh://git@git.sumptuouscapital.com:2222/gentoo/wg-stable.git
+2016-09-18 22:12:36<@K_F> jmorgan: you should have access now
+2016-09-18 22:12:48-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
+2016-09-18 22:12:50<@jmorgan> K_F: ok, i;ll take a look later, thanks
+2016-09-18 22:12:52<@K_F> 4. Discussion regarding feedback from arch teams     
+2016-09-18 22:13:01<+WilliamH> Can I ask folks to do something with the document so it is easier to read?
+2016-09-18 22:13:02<@K_F> jmorgan: thank you for the feedback, that was useful
+2016-09-18 22:13:08<+WilliamH> the source I mean?
+2016-09-18 22:13:19<@K_F> WilliamH: hard-wrapping it you mean?
+2016-09-18 22:13:30<+WilliamH> K_F: Yes
+2016-09-18 22:13:31<@K_F> WilliamH: or making multiple files ?
+2016-09-18 22:13:43<+WilliamH> K_F: hard wrapping it around 72-80 chars
+2016-09-18 22:13:52<@K_F> WilliamH: makes sense. will look into that
+2016-09-18 22:14:00< dwfreed> fold -sw 80 input
+2016-09-18 22:14:41<+WilliamH> dwfreed: ?
+2016-09-18 22:14:46<@K_F> WilliamH: command to do it
+2016-09-18 22:14:49< dwfreed> ^
+2016-09-18 22:15:15<@K_F> but I'll likely do it in vim on semi-automatic basis instead
+2016-09-18 22:15:26< dwfreed> 80 is the default, apparently so you can also do just 'fold -s input'
+2016-09-18 22:15:58<+WilliamH> K_F: you use vim?
+2016-09-18 22:16:14<@K_F> WilliamH: yes
+2016-09-18 22:16:24< dwfreed> K_F: :set cc=81 will draw a red column at column 81
+2016-09-18 22:16:26<@jmorgan> anyway, back to next topic...
+2016-09-18 22:16:29<@K_F> WilliamH: well, and for tex TexmakerX
+2016-09-18 22:16:51<+WilliamH> K_F: :set textwith=<somenumber>
+2016-09-18 22:17:22<@K_F> jmorgan: yes. we've gotten 3 feedback so far
+2016-09-18 22:17:30<@K_F> jmorgan: thank you for yours :)
+2016-09-18 22:17:36<@jmorgan> no problem
+2016-09-18 22:18:37<@K_F> its curious we haven't heard back from amd64
+2016-09-18 22:19:15<@dilfridge> well
+2016-09-18 22:19:21<@dilfridge> there's noone active in amd64
+2016-09-18 22:19:42<@K_F> dilfridge: which is an issue
+2016-09-18 22:19:50<@dilfridge> I haven't seen a single non-security stabilization for amd64 for quite some time
+2016-09-18 22:20:16<@dilfridge> dev-lang/perl was picked up by ago because it was re-assigned to security@
+2016-09-18 22:20:21<@rich0_> I think for the most part maintainers are self-stabilizing on amd64, if they stabilize at all
+2016-09-18 22:20:29<+WilliamH> We all are allowed by the amd64 guys to stabilize our own packages on that arch but no one does.
+2016-09-18 22:20:38-!- mode/#gentoo-wg-stable [+v NeddySeagoon] by ChanServ
+2016-09-18 22:20:42<+WilliamH> if we have that arch
+2016-09-18 22:21:01<+WilliamH> But, yes, the amd64 team is basically dead
+2016-09-18 22:21:13<@K_F> WilliamH: which goes back a bit at documenting the self-stabilisation policy. and later on discussing if it is a good idea to do so
+2016-09-18 22:21:26<@kent\n> the ability to self-stabilize is one of the things that needed clarifying in #3
+2016-09-18 22:21:39<@K_F> we likely want to write a GLEP to replace GLEP40 that has it included if so
+2016-09-18 22:21:41<@K_F> kent\n: correct
+2016-09-18 22:23:03<+WilliamH> There are 5 devs on the amd64 team, but who knows why they aren't active.
+2016-09-18 22:23:08-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
+2016-09-18 22:23:27<@K_F> since amd64 is the most used arch (presumably) we want to discuss that , but likely better to do so on alias etc as it is a longer discussion
+2016-09-18 22:23:37<@K_F> and likely also -project
+2016-09-18 22:23:58<@K_F> but it might be a bit early to do so at this stage?
+2016-09-18 22:24:05<+WilliamH> Did you hear from x86?
+2016-09-18 22:24:09<@K_F> WilliamH: yes
+2016-09-18 22:24:30<@K_F> WilliamH: nativemad responded for x86
+2016-09-18 22:24:52<+WilliamH> K_F: what's the policy there?
+2016-09-18 22:25:10<@K_F> WilliamH: "I work on Everything if I find the time. Security bugs first, the rest
+2016-09-18 22:25:11<@K_F> mostly fifo.
+2016-09-18 22:27:05<@K_F> anyhow, I'm not sure if there is much more to discuss on the feedback at this point, makes sense to get the rest to a better state and incorporate some of the suggestions we got in the doc
+2016-09-18 22:27:32<@K_F> so lets move on to 
+2016-09-18 22:27:33<@K_F> 5. Stabilisation process                                                           
+2016-09-18 22:27:34<@K_F>    Section 5.3  
+2016-09-18 22:28:02<@K_F> we have a few comments on how the arch teams does it from 4 that haven't been worked into the docs yet
+2016-09-18 22:28:25< dwfreed> it might be a nice idea to have a machine-readable testing requirements section in metadata.xml or the ebuild or whatever
+2016-09-18 22:28:34< dwfreed> as well as a human readable one
+2016-09-18 22:29:02<@K_F> dwfreed: wouldn't it make more sense to build that into src_tests?
+2016-09-18 22:29:11<@jmorgan> i'd like to add the needing to define how to add/remove an arch but that might go in 5.1 section instead
+2016-09-18 22:29:19<@kent\n> I assume by that you mean a testing /policy/, not actual testing code.
+2016-09-18 22:29:30< dwfreed> kent\n: yes
+2016-09-18 22:29:42<@K_F> jmorgan: add/remove from stable, i.e council decision? or in general for nonstable arches?
+2016-09-18 22:29:44< dwfreed> K_F: state during src_test is not necessarily conducive to using things
+2016-09-18 22:29:45<@K_F> stable/supported
+2016-09-18 22:30:15< dwfreed> K_F: eg, RDEPEND does not have to be satisfied during src_test
+2016-09-18 22:30:31<@K_F> dwfreed: true
+2016-09-18 22:31:03<@kent\n> except when you're running Perl stuff, RDEPEND does have to be satisfied, but we've been folding RDEPEND into DEPEND for ages because of this ;)
+2016-09-18 22:31:03<@K_F> dwfreed: but would a testing stage later in the process be something for a future EAPI?
+2016-09-18 22:31:20< dwfreed> pkg_test?
+2016-09-18 22:31:23<@jmorgan> K_F: i mean adding a new arch (ppc64le of example) or removing an arch, next step after non-stable arches (no longer supported arch)
+2016-09-18 22:31:23< dwfreed> perhaps
+2016-09-18 22:31:26<@K_F> dwfreed: yes
+2016-09-18 22:31:52<@K_F> dwfreed: that can incorporate distro-specific test suites etc
+2016-09-18 22:32:00<@jmorgan> i think it makes sense to add it to an ebuild if we have some tool to take advantage of it
+2016-09-18 22:32:23<@jmorgan> otherwise, who will read notes on how to test an eabuild in the ebuild itself?
+2016-09-18 22:32:32< dwfreed> K_F: but I mean more like the maintainer declaring 'if you can emerge it, that's good enough' or 'if it merges with FEATURES=test, that's good'
+2016-09-18 22:32:40<@K_F> jmorgan: thats what I'm thinking, I'd rather prefer adding a mechanism for it that is automated
+2016-09-18 22:32:44<@jmorgan> we want the process to be easier no more complex
+2016-09-18 22:32:48 * kent\n can see you're going to want reverse-dependency based tests in pkg_test at one stage
+2016-09-18 22:32:58<@kent\n> and that's gonna be fun!
+2016-09-18 22:32:58< dwfreed> which is why I'm suggesting a machine-readable format
+2016-09-18 22:33:21< dwfreed> it really doesn't matter if you shove it in metadata.xml or a global var in the ebuild
+2016-09-18 22:33:42<@K_F> dwfreed: well, ebuild could add new tests for new features on version 
+2016-09-18 22:33:50<@K_F> metadata would need to be package wide
+2016-09-18 22:33:53< dwfreed> right
+2016-09-18 22:33:59<@jmorgan> i thinks its a great idea for the package maintainer to include details on how to test their package that can be automated or semi-automated
+2016-09-18 22:34:05< dwfreed> unless you use specifiers like maintainer does
+2016-09-18 22:34:07<@kent\n> yeah, would be better to have a key like <tests><reverse-deps>*</reverse-deps></tests> saying "for all reverse dependencies of this package, run pkg_test"
+2016-09-18 22:34:19< dwfreed> but that gets messy
+2016-09-18 22:34:21<@kent\n> or something, maybe white/black list
+2016-09-18 22:34:29< dwfreed> kent\n: yeah, that too
+2016-09-18 22:34:45<@K_F> but I'm noting it for future discussion, it is too complex to solve today
+2016-09-18 22:34:53< dwfreed> sure
+2016-09-18 22:34:54<@K_F> but I know it has been discussed previously so will try to find some discussion on it
+2016-09-18 22:35:00<@kent\n> because if you try to "ensure the reverse deps work from within pkg_test" you're going to have circularity problems
+2016-09-18 22:35:52<@K_F> jmorgan: I want to get back to your thread a bit though
+2016-09-18 22:36:07<@K_F> I think it is a good idea to add something on new arches and removal of them
+2016-09-18 22:36:26<@K_F> including process for moving it in/out of supported arches
+2016-09-18 22:36:46<@K_F> and an authorative list of arches, and not just the bugzilla statement
+2016-09-18 22:36:51<@kent\n> ++
+2016-09-18 22:36:56<@kent\n> was about to suggest the same
+2016-09-18 22:37:02<@K_F> jmorgan: could you write somethign on it to start off?
+2016-09-18 22:37:05<@kent\n> scraping profiles.desc sucks
+2016-09-18 22:37:09<@dilfridge> we might also consider improvements to profiles.desc
+2016-09-18 22:37:11<@jmorgan> right, another area for better clearification
+2016-09-18 22:37:32<@jmorgan> K_F: sure, will send to wg alias
+2016-09-18 22:37:36<@K_F> jmorgan: thanks
+2016-09-18 22:37:48<@dilfridge> right now people seem to imply "stable profile in profiles.desc -> stable arch" but that makes only limited sense
+2016-09-18 22:38:00<@jmorgan> just to add, i think we need coucil approval to add / remove new arch
+2016-09-18 22:38:08<@K_F> jmorgan: for supported arches, sure
+2016-09-18 22:38:15<@dilfridge> (or let vapier just do it)
+2016-09-18 22:38:17<@jmorgan> as its a real cost in terms of infrastructure and support time
+2016-09-18 22:38:22<@K_F> I'm not sure for non-supported, that can likely be done in dev/exp without council
+2016-09-18 22:38:53 * WilliamH doesn't think we need to worry about dev/exp as much
+2016-09-18 22:38:58<@K_F> but having some policy discussion on that part and documenting it makes sense
+2016-09-18 22:39:09<@jmorgan> K_F: well, what i move x86 to dev/exp for example;)
+2016-09-18 22:39:09<@K_F> WilliamH: agreed
+2016-09-18 22:39:44<@K_F> jmorgan: yes, I think that becomes the boundry, if moving in/out of dev/exp it requires council approval
+2016-09-18 22:40:27<+WilliamH> moving to stable requires council approval I would say, but I think they can just notify the council if they move out of stable...
+2016-09-18 22:40:39<@K_F> WilliamH: I'm not sure if that makes sense
+2016-09-18 22:40:47<+WilliamH> There's not a reason the council should stop an arch from moving out of stable...
+2016-09-18 22:40:51<@K_F> it should require approval bi-directional
+2016-09-18 22:41:16<+WilliamH> K_F: why should moving back to dev or exp require approval?
+2016-09-18 22:41:21<@K_F> WilliamH: it can be strategic reasons to want to support the arch
+2016-09-18 22:41:34<@K_F> and certainly something that should be discussed
+2016-09-18 22:41:38<@jmorgan> WilliamH: i'm thinking of asituation where a non-arch dev moves that arch to dev/exp
+2016-09-18 22:41:39<@K_F> not done on a whim
+2016-09-18 22:41:49<@kent\n> I think its more a problem that nobody other than council really have authority for such a large decision that affect so many people
+2016-09-18 22:42:26<+WilliamH> jmorgan: non-arch-team members more than likely shouldn't do that... maybe qa, but that's about it....
+2016-09-18 22:42:44<@K_F> WilliamH: so a consistent policy is required :)
+2016-09-18 22:42:56<@jmorgan> WilliamH: right, so making it both ways (add/remove) protects us from that situation, is my comment
+2016-09-18 22:43:02<@K_F> yup
+2016-09-18 22:43:34<@kent\n> I mean, we required council decisions for ffmpeg and things, iirc, and you think "stability of an entire arch" is less contentuous than that?
+2016-09-18 22:43:38<@jmorgan> not that we have seen angry devs do things on their own to piss off other devs ever in gentoo ;)
+2016-09-18 22:44:03<@K_F> but lets continue working on that and see where we end up
+2016-09-18 22:44:03< dwfreed> I'm going to make 1 comment out of order, because I'm about to fall asleep; re bugzilla workflow, no complaints, my only suggestion is that IN_TESTING not have any kind of "resolution" state so that it shows up in default searches; default searches include "Resolution: ---" which will only match bugs not RESOLVED (also skipped the old VERIFIED state); this seems pretty logical, so I doubt
+2016-09-18 22:44:06<+WilliamH> jmorgan: Gentoo devs doing things to piss people off? ;-)
+2016-09-18 22:44:09< dwfreed> there'll be any contention here
+2016-09-18 22:44:15<@K_F> dwfreed: sounds good, lets move on to that point
+2016-09-18 22:44:20<@K_F> 7. Bugzilla workflow                                                               
+2016-09-18 22:45:03<@K_F> dwfreed: that is the thinking, it is a non-resolved state
+2016-09-18 22:45:14< dwfreed> cool
+2016-09-18 22:45:18< dwfreed> with that, I'm going to sleep
+2016-09-18 22:45:22<@K_F> dwfreed: g'night
+2016-09-18 22:47:06<@jmorgan> so i like the comments on bugs workflow, my only thought is i'd like to remove stablereq from bugzilla and it be done via another tool/process (this might be a future topic)
+2016-09-18 22:47:33<@K_F> jmorgan: I'm not sure I agree with it
+2016-09-18 22:47:40<@K_F> but sure, lets discuss it a bit
+2016-09-18 22:47:46<@dilfridge> jmorgan: that makes sense, but it's a chicken and egg problem
+2016-09-18 22:47:53<@K_F> the reason I'm against that de-coupling is it removes maintainer awareness
+2016-09-18 22:47:58<@dilfridge> and we have a long history of producing non-viable webapps
+2016-09-18 22:48:19<@K_F> and it is maintainer responsibility to ensure it is in stable if it fixes bugs of importance
+2016-09-18 22:48:25<@kent\n> GSOC have a long history of producing nothing too
+2016-09-18 22:48:42<@K_F> and having many tools to work with increases complexity
+2016-09-18 22:49:08<@jmorgan> ok, i'll come back to this in open floor for new tool/process ;)
+2016-09-18 22:49:12 * kent\n suspects a lot of our problems actually stem from portage's own design
+2016-09-18 22:49:28<@K_F> kent\n: how so?
+2016-09-18 22:49:47<@kent\n> ie: you ever tried wrapping portage to get out a "Canonical" ( as in, metadata cache ready ) versions of ebuilds?
+2016-09-18 22:49:51<@kent\n> its self abuse.
+2016-09-18 22:50:28<@kent\n> so when you want to write tools that rely on this data ...
+2016-09-18 22:50:35<@dilfridge> kent\n: you are thinking of automatic extraction of dependencies from the ebuild,e.g.?
+2016-09-18 22:51:07<@kent\n> yeah. Anything you want to write that helps us do our job ultimately needs to be able to look inside the ebuilds to understand them
+2016-09-18 22:51:17<@kent\n> and it has to be better than "regex?" because its bash.
+2016-09-18 22:52:53<@kent\n> and the pipeline from "repoman" to "a md5 cache version of the sourced ebuild"  is really filled with a shitshow
+2016-09-18 22:53:12<@K_F> kent\n: have you looked into the libebuild GSoC project?
+2016-09-18 22:53:20<@kent\n> just ask xiaomao ... anyone who touches that is luckly to leave with their sanity attached.
+2016-09-18 22:53:25<@kent\n> not quite.
+2016-09-18 22:54:12<@K_F> kent\n: for our purposes we're talking more about the data in VDB though
+2016-09-18 22:54:13<@kent\n> but like, repos.conf being communicated via  setting a variable to the contents of that file, and then passed around the call stack, is not what I'd consider "great"
+2016-09-18 22:54:26<@K_F> and not dynamic dependencies
+2016-09-18 22:54:30<@kent\n> Right, VDB is much easier to work with
+2016-09-18 22:54:50<@kent\n> but the problem is doing portage work needs you do deal with entries that aren't installed
+2016-09-18 22:54:56<@kent\n> so they're not in the VDB
+2016-09-18 22:55:17-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
+2016-09-18 22:55:20<@K_F> kent\n: won't it be installed in the chroot the testing is done in?
+2016-09-18 22:55:31<@K_F> so we should still use VDB at that point
+2016-09-18 22:55:39<@K_F> to test consistency similar to what users see
+2016-09-18 22:55:49<@kent\n> thats good, but that's not good for "oh, are my keywords non shit?"
+2016-09-18 22:56:08<@kent\n> the amount of garbage you wade through just to check your keywords are consistent is .... well, not great.
+2016-09-18 22:57:11<@K_F> ok, I think we're over to 
+2016-09-18 22:57:12<@K_F> 8. Open floor   
+2016-09-18 22:57:55<+WilliamH> I want some kind of way to move forward on stable requests after a timeout if the arch teams don't respond.
+2016-09-18 22:58:01<@K_F> kent\n: but I'm not sure I understand your concern. could you write a bit of a memo and send it to alias for discussion?
+2016-09-18 22:58:08<@jmorgan> so we need to work on better stabalization tools and process then how to automate it
+2016-09-18 22:58:10<@K_F> with some references and examples etc
+2016-09-18 22:58:32<@kent\n> K_F: its kinda hard to explain and understand unless you've ever tried dealing with ebuild.sh and friends directly.
+2016-09-18 22:59:07<@jmorgan> WilliamH: yes, i think timelines need to be revisited along the how we do things (process) discussion
+2016-09-18 22:59:09<@K_F> kent\n: I do use the tools, but would be helpful to have a more complete writeup for it
+2016-09-18 22:59:40<@K_F> WilliamH: yes, that is part of the discussion, including 5.4
+2016-09-18 22:59:42<@kent\n> and once you understand the problem, its hard to explain it in terms that are understandable to an outsider.
+2016-09-18 22:59:48<+WilliamH> jmorgan: case in point the openrc stabilization bug that is open.
+2016-09-18 23:00:13<@K_F> WilliamH: but it comes down to what the consequence is for end-users of not having latest stable
+2016-09-18 23:00:25<@K_F> i.e are there severe bugs to it, including security vulns
+2016-09-18 23:00:36<@K_F> otherwise, staying on a lower version might not be an issue
+2016-09-18 23:00:45<+WilliamH> K_F: it also comes down to there may be new features in the latest stable.
+2016-09-18 23:01:05<+WilliamH> K_F: stabilization shouldn't just be based on bug fixes or security issues.
+2016-09-18 23:01:42<@K_F> WilliamH: that comes back to 5.4 Stable tree freshness
+2016-09-18 23:01:56<+WilliamH> K_F: that should be driven by the maintainer.
+2016-09-18 23:02:04<@K_F> but for a stable user, the need for that functionality might not be severe
+2016-09-18 23:02:43<@jmorgan> so why don't we stabilize ebuilds on time?
+2016-09-18 23:03:28<@K_F> jmorgan: that is the overall discussion, but if needing to prioritize, security, bug fixes, new features might not be the wrong order of things
+2016-09-18 23:03:50<@K_F> (which seems consistent with the feedback)
+2016-09-18 23:04:08<@K_F> a user always wanting latest and greatest will be in testing
+2016-09-18 23:04:22<@jmorgan> my thought is the the process for doing so is not easy (need scripts to automate it) and its just boring over long term
+2016-09-18 23:04:26<@jmorgan> a coupld of ideas:
+2016-09-18 23:04:31<@K_F> so for stability purposes, in order to releave arch teams of requests, it might not be necessary to stabilize all versions
+2016-09-18 23:04:53<+WilliamH> K_F: that is what the maintainer should decide, not a global policy.
+2016-09-18 23:04:55<@K_F> jmorgan: sure, lets hear your ideas on it
+2016-09-18 23:05:25<@jmorgan> moving to a arch specific overlay when needing to remove last stable version
+2016-09-18 23:05:58<+WilliamH> K_F: I will be loudly against a global policy that mandates which versions of a package a maintainer can or can't stabilize.
+2016-09-18 23:06:36<@jmorgan> 2) have some thinking on what can be auto-stabilized, for example build only testing is fine
+2016-09-18 23:06:58<+WilliamH> K_F: maybe some way to allow minor bug fixes to go straight to stable without going through the arch teams would help.
+2016-09-18 23:07:18<@K_F> jmorgan: from my point of view, it is dependent on upstream policies on backwards compatibility
+2016-09-18 23:07:27<@jmorgan> 3) assuming automating build only testing (with no failures), auto-stabilize after 90 days
+2016-09-18 23:07:33<+WilliamH> K_F: so if there is 1.0 and 1.0.1 is bug fixes and 1.0 is stable 1.0.1 can go straight to stable.
+2016-09-18 23:07:40<@K_F> jmorgan: if upstream has a strong no-breakage policy, new point releases can likely be automated or at least with shorter time in testing than 30 days
+2016-09-18 23:08:02<@K_F> but likely want to hold off on new branches from same upstream, as that can break backwards compat
+2016-09-18 23:08:24<@jmorgan> yes (both), let's look at the impact of auto-stabilization
+2016-09-18 23:08:25<@K_F> jmorgan: without some consideration of that, auto-stabilization to me sounds counter intuitive
+2016-09-18 23:08:29<@K_F> as it reduces the user experience
+2016-09-18 23:09:03<@K_F> i.e upstream releases new version 2 from 1.1.30, should that be auto-stabilized after 90 days as a matter of policy?
+2016-09-18 23:09:12<@jmorgan> K_F: besides, looking at it from a best practices perspective, what is the impact? users find bugs?
+2016-09-18 23:09:32<@K_F> jmorgan: say it breaks 100 servers
+2016-09-18 23:09:54<@jmorgan> again some of the details need to be flushed out, like make releases might be an exception
+2016-09-18 23:10:07<+WilliamH> I would change it to,
+2016-09-18 23:10:08<@K_F> jmorgan: I'm worried because many upstreams don't do proper release management
+2016-09-18 23:10:29<+WilliamH> if something has been sitting with a stable request with no blockers for 90 days it goes automatically to stable.
+2016-09-18 23:10:31<@jmorgan> K_F:i think it depends on arch
+2016-09-18 23:10:40<@K_F> jmorgan: it becomes a maintainer responsibility to be aware of the upstream policies
+2016-09-18 23:10:46<@jmorgan> for ia64, 100 users would be fantastic ;)
+2016-09-18 23:10:47<+WilliamH> you can check for blockers in bz.
+2016-09-18 23:11:47<@K_F> WilliamH: that depends on whether it has been tested in various configurations
+2016-09-18 23:11:56<+WilliamH> jmorgan: the other side of that coin is, should ia64 even be a stable arch?
+2016-09-18 23:12:36<@jmorgan> WilliamH: yes its a good question and one that the council needs to bottom out on
+2016-09-18 23:12:53<@jmorgan> WilliamH: the requirement for starting something in gentoo is too low
+2016-09-18 23:13:04<@jmorgan> WilliamH: then you are left with maintaining it
+2016-09-18 23:13:10<@K_F> jmorgan: I tend to agree with that
+2016-09-18 23:13:27<@jmorgan> WilliamH: this goes back to my comment on how to add/remove archs
+2016-09-18 23:13:39<+WilliamH> jmorgan: the problem is there's no way to quantify how many users are on a specific arch etc.
+2016-09-18 23:13:42<@jmorgan> there are no requirements in this area
+2016-09-18 23:13:54<@jmorgan> WilliamH: yes, we can't control users only devs
+2016-09-18 23:14:28<@jmorgan> for example, to start a new dev you need two active devs at all times + hardware in a shared gentoo lab for devs to use
+2016-09-18 23:14:36<@jmorgan> start a new arch
+2016-09-18 23:14:48<+WilliamH> K_F: back to what you said about testing in various configurations. The maintainer can't do all of it, that's what ~arch is for.
+2016-09-18 23:14:54<@jmorgan> we have no such thinking in gentoo
+2016-09-18 23:15:19<@K_F> jmorgan: well, we would have some considerations of that for council to approve it as supported arch
+2016-09-18 23:15:53<@jmorgan> K_F: i'll type up my thoughts when i send out the email on this topic
+2016-09-18 23:16:00<@K_F> jmorgan: sounds good
+2016-09-18 23:16:10<@K_F> WilliamH: I think it boils down to asymmetric risk
+2016-09-18 23:16:31<@K_F> it is worse to break 100 servers in stable than for some stable users not to have the latest functionality
+2016-09-18 23:17:02<@K_F> so more time in ~arch might not, itself, be a bad thing
+2016-09-18 23:17:05<@K_F> depending on context
+2016-09-18 23:17:49<@K_F> but lets wrap up the meeting
+2016-09-18 23:18:00<@K_F> we can continue discussing things, thanks for showing up folks
+2016-09-18 23:18:01<@jmorgan> so let's say you move ~arch to arch and it breaks 100 servers, how could we have caught that defect before the 100 servers user?
+2016-09-18 23:18:21 * WilliamH agrees with jmorgan 
+2016-09-18 23:18:31<@K_F> jmorgan: it depends on reason for breakage
+2016-09-18 23:18:38<@jmorgan> that is the nature of software testing
+2016-09-18 23:18:44<@K_F> jmorgan: proper stabilisation testing and unit tests would be one answer
+2016-09-18 23:18:55<@jmorgan> im not arguing either way, just fostering discussion
+2016-09-18 23:18:57<@K_F> but you need to have the test suites defined
+2016-09-18 23:19:04<@jmorgan> let me give an example,
+2016-09-18 23:19:07<@K_F> for use-case testing, not only build testing
+2016-09-18 23:19:27<@jmorgan> on sparc, about a year ago nfs stopped working for me
+2016-09-18 23:19:52<@K_F> jmorgan: but for stable, not having the new version, if it doesn't fix security or severe bug.. it would be better off not having that new version in stable at that point
+2016-09-18 23:20:02<@K_F> jmorgan: ouch
+2016-09-18 23:20:11<@jmorgan> come to find out in the last month, it was due to a kernl bug
+2016-09-18 23:20:33<@jmorgan> so rsync and ssh was affected as well
+2016-09-18 23:20:52<@jmorgan> it wasn't becuase of lack of testing, it is just a defect
+2016-09-18 23:21:54<@jmorgan> we have had this unknow issue causing seg faults but didn't know why
+2016-09-18 23:22:20<@jmorgan> my point is that somethings those things happen and nothing i could do to find it
+2016-09-18 23:22:31<@jmorgan> a sparc kernel dev who likes gentoo found it
+2016-09-18 23:22:59<@jmorgan> anyhoot, good discussion. it well for our first meeting
+2016-09-18 23:23:00<@jmorgan> thanks
+2016-09-18 23:26:20<+WilliamH> K_F: what I'm hearing you say is, once a version of a package is in stable, no new versions should go there unless they fix a security issue or severe bug.
+2016-09-18 23:26:44<+WilliamH> K_F: that doesn't make any sense to me.
+2016-09-18 23:27:42<@K_F> WilliamH: no, thats not what I'm saying
+2016-09-18 23:28:01<@K_F> but it shouldn't be auto-stabilised
+2016-09-18 23:28:05<@K_F> just for the sake of it
+2016-09-18 23:28:36<+WilliamH> K_F: it shouldn't sit in ~ for years if there are no blockers and if there is a stable req open.
+2016-09-18 23:28:45< veremit> any -r should be candidates for a fast0stable
+2016-09-18 23:28:54< veremit> multiple stable versions is surely fine?!
+2016-09-18 23:29:46<@K_F> veremit: depends on what it fixes
+2016-09-18 23:30:09< veremit> K_F: well ..assuming its based of a previous -r stable?
+2016-09-18 23:30:39<+WilliamH> K_F: what I'm not interested in is a global list of criteria that have to be met before a maintainer can stabilize a new version of a package.
+2016-09-18 23:30:40<@K_F> veremit: there are examples of one-liners breaking things that wasn't considered
+2016-09-18 23:30:55< veremit> K_F: hmm alwats the edge case lol
+2016-09-18 23:31:23<+WilliamH> K_F: The maintainer knows the package best and therefore should be able to open stable reqs for whatever version he chooses.
+2016-09-18 23:31:55<@K_F> WilliamH: opening stable reqs, yes. I'm opposing auto-stabilisation
+2016-09-18 23:32:27< veremit> I'm not sure auto-stab. will ever happen in gentoo
+2016-09-18 23:32:37< veremit> but the process needs to be better honed-down
+2016-09-18 23:32:42<@K_F> veremit: we're already approving it for kernel
+2016-09-18 23:33:13< veremit> K_F: I never noticed a problem with kernel sources .. the individuals responsible for g-s seem to be doing a fine job from what I See
+2016-09-18 23:33:14<@K_F> veremit: and that is the current discussion, 90 days if non-action by arch team -> auto stable
+2016-09-18 23:33:27<+WilliamH> K_F: If I open a stable req, and arch teams sit on it for months with no activity, as the maintainer, I want to stable it everywhere and stop waiting.
+2016-09-18 23:33:33<@jmorgan> for auto-stabilization, i think it depends on the arch
+2016-09-18 23:33:36< veremit> I'd rather use a matured stable kernel .. than a auto-stab. bleeding edge
+2016-09-18 23:33:45< veremit> WilliamH++
+2016-09-18 23:33:52<@K_F> veremit: only LTS point releases will be auto stabilised
+2016-09-18 23:33:57<@jmorgan> i would agree with K_F for amd64 but might not for ia64
+2016-09-18 23:34:28< veremit> WilliamH: we need a better process where maintainers can do at least part of the work .. but its not such a black-box as it is now
+2016-09-18 23:34:43<@K_F> jmorgan: yeah, might make sense to differentiate a bit on that, but it comes down to what stability guarantee we make
+2016-09-18 23:35:29<+WilliamH> K_F: I'm definitely not railing against arch teams. All I'm saying is, if a stable req is opened, after a timeout, I want to stabilize everywhere as the maintainer and move on.
+2016-09-18 23:35:30<@jmorgan> K_F: i guess my ia64 example would be the other side of dev/exp profile ;)
+2016-09-18 23:36:04<@K_F> jmorgan: yup
+2016-09-18 23:36:56<@K_F> WilliamH: which comes down to a question of which arches should be supported arches
+2016-09-18 23:37:20<@jmorgan> agree with K_F here
+2016-09-18 23:37:51<@jmorgan> we need a better way to deal with non-supported arch though
+2016-09-18 23:37:52< veremit> K_F: primary arches and secondary arches maybe?
+2016-09-18 23:38:00<@K_F> veremit: we already have that
+2016-09-18 23:38:07< veremit> hmm
+2016-09-18 23:38:14<@jmorgan> K_F: how?
+2016-09-18 23:38:24<@K_F> jmorgan: dev/exp
+2016-09-18 23:38:27< veremit> why aren't people/policies using it?!
+2016-09-18 23:38:33< veremit> oh.
+2016-09-18 23:38:42<@jmorgan> i would argue that gentoo "supports" mips even though its dev/exp
+2016-09-18 23:38:50<+WilliamH> veremit: https://bugs.gentoo.org/show_bug.cgi?id=588786 is a good example. jmorgan  gave me the ok to stable on his arches a few days ago, but x86 is still not there.
+2016-09-18 23:39:06<@K_F> jmorgan: ok, supported/stable arches then
+2016-09-18 23:39:51<@K_F> jmorgan: but that comes down to properly defining that list
+2016-09-18 23:40:06< veremit> could we better define 'fast-lane' and 'slow-lane' arches .. based on manpower and stabilisation times?
+2016-09-18 23:40:08<@K_F> and movement requiring council approval as discussed above
+2016-09-18 23:40:17<@jmorgan> i thought about coming up with a sparc.git repo for /etc/portage that defined every stable package ;)
+2016-09-18 23:40:20<+WilliamH> stable arches are the ones with a stable entry in profiles
+2016-09-18 23:40:37< veremit> WilliamH: but what does that mean ?!
+2016-09-18 23:41:19< veremit> and do they ever get reviewd? or do they just sit there ...
+2016-09-18 23:41:36<+WilliamH> veremit: it means that by default repoman yells if we break their depgraph, so if we have a stable version of a package we can't remove it without stabling a newer version.
+2016-09-18 23:41:42<@K_F> veremit: marking it stable requires council approval
+2016-09-18 23:41:52<@jmorgan> WilliamH: i'd gentoo to say we suport arch that have hardware that is actively being developed --> amd64, arm, powerpc(power8), sparc(new T processors) perhaps those are ones we offically support
+2016-09-18 23:42:09<@jmorgan> the others are something else
+2016-09-18 23:42:39<@K_F> in my experience, hppa, alpha are amongst the quickest to respond these days
+2016-09-18 23:43:16< veremit> <@K_F> veremit: marking it stable requires council approval <= means nothing :)
+2016-09-18 23:43:22< veremit> WilliamH: fair enough
+2016-09-18 23:43:27<+WilliamH> It's definitely weird that one of the most widely used arches (amd64) is so far behind on stabilizations.
+2016-09-18 23:43:35< veremit> WilliamH: lack of resources
+2016-09-18 23:43:43<@jmorgan> K_F: yes, but why? because they have the right tools/process and workflow
+2016-09-18 23:44:10< veremit> jmorgan: +1
+2016-09-18 23:44:14<@jmorgan> K_F: if everyone do what alpha, hppa do, then I don't think we would have this probelm
+2016-09-18 23:44:25< veremit> so whats their secret?
+2016-09-18 23:44:37<@K_F> veremit: devs using the arches and caring for it internally
+2016-09-18 23:44:45<@jmorgan> i can't find out, ancient chineese secret ;)
+2016-09-18 23:45:00<+WilliamH> as an example of what I would do if policy allowed it,
+2016-09-18 23:45:00<@K_F> veremit: I suspect many devs on amd64 are ~arch
+2016-09-18 23:45:16<+WilliamH> Right now I would stabilize openrc-0.21.7 on x86.
+2016-09-18 23:45:39<@K_F> WilliamH: has it been tested on it?
+2016-09-18 23:45:44<@K_F> either on gentoo infra or otherwise?
+2016-09-18 23:45:56<+WilliamH> K_F: unknown; there are now x86 specific bug reports.
+2016-09-18 23:45:58<@jmorgan> can't we test x86 in a kvm vm?
+2016-09-18 23:46:10<@K_F> jmorgan: certainly better than nothing
+2016-09-18 23:46:30<@jmorgan> if it fails on real hardware, then its a defect
+2016-09-18 23:46:34<@K_F> jmorgan: for x86 that'd likely be sufficient, I'd be more concerned with emulation for fridnge arches
+2016-09-18 23:47:01 * WilliamH wonders if x86 is almost a fringe arch now adays? ;-)
+2016-09-18 23:47:03<@jmorgan> hey, hey, hey.. who you calling frindge arch ;)
+2016-09-18 23:47:25<+WilliamH> jmorgan: heh
+2016-09-18 23:47:51< veremit> lol
+2016-09-18 23:48:51<+WilliamH> veremit: another way to think about stable vs dev/exp profiles is, if an arch is dev/exp the arch team is fully responsible for maintaining a stable depgraph if they want one.
+2016-09-18 23:49:11< veremit> WilliamH: sounds good
+2016-09-18 23:49:18<+WilliamH> veremit: That's what repoman -d or -e are for.
+2016-09-18 23:50:08<@jmorgan> well, its a major pain once an arch goes dev/exp, i hear
+2016-09-18 23:51:29<+WilliamH> jmorgan: I would guess it could be, yes, because maintainers remove things etc so the arch team would have to keep up with what was happening.
+2016-09-18 23:51:45<@jmorgan> ok, got some other things to do. good discussion. thanks again
+2016-09-18 23:52:20<@K_F> jmorgan: have a nice evening, thanks for participating