<@ebassi> hi everyone, and welcome to the Foundation's IRC meeting < andre> hi <@ebassi> the agenda is in the URL in the channel's topic, but let me copy it here: < fredp> hey <@ebassi> * Role and scope of the Release Team <@ebassi> * Continuation of the discussion from the AGM at GUADEC 2012. <@ebassi> * http://www.0d.be/2012/08/03/guadec-2012/ < yippi> hi <@ebassi> there is an etherpad for the minutes of the meeting: https://etherpad.mozilla.org/ep/pad/view/ro.kgAvgShAxty/latest <@muelli> also sri, you wanted to discuss the commit digest being on pgo, no? <@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 :-) <@muelli> so what's the timeframe? An hour? <@andreasn> maybe add it under "to discuss if there is time" then <@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 < 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 < mclasen_> not sure it is directly relevant for the discussion today <@andreasn> I think it is, to some extent at least <@ebassi> mclasen_: that looks really good, and it definitely should be part of the discussion <@ebassi> the discussion at the AGM had to be interrupted because of time constraints <@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? <@ebassi> if I missed other points, feel free to note them here :-) <@andreasn> has to be released? <@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.) < 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. <@joanie> fredp: (arbitrer of what specifically?) < mclasen_> there is certainly decisions to be made at some points in the cycle, in particular when discussing new features or modules < mclasen_> maybe this discussion would benefit from some recent examples of what we actually did last cycle <@andreasn> sure < mclasen_> joanie: you've been at the other end of a release team decision when we decided to defer python3 * joanie nods <@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. <@joanie> To keep devs like me "in line" for lack of a better word. * joanie notes that she says that as a dev and not as a board member < 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 <@ebassi> joanie: that's what I meant when I used the word "arbiter" <@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) <@andreasn> so arbiter as in "the body that in the end decides what goes into the product called GNOME"? < 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) < 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 < andre> but this rather refers to better planning (or better communication) of maintainers, IMHO. < mclasen_> joanie: as an aside, now would be a great time to set up a feature planning page for python3 migration... <@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 <@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? * joanie nods < 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? <@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 < andre> fredp: yeah, that is the question. < andre> shaunm_, we consider feature proposals rather to be system-wide and not refering to one application. it's hard to draw the line. < 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 < mclasen_> we write the module sets that define the release, so we clearly have the ability to pick an older tarball of a module <@shaunm_> andre: but they often are just a matter of including one application < 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 < 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' <@joanie> lucasr_: I think the community (somehow) sets direction and the RT ensures we actually get there < lucasr_> joanie, yep, although, in practice, the people actually setting direction is actually a much smaller group than the community as a whole < lucasr_> release team should have final word on things like "this feature is not ready for the release, punt it" <@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 <@joanie> enforce is a word I like and agree with <@shaunm_> traditionally, the rt's job was to capture community consensus < lucasr_> and make sure new features make sense architecture/release-engineering wise (dependencies, hosting requirements, etc) <@joanie> I agree with that as well lucasr_ <@andreasn> has it ever happened, or is it even possible to kick modules out of the release? < jjardon> we are already doing that (libgee comes to my mind, or python3) <@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 < jjardon> reverting I mean < 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 < 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. < lucasr_> mclasen_, yeah, just explicitly saying that to see how people feel about it < lucasr_> I think the feature-oriented process is the way to go < 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) < API> lucasr_, some people see current feature-oriented process too narrow-minded, or short-term minded <@andreasn> fredp, I guess also in the past sawfish -> metacity < API> and that they lack someone pushing for a long term target < lucasr_> maybe the actually major unanswered question is: who sets the direction of the "big picture"? < API> lucasr_, exactly < API> some people thought that it was the r-t the one doing that < API> when as you said, < mclasen_> we've had some attempts at providing longer term perspectives < API> 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 < lucasr_> and that's something that I don't think the r-t should be the only group to decide < mclasen_> such as adays 'big' posts < API> this is basically what we told on the AGM this year < mclasen_> and the recent gnome4/gnomeos discussion in la coruna < lucasr_> at some point, I suggested a fixed time-frame for big picture discussions < fredp> we're not setting the direction, but we're seen as the ones that can officialize the "community" will. < lucasr_> like: every 2 years, guadec is *focused* on what's the next 3 major areas < lucasr_> and stick with that < lucasr_> in this case, the release team could be the group to make sure the community is focused on the longer-term topics <@andreasn> lucasr_, in regards to what talks get accepted etc? < lucasr_> andreasn, that too <@shaunm_> lucasr_: I like that in general, though I fear it marginalizes people who can't make it to that guadec < lucasr_> shaunm_, I'm just saying guadec because it's where we get the biggest group together < lucasr_> the process can be asynchronous somehow <@shaunm_> I know, and it's clearly the best place for that if you're going to do it, and do it in-person < lucasr_> guadec could be the big boost to get things discussed properly < lucasr_> and decided < lucasr_> doesn't need to be 2 years < lucasr_> btw < lucasr_> ideally: < lucasr_> we decide 3 topics of focus for the next 2-3 years <@ebassi> shaunm_: that's also where the travel budget comes in < lucasr_> feature-driven process then is discussed from the perspective of these 3 topics < lucasr_> always < mclasen_> 3 topics: http://afaikblog.wordpress.com/2012/08/07/gnome-os/ :-) < lucasr_> with some space for the unexpected and innovations <@shaunm_> ebassi: it's not always just finances <@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 < lucasr_> mclasen_, yeah, gnome os could be *the* topic <@ebassi> shaunm_: true, fair point < lucasr_> for the next 2-3 years < mclasen_> lucasr_: right, I was thinking: testable, sdk, apps < lucasr_> although, this would have to be narrowed down to more concrete stuff < lucasr_> mclasen_, yeah, exactly <@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 < 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 < lucasr_> say, dell and lenovo < lucasr_> there are tons of tricky issues around that (support, etc) but I think that would be great for the gnome ecosystem <@shaunm_> lucasr_++ < 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 < lucasr_> could be super-niche stuff really < lucasr_> dell's hacker laptop with gnome os < lucasr_> or whatever <@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? < lucasr_> ebassi, yep < lucasr_> ebassi, I think the release team could be the major facilitators of the big picture discussions during guadec < lucasr_> should be <@ebassi> okay < Ankh> shaunm_, re. marginalization, maybe consider tools for remote participation at some specific guadec sessions? < lucasr_> but I think the actual decisions should come from a mixed group of: release team + design people + gnome foundation + other community leaders <@andreasn> but release-team are still the ones who decides if the things fitting that big-picture goes in or out, correct? <@shaunm_> somebody still needs to act as the sort of editor of the vision < lucasr_> andreasn, on a more meta-technical level, yes < lucasr_> shaunm_, yeah, I think there could be a small group formed by release team + design people + gnome foundation + other community leaders < fredp> shaunm_: the editor of that vision would then be the release team, transforming it into the moduleset we release? < 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) ? <@joanie> and we need concrete benchmarks for the two year plan < lucasr_> joanie, yeah, that's important <@joanie> and we need to identify the in-between steps < lucasr_> very good point actually <@joanie> and someone needs to be sure individual developers meet those goals * joanie coughs: the release team < 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 <@joanie> :) <@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 * lucasr_ has a meeting now, should be back later < fredp> shaunm_: ok, your "RFC" idea, I'm all for that. < 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 <@andreasn> mclasen_, best goal ever <@joanie> +1 to that <@muelli> heh <@joanie> so have steps been defined to ensure that benchmark is reached? < 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. <@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. < yippi> the only mailing lists that maintainers are expected or required to be on, for example, are all announce mailing lists. < mclasen_> joanie : ahem... < 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. <@joanie> mclasen_: ? < mclasen_> ....no concrete steps, yet <@joanie> ah <@andreasn> yippi, are you thinking of any particular decisions? <@andreasn> yippi, like a good example I can look at? <@joanie> and that is what I think many of us look to the RT to do mclasen_ < 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 <@joanie> to provide that technical leadership and direction <@joanie> and gently nudge us all < 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. <@shaunm_> I think d-d-l is exactly the right place to have those conversations * joanie wonders what consensus needs to be reached for proper documentation being a requirement < mclasen_> joanie: I have 'work on direction setting for the release team' buried somewhere on my todo list... < 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. <@ebassi> the issue with d-d-l is that it's also open to non-maintainers, so the SNR is pretty bad <@ebassi> so if we're trying to get consensus between maintainers and team members (design, a11y, marketing) it can get ugly real fast < 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 < 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. < vuntz> ebassi: to fix SNR, I think we'd simply need to have more maintainers speak on ddl < 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. <@ebassi> vuntz: you'd have to bring them back :-) < yippi> or Gnome Fallback mode <@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 < vuntz> ebassi: +1 < yippi> what does SNR mean? < mclasen_> signal-to-noise ratio < desrt> signal:noise < yippi> oh, right, thanks < yippi> d-d-l is overloaded for a lot of different roles, also < yippi> it's basically the place to discuss any technical developer issue, not really for maintainers to make decisions. <@andreasn> are you suggesting a gnome-maintainers-list? <@shaunm_> are maintainers the only part of our community that matters? < 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. <@joanie> and have we strayed from the original topic? < mclasen_> I think 'taking back' ddl for these kinds of discussion is better than yet-another-ml < 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. <@ebassi> mclasen_: yes <@andreasn> nso, but I would say they are the ones with a strong say on what goes in and not < 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. <@andreasn> sno/no < fredp> (we can extract the list of maintainers from the doap files, and publish that somewhere, if it helps.) <@ebassi> fredp: was about to say that <@andreasn> fredp, that would be great < andre> even if maintainers had to subscribe: if there is too much noise people might not read the emails. < fredp> ebassi: add that as an action item for me <@ebassi> I'd say that if you have commit access to git.gnome.org you should really also be subscribed to desktop-devel-list < mclasen_> yippi: its a fair point; for gtk, I've started to write this: http://live.gnome.org/GTK+/Areas < yippi> sure, but maybe we should put that on the wiki < desrt> ebassi: most maintainers i know have ragequit ddl at least once < Ankh> possibly a mistake to say/imply that the only people who can have a vision for future direction are current maintainers < yippi> since maintainers often have to make controversial decisions, it might even make sense to use a more private mailing list. <@shaunm_> not I, though I have ragequit foundation-list before <@ebassi> desrt: I know <@andreasn> shaunm_, funny. same here :) <@ebassi> I've ragequit desktop-devel, gtk-devel, and foundation-list at multiple times in my 10 years of involvement ;-) < vuntz> yippi: would "more private" be still public? < yippi> i'd say the maintainer community should decide how public they want to be. < 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 < fredp> (agree) < vuntz> +1 < desrt> ...and then you do what? < 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. < mclasen_> we'll just have to live with some level of noise; everybody can help to keep it down by ignoring flames < yippi> sure, and i'll just keep banging my head against my monitor and wiping away the blood. :) <@joanie> yippi: gotta dump that crt <@joanie> ;) <@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 <@shaunm_> sort of like a subcommittee < desrt> or bkor pulls the threadkill trigger :) * fredp has to go, will read the backlog later on. < mclasen_> shaunm_: its beginning to sound more and more like a fulltime job :-) <@shaunm_> yeah, it would certainly be a lot of work < desrt> the takeaway so far is that the release team can come to 'conclusions' < desrt> but i wonder what that means <@shaunm_> but I think when you have a sufficiently large community, these are the kinds of things somebody has to deal with <@ebassi> desrt: the 'enforcement' side? < desrt> ebassi: something like that < desrt> not that i think we'll need it, of course... < desrt> since everyone will always go along with what the release team says <@ebassi> desrt: i.e. once the community decided the direction, and the r-t formalized it, what keeps everything from going off the rails? <@ebassi> desrt: right, I think self-policing is working well enough already < desrt> despite my sarcastic tone, i think that will probably actually work <@shaunm_> they do control the jhbuild modulesets, and that's worth something enforcement-wise < yippi> i'd think that if the release team could just rely on the maintainers to make decisions, the process could become easier. < gpoo> ebassi: I think we expect the direction is going to be revisited as needed (as usual), not necessarily every 2 years, right? < 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 < yippi> currently there seems to be an attitude that the r-t should make decisions for maintainers, rather than letting maintainers make decisions collectively. < lucasr_> yippi, easier but potentially incoherent (if we want to get the community to focus) <@ebassi> yippi: the issue is that those decisions could be potentially conflicting < 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? <@andreasn> vuntz, fork? <@ebassi> gpoo: that would be part of a discussion on benchmarking the direction < mclasen_> in practice, almost every release team decision will be taken in discussion with the affected maintainers < vuntz> andreasn: I don't think the r-t has the resources to fork ;-) < yippi> while a fork is always a potential in a free software community, GNOME has navigated a lot of controversial issues without serious forking. < lucasr_> gpoo, 2 years is actually a pretty short period <@shaunm_> vuntz: if it's truly the will of the community, somebody will branch/fork and do the work <@ebassi> gpoo: so yes, we can use development cycles to do a milestone sanity check < lucasr_> it's basically 4 releases every 6 months < mclasen_> forking is happening from the outside, mostly... < yippi> unless you consider projects that are trying to fork GNOME 2 to be an example of a controversial issue, I guess. :) < lucasr_> I think 4 releases is enough to get major bits landed and solid in the UX or platform < 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 <@andreasn> yeah, but forking of GNOME 2 didn't end up being called GNOME, since the foundation controls that trademark < lucasr_> this is why I suggest the 2 years big picture cycles < vuntz> shaunm_: nobody was crazy enough to branch/fork gdm < lucasr_> suggested < desrt> vuntz: wrong :) < vuntz> desrt: let me add "at that time"? ;-) < yippi> you could consider LightDM a GDM fork maybe. <@ebassi> not really < gpoo> lucasr_: I was thinking in adjustments, more than big changes. Revisiting them with the benchmarking sounds good for that. < yippi> i'd call it more a rewrite < desrt> vuntz: the yippi-era gdm has been forked by someone or other (mint, i think?) <@ebassi> unless "a completely new replacement" is a fork < lucasr_> gpoo, yep <@ebassi> desrt: debian has been shipping a very old gdm for years < yippi> Oracle delivers a forked GDM to support Sun Ray. <@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. < desrt> 2.20 <@ebassi> and patching everything that depended on gdm <@andreasn> ebassi, well, that is what I thought of too when I said fork < desrt> let's assume that internal forks don't happen <@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 <@ebassi> desrt: yes, I'd say that it would be the wrong corner case to optimize process for < desrt> or if we do, make it a bit more concrete: like the nautilus situation we have presently < 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? < desrt> yippi: i think that's not the issue at hand? <@shaunm_> andreasn: ultimately, the board can control everything. in practice, we really, really, really do not want to. < 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 <@ebassi> yippi: patching old branches of gnome projects is not controversial <@andreasn> shaunm_, I know. And I agree that we shouldn't < vuntz> yippi: that'd be maintenance releases, not a fork < yippi> good to hear, i just wanted to clarify whether that would be considered an internal fork. <@ebassi> we're going a bit off the rails, and the meeting has been going on for an hour already <@ebassi> desrt raised the point of nautilus <@ebassi> though I think that's more an upstream/downstream issue * vuntz supports desrt in his effort to use the nautilus situation as an example for the discussion < desrt> here's how i see the issue: < desrt> the nautilus feature changes are mostly good news, but there are regressions < desrt> and in any case it was a _massive_ change < desrt> ie: easily above the level that would have qualified it for consideration as a 'feature' during the normal process < desrt> and it was not proposed... < desrt> so there was no time for input/discussion before hand < desrt> which is the entire point of feature proposals * mclasen_ bailing out for another meeting now, sorry <@shaunm_> I really don't think it's been clear how much the feature proposal process affects single-module changes < andre> shaunm_, yes. < desrt> my understanding is that we have the 'feature proposals' process because we deem the boundary between modules to be arbitrary < 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..." <@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 <@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" <@shaunm_> desrt: in that case, it is really no longer true that maintainers have authority over their modules < desrt> andreasn: indeed, that's what i would have expected <@joanie> +1 to that < desrt> shaunm_: maintainers have authority over their modules. the r-t has the authority not to ship the new version. <@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" <@joanie> heh <@shaunm_> desrt: but the expectations you're implying are that maintainers should ask permission before making substantial changes to their modules < 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. < desrt> andreasn: intentional invocation of godwin's law? :) <@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 <@andreasn> desrt, always :) < vuntz> ebassi: would have helped with communication? <@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 < desrt> ebassi: i'm not talking about 'bug' regressions. i'm talking about the well-known (and several) feature regressions <@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 <@ebassi> shouldn't, even <@ebassi> desrt: what's a feature regression? < 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" <@ebassi> how's that different from a perfectly valid feature removal? < desrt> ebassi: the loss of compact mode is absolutely at the top of my list < desrt> ebassi: feature removal = feature regression. just language. <@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? < desrt> that's not the takeaway i've been getting from the discussion < desrt> and in this case, true or not, the wide perception is that these feature removals were done in an extremely hasty way < 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. < vuntz> (at least, that's my understanding) < 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 < desrt> i can't blame them.... <@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 < desrt> this isn't a case of putting a maintainer in the penalty box for a cycle < desrt> it's bumping it until the issues are addressed <@ebassi> desrt: flogging in a public place is not an option < desrt> which may be a cycle, or shorter or longer <@ebassi> we don't have the manpower to do that <@ebassi> (flogging, I mean) <@ebassi> desrt: I used "a cycle" as an example < desrt> sure <@ebassi> but, again, using an older version has been done < desrt> a cycle does turn out to be a natural measurement in one sense... <@ebassi> it's also 6 months < 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 < 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) <@ebassi> in theory, we should not have a case where that happens; but the feature proposal period is still fuzzy as shaunm_ said <@shaunm_> it has gotten better <@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 <@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? <@ebassi> does it depend on the module? < desrt> yes. absolutely. < desrt> "core" = yes < desrt> "apps", "world" = if you feel like it <@ebassi> so the trick is to move nautilus to apps, and be done with it? -) <@andreasn> where can I find a list of what is in core and apps/world now again? < desrt> of course, there's a fuzzy line between what is a 'substantial' change and not < vuntz> andreasn: in the jhbuild modulesets <@ebassi> andreasn: it's the name of the modulesets < vuntz> andreasn: http://git.gnome.org/browse/jhbuild/tree/modulesets < desrt> but falling on the "i know it when i see it" definition, the nautilus changes are substantial... < desrt> and really importantly (and i do think this is a distinct issue that requires some special consideration): it had feature removals < desrt> users get really fucking pissed about feature removals < gpoo> desrt: maybe 'potentially controversial' could help to assess what 'substantial' would mean <@ebassi> gpoo: it's all fuzzy to me still <@andreasn> vuntz, thanks <@shaunm_> andreasn: or this old gem: http://blip.blip-monitor.com/set/gnome-3-6 <@ebassi> desrt: it's always been that way, and that hasn't changed our approach at making gnome * andre slowly has to leave and passes the r-t flag to bkor <@ebassi> desrt: we still have glaring regressions when doing settings migrations - that would be a bigger issue to tackle <@ebassi> but we'd also be going really off topic, here < fredp> andre: just as I get back <@ebassi> so, the take away from the nautilus case is: <@shaunm_> have we come up with anything actionable in the last 1.5 hours? < desrt> ebassi: settings migrations are temporarily pain. missing feature in the new version is not. <@andreasn> desrt, both will fuck you up possibly <@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 < andre> fredp, awesome :) < desrt> ebassi: size of change <@ebassi> * the r-t should exercise the option to punt the module from the release until the regressions are fixed <@ebassi> (or until a sizeable discussion happened) < 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 < andre> ebassi: for the first item, maybe also plus "Better announce too much than not enough." as an advice <@ebassi> good point <@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 * ebassi will have to use the log to minute this part :-) < desrt> ebassi: on the criteria i'd put "user visibility" as well <@shaunm_> so is this the same definition of feature that we use for the feature freeze? < desrt> there does appear to be some coincidence there... < desrt> but i'd say this is a higher bar <@ebassi> okay <@ebassi> I'd say we can close this point, unless somebody else has some other issue to raise <@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 <@ebassi> given that it's been 1hr 45min of meeting :-) <@muelli> heh. true. * mclasen_ gives a +1 for commit digests * ebassi +1 as well <@andreasn> yes, yes <@andreasn> +1 <@muelli> aye, me, too. <@ebassi> I don't think it's really controversial: it's a great window on the state of the project <@muelli> +1 < vuntz> +1, but I still keep my comment from https://mail.gnome.org/archives/foundation-list/2012-July/msg00019.html :-) <@ebassi> we could even style it differently, and we still allow people to change the feeds displayed on pgo :-) <@ebassi> vuntz: right <@andreasn> ebassi, do we need to do anything formal in order to change the rules? <@muelli> no, not that I am aware of. <@ebassi> nope <@ebassi> I'll take the action to poke aruiz <@ebassi> and have him add the feed <@ebassi> and fix the style :-) <@andreasn> sounds great! <@muelli> well, although I don't remember the current editorial policy. Eventually a statement like "the editor has a <@muelli> aye, me, too. <@ebassi> I don't think it's really controversial: it's a great window on the state of the project <@muelli> +1 < vuntz> +1, but I still keep my comment from https://mail.gnome.org/archives/foundation-list/2012-July/msg00019.html :-) <@ebassi> we could even style it differently, and we still allow people to change the feeds displayed on pgo :-) <@ebassi> vuntz: right <@andreasn> ebassi, do we need to do anything formal in order to change the rules? <@muelli> no, not that I am aware of. <@ebassi> nope <@ebassi> I'll take the action to poke aruiz <@ebassi> and have him add the feed <@ebassi> and fix the style :-) <@andreasn> sounds great! <@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. <@muelli> * needs to be added. < desrt> can't we have the release team decide what feeds are on planet? <@muelli> O-o * ebassi kicks desrt < desrt> ideally after a long discussion on d-d-l? <@joanie> ebassi: permission to flog him? <@andreasn> hehe <@ebassi> muelli: the current editorial policy is that the editor(s) have the ultimate decision < desrt> joanie: ebassi said public floggings are out <@ebassi> I don't know, we could be making an exception <@ebassi> anyway, thanks a lot to everyone for attending. it was a great meeting <@joanie> like python 3, I'll just do it and wait for the RT to take action <@joanie> ;) <@andreasn> ebassi, thanks for holding it. Excellent discussion <@ebassi> the minutes will be put on the wiki after a bit of editing, along with the log <@muelli> thanks!