Attachment '2012-09-12-irc-meeting-log.txt'
Download 1 <@ebassi> hi everyone, and welcome to the Foundation's IRC meeting
2 < andre> hi
3 <@ebassi> the agenda is in the URL in the channel's topic, but let me copy it here:
4 < fredp> hey
5 <@ebassi> * Role and scope of the Release Team
6 <@ebassi> * Continuation of the discussion from the AGM at GUADEC 2012.
7 <@ebassi> * http://www.0d.be/2012/08/03/guadec-2012/
8 < yippi> hi
9 <@ebassi> there is an etherpad for the minutes of the meeting: https://etherpad.mozilla.org/ep/pad/view/ro.kgAvgShAxty/latest
10 <@muelli> also sri, you wanted to discuss the commit digest being on pgo, no?
11 <@ebassi> right; further topics can be added to the agenda at the last minute, but they will be subject to actually having the time to discuss them :-)
12 <@muelli> so what's the timeframe? An hour?
13 <@andreasn> maybe add it under "to discuss if there is time" then
14 <@ebassi> for those not at the AGM during GUADEC 2012, I've put the release team slides on: http://www.emmanuelebassi.name/~ebassi/01-release-team.pdf
15 < mclasen_> I have written this up recently: http://live.gnome.org/ReleasePlanning/WhatWeRelease - we've been tossing this around in the release team for a while, as an attempt to clarify some of the unwritten rules and assumptions the release team operates under
16 < mclasen_> not sure it is directly relevant for the discussion today
17 <@andreasn> I think it is, to some extent at least
18 <@ebassi> mclasen_: that looks really good, and it definitely should be part of the discussion
19 <@ebassi> the discussion at the AGM had to be interrupted because of time constraints
20 <@ebassi> but the general impression I had was that people look up at the release team as arbiters of what is gnome, as well as defining the rules of what has to be released; one of the issues is: should the release team also enforce those rules, and how, in case the answer is positive?
21 <@ebassi> if I missed other points, feel free to note them here :-)
22 <@andreasn> has to be released?
23 <@joanie> the impression I myself had was slightly different: We look up to/respect the release team and see them as being in the best position to ensure we all work together effectively as individual contributors to reach our goal of producing an awesome gnome. (But I don't recall hearing views that they are the arbiters of what is gnome.)
24 < fredp> some people are looking for an arbitrer, be it the the release team, the board, or a new body; during guadec I think people (both in and out the release team) were ok to have this role assumed by the release team.
25 <@joanie> fredp: (arbitrer of what specifically?)
26 < mclasen_> there is certainly decisions to be made at some points in the cycle, in particular when discussing new features or modules
27 < mclasen_> maybe this discussion would benefit from some recent examples of what we actually did last cycle
28 <@andreasn> sure
29 < mclasen_> joanie: you've been at the other end of a release team decision when we decided to defer python3
30 * joanie nods
31 <@joanie> and while I wasn't jazzed by it, I 100% agreed with it and respected it. Someone (like you guys) needs to play that role.
32 <@joanie> To keep devs like me "in line" for lack of a better word.
33 * joanie notes that she says that as a dev and not as a board member
34 < mclasen_> in many other cases, we have been taking more of a 'cheerleading' approach: e.g. pushing a selected set of goals by making them 'official', and posting semi-regular progress reports
35 <@ebassi> joanie: that's what I meant when I used the word "arbiter"
36 <@joanie> ebassi: yeah, that word I got. It's the of what I am questioning. (i.e. "what is gnome" I am not so sure is the RT's sole dominion)
37 <@andreasn> so arbiter as in "the body that in the end decides what goes into the product called GNOME"?
38 < andre> another example was maybe the introduction of Nautilus UI changes that were considered disruptive by some people, mainly because of a missing announcement beforehand. I remember at least one person proposing that the r-t could influence the situation "somehow" (e.g. by a temporary revert until regressions have been sorted out)
39 < fredp> andreasn: kind of, we have been deciding on "version numbers" (python, or generally any external dependencies), and (historically) on new modules being accepted in gnome
40 < andre> but this rather refers to better planning (or better communication) of maintainers, IMHO.
41 < mclasen_> joanie: as an aside, now would be a great time to set up a feature planning page for python3 migration...
42 <@ebassi> I definitely see asking maintainers to revert things (or, in cases, keeping an old branch in a new moduleset) as a prerogative of the release team
43 <@andreasn> andre, so, not in the case of nautilus specifically, but in general. Would the r-t today have the powers to either decide on not releasing a new module version?
44 * joanie nods
45 < fredp> andre: but would it be the role of the release team to pester, blame, whatever, the maintainers that do not plan, or communicate, properly?
46 <@shaunm_> andre: in the past, maintainers could do whatever they wanted with the modules they maintained. how that interacts with a feature-proposal world is a bit muddy, IMO
47 < andre> fredp: yeah, that is the question.
48 < andre> shaunm_, we consider feature proposals rather to be system-wide and not refering to one application. it's hard to draw the line.
49 < lucasr_> I tend to see the release team more in the position of making sure the software we release is high quality and that we have a sane development process
50 < mclasen_> we write the module sets that define the release, so we clearly have the ability to pick an older tarball of a module
51 <@shaunm_> andre: but they often are just a matter of including one application
52 < lucasr_> if we want release team to set direction, we'd need design people in it, which I think it doesn't make much sense
53 < mclasen_> but that is merely technical; in practice, a solution like the one we have for python3 now seems much more likely - where some modules 'branch early'
54 <@joanie> lucasr_: I think the community (somehow) sets direction and the RT ensures we actually get there
55 < lucasr_> joanie, yep, although, in practice, the people actually setting direction is actually a much smaller group than the community as a whole
56 < lucasr_> release team should have final word on things like "this feature is not ready for the release, punt it"
57 <@ebassi> joanie: in order to ensure that, then the role of the release team is also to enforce the planned changes, and eventually to back stuff out in case is not ready
58 <@joanie> enforce is a word I like and agree with
59 <@shaunm_> traditionally, the rt's job was to capture community consensus
60 < lucasr_> and make sure new features make sense architecture/release-engineering wise (dependencies, hosting requirements, etc)
61 <@joanie> I agree with that as well lucasr_
62 <@andreasn> has it ever happened, or is it even possible to kick modules out of the release?
63 < jjardon> we are already doing that (libgee comes to my mind, or python3)
64 <@shaunm_> i.e. the community sets direction, and in the common case that it's not a unanimous cheer, the release team was supposed to figure out what most people wanted
65 < jjardon> reverting I mean
66 < mclasen_> lucasr_: I'll point out that this is actually happening to some extent - we're moving feature pages that have not seen action or that are incomplete to the next cycle
67 < andre> backing out stuff that is not ready touches the question how conservative the r-t should be. For example we received some criticism that the move to gstreamer-1.0 was a bit late when it comes to ensuring quality.
68 < lucasr_> mclasen_, yeah, just explicitly saying that to see how people feel about it
69 < lucasr_> I think the feature-oriented process is the way to go
70 < fredp> andreasn: for example nautilus-cd-burner was removed in favour of brasero (and that's also an exemple of not enough communication, as n-c-b maintainers were not aware of that)
71 < API> lucasr_, some people see current feature-oriented process too narrow-minded, or short-term minded
72 <@andreasn> fredp, I guess also in the past sawfish -> metacity
73 < API> and that they lack someone pushing for a long term target
74 < lucasr_> maybe the actually major unanswered question is: who sets the direction of the "big picture"?
75 < API> lucasr_, exactly
76 < API> some people thought that it was the r-t the one doing that
77 < API> when as you said,
78 < mclasen_> we've had some attempts at providing longer term perspectives
79 < API> <lucasr_> I tend to see the release team more in the position of making sure the software we release is high quality and that we have a sane development process
80 < lucasr_> and that's something that I don't think the r-t should be the only group to decide
81 < mclasen_> such as adays 'big' posts
82 < API> this is basically what we told on the AGM this year
83 < mclasen_> and the recent gnome4/gnomeos discussion in la coruna
84 < lucasr_> at some point, I suggested a fixed time-frame for big picture discussions
85 < fredp> we're not setting the direction, but we're seen as the ones that can officialize the "community" will.
86 < lucasr_> like: every 2 years, guadec is *focused* on what's the next 3 major areas
87 < lucasr_> and stick with that
88 < lucasr_> in this case, the release team could be the group to make sure the community is focused on the longer-term topics
89 <@andreasn> lucasr_, in regards to what talks get accepted etc?
90 < lucasr_> andreasn, that too
91 <@shaunm_> lucasr_: I like that in general, though I fear it marginalizes people who can't make it to that guadec
92 < lucasr_> shaunm_, I'm just saying guadec because it's where we get the biggest group together
93 < lucasr_> the process can be asynchronous somehow
94 <@shaunm_> I know, and it's clearly the best place for that if you're going to do it, and do it in-person
95 < lucasr_> guadec could be the big boost to get things discussed properly
96 < lucasr_> and decided
97 < lucasr_> doesn't need to be 2 years
98 < lucasr_> btw
99 < lucasr_> ideally:
100 < lucasr_> we decide 3 topics of focus for the next 2-3 years
101 <@ebassi> shaunm_: that's also where the travel budget comes in
102 < lucasr_> feature-driven process then is discussed from the perspective of these 3 topics
103 < lucasr_> always
104 < mclasen_> 3 topics: http://afaikblog.wordpress.com/2012/08/07/gnome-os/ :-)
105 < lucasr_> with some space for the unexpected and innovations
106 <@shaunm_> ebassi: it's not always just finances
107 <@andreasn> related to that, Mozcamp this year had a lot of sessions on UX and Mobile this year, as that was areas Mozilla identified to be the most important this year
108 < lucasr_> mclasen_, yeah, gnome os could be *the* topic
109 <@ebassi> shaunm_: true, fair point
110 < lucasr_> for the next 2-3 years
111 < mclasen_> lucasr_: right, I was thinking: testable, sdk, apps
112 < lucasr_> although, this would have to be narrowed down to more concrete stuff
113 < lucasr_> mclasen_, yeah, exactly
114 <@shaunm_> so what I think would be fair would be to have the big discussion at guadec, then publish a sort of RFC and give it a month on the mailing lists before calling it the official two-year vision
115 < lucasr_> as a project, I'd love to have a goal like: get 2 major computer manufacturers to release developer-oriented products shipping gnome OS
116 < lucasr_> say, dell and lenovo
117 < lucasr_> there are tons of tricky issues around that (support, etc) but I think that would be great for the gnome ecosystem
118 <@shaunm_> lucasr_++
119 < lucasr_> even if it they are not mass market products, it should be enough to get consulting companies doing support, development for those big companies
120 < lucasr_> could be super-niche stuff really
121 < lucasr_> dell's hacker laptop with gnome os
122 < lucasr_> or whatever
123 <@ebassi> so, to summarize what lucasr_ and shaunm_ are saying: try to solve the issue of the direction of the community from within the community (using guadec as the framing environment), and not have a separate team (or the release team) handle this work. is it correct?
124 < lucasr_> ebassi, yep
125 < lucasr_> ebassi, I think the release team could be the major facilitators of the big picture discussions during guadec
126 < lucasr_> should be
127 <@ebassi> okay
128 < Ankh> shaunm_, re. marginalization, maybe consider tools for remote participation at some specific guadec sessions?
129 < lucasr_> but I think the actual decisions should come from a mixed group of: release team + design people + gnome foundation + other community leaders
130 <@andreasn> but release-team are still the ones who decides if the things fitting that big-picture goes in or out, correct?
131 <@shaunm_> somebody still needs to act as the sort of editor of the vision
132 < lucasr_> andreasn, on a more meta-technical level, yes
133 < lucasr_> shaunm_, yeah, I think there could be a small group formed by release team + design people + gnome foundation + other community leaders
134 < fredp> shaunm_: the editor of that vision would then be the release team, transforming it into the moduleset we release?
135 < mclasen_> ok, so concretely at the next guadec, we'll have a plenary discussion about direction that will be lead by the release team (with maybe some designers on the stage for extra fun) ?
136 <@joanie> and we need concrete benchmarks for the two year plan
137 < lucasr_> joanie, yeah, that's important
138 <@joanie> and we need to identify the in-between steps
139 < lucasr_> very good point actually
140 <@joanie> and someone needs to be sure individual developers meet those goals
141 * joanie coughs: the release team
142 < lucasr_> it's key to have a very concrete way to know if the goals have been reached after the 2-3 big picture cycles
143 <@joanie> :)
144 <@shaunm_> fredp: well, also writing it up in a human-understandable form, something we can reference as a plan, and something people can comment on asynchronously after guadec
145 * lucasr_ has a meeting now, should be back later
146 < fredp> shaunm_: ok, your "RFC" idea, I'm all for that.
147 < mclasen_> we tried to do a bit of that in the gnomeos session in la coruna: the benchmark for testable is that no soc student will struggle through unfixable jhbuild trouble next summer
148 <@andreasn> mclasen_, best goal ever
149 <@joanie> +1 to that
150 <@muelli> heh
151 <@joanie> so have steps been defined to ensure that benchmark is reached?
152 < yippi> i think one of the big limitations with the release team is that many times we really need the collective maintainers of GNOME to make a decision. It seems the r-t often makes this happen currently. But because GNOME doesn't really have any structure for maintainers to come to consensus it often takes forever.
153 <@shaunm_> Ankh: I've had less-than-fantastic experience with just calling in. I think a more sophisticated setup could make remote participation better, but that does take work to set up.
154 < yippi> the only mailing lists that maintainers are expected or required to be on, for example, are all announce mailing lists.
155 < mclasen_> joanie : ahem...
156 < yippi> so there's no real place for discussion except desktop-devel-list, which I'm not sure if really the best place for maintainers to discuss topics like this.
157 <@joanie> mclasen_: ?
158 < mclasen_> ....no concrete steps, yet
159 <@joanie> ah
160 <@andreasn> yippi, are you thinking of any particular decisions?
161 <@andreasn> yippi, like a good example I can look at?
162 <@joanie> and that is what I think many of us look to the RT to do mclasen_
163 < vuntz> (coming a bit late, was busy somewhere else) +1 to the idea of defining 3 big topics for the next 2/3 years, and guadec seems like a natural place to do a first iteration of that, that can then be discussed on the list
164 <@joanie> to provide that technical leadership and direction
165 <@joanie> and gently nudge us all
166 < yippi> there are lots of examples. for example, when the release team decided that it should be a requirement that ABI stable libraries have full docs. The decision took a long time to get maintainer consensus.
167 <@shaunm_> I think d-d-l is exactly the right place to have those conversations
168 * joanie wonders what consensus needs to be reached for proper documentation being a requirement
169 < mclasen_> joanie: I have 'work on direction setting for the release team' buried somewhere on my todo list...
170 < yippi> for most GnomeGoals or r-t process changes, the implementation is often time-consuming and painful. Perhaps d-d-l is the right place for discussions, but since there is no real process to get maintainers to decide on things, decisions are often made in ways that don't seem so effecient.
171 <@ebassi> the issue with d-d-l is that it's also open to non-maintainers, so the SNR is pretty bad
172 <@ebassi> so if we're trying to get consensus between maintainers and team members (design, a11y, marketing) it can get ugly real fast
173 < Ankh> shaunm_, agree that remote participation is hard and takes work to set up. But the work can definitely pay off in reaching out to a wider community, making people feel included, and building consensus
174 < yippi> right, that is also an issue, but the main issue is that GNOME doesn't really have a process to get maintainers to consider an issue and decide what to do about it. This is often left to the r-t or the GnomeGoals folks to push.
175 < vuntz> ebassi: to fix SNR, I think we'd simply need to have more maintainers speak on ddl
176 < yippi> So, for example, what to do about GNOME 2.x support is an example of a current problem that we should probably be deciding what to do about with more maintainer participation.
177 <@ebassi> vuntz: you'd have to bring them back :-)
178 < yippi> or Gnome Fallback mode
179 <@ebassi> vuntz: or we start using d-d-l as the development mailing list it's supposed to be, as opposed to the "public face" of gnome
180 < vuntz> ebassi: +1
181 < yippi> what does SNR mean?
182 < mclasen_> signal-to-noise ratio
183 < desrt> signal:noise
184 < yippi> oh, right, thanks
185 < yippi> d-d-l is overloaded for a lot of different roles, also
186 < yippi> it's basically the place to discuss any technical developer issue, not really for maintainers to make decisions.
187 <@andreasn> are you suggesting a gnome-maintainers-list?
188 <@shaunm_> are maintainers the only part of our community that matters?
189 < yippi> also, maintainers aren't expected to join d-d-l. it's not listed as a requirement to be a mainatiner. Maintainers currently only *have* to subscribe to announce lists, not sure if they do.
190 <@joanie> and have we strayed from the original topic?
191 < mclasen_> I think 'taking back' ddl for these kinds of discussion is better than yet-another-ml
192 < yippi> it would probably benefit the maintainer community if people better knew who the maintainers were, and a mailing list just for maintainers might help.
193 <@ebassi> mclasen_: yes
194 <@andreasn> nso, but I would say they are the ones with a strong say on what goes in and not
195 < yippi> sure, though we might want to make it a requirement for maintainers to subscribe and actually explain that's where such discussions should take place.
196 <@andreasn> sno/no
197 < fredp> (we can extract the list of maintainers from the doap files, and publish that somewhere, if it helps.)
198 <@ebassi> fredp: was about to say that
199 <@andreasn> fredp, that would be great
200 < andre> even if maintainers had to subscribe: if there is too much noise people might not read the emails.
201 < fredp> ebassi: add that as an action item for me
202 <@ebassi> I'd say that if you have commit access to git.gnome.org you should really also be subscribed to desktop-devel-list
203 < mclasen_> yippi: its a fair point; for gtk, I've started to write this: http://live.gnome.org/GTK+/Areas
204 < yippi> sure, but maybe we should put that on the wiki
205 < desrt> ebassi: most maintainers i know have ragequit ddl at least once
206 < Ankh> possibly a mistake to say/imply that the only people who can have a vision for future direction are current maintainers
207 < yippi> since maintainers often have to make controversial decisions, it might even make sense to use a more private mailing list.
208 <@shaunm_> not I, though I have ragequit foundation-list before
209 <@ebassi> desrt: I know
210 <@andreasn> shaunm_, funny. same here :)
211 <@ebassi> I've ragequit desktop-devel, gtk-devel, and foundation-list at multiple times in my 10 years of involvement ;-)
212 < vuntz> yippi: would "more private" be still public?
213 < yippi> i'd say the maintainer community should decide how public they want to be.
214 < mclasen_> to get back to the original topic, I think for the release team, we want to consider ddl as the forum where we approach the 'community' and try to feel out the prevailing opinions, and where we have discussions about new features, etc
215 < fredp> (agree)
216 < vuntz> +1
217 < desrt> ...and then you do what?
218 < yippi> i was just highlighting that some maintainership decisions could generate bad press, so giving maintainers a place to make a decision in private might be useful.
219 < mclasen_> we'll just have to live with some level of noise; everybody can help to keep it down by ignoring flames
220 < yippi> sure, and i'll just keep banging my head against my monitor and wiping away the blood. :)
221 <@joanie> yippi: gotta dump that crt
222 <@joanie> ;)
223 <@shaunm_> so here's a potential way to decrease the noise without shutting down people who still have input: if it's clear a thread is going off the tracks, members of the release team and the interested parties go have a conversation off-list, and come back to list with the conclusion
224 <@shaunm_> sort of like a subcommittee
225 < desrt> or bkor pulls the threadkill trigger :)
226 * fredp has to go, will read the backlog later on.
227 < mclasen_> shaunm_: its beginning to sound more and more like a fulltime job :-)
228 <@shaunm_> yeah, it would certainly be a lot of work
229 < desrt> the takeaway so far is that the release team can come to 'conclusions'
230 < desrt> but i wonder what that means
231 <@shaunm_> but I think when you have a sufficiently large community, these are the kinds of things somebody has to deal with
232 <@ebassi> desrt: the 'enforcement' side?
233 < desrt> ebassi: something like that
234 < desrt> not that i think we'll need it, of course...
235 < desrt> since everyone will always go along with what the release team says
236 <@ebassi> desrt: i.e. once the community decided the direction, and the r-t formalized it, what keeps everything from going off the rails?
237 <@ebassi> desrt: right, I think self-policing is working well enough already
238 < desrt> despite my sarcastic tone, i think that will probably actually work
239 <@shaunm_> they do control the jhbuild modulesets, and that's worth something enforcement-wise
240 < yippi> i'd think that if the release team could just rely on the maintainers to make decisions, the process could become easier.
241 < gpoo> ebassi: I think we expect the direction is going to be revisited as needed (as usual), not necessarily every 2 years, right?
242 < mclasen_> a lot of repeated small-scale intervention helps too - e.g, colin is catching tons of intermittent build breakages with his ostree build server
243 < yippi> currently there seems to be an attitude that the r-t should make decisions for maintainers, rather than letting maintainers make decisions collectively.
244 < lucasr_> yippi, easier but potentially incoherent (if we want to get the community to focus)
245 <@ebassi> yippi: the issue is that those decisions could be potentially conflicting
246 < vuntz> shaunm_: well, there are limits to that. If a maintainer decides to be stubborn and won't revert a decision the r-t doesn't like, then r-t can only stay on an old branch. And then, what happens after two years?
247 <@andreasn> vuntz, fork?
248 <@ebassi> gpoo: that would be part of a discussion on benchmarking the direction
249 < mclasen_> in practice, almost every release team decision will be taken in discussion with the affected maintainers
250 < vuntz> andreasn: I don't think the r-t has the resources to fork ;-)
251 < yippi> while a fork is always a potential in a free software community, GNOME has navigated a lot of controversial issues without serious forking.
252 < lucasr_> gpoo, 2 years is actually a pretty short period
253 <@shaunm_> vuntz: if it's truly the will of the community, somebody will branch/fork and do the work
254 <@ebassi> gpoo: so yes, we can use development cycles to do a milestone sanity check
255 < lucasr_> it's basically 4 releases every 6 months
256 < mclasen_> forking is happening from the outside, mostly...
257 < yippi> unless you consider projects that are trying to fork GNOME 2 to be an example of a controversial issue, I guess. :)
258 < lucasr_> I think 4 releases is enough to get major bits landed and solid in the UX or platform
259 < vuntz> shaunm_: well, r-t wasn't happy with the new gdm back in the 2.2x days, and in the end, we had to accept the few remaining regressions in the new gdm after a few cycles
260 <@andreasn> yeah, but forking of GNOME 2 didn't end up being called GNOME, since the foundation controls that trademark
261 < lucasr_> this is why I suggest the 2 years big picture cycles
262 < vuntz> shaunm_: nobody was crazy enough to branch/fork gdm
263 < lucasr_> suggested
264 < desrt> vuntz: wrong :)
265 < vuntz> desrt: let me add "at that time"? ;-)
266 < yippi> you could consider LightDM a GDM fork maybe.
267 <@ebassi> not really
268 < gpoo> lucasr_: I was thinking in adjustments, more than big changes. Revisiting them with the benchmarking sounds good for that.
269 < yippi> i'd call it more a rewrite
270 < desrt> vuntz: the yippi-era gdm has been forked by someone or other (mint, i think?)
271 <@ebassi> unless "a completely new replacement" is a fork
272 < lucasr_> gpoo, yep
273 <@ebassi> desrt: debian has been shipping a very old gdm for years
274 < yippi> Oracle delivers a forked GDM to support Sun Ray.
275 <@shaunm_> andreasn: meh, they didn't ask. I have no problem with a group of people continuing the development of GNOME 2 and calling it GNOME 2.
276 < desrt> 2.20
277 <@ebassi> and patching everything that depended on gdm
278 <@andreasn> ebassi, well, that is what I thought of too when I said fork
279 < desrt> let's assume that internal forks don't happen
280 <@andreasn> shaunm_, Indeed they didn't. I think I would. And to some extent I think that is how the board somewhat holds ultimate veto somehow
281 <@ebassi> desrt: yes, I'd say that it would be the wrong corner case to optimize process for
282 < desrt> or if we do, make it a bit more concrete: like the nautilus situation we have presently
283 < yippi> desrt, would you consider it a fork if the GNOME community decided to provide some base-level on-going support for GNOME 2, such as updated modules to fix security bugs?
284 < desrt> yippi: i think that's not the issue at hand?
285 <@shaunm_> andreasn: ultimately, the board can control everything. in practice, we really, really, really do not want to.
286 < desrt> i find the idea of a new gnome 2.x release to be interesting... but it's not what we're trying to solve right now, i think
287 <@ebassi> yippi: patching old branches of gnome projects is not controversial
288 <@andreasn> shaunm_, I know. And I agree that we shouldn't
289 < vuntz> yippi: that'd be maintenance releases, not a fork
290 < yippi> good to hear, i just wanted to clarify whether that would be considered an internal fork.
291 <@ebassi> we're going a bit off the rails, and the meeting has been going on for an hour already
292 <@ebassi> desrt raised the point of nautilus
293 <@ebassi> though I think that's more an upstream/downstream issue
294 * vuntz supports desrt in his effort to use the nautilus situation as an example for the discussion
295 < desrt> here's how i see the issue:
296 < desrt> the nautilus feature changes are mostly good news, but there are regressions
297 < desrt> and in any case it was a _massive_ change
298 < desrt> ie: easily above the level that would have qualified it for consideration as a 'feature' during the normal process
299 < desrt> and it was not proposed...
300 < desrt> so there was no time for input/discussion before hand
301 < desrt> which is the entire point of feature proposals
302 * mclasen_ bailing out for another meeting now, sorry
303 <@shaunm_> I really don't think it's been clear how much the feature proposal process affects single-module changes
304 < andre> shaunm_, yes.
305 < desrt> my understanding is that we have the 'feature proposals' process because we deem the boundary between modules to be arbitrary
306 < desrt> ie: we should _not_ use the fact that only a single module had changes as a justification for saying "this is not a 'feature' in that sense..."
307 <@shaunm_> honestly, feature proposals were a mess at first. they've gotten a lot better, but I think it's still something we're ironing the kinks out of
308 <@andreasn> desrt, so I think what the release-team could have done is said "We saw no feature proposal for this. Module set will stay on 3.4 until we can talk about this"
309 <@shaunm_> desrt: in that case, it is really no longer true that maintainers have authority over their modules
310 < desrt> andreasn: indeed, that's what i would have expected
311 <@joanie> +1 to that
312 < desrt> shaunm_: maintainers have authority over their modules. the r-t has the authority not to ship the new version.
313 <@andreasn> desrt, and say that there was a release of nautilus where all the icons were swastikas instead. I would expect the r-t to say "holding on to last release, and we're thinking of kicking this module out"
314 <@joanie> heh
315 <@shaunm_> desrt: but the expectations you're implying are that maintainers should ask permission before making substantial changes to their modules
316 < andre> Nautilus UI changes were rather a communication issue. Regressions have been fixed (I tried to track them), but once an impression is out there it's hard to fix that impression. So generally maintainers/developers need a feeling beforehand how "controversial" changes will be seen by users/press, but that's hard to know in advance. I saw the bug reports but didn't expect this feedback either.
317 < desrt> andreasn: intentional invocation of godwin's law? :)
318 <@ebassi> desrt: on the other hand, even if we had a massive proposal for nautilus, what would have the discussion been? regressions aren't known until the end of the cycle, and I can promise all day that there won't be any regressions - that doesn't imply that there won't be
319 <@andreasn> desrt, always :)
320 < vuntz> ebassi: would have helped with communication?
321 <@ebassi> desrt: and UI changes, even if communicated, have to be accepted if they are brought forward from the module maintainer - which is something that we have been saying for the past 30 minutes
322 < desrt> ebassi: i'm not talking about 'bug' regressions. i'm talking about the well-known (and several) feature regressions
323 <@ebassi> I'm not in any way saying that the changes should have been communicated beforehand, and that it hasn't been a communication fail - it has
324 <@ebassi> shouldn't, even
325 <@ebassi> desrt: what's a feature regression?
326 < desrt> i'm suggesting that the degree of the failure to communicate (which has been pretty massive, imho) means that the release-team should not just say "oh well, try harder next time"
327 <@ebassi> how's that different from a perfectly valid feature removal?
328 < desrt> ebassi: the loss of compact mode is absolutely at the top of my list
329 < desrt> ebassi: feature removal = feature regression. just language.
330 <@ebassi> desrt: if you're the maintainer of nautilus, you get to decide what feature lives and what dies. haven't we just talked for 30 minutes on how maintainers should be the actal people doing actual decisions, and that the release team should honour those decisions?
331 < desrt> that's not the takeaway i've been getting from the discussion
332 < desrt> and in this case, true or not, the wide perception is that these feature removals were done in an extremely hasty way
333 < vuntz> ebassi: I think we've been discussing the "everything goes well, but we don't have a direction" issue earlier. Not the "there's disagreement on a specific thing in one module" part.
334 < vuntz> (at least, that's my understanding)
335 < desrt> real impact of this situation: ubuntu has dropped back to shipping nautilus 3.4 this cycle (even though they were planning on 3.6) and are shopping for a new default file manager next cycle
336 < desrt> i can't blame them....
337 <@ebassi> I'm just trying to figure out what the result of a r-t decision would be, in a similar case. bump the module out for a cycle? okay, it's been done already
338 < desrt> this isn't a case of putting a maintainer in the penalty box for a cycle
339 < desrt> it's bumping it until the issues are addressed
340 <@ebassi> desrt: flogging in a public place is not an option
341 < desrt> which may be a cycle, or shorter or longer
342 <@ebassi> we don't have the manpower to do that
343 <@ebassi> (flogging, I mean)
344 <@ebassi> desrt: I used "a cycle" as an example
345 < desrt> sure
346 <@ebassi> but, again, using an older version has been done
347 < desrt> a cycle does turn out to be a natural measurement in one sense...
348 <@ebassi> it's also 6 months
349 < desrt> if the original problem is that the changes were undertaken without appropriate feedback/input by being discussed during feature proposals then the module can be held back until the changes get discussed in the next round
350 < desrt> and shipped again if the features are implemented in time (ie: exactly in the way that we would expect to land a feature branch, or not)
351 <@ebassi> in theory, we should not have a case where that happens; but the feature proposal period is still fuzzy as shaunm_ said
352 <@shaunm_> it has gotten better
353 <@shaunm_> but before this conversation, it would never occur to me that I have to do a proposal to make some changes only inside yelp
354 <@ebassi> but, again, we keep circling back to the issue of what's "appropriate feedback". if I want to change dictionary, and it affects the dictionary only, what's the level of appropriate community feedback?
355 <@ebassi> does it depend on the module?
356 < desrt> yes. absolutely.
357 < desrt> "core" = yes
358 < desrt> "apps", "world" = if you feel like it
359 <@ebassi> so the trick is to move nautilus to apps, and be done with it? -)
360 <@andreasn> where can I find a list of what is in core and apps/world now again?
361 < desrt> of course, there's a fuzzy line between what is a 'substantial' change and not
362 < vuntz> andreasn: in the jhbuild modulesets
363 <@ebassi> andreasn: it's the name of the modulesets
364 < vuntz> andreasn: http://git.gnome.org/browse/jhbuild/tree/modulesets
365 < desrt> but falling on the "i know it when i see it" definition, the nautilus changes are substantial...
366 < desrt> and really importantly (and i do think this is a distinct issue that requires some special consideration): it had feature removals
367 < desrt> users get really fucking pissed about feature removals
368 < gpoo> desrt: maybe 'potentially controversial' could help to assess what 'substantial' would mean
369 <@ebassi> gpoo: it's all fuzzy to me still
370 <@andreasn> vuntz, thanks
371 <@shaunm_> andreasn: or this old gem: http://blip.blip-monitor.com/set/gnome-3-6
372 <@ebassi> desrt: it's always been that way, and that hasn't changed our approach at making gnome
373 * andre slowly has to leave and passes the r-t flag to bkor
374 <@ebassi> desrt: we still have glaring regressions when doing settings migrations - that would be a bigger issue to tackle
375 <@ebassi> but we'd also be going really off topic, here
376 < fredp> andre: just as I get back
377 <@ebassi> so, the take away from the nautilus case is:
378 <@shaunm_> have we come up with anything actionable in the last 1.5 hours?
379 < desrt> ebassi: settings migrations are temporarily pain. missing feature in the new version is not.
380 <@andreasn> desrt, both will fuck you up possibly
381 <@ebassi> * feature proposals for single modules should happen alongside with multi-module features, depending on a set of constraints: feature removal, importance of the module
382 < andre> fredp, awesome :)
383 < desrt> ebassi: size of change
384 <@ebassi> * the r-t should exercise the option to punt the module from the release until the regressions are fixed
385 <@ebassi> (or until a sizeable discussion happened)
386 < desrt> ebassi: in the event that the feature as implemented in the module does not meet the concensus (determined by the r-t) of the feature discussion, or if no discussion happened
387 < andre> ebassi: for the first item, maybe also plus "Better announce too much than not enough." as an advice
388 <@ebassi> good point
389 <@ebassi> I'd say that's an actionable proposal that can be added to the list of things that the release team is in charge of
390 * ebassi will have to use the log to minute this part :-)
391 < desrt> ebassi: on the criteria i'd put "user visibility" as well
392 <@shaunm_> so is this the same definition of feature that we use for the feature freeze?
393 < desrt> there does appear to be some coincidence there...
394 < desrt> but i'd say this is a higher bar
395 <@ebassi> okay
396 <@ebassi> I'd say we can close this point, unless somebody else has some other issue to raise
397 <@ebassi> I don't know if somebody wants to discuss the other point on the agenda - amending the PGO rules to allow the commit digest
398 <@ebassi> given that it's been 1hr 45min of meeting :-)
399 <@muelli> heh. true.
400 * mclasen_ gives a +1 for commit digests
401 * ebassi +1 as well
402 <@andreasn> yes, yes
403 <@andreasn> +1
404 <@muelli> aye, me, too.
405 <@ebassi> I don't think it's really controversial: it's a great window on the state of the project
406 <@muelli> +1
407 < vuntz> +1, but I still keep my comment from https://mail.gnome.org/archives/foundation-list/2012-July/msg00019.html :-)
408 <@ebassi> we could even style it differently, and we still allow people to change the feeds displayed on pgo :-)
409 <@ebassi> vuntz: right
410 <@andreasn> ebassi, do we need to do anything formal in order to change the rules?
411 <@muelli> no, not that I am aware of.
412 <@ebassi> nope
413 <@ebassi> I'll take the action to poke aruiz
414 <@ebassi> and have him add the feed
415 <@ebassi> and fix the style :-)
416 <@andreasn> sounds great!
417 <@muelli> well, although I don't remember the current editorial policy. Eventually a statement like "the editor has a
418 <@muelli> aye, me, too.
419 <@ebassi> I don't think it's really controversial: it's a great window on the state of the project
420 <@muelli> +1
421 < vuntz> +1, but I still keep my comment from https://mail.gnome.org/archives/foundation-list/2012-July/msg00019.html :-)
422 <@ebassi> we could even style it differently, and we still allow people to change the feeds displayed on pgo :-)
423 <@ebassi> vuntz: right
424 <@andreasn> ebassi, do we need to do anything formal in order to change the rules?
425 <@muelli> no, not that I am aware of.
426 <@ebassi> nope
427 <@ebassi> I'll take the action to poke aruiz
428 <@ebassi> and have him add the feed
429 <@ebassi> and fix the style :-)
430 <@andreasn> sounds great!
431 <@muelli> well, although I don't remember the current editorial policy. Eventually a statement like "the editor has a final word on feeds being added or not" or so.
432 <@muelli> * needs to be added.
433 < desrt> can't we have the release team decide what feeds are on planet?
434 <@muelli> O-o
435 * ebassi kicks desrt
436 < desrt> ideally after a long discussion on d-d-l?
437 <@joanie> ebassi: permission to flog him?
438 <@andreasn> hehe
439 <@ebassi> muelli: the current editorial policy is that the editor(s) have the ultimate decision
440 < desrt> joanie: ebassi said public floggings are out
441 <@ebassi> I don't know, we could be making an exception
442 <@ebassi> anyway, thanks a lot to everyone for attending. it was a great meeting
443 <@joanie> like python 3, I'll just do it and wait for the RT to take action
444 <@joanie> ;)
445 <@andreasn> ebassi, thanks for holding it. Excellent discussion
446 <@ebassi> the minutes will be put on the wiki after a bit of editing, along with the log
447 <@muelli> thanks!
Attached Files
To refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.You are not allowed to attach a file to this page.