(docs/meeting-logs) Add agenda and log from 2016-09-18 meeting
[gentoo/wg-stable.git] / docs / meeting-logs / 2016-09-18-wg-meeting.txt
1 2016-09-18 00:34:05-!- Irssi: #gentoo-wg-stable: Total of 16 nicks [7 ops, 0 halfops, 4 voices, 5 normal]
2 2016-09-18 00:35:18-!- Irssi: Join to #gentoo-wg-stable was synced in 79 secs
3 2016-09-18 03:43:10-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
4 2016-09-18 08:09:00-!- mode/#gentoo-wg-stable [+v graaff] by ChanServ
5 2016-09-18 09:06:37-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
6 2016-09-18 14:40:46-!- mode/#gentoo-wg-stable [+v K_F] by ChanServ
7 2016-09-18 15:42:58-!- mode/#gentoo-wg-stable [+o K_F] by ChanServ
8 2016-09-18 16:06:31-!- mode/#gentoo-wg-stable [+v WilliamH] by ChanServ
9 2016-09-18 17:09:01<@jmorgan> might want to put something about today's meeting in topic
10 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
11 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
12 2016-09-18 19:58:23<@K_F> 1h warning
13 2016-09-18 19:59:02<@jmorgan> its not starting now, but an hour?
14 2016-09-18 19:59:48<@K_F> correct
15 2016-09-18 20:00:14<@jmorgan> stupid daylight savings time mixed me up ;)
16 2016-09-18 20:00:22<@K_F> jmorgan: :)
17 2016-09-18 20:00:22<+graaff> date -u helped me out
18 2016-09-18 20:00:59<@jmorgan> nice, i'm going to use that (date -u)
19 2016-09-18 20:03:36<+graaff> K_F: for the agenda: perhaps include a feedback round on the document so far?
20 2016-09-18 20:04:20<@K_F> graaff: sounds good to me, early , late..?
21 2016-09-18 20:04:47<+graaff> I'd do it early, but probably needs timeboxing.
22 2016-09-18 20:04:49<@K_F> can start off with it
23 2016-09-18 20:05:46<+graaff> Yes, that way we can collect things that are still missing before going into more detailed discussion.
24 2016-09-18 21:00:01<@K_F> Roll Call
25 2016-09-18 21:00:20 * K_F here
26 2016-09-18 21:00:45 * graaff present
27 2016-09-18 21:00:50<@jmorgan> jmorgan (ia64,sparc,ppc*)
28 2016-09-18 21:00:54 * dilfridge mostly present
29 2016-09-18 21:01:34 * WilliamH here, but not actually a member of the wg
30 2016-09-18 21:02:04<@K_F> WilliamH: thats better than the opposite (not here and member)
31 2016-09-18 21:02:14<+WilliamH> heh
32 2016-09-18 21:03:07<@K_F> so we have 3 members + 2 non-members present so far
33 2016-09-18 21:03:46<@rich0> I'm semi-here :)
34 2016-09-18 21:03:52< dwfreed> I'm around, though I count for even less
35 2016-09-18 21:04:15<@K_F> ok good, 4+3 
36 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
37 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
38 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.
39 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
40 2016-09-18 21:06:24<@K_F> so Item 1 on agenda is 1. General discussion about the report so far
41 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
42 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
43 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.
44 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.
45 2016-09-18 21:08:11<@dilfridge> graaff++ (see the perl mess)
46 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
47 2016-09-18 21:08:55<@dilfridge> ok
48 2016-09-18 21:08:59<@dilfridge> wfm
49 2016-09-18 21:09:02<+graaff> K_F: +1
50 2016-09-18 21:09:25< dwfreed> agree
51 2016-09-18 21:10:02<@K_F> graaff: can you elaborate a bit more on that point
52 2016-09-18 21:10:17<@K_F> i.e pending stable bugs preventing additional stabilization requests
53 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
54 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).
55 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?
56 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.
57 2016-09-18 21:11:50<@K_F> or wanted state for that matter (and/or both on some level)
58 2016-09-18 21:12:06<+graaff> K_F: yes, second paragraph starting with "A common developer complaint"
59 2016-09-18 21:12:36<@K_F> graaff: Gotcha, can you file a pull request or format-patch with suggested text?
60 2016-09-18 21:12:36<+graaff> The problem with this specific situation is that it is a multiplier for the stable delays.
61 2016-09-18 21:12:44<@jmorgan> let's sections for clearity, IE section 4,
62 2016-09-18 21:12:54<@jmorgan> let's add sections..
63 2016-09-18 21:12:58 * graaff should use that trick in his own meetings...
64 2016-09-18 21:13:00<+graaff> ok
65 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
66 2016-09-18 21:14:49<+WilliamH> jmorgan: ?
67 2016-09-18 21:14:55<@K_F> jmorgan: for Table 1 you mean?
68 2016-09-18 21:14:59<@jmorgan> yes
69 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.
70 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.
71 2016-09-18 21:16:10< dwfreed> see openrc, for example
72 2016-09-18 21:16:24< dwfreed> still waiting on x86 to stable 0.21.7
73 2016-09-18 21:16:38< dwfreed> bug 588786 for reference
74 2016-09-18 21:16:41<@jmorgan> WilliamH: it would tell you if that package is getting run time tested on a specific arch
75 2016-09-18 21:16:58<+WilliamH> jmorgan: not necessarily
76 2016-09-18 21:17:22 * dilfridge inserts random remark about gentoostats and buggers off again...
77 2016-09-18 21:17:23<@jmorgan> unless its a build only bugzilla
78 2016-09-18 21:18:38<+WilliamH> jmorgan: I'm not following?
79 2016-09-18 21:18:45<@K_F> well, if a package is working perfectly fine it wouldn't have defects listed for it :)
80 2016-09-18 21:19:01<@jmorgan> bugzilla is a tool to track defects (traditionally)
81 2016-09-18 21:19:21<@jmorgan> gentoo uses it to also track tasks (stablereq/keywordreq for example)
82 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
83 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
84 2016-09-18 21:20:30<@jmorgan> which was pointed out a problem in the last paragraph of 5.3
85 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
86 2016-09-18 21:21:37<+WilliamH> jmorgan: not necessarily, that assumes that everyone files bugs on bugzilla.
87 2016-09-18 21:21:57<@K_F> WilliamH: if its not on bugzilla it doesn't exist
88 2016-09-18 21:22:06<+WilliamH> jmorgan: what you really want, like dilfridge  says is gentoo-stats.
89 2016-09-18 21:22:08<@jmorgan> WilliamH: well we can't work of of undocumented things ;)
90 2016-09-18 21:22:47<+WilliamH> K_F: that could also mean that the testing is going fine on the arches. :-)
91 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?
92 2016-09-18 21:23:08<@jmorgan> sure, let's move on
93 2016-09-18 21:23:15<+WilliamH> K_F: using that logic if things are going fine we aren't testing.
94 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
95 2016-09-18 21:24:17<@K_F> that'd be an indication of lack of runtime testing
96 2016-09-18 21:24:35<@K_F> but the point here isn't to put arches up against each other etc
97 2016-09-18 21:24:49<+WilliamH> K_F: that also assumes that everyone puts the correct version in the bugs. :-)
98 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
99 2016-09-18 21:25:28<+WilliamH> K_F: I tend to agree.
100 2016-09-18 21:27:05<@K_F> But overall, do you agree with the structure of the report?
101 2016-09-18 21:27:35<+WilliamH> K_F: It seems to be ok to me.
102 2016-09-18 21:27:41<@K_F> (it will of course need extending as more data gets added)
103 2016-09-18 21:27:49<+graaff> The one thing I find missing is the topic of manpower
104 2016-09-18 21:28:11<+WilliamH> graaff: it is briefly mentioned...
105 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.
106 2016-09-18 21:28:14<@K_F> graaff: yes, we can likely be more specific to that
107 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)
108 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
109 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
110 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?
111 2016-09-18 21:30:42<@dilfridge> since you become familiar with portage workings etc bla bla
112 2016-09-18 21:31:08<@K_F> dwfreed: any suggestions for how we could get some reasonable figures on it?
113 2016-09-18 21:31:18<+graaff> We may also enlist users to work on keywording bugs by providing build logs for those bugs.
114 2016-09-18 21:31:34<+graaff> As a maintainer I'd be happy to add the keyword in that case.
115 2016-09-18 21:31:51<@dilfridge> K_F: I could check my Perl inbox :P
116 2016-09-18 21:31:58<@dilfridge> not many
117 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
118 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
119 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
120 2016-09-18 21:33:54<+WilliamH> I'm not as concerned about keyword as I am stabilization.
121 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
122 2016-09-18 21:34:19<@K_F> dwfreed: that'd be my thinking as well
123 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)
124 2016-09-18 21:34:41<@K_F> graaff: yes, that'd be a difference as well
125 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
126 2016-09-18 21:36:01<@K_F> jmorgan: please elaborate a bit on that, I think it is an interesting thought
127 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
128 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
129 2016-09-18 21:37:25<@jmorgan> its a very labor intensive effort
130 2016-09-18 21:37:53<@K_F> jmorgan: indeed, but so is most testing unless we can improve unit/functionality tests
131 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
132 2016-09-18 21:38:30<@jmorgan> there are even arch specific hardware any gentoo dev can use to do arch testing
133 2016-09-18 21:38:31<@K_F> I see a surprising amount of applications that are being stabilized despite failing tests for instance
134 2016-09-18 21:38:41<@K_F> and not being fixed upstream
135 2016-09-18 21:38:55<@K_F> and an even scarier number of packages being stabilized without unit tests at all
136 2016-09-18 21:39:18<@jmorgan> what is the impact?
137 2016-09-18 21:39:21<+WilliamH> K_F: I'm not sure it is up to us to write those unit tests.
138 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
139 2016-09-18 21:39:54<@jmorgan> for example, build only testing as process to stablization
140 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
141 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
142 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.
143 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?
144 2016-09-18 21:42:07<@K_F> graaff: thanks
145 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.
146 2016-09-18 21:42:29<+WilliamH> K_F: that's why kmod has RESTRICT="test"
147 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
148 2016-09-18 21:44:11 * kent\n arrives about an hour late, but in my defense, I just woke up :D 
149 2016-09-18 21:44:29<@K_F> kent\n: welcome
150 2016-09-18 21:45:03<+WilliamH> kent\n: heh
151 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
152 2016-09-18 21:45:42<@K_F> as an example
153 2016-09-18 21:46:06<@K_F> so unit tests are normally useful for more than upstream/maintainer.. 
154 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
155 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
156 2016-09-18 21:50:03<@K_F> 2. Kernel stabilisation
157 2016-09-18 21:50:03<@K_F>    Kernel stabilisation is likely one of the points that is most complete and
158 2016-09-18 21:50:03<@K_F>    in line with what has already been discussed previously. Is the section of 
159 2016-09-18 21:50:03<@K_F>    how we want kernel stabilisation to work (Section 3.2) reaching completion?
160 2016-09-18 21:50:37< dwfreed> I have no objections to that section
161 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
162 2016-09-18 21:50:55< dwfreed> it may make sense to spell out the packages we want stabilized
163 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
164 2016-09-18 21:51:28<@K_F> as that is what new users will encounter
165 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
166 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
167 2016-09-18 21:51:53<@kent\n> Lint tests. etc.
168 2016-09-18 21:52:01<@K_F> although we might write something to that extent as point of process
169 2016-09-18 21:52:23-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
170 2016-09-18 21:52:31<+WilliamH> I will ask again about unrestricting the tests for kmod.
171 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"
172 2016-09-18 21:53:24<@K_F> kent\n: exactly
173 2016-09-18 21:53:27<+graaff> kent\n: on ruby we always strip coverage and code quality tests but keep all the rest
174 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.
175 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
176 2016-09-18 21:54:17 * WilliamH is fine with the kernel stuff
177 2016-09-18 21:54:17<@K_F> graaff: it was, and it was started, but got backlash, so now we provide coverage
178 2016-09-18 21:54:34<+graaff> What kind of backlash?
179 2016-09-18 21:54:53<@K_F> graaff: complaints about lack of testing / automation of it
180 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 )
181 2016-09-18 21:54:59<+WilliamH> What I would be more interested in is how many people were involved in the backlash?
182 2016-09-18 21:55:22<+WilliamH> Gentoo tends to have very small groups who can be very vocal.
183 2016-09-18 21:55:30<+graaff> WilliamH: +1
184 2016-09-18 21:55:37<+WilliamH> and create the sense that there is a lot more backlash than there is.
185 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
186 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
187 2016-09-18 21:56:10<@K_F> dwfreed: in the handbook that is?
188 2016-09-18 21:56:26< dwfreed> K_F: the handbook says 'use gentoo-sources, but here's this page with all the kernels'
189 2016-09-18 21:56:41<@K_F> dwfreed: ok, we might need to be more specific then, indeed
190 2016-09-18 21:56:47< dwfreed> which is Kernel/Overview
191 2016-09-18 21:57:27<@K_F> dwfreed: thanks for that note, will rewrite it to be more restrictive
192 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
193 2016-09-18 21:58:35< dwfreed> K_F: I would list specifically gentoo-sources and hardened-sources, and perhaps specifically exclude vanilla-sources
194 2016-09-18 21:59:09<+WilliamH> Why specifically exclude vanilla-sources? After all that is what upstream is calling lts
195 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
196 2016-09-18 21:59:33< dwfreed> WilliamH: kernel team does not stabilize vanilla sources
197 2016-09-18 21:59:36< dwfreed> only gentoo sources
198 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.
199 2016-09-18 22:00:16< dwfreed> they're the ones that decided to stop, and give good reasons for doing so
200 2016-09-18 22:00:31<+WilliamH> dwfreed: leave it up to them.
201 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
202 2016-09-18 22:00:38< dwfreed> s/give/gave/
203 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
204 2016-09-18 22:01:17< dwfreed> k
205 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.
206 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
207 2016-09-18 22:02:03<@K_F> dwfreed: I think whitelisting makes more sense
208 2016-09-18 22:02:23<@K_F> i.e only kernels the kernel team says should be stable should be stabilised
209 2016-09-18 22:02:36<@K_F> but it needs to be a superset of gentoo-sources (and maybe hardened)
210 2016-09-18 22:03:49 * WilliamH agrees with K_F 
211 2016-09-18 22:03:50<@K_F> anyhow, lets move on to item 3
212 2016-09-18 22:04:02<@K_F> 3. Documentation of current stabilisation policy and practice  
213 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?
214 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
215 2016-09-18 22:04:55 * kent\n sucks at open-ended things 
216 2016-09-18 22:04:55<@jmorgan> kent\n: jusst start an email discusion to alias
217 2016-09-18 22:05:15<@K_F> its not as much a matter of discussion, but documenting history at this point
218 2016-09-18 22:05:24 * graaff has to go
219 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
220 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
221 2016-09-18 22:05:58<@K_F> starting off with GLEP 40
222 2016-09-18 22:06:05<@K_F> there already is section 4.1
223 2016-09-18 22:06:09<@K_F> but it needs to be extended
224 2016-09-18 22:06:20<@K_F> and documented/references
225 2016-09-18 22:06:37<@jmorgan> AT howto will be helpful too
226 2016-09-18 22:07:21<@K_F> jmorgan: i.e https://wiki.gentoo.org/wiki/Project:X86/Arch_Testers_FAQ etc
227 2016-09-18 22:07:22<@K_F> ?
228 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"
229 2016-09-18 22:08:21<@kent\n> as opposed to every arch having their own testing FAQ
230 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
231 2016-09-18 22:08:39<@K_F> kent\n: likely makes sense
232 2016-09-18 22:09:10<@K_F> jmorgan: maybe you and kent\n can look into it together?
233 2016-09-18 22:09:12<@jmorgan> the last procedures link being the most helpful on process
234 2016-09-18 22:09:29<@jmorgan> K_F: sure
235 2016-09-18 22:09:56<@K_F> I'll set up gitolite with access to your keys in ldap later on then
236 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
237 2016-09-18 22:11:21<@jmorgan> next topic?
238 2016-09-18 22:11:31<@K_F> yeah, we can move on to next
239 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
240 2016-09-18 22:12:36<@K_F> jmorgan: you should have access now
241 2016-09-18 22:12:48-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
242 2016-09-18 22:12:50<@jmorgan> K_F: ok, i;ll take a look later, thanks
243 2016-09-18 22:12:52<@K_F> 4. Discussion regarding feedback from arch teams     
244 2016-09-18 22:13:01<+WilliamH> Can I ask folks to do something with the document so it is easier to read?
245 2016-09-18 22:13:02<@K_F> jmorgan: thank you for the feedback, that was useful
246 2016-09-18 22:13:08<+WilliamH> the source I mean?
247 2016-09-18 22:13:19<@K_F> WilliamH: hard-wrapping it you mean?
248 2016-09-18 22:13:30<+WilliamH> K_F: Yes
249 2016-09-18 22:13:31<@K_F> WilliamH: or making multiple files ?
250 2016-09-18 22:13:43<+WilliamH> K_F: hard wrapping it around 72-80 chars
251 2016-09-18 22:13:52<@K_F> WilliamH: makes sense. will look into that
252 2016-09-18 22:14:00< dwfreed> fold -sw 80 input
253 2016-09-18 22:14:41<+WilliamH> dwfreed: ?
254 2016-09-18 22:14:46<@K_F> WilliamH: command to do it
255 2016-09-18 22:14:49< dwfreed> ^
256 2016-09-18 22:15:15<@K_F> but I'll likely do it in vim on semi-automatic basis instead
257 2016-09-18 22:15:26< dwfreed> 80 is the default, apparently so you can also do just 'fold -s input'
258 2016-09-18 22:15:58<+WilliamH> K_F: you use vim?
259 2016-09-18 22:16:14<@K_F> WilliamH: yes
260 2016-09-18 22:16:24< dwfreed> K_F: :set cc=81 will draw a red column at column 81
261 2016-09-18 22:16:26<@jmorgan> anyway, back to next topic...
262 2016-09-18 22:16:29<@K_F> WilliamH: well, and for tex TexmakerX
263 2016-09-18 22:16:51<+WilliamH> K_F: :set textwith=<somenumber>
264 2016-09-18 22:17:22<@K_F> jmorgan: yes. we've gotten 3 feedback so far
265 2016-09-18 22:17:30<@K_F> jmorgan: thank you for yours :)
266 2016-09-18 22:17:36<@jmorgan> no problem
267 2016-09-18 22:18:37<@K_F> its curious we haven't heard back from amd64
268 2016-09-18 22:19:15<@dilfridge> well
269 2016-09-18 22:19:21<@dilfridge> there's noone active in amd64
270 2016-09-18 22:19:42<@K_F> dilfridge: which is an issue
271 2016-09-18 22:19:50<@dilfridge> I haven't seen a single non-security stabilization for amd64 for quite some time
272 2016-09-18 22:20:16<@dilfridge> dev-lang/perl was picked up by ago because it was re-assigned to security@
273 2016-09-18 22:20:21<@rich0_> I think for the most part maintainers are self-stabilizing on amd64, if they stabilize at all
274 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.
275 2016-09-18 22:20:38-!- mode/#gentoo-wg-stable [+v NeddySeagoon] by ChanServ
276 2016-09-18 22:20:42<+WilliamH> if we have that arch
277 2016-09-18 22:21:01<+WilliamH> But, yes, the amd64 team is basically dead
278 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
279 2016-09-18 22:21:26<@kent\n> the ability to self-stabilize is one of the things that needed clarifying in #3
280 2016-09-18 22:21:39<@K_F> we likely want to write a GLEP to replace GLEP40 that has it included if so
281 2016-09-18 22:21:41<@K_F> kent\n: correct
282 2016-09-18 22:23:03<+WilliamH> There are 5 devs on the amd64 team, but who knows why they aren't active.
283 2016-09-18 22:23:08-!- mode/#gentoo-wg-stable [+o rich0_] by ChanServ
284 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
285 2016-09-18 22:23:37<@K_F> and likely also -project
286 2016-09-18 22:23:58<@K_F> but it might be a bit early to do so at this stage?
287 2016-09-18 22:24:05<+WilliamH> Did you hear from x86?
288 2016-09-18 22:24:09<@K_F> WilliamH: yes
289 2016-09-18 22:24:30<@K_F> WilliamH: nativemad responded for x86
290 2016-09-18 22:24:52<+WilliamH> K_F: what's the policy there?
291 2016-09-18 22:25:10<@K_F> WilliamH: "I work on Everything if I find the time. Security bugs first, the rest
292 2016-09-18 22:25:11<@K_F> mostly fifo.
293 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
294 2016-09-18 22:27:32<@K_F> so lets move on to 
295 2016-09-18 22:27:33<@K_F> 5. Stabilisation process                                                           
296 2016-09-18 22:27:34<@K_F>    Section 5.3  
297 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
298 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
299 2016-09-18 22:28:34< dwfreed> as well as a human readable one
300 2016-09-18 22:29:02<@K_F> dwfreed: wouldn't it make more sense to build that into src_tests?
301 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
302 2016-09-18 22:29:19<@kent\n> I assume by that you mean a testing /policy/, not actual testing code.
303 2016-09-18 22:29:30< dwfreed> kent\n: yes
304 2016-09-18 22:29:42<@K_F> jmorgan: add/remove from stable, i.e council decision? or in general for nonstable arches?
305 2016-09-18 22:29:44< dwfreed> K_F: state during src_test is not necessarily conducive to using things
306 2016-09-18 22:29:45<@K_F> stable/supported
307 2016-09-18 22:30:15< dwfreed> K_F: eg, RDEPEND does not have to be satisfied during src_test
308 2016-09-18 22:30:31<@K_F> dwfreed: true
309 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 ;)
310 2016-09-18 22:31:03<@K_F> dwfreed: but would a testing stage later in the process be something for a future EAPI?
311 2016-09-18 22:31:20< dwfreed> pkg_test?
312 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)
313 2016-09-18 22:31:23< dwfreed> perhaps
314 2016-09-18 22:31:26<@K_F> dwfreed: yes
315 2016-09-18 22:31:52<@K_F> dwfreed: that can incorporate distro-specific test suites etc
316 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
317 2016-09-18 22:32:23<@jmorgan> otherwise, who will read notes on how to test an eabuild in the ebuild itself?
318 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'
319 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
320 2016-09-18 22:32:44<@jmorgan> we want the process to be easier no more complex
321 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
322 2016-09-18 22:32:58<@kent\n> and that's gonna be fun!
323 2016-09-18 22:32:58< dwfreed> which is why I'm suggesting a machine-readable format
324 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
325 2016-09-18 22:33:42<@K_F> dwfreed: well, ebuild could add new tests for new features on version 
326 2016-09-18 22:33:50<@K_F> metadata would need to be package wide
327 2016-09-18 22:33:53< dwfreed> right
328 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
329 2016-09-18 22:34:05< dwfreed> unless you use specifiers like maintainer does
330 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"
331 2016-09-18 22:34:19< dwfreed> but that gets messy
332 2016-09-18 22:34:21<@kent\n> or something, maybe white/black list
333 2016-09-18 22:34:29< dwfreed> kent\n: yeah, that too
334 2016-09-18 22:34:45<@K_F> but I'm noting it for future discussion, it is too complex to solve today
335 2016-09-18 22:34:53< dwfreed> sure
336 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
337 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
338 2016-09-18 22:35:52<@K_F> jmorgan: I want to get back to your thread a bit though
339 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
340 2016-09-18 22:36:26<@K_F> including process for moving it in/out of supported arches
341 2016-09-18 22:36:46<@K_F> and an authorative list of arches, and not just the bugzilla statement
342 2016-09-18 22:36:51<@kent\n> ++
343 2016-09-18 22:36:56<@kent\n> was about to suggest the same
344 2016-09-18 22:37:02<@K_F> jmorgan: could you write somethign on it to start off?
345 2016-09-18 22:37:05<@kent\n> scraping profiles.desc sucks
346 2016-09-18 22:37:09<@dilfridge> we might also consider improvements to profiles.desc
347 2016-09-18 22:37:11<@jmorgan> right, another area for better clearification
348 2016-09-18 22:37:32<@jmorgan> K_F: sure, will send to wg alias
349 2016-09-18 22:37:36<@K_F> jmorgan: thanks
350 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
351 2016-09-18 22:38:00<@jmorgan> just to add, i think we need coucil approval to add / remove new arch
352 2016-09-18 22:38:08<@K_F> jmorgan: for supported arches, sure
353 2016-09-18 22:38:15<@dilfridge> (or let vapier just do it)
354 2016-09-18 22:38:17<@jmorgan> as its a real cost in terms of infrastructure and support time
355 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
356 2016-09-18 22:38:53 * WilliamH doesn't think we need to worry about dev/exp as much
357 2016-09-18 22:38:58<@K_F> but having some policy discussion on that part and documenting it makes sense
358 2016-09-18 22:39:09<@jmorgan> K_F: well, what i move x86 to dev/exp for example;)
359 2016-09-18 22:39:09<@K_F> WilliamH: agreed
360 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
361 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...
362 2016-09-18 22:40:39<@K_F> WilliamH: I'm not sure if that makes sense
363 2016-09-18 22:40:47<+WilliamH> There's not a reason the council should stop an arch from moving out of stable...
364 2016-09-18 22:40:51<@K_F> it should require approval bi-directional
365 2016-09-18 22:41:16<+WilliamH> K_F: why should moving back to dev or exp require approval?
366 2016-09-18 22:41:21<@K_F> WilliamH: it can be strategic reasons to want to support the arch
367 2016-09-18 22:41:34<@K_F> and certainly something that should be discussed
368 2016-09-18 22:41:38<@jmorgan> WilliamH: i'm thinking of asituation where a non-arch dev moves that arch to dev/exp
369 2016-09-18 22:41:39<@K_F> not done on a whim
370 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
371 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....
372 2016-09-18 22:42:44<@K_F> WilliamH: so a consistent policy is required :)
373 2016-09-18 22:42:56<@jmorgan> WilliamH: right, so making it both ways (add/remove) protects us from that situation, is my comment
374 2016-09-18 22:43:02<@K_F> yup
375 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?
376 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 ;)
377 2016-09-18 22:44:03<@K_F> but lets continue working on that and see where we end up
378 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
379 2016-09-18 22:44:06<+WilliamH> jmorgan: Gentoo devs doing things to piss people off? ;-)
380 2016-09-18 22:44:09< dwfreed> there'll be any contention here
381 2016-09-18 22:44:15<@K_F> dwfreed: sounds good, lets move on to that point
382 2016-09-18 22:44:20<@K_F> 7. Bugzilla workflow                                                               
383 2016-09-18 22:45:03<@K_F> dwfreed: that is the thinking, it is a non-resolved state
384 2016-09-18 22:45:14< dwfreed> cool
385 2016-09-18 22:45:18< dwfreed> with that, I'm going to sleep
386 2016-09-18 22:45:22<@K_F> dwfreed: g'night
387 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)
388 2016-09-18 22:47:33<@K_F> jmorgan: I'm not sure I agree with it
389 2016-09-18 22:47:40<@K_F> but sure, lets discuss it a bit
390 2016-09-18 22:47:46<@dilfridge> jmorgan: that makes sense, but it's a chicken and egg problem
391 2016-09-18 22:47:53<@K_F> the reason I'm against that de-coupling is it removes maintainer awareness
392 2016-09-18 22:47:58<@dilfridge> and we have a long history of producing non-viable webapps
393 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
394 2016-09-18 22:48:25<@kent\n> GSOC have a long history of producing nothing too
395 2016-09-18 22:48:42<@K_F> and having many tools to work with increases complexity
396 2016-09-18 22:49:08<@jmorgan> ok, i'll come back to this in open floor for new tool/process ;)
397 2016-09-18 22:49:12 * kent\n suspects a lot of our problems actually stem from portage's own design
398 2016-09-18 22:49:28<@K_F> kent\n: how so?
399 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?
400 2016-09-18 22:49:51<@kent\n> its self abuse.
401 2016-09-18 22:50:28<@kent\n> so when you want to write tools that rely on this data ...
402 2016-09-18 22:50:35<@dilfridge> kent\n: you are thinking of automatic extraction of dependencies from the ebuild,e.g.?
403 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
404 2016-09-18 22:51:17<@kent\n> and it has to be better than "regex?" because its bash.
405 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
406 2016-09-18 22:53:12<@K_F> kent\n: have you looked into the libebuild GSoC project?
407 2016-09-18 22:53:20<@kent\n> just ask xiaomao ... anyone who touches that is luckly to leave with their sanity attached.
408 2016-09-18 22:53:25<@kent\n> not quite.
409 2016-09-18 22:54:12<@K_F> kent\n: for our purposes we're talking more about the data in VDB though
410 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"
411 2016-09-18 22:54:26<@K_F> and not dynamic dependencies
412 2016-09-18 22:54:30<@kent\n> Right, VDB is much easier to work with
413 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
414 2016-09-18 22:54:56<@kent\n> so they're not in the VDB
415 2016-09-18 22:55:17-!- mode/#gentoo-wg-stable [+o blueness] by ChanServ
416 2016-09-18 22:55:20<@K_F> kent\n: won't it be installed in the chroot the testing is done in?
417 2016-09-18 22:55:31<@K_F> so we should still use VDB at that point
418 2016-09-18 22:55:39<@K_F> to test consistency similar to what users see
419 2016-09-18 22:55:49<@kent\n> thats good, but that's not good for "oh, are my keywords non shit?"
420 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.
421 2016-09-18 22:57:11<@K_F> ok, I think we're over to 
422 2016-09-18 22:57:12<@K_F> 8. Open floor   
423 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.
424 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?
425 2016-09-18 22:58:08<@jmorgan> so we need to work on better stabalization tools and process then how to automate it
426 2016-09-18 22:58:10<@K_F> with some references and examples etc
427 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.
428 2016-09-18 22:59:07<@jmorgan> WilliamH: yes, i think timelines need to be revisited along the how we do things (process) discussion
429 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
430 2016-09-18 22:59:40<@K_F> WilliamH: yes, that is part of the discussion, including 5.4
431 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.
432 2016-09-18 22:59:48<+WilliamH> jmorgan: case in point the openrc stabilization bug that is open.
433 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
434 2016-09-18 23:00:25<@K_F> i.e are there severe bugs to it, including security vulns
435 2016-09-18 23:00:36<@K_F> otherwise, staying on a lower version might not be an issue
436 2016-09-18 23:00:45<+WilliamH> K_F: it also comes down to there may be new features in the latest stable.
437 2016-09-18 23:01:05<+WilliamH> K_F: stabilization shouldn't just be based on bug fixes or security issues.
438 2016-09-18 23:01:42<@K_F> WilliamH: that comes back to 5.4 Stable tree freshness
439 2016-09-18 23:01:56<+WilliamH> K_F: that should be driven by the maintainer.
440 2016-09-18 23:02:04<@K_F> but for a stable user, the need for that functionality might not be severe
441 2016-09-18 23:02:43<@jmorgan> so why don't we stabilize ebuilds on time?
442 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
443 2016-09-18 23:03:50<@K_F> (which seems consistent with the feedback)
444 2016-09-18 23:04:08<@K_F> a user always wanting latest and greatest will be in testing
445 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
446 2016-09-18 23:04:26<@jmorgan> a coupld of ideas:
447 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
448 2016-09-18 23:04:53<+WilliamH> K_F: that is what the maintainer should decide, not a global policy.
449 2016-09-18 23:04:55<@K_F> jmorgan: sure, lets hear your ideas on it
450 2016-09-18 23:05:25<@jmorgan> moving to a arch specific overlay when needing to remove last stable version
451 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.
452 2016-09-18 23:06:36<@jmorgan> 2) have some thinking on what can be auto-stabilized, for example build only testing is fine
453 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.
454 2016-09-18 23:07:18<@K_F> jmorgan: from my point of view, it is dependent on upstream policies on backwards compatibility
455 2016-09-18 23:07:27<@jmorgan> 3) assuming automating build only testing (with no failures), auto-stabilize after 90 days
456 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.
457 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
458 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
459 2016-09-18 23:08:24<@jmorgan> yes (both), let's look at the impact of auto-stabilization
460 2016-09-18 23:08:25<@K_F> jmorgan: without some consideration of that, auto-stabilization to me sounds counter intuitive
461 2016-09-18 23:08:29<@K_F> as it reduces the user experience
462 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?
463 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?
464 2016-09-18 23:09:32<@K_F> jmorgan: say it breaks 100 servers
465 2016-09-18 23:09:54<@jmorgan> again some of the details need to be flushed out, like make releases might be an exception
466 2016-09-18 23:10:07<+WilliamH> I would change it to,
467 2016-09-18 23:10:08<@K_F> jmorgan: I'm worried because many upstreams don't do proper release management
468 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.
469 2016-09-18 23:10:31<@jmorgan> K_F:i think it depends on arch
470 2016-09-18 23:10:40<@K_F> jmorgan: it becomes a maintainer responsibility to be aware of the upstream policies
471 2016-09-18 23:10:46<@jmorgan> for ia64, 100 users would be fantastic ;)
472 2016-09-18 23:10:47<+WilliamH> you can check for blockers in bz.
473 2016-09-18 23:11:47<@K_F> WilliamH: that depends on whether it has been tested in various configurations
474 2016-09-18 23:11:56<+WilliamH> jmorgan: the other side of that coin is, should ia64 even be a stable arch?
475 2016-09-18 23:12:36<@jmorgan> WilliamH: yes its a good question and one that the council needs to bottom out on
476 2016-09-18 23:12:53<@jmorgan> WilliamH: the requirement for starting something in gentoo is too low
477 2016-09-18 23:13:04<@jmorgan> WilliamH: then you are left with maintaining it
478 2016-09-18 23:13:10<@K_F> jmorgan: I tend to agree with that
479 2016-09-18 23:13:27<@jmorgan> WilliamH: this goes back to my comment on how to add/remove archs
480 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.
481 2016-09-18 23:13:42<@jmorgan> there are no requirements in this area
482 2016-09-18 23:13:54<@jmorgan> WilliamH: yes, we can't control users only devs
483 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
484 2016-09-18 23:14:36<@jmorgan> start a new arch
485 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.
486 2016-09-18 23:14:54<@jmorgan> we have no such thinking in gentoo
487 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
488 2016-09-18 23:15:53<@jmorgan> K_F: i'll type up my thoughts when i send out the email on this topic
489 2016-09-18 23:16:00<@K_F> jmorgan: sounds good
490 2016-09-18 23:16:10<@K_F> WilliamH: I think it boils down to asymmetric risk
491 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
492 2016-09-18 23:17:02<@K_F> so more time in ~arch might not, itself, be a bad thing
493 2016-09-18 23:17:05<@K_F> depending on context
494 2016-09-18 23:17:49<@K_F> but lets wrap up the meeting
495 2016-09-18 23:18:00<@K_F> we can continue discussing things, thanks for showing up folks
496 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?
497 2016-09-18 23:18:21 * WilliamH agrees with jmorgan 
498 2016-09-18 23:18:31<@K_F> jmorgan: it depends on reason for breakage
499 2016-09-18 23:18:38<@jmorgan> that is the nature of software testing
500 2016-09-18 23:18:44<@K_F> jmorgan: proper stabilisation testing and unit tests would be one answer
501 2016-09-18 23:18:55<@jmorgan> im not arguing either way, just fostering discussion
502 2016-09-18 23:18:57<@K_F> but you need to have the test suites defined
503 2016-09-18 23:19:04<@jmorgan> let me give an example,
504 2016-09-18 23:19:07<@K_F> for use-case testing, not only build testing
505 2016-09-18 23:19:27<@jmorgan> on sparc, about a year ago nfs stopped working for me
506 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
507 2016-09-18 23:20:02<@K_F> jmorgan: ouch
508 2016-09-18 23:20:11<@jmorgan> come to find out in the last month, it was due to a kernl bug
509 2016-09-18 23:20:33<@jmorgan> so rsync and ssh was affected as well
510 2016-09-18 23:20:52<@jmorgan> it wasn't becuase of lack of testing, it is just a defect
511 2016-09-18 23:21:54<@jmorgan> we have had this unknow issue causing seg faults but didn't know why
512 2016-09-18 23:22:20<@jmorgan> my point is that somethings those things happen and nothing i could do to find it
513 2016-09-18 23:22:31<@jmorgan> a sparc kernel dev who likes gentoo found it
514 2016-09-18 23:22:59<@jmorgan> anyhoot, good discussion. it well for our first meeting
515 2016-09-18 23:23:00<@jmorgan> thanks
516 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.
517 2016-09-18 23:26:44<+WilliamH> K_F: that doesn't make any sense to me.
518 2016-09-18 23:27:42<@K_F> WilliamH: no, thats not what I'm saying
519 2016-09-18 23:28:01<@K_F> but it shouldn't be auto-stabilised
520 2016-09-18 23:28:05<@K_F> just for the sake of it
521 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.
522 2016-09-18 23:28:45< veremit> any -r should be candidates for a fast0stable
523 2016-09-18 23:28:54< veremit> multiple stable versions is surely fine?!
524 2016-09-18 23:29:46<@K_F> veremit: depends on what it fixes
525 2016-09-18 23:30:09< veremit> K_F: well ..assuming its based of a previous -r stable?
526 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.
527 2016-09-18 23:30:40<@K_F> veremit: there are examples of one-liners breaking things that wasn't considered
528 2016-09-18 23:30:55< veremit> K_F: hmm alwats the edge case lol
529 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.
530 2016-09-18 23:31:55<@K_F> WilliamH: opening stable reqs, yes. I'm opposing auto-stabilisation
531 2016-09-18 23:32:27< veremit> I'm not sure auto-stab. will ever happen in gentoo
532 2016-09-18 23:32:37< veremit> but the process needs to be better honed-down
533 2016-09-18 23:32:42<@K_F> veremit: we're already approving it for kernel
534 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
535 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
536 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.
537 2016-09-18 23:33:33<@jmorgan> for auto-stabilization, i think it depends on the arch
538 2016-09-18 23:33:36< veremit> I'd rather use a matured stable kernel .. than a auto-stab. bleeding edge
539 2016-09-18 23:33:45< veremit> WilliamH++
540 2016-09-18 23:33:52<@K_F> veremit: only LTS point releases will be auto stabilised
541 2016-09-18 23:33:57<@jmorgan> i would agree with K_F for amd64 but might not for ia64
542 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
543 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
544 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.
545 2016-09-18 23:35:30<@jmorgan> K_F: i guess my ia64 example would be the other side of dev/exp profile ;)
546 2016-09-18 23:36:04<@K_F> jmorgan: yup
547 2016-09-18 23:36:56<@K_F> WilliamH: which comes down to a question of which arches should be supported arches
548 2016-09-18 23:37:20<@jmorgan> agree with K_F here
549 2016-09-18 23:37:51<@jmorgan> we need a better way to deal with non-supported arch though
550 2016-09-18 23:37:52< veremit> K_F: primary arches and secondary arches maybe?
551 2016-09-18 23:38:00<@K_F> veremit: we already have that
552 2016-09-18 23:38:07< veremit> hmm
553 2016-09-18 23:38:14<@jmorgan> K_F: how?
554 2016-09-18 23:38:24<@K_F> jmorgan: dev/exp
555 2016-09-18 23:38:27< veremit> why aren't people/policies using it?!
556 2016-09-18 23:38:33< veremit> oh.
557 2016-09-18 23:38:42<@jmorgan> i would argue that gentoo "supports" mips even though its dev/exp
558 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.
559 2016-09-18 23:39:06<@K_F> jmorgan: ok, supported/stable arches then
560 2016-09-18 23:39:51<@K_F> jmorgan: but that comes down to properly defining that list
561 2016-09-18 23:40:06< veremit> could we better define 'fast-lane' and 'slow-lane' arches .. based on manpower and stabilisation times?
562 2016-09-18 23:40:08<@K_F> and movement requiring council approval as discussed above
563 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 ;)
564 2016-09-18 23:40:20<+WilliamH> stable arches are the ones with a stable entry in profiles
565 2016-09-18 23:40:37< veremit> WilliamH: but what does that mean ?!
566 2016-09-18 23:41:19< veremit> and do they ever get reviewd? or do they just sit there ...
567 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.
568 2016-09-18 23:41:42<@K_F> veremit: marking it stable requires council approval
569 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
570 2016-09-18 23:42:09<@jmorgan> the others are something else
571 2016-09-18 23:42:39<@K_F> in my experience, hppa, alpha are amongst the quickest to respond these days
572 2016-09-18 23:43:16< veremit> <@K_F> veremit: marking it stable requires council approval <= means nothing :)
573 2016-09-18 23:43:22< veremit> WilliamH: fair enough
574 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.
575 2016-09-18 23:43:35< veremit> WilliamH: lack of resources
576 2016-09-18 23:43:43<@jmorgan> K_F: yes, but why? because they have the right tools/process and workflow
577 2016-09-18 23:44:10< veremit> jmorgan: +1
578 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
579 2016-09-18 23:44:25< veremit> so whats their secret?
580 2016-09-18 23:44:37<@K_F> veremit: devs using the arches and caring for it internally
581 2016-09-18 23:44:45<@jmorgan> i can't find out, ancient chineese secret ;)
582 2016-09-18 23:45:00<+WilliamH> as an example of what I would do if policy allowed it,
583 2016-09-18 23:45:00<@K_F> veremit: I suspect many devs on amd64 are ~arch
584 2016-09-18 23:45:16<+WilliamH> Right now I would stabilize openrc-0.21.7 on x86.
585 2016-09-18 23:45:39<@K_F> WilliamH: has it been tested on it?
586 2016-09-18 23:45:44<@K_F> either on gentoo infra or otherwise?
587 2016-09-18 23:45:56<+WilliamH> K_F: unknown; there are now x86 specific bug reports.
588 2016-09-18 23:45:58<@jmorgan> can't we test x86 in a kvm vm?
589 2016-09-18 23:46:10<@K_F> jmorgan: certainly better than nothing
590 2016-09-18 23:46:30<@jmorgan> if it fails on real hardware, then its a defect
591 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
592 2016-09-18 23:47:01 * WilliamH wonders if x86 is almost a fringe arch now adays? ;-)
593 2016-09-18 23:47:03<@jmorgan> hey, hey, hey.. who you calling frindge arch ;)
594 2016-09-18 23:47:25<+WilliamH> jmorgan: heh
595 2016-09-18 23:47:51< veremit> lol
596 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.
597 2016-09-18 23:49:11< veremit> WilliamH: sounds good
598 2016-09-18 23:49:18<+WilliamH> veremit: That's what repoman -d or -e are for.
599 2016-09-18 23:50:08<@jmorgan> well, its a major pain once an arch goes dev/exp, i hear
600 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.
601 2016-09-18 23:51:45<@jmorgan> ok, got some other things to do. good discussion. thanks again
602 2016-09-18 23:52:20<@K_F> jmorgan: have a nice evening, thanks for participating