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.
  • [get | view] (2021-02-25 09:51:09, 38.3 KB) [[attachment:2012-09-12-irc-meeting-log.txt]]
 All files | Selected Files: delete move to page copy to page

You are not allowed to attach a file to this page.