| Time | Nick | Message |
|---|---|---|
| 09:01 | erikos | #TOPIC 0.90 Sucrose release |
| 09:02 | #LINK http://wiki.sugarlabs.org/go/0.90/Roadmap | |
| 09:02 | tomeu | hi all! |
| 09:03 | reads | |
| 09:03 | garycmartin | hey tomeu, you made it. |
| 09:03 | tomeu | hi, garycmartin, nice to see you all |
| 09:03 | erikos | makes another "roll call" |
| 09:04 | walterbender | here |
| 09:04 | garycmartin | here |
| 09:04 | walterbender | hi Michael... |
| 09:04 | erikos | tch: here for the release meeting? |
| 09:04 | walterbender | (Michael: late lunch today in Cambridge? or a coffee at least?) |
| 09:04 | m_stone | walterbender: insofar as mornings can be good, good morning. :) |
| 09:04 | walterbender: see pm | |
| 09:05 | tch | erikos: ack |
| 09:05 | erikos | tch: nice ;p |
| 09:05 | ok, hello everyobody, todays agenda looks the following: | |
| 09:05 | * Introduction: the release cycle approach | |
| 09:05 | * Define the overall goal for 0.90 | |
| 09:05 | * Review processes (review, Feature) | |
| 09:05 | * Open positions (development team, design team, testing team) | |
| 09:06 | anyone wants to add a point? | |
| 09:07 | (you can still do that at the end of the meeting of course) | |
| 09:07 | * Introduction | |
| 09:07 | tomeu | can only stay for 1 hour |
| 09:07 | erikos | tomeu: it won't be longer than an hour of course |
| 09:08 | walterbender | so, shall we begin then? |
| 09:08 | silbe | * how to handle "experimental" work |
| 09:08 | erikos | silbe: ok |
| 09:09 | so, since 0.84 we have been following a 6 moth release cycle | |
| 09:09 | based on the GNOME model and schedule | |
| 09:09 | m_stone | erikos: I have one more suggested agenda item, which is "* stakeholders" |
| 09:09 | erikos | m_stone: ok |
| 09:10 | m_stone | but that can go with your "goal" item. |
| 09:10 | (also, apologies for the interruption) | |
| 09:10 | erikos | http://wiki.sugarlabs.org/go/0.90/Roadmap |
| 09:10 | I have layed out the basic 0.90 roadmap | |
| 09:11 | there is a link at the top - to the GNOME schedule | |
| 09:11 | and as you might see, they are nearly identical | |
| 09:11 | silbe | Why is API freeze before Feature freeze? Shouldn't it be the other way round? |
| 09:12 | erikos | silbe: they are at the same date |
| 09:12 | silbe: we had that different before | |
| 09:12 | silbe | erikos: not according to the page I see in front of me |
| 09:12 | tomeu | I see 19th and 26th |
| 09:13 | a reason for having api freeze before is because it impacts the work of more people | |
| 09:14 | as freezes are primarily a way of limiting the toe stepping between teams | |
| 09:14 | erikos | Aug 02 Sucrose 0.89.x Unstable tarballs due Feature Freeze API/ABI Freeze for 0.87.x Developer APIs should be frozen at this point. |
| 09:15 | silbe: anyhow, it will be the same day | |
| 09:15 | tomeu | ah, the table above needs updating |
| 09:15 | erikos | tomeu: yeah, I was doing last minute edits sorry for that |
| 09:15 | silbe: sorry, but will be good in the end ;p | |
| 09:16 | silbe | maybe the real issue is what the threshold for the feature process (and freeze) is |
| 09:16 | tomeu | we don't have as much API as GNOME, but the idea is that people working on apps that could be using new API should have a bit of time where they can finish their features without having to update to API changes |
| 09:16 | erikos | tomeu: yes, that is the main idea |
| 09:17 | tomeu: GNOME changed to have that at the same date now | |
| 09:17 | tomeu: i am ok with both ways | |
| 09:17 | silbe | for me there's a large overlap between a Feature (one requiring following the Feature Process) and API changes. |
| 09:17 | tomeu | ok, can we move now? |
| 09:17 | erikos | yes |
| 09:17 | tomeu | well, some features will require API changes, some not |
| 09:18 | may be missing the point in question | |
| 09:18 | erikos | silbe: ok, can you ellaborate? |
| 09:19 | silbe: anything you want to be changed? | |
| 09:19 | silbe | the point is that those code changes that are big enough that they should follow the Feature Process are rather likely to change the API of some component. |
| 09:20 | tomeu | so the api changes would need to land before the api freeze, and other changes can land later |
| 09:20 | erikos | silbe: ok, so you think it is a good idea to make API and Feature freeze at the same time? |
| 09:20 | tomeu | if the feature for some reason can only be merged in one go, then the window for merging that feature is shorter than others |
| 09:21 | erikos | silbe: if another Feature depends on that API there is an overlap |
| 09:21 | silbe: that is why the API freeze was done a bit earlier | |
| 09:21 | silbe | erikos: having the dates the same as they seem to be now (modulo some out-of-date table) is fine for me. What I'm missing is a threshold for when patch authors need to follow the Feature Process. |
| 09:22 | erikos | silbe: ok, but that is another issue, or? |
| 09:22 | tomeu | silbe: ah, when something is small enough to not have to follow the feature process? |
| 09:22 | erikos | silbe: you can have a patch that changes API but is not a Feature |
| 09:22 | silbe: so it only needs to repect the API freeze | |
| 09:22 | silbe | tomeu: that's exactly the question, and whether it may make sense to have the dates separate depends on the answer. |
| 09:23 | but actually we should be discussing a different item, and that is: when do patches get merged? | |
| 09:23 | erikos | silbe: for example API cleanup |
| 09:24 | tomeu | silbe: http://wiki.sugarlabs.org/go/F[…]What_is_a_feature.3F |
| 09:25 | erikos | silbe: ok, I tink we should leave this question to the end, to first iron out the overall goal |
| 09:25 | silbe: is that ok with you? | |
| 09:25 | silbe | erikos: sure |
| 09:25 | erikos | silbe: thanks |
| 09:25 | * Define the overall goal for 0.90 | |
| 09:26 | so, as the release cycle is short (due to several circumstances) there are not as many oportunities to cover | |
| 09:26 | I propose the following: | |
| 09:26 | silbe | is feeling we're discussing low-level stuff when the real questions are high level ones, anyway. |
| 09:27 | erikos | - make sure the Features that did not land in 0.88 land |
| 09:27 | - land all the patches that are available | |
| 09:27 | - do more stability/bug fix work | |
| 09:28 | - reduce maintenance burden (collaboaration update - or kill PS) | |
| 09:28 | - and land a few Features (following the Feature process) | |
| 09:28 | obviously there is not so much time left for Features | |
| 09:29 | to not stop new work (Features) we should layout the next cycles that people can work towards that dates | |
| 09:29 | (next cycles can be 2-3 releases) | |
| 09:30 | that would be my basic approach, comments? | |
| 09:30 | walterbender | erikos: all of that is rational, but do we also want to try to draw attention to any gapping holes? |
| 09:31 | erikos | walterbender: if people want to sure |
| 09:31 | m_stone | erikos: these seem like tactical goals rather than like a strategic goal. |
| 09:31 | erikos | walterbender: so my main issue is the following |
| 09:32 | walterbender: depending on the holes, we need certain things in place | |
| 09:32 | walterbender: design, test etc | |
| 09:32 | walterbender | erikos: my point is that the Release Process can also be used to draw attention to important work that needs to be done... it is like planting a flag. |
| 09:32 | erikos | walterbender: right, that is what we have the Feature process for |
| 09:33 | walterbender: and if it is ready for 0.90, great, if not we can land it in 0.92 | |
| 09:33 | tomeu | maybe walterbender is thinking that only the people who is going to do the coding can propose a feature? |
| 09:33 | erikos | walterbender: the schedule gives only a window |
| 09:33 | walterbender | I was thinking that if we agree that certain things are important, maybe we can attract the coders, reviewers, etc. |
| 09:34 | but this may be out of scope for this meeting. | |
| 09:34 | tomeu | walterbender: ah sure, would be good to have a community team thinking about these things :) |
| 09:34 | erikos | walterbender: these a fine ideas indeed |
| 09:34 | m_stone | walterbender: it's definitely relevant to my interest in the meeting. |
| 09:34 | walterbender | this process is very much neutral, which I suppose it should be... |
| 09:34 | silbe | sorry to be blunt, but so far I only see buzz words. What are the actual goals for this release? |
| 09:34 | tomeu | (32 minutes in the meeting) |
| 09:34 | m_stone | (and who, concretely, are primary the stakeholders?) |
| 09:35 | erikos | walterbender: though, out of the skope of the release process |
| 09:35 | walterbender | silbe: that is my point... the release process is a process, not a forum for setting goals... (or am I mistaken?) |
| 09:35 | tomeu | silbe: erikos explained his "basic approach" and asked for comments, if we have none about that we can move to more specific stuff |
| 09:35 | m_stone | erikos: but not out of scope of the selection of a release process. |
| 09:36 | tomeu: I have some, but didn't want to interrupt silbe's and walter's thread. | |
| 09:36 | briefly then: | |
| 09:36 | erikos: I think your list of goals is a fine list for the release process you envision. | |
| 09:36 | silbe | tomeu: everything he mentioned seemed obvious to me. |
| 09:37 | erikos | silbe: well, the release process is about a tool to get the ideas that are floating around into a release |
| 09:37 | m_stone | I particularly like the inclusion of the "merge outstanding patches" and "bug-fix work", along with the "land a few features". |
| 09:37 | erikos | silbe: what do you want me to say, what is needed in the field? |
| 09:37 | silbe: that is what the Feature process is for | |
| 09:38 | silbe | erikos: can you rephrase your last question (now second-last)? |
| 09:38 | m_stone | however, for me, your preferred release process doesn't match very well with my ideas on what is most important for Sugar. |
| 09:38 | erikos | silbe: ok, I try to set a framework for the ideas and needs that are in the sugar community to get into a release that can be packaged by distributions |
| 09:39 | m_stone | or rather, the things that your release process places the most emphasis on. |
| 09:39 | erikos | silbe: but I don't want to talk about each specific Feature |
| 09:39 | silbe: of course I have a personal list, what I would like to see | |
| 09:39 | silbe: i hope you see what i mean | |
| 09:40 | silbe: I think this can be better handled by the deployent teams | |
| 09:40 | silbe | erikos: it seems I'm confused about what the current topic is about. Is it about what (actual patches/features/whatever) we should include / work on for 0.90, or is it whether we should change the current release process? |
| 09:41 | erikos | silbe: I never talked about changing the current process |
| 09:41 | silbe: I proposed the schedule what I think makes sense to tackle | |
| 09:41 | silbe | erikos: so what is this topic about then, if it's neither of the two options I presented? |
| 09:42 | erikos | silbe: and I wanted to talk about the positions that would help to move us forward |
| 09:42 | silbe | erikos: positions? |
| 09:42 | erikos | silbe: like dev team coordinator |
| 09:42 | silbe: testing team coordinator | |
| 09:42 | silbe: design team coordinator | |
| 09:42 | m_stone | listens. |
| 09:42 | silbe | ah, position = role / hat |
| 09:43 | erikos | silbe: yes, sorry |
| 09:43 | tomeu | the testing team would also help with triaging? |
| 09:43 | erikos | silbe: my initial words were about the general approach i justed wanted to repeat why i think it is important |
| 09:44 | tomeu: triaging would be great of course, too | |
| 09:44 | m_stone | erikos: I think I missed the sentence "it is important that we do it this way because...." |
| 09:44 | erikos | m_stone: now you know |
| 09:45 | tomeu: so, I doubt we can fill all the positions | |
| 09:45 | m_stone | erikos: your purpose was "I try to set a framework for the ideas and needs that are in the sugar community to get into a release that can be packaged by distributions" ? |
| 09:45 | erikos | tomeu: I think the most crucial position is that we do not have a dev team coordinator |
| 09:45 | m_stone | or rather, that was your statement of why it's important? |
| 09:46 | tomeu | hmm, I think I would give more importance to someone to coordinate a team for those areas that are very important but almost totally absent |
| 09:46 | at least, the dev team is having meetings without having a coordinator | |
| 09:46 | erikos | tomeu: when was the last dev meeting? |
| 09:47 | walterbender | could use some help from the design team... |
| 09:47 | erikos | walterbender: right |
| 09:47 | tomeu | walterbender: all features would use some fo that help |
| 09:47 | walterbender | some more than others... e.g., write to journal any time. |
| 09:48 | really wants to land that one in 0.90 | |
| 09:48 | erikos | walterbender: that is what I was trying to say earlier: I gave out the points like stability etc |
| 09:48 | m_stone | has not been thrilled with the result of allocating work by forming Teams |
| 09:48 | erikos | walterbender: because we lack so many positions like someone corrdinating the design team |
| 09:48 | garycmartin | walterbender: re design team, I've been off list emailing with Christian a reasonable amount, we has one quick design meeting two/three weeks ago and a planning for one this Sunday. |
| 09:48 | erikos | garycmartin: fab! |
| 09:49 | walterbender | garycmartin: :) I'll try to join you. |
| 09:49 | tomeu | garycmartin: that's excellent news |
| 09:49 | erikos | garycmartin: so my main question is how Feature coders that want design feedback contact you guys |
| 09:49 | garycmartin | walterbender: fab, just Sunday so far no time yet agreed, hence no public email. |
| 09:49 | erikos | garycmartin: what ways do work best for you |
| 09:49 | garycmartin: we should make this clear in the Feature process | |
| 09:50 | garycmartin: maybe we can have a short chat about this later | |
| 09:50 | m_stone | erikos: I ran into a really interesting article yesterday that seems relevant to this discussion: http://www.imatix.com/articles[…]-reliable-systems |
| 09:50 | erikos | tomeu: so what is the most missing team in your opinion? |
| 09:51 | tomeu | community team, without a doubt |
| 09:51 | garycmartin | erikos: I follow all trac posts and emails, but I only chime in if I have positive forward input. I try not to shoot down poor items, just boost good ones. But I only have so many cycles. |
| 09:51 | erikos | (we somehow cover * Review processes (review, Feature) and * Open positions (development team, design team, testing team) at the moment |
| 09:51 | m_stone | erikos: the divide-and-conquer section has a particularly relevant line: Pieces need to fit people. Ultimately, architecture is about fitting the problem to people. If a problem fits neatly to one developer or one small team, it has a good size. If a problem can only be solved by collaborating teams, it's badly sized. |
| 09:51 | tomeu | because if we don't have people working on how to work together, we won't cover the other positions any time soon |
| 09:52 | erikos | garycmartin: sure, maybe we find a process that makes the interaction easier |
| 09:52 | garycmartin: if it is a clear one | |
| 09:53 | tomeu: ok, sounds good to me | |
| 09:53 | walterbender: anybody showed up for that position so far? | |
| 09:53 | garycmartin | erikos: my big worry is when it looks like completely unreviewed (by any design team) features suddenly looks close to landing. aka Journal backup is realy scary just now to my eyes, but I'm not going to start sniping at other folks efforts. |
| 09:53 | _bernie | lurks |
| 09:54 | erikos | hey _bernie |
| 09:54 | garycmartin: sure, makes sense | |
| 09:54 | silbe | _bernie: hey! nice to have you lurking. |
| 09:54 | m_stone | erikos: so concretely, who do you think should be responsible for mediating that conflict? |
| 09:54 | tomeu | garycmartin: one of the ideas behind the feature process is to make easier for people to remember how important is to give feedback on the UX from the start, but I'm not sure everybody has actually read the policy page |
| 09:57 | erikos | ok, we have 5 minutes left |
| 09:58 | I am a bit unsure on how to go on with the open positions | |
| 09:58 | tomeu: I know we have the page and emailed several times alread | |
| 09:58 | y | |
| 09:59 | and the slobs have been talking about it, too | |
| 09:59 | tomeu | erikos: I think there's a lot of things that can be done about resourcing, like other projects do |
| 09:59 | I'm not sure why SLs seems to think that these things will happen by themselves | |
| 10:00 | m_stone | my takeaway from the open positions situation is that the team-and-coordinator approach is not working for the people who are currently available. |
| 10:00 | erikos | tomeu: those efforts take time |
| 10:00 | m_stone | comments? |
| 10:00 | tomeu | m_stone: dunno, it hasn't been put in practice ;) |
| 10:00 | m_stone | tomeu: :) |
| 10:01 | tomeu | I saw discussions about this back when gregdek was marketing team coordinator, but not since then |
| 10:01 | m_stone | tomeu: then "the team-and-coordinator approach has not had a large enough marketing budget to interest the people who are currently available" :) |
| 10:01 | walterbender | but we need to consider why it hasn't worked (finding coordinators) |
| 10:01 | garycmartin | erikos: it boils down with having concrete time to commit to a spcific shaped hat. I know I don't, but could easily see my in the testing or design role if there are no takers. But I don't have that time to offer (and then let folks down), being a co-coordinator is a big enough hat for me at least, perhaps the roles should be smaller? |
| 10:01 | tomeu | m_stone: I do'nt think the problem is if one approach would work or not, rather about people not discussing about how to resource what we really want to happen |
| 10:01 | well, we are now, which is good | |
| 10:02 | walterbender, m_stone: btw, I don't care if the people who take responsibilities want to call themselves coordinators or whatever, but there some organization work that needs to happen | |
| 10:03 | m_stone | tomeu: fully agreed on that. |
| 10:04 | erikos | tomeu: right, and those tasks are always vagabonded |
| 10:04 | tomeu | garycmartin: maybe have more than one person coordinating? but I think that a focused coordinator could spend very little time on this role and have a big impact |
| 10:04 | erikos | tomeu: at Sugar Labs, and in any other community out there |
| 10:04 | tomeu | erikos: well, some do better than others at engaging people for these tasks |
| 10:05 | erikos | tomeu: sure, I just mean that the problem is known |
| 10:05 | tomeu | sure, again, it's nothing that happens by itself, we need to start caring about it |
| 10:05 | erikos | ok, time is up, maybe we can give out a few action items |
| 10:06 | tomeu | is the agenda finished? |
| 10:06 | any items left for a future meeting or for a mailing list thread? | |
| 10:06 | erikos | tomeu: yes, we did not talk about the review process |
| 10:07 | tch | erikos: review for code or ideas/features ? |
| 10:07 | erikos | tomeu: and the 'open positions item' should maybe be moved to a slobs meeting |
| 10:07 | tch: review for code | |
| 10:08 | tch: as the code review process has not changed, I find it a bit confusing that many people are sending their patches to the ml | |
| 10:08 | tch: I mean, this is good in general | |
| 10:08 | m_stone | erikos: what about it confuses you? |
| 10:08 | erikos: just that people aren't following the review process you wrote? | |
| 10:09 | erikos | tch: but I am not sure people know that they in order being merged they need to open a ticket |
| 10:09 | tch | erikos: maybe because they take it as "accept this" while in fact is a "please, help me to improve it, by reviewing" call |
| 10:09 | erikos | I meant that newcomer might be confused about it |
| 10:10 | tch: yeah, this is what i meant | |
| 10:10 | tch: I am worried that it leads to confusion | |
| 10:10 | (using the term "I am confused" was not the right one) | |
| 10:10 | silbe | Why do we still require filing Trac tickets for patches? |
| 10:10 | erikos | m_stone: ^^ |
| 10:10 | tch | erikos: should we use a new tag like [CALL FOR REVIEWING] |
| 10:11 | erikos | silbe: I think the issue is that after all this discussion there was no outcome with a new proposal |
| 10:12 | silbe: I only followed the discussion and I did not read all the pros and cons | |
| 10:12 | silbe: for me at least as a maintainer I miss a clear outcome | |
| 10:12 | silbe | erikos: so we're stalling all patches submitted so far because bernie didn't have time yet to change a wiki page? |
| 10:12 | tomeu | silbe: ? |
| 10:13 | m_stone | silbe: some people might be stalling -- I'm not. |
| 10:13 | silbe: (I'm merging patches that I see that I like, and testing others.) | |
| 10:13 | tomeu | silbe: can you rephrase? |
| 10:15 | silbe | tomeu: we apparently agreed on a new process (at least to me it looked like consensus), but no one ever ACKs patches sent to the mailing list. |
| 10:15 | tomeu | silbe: I don't think we can agree on a new process if we don't have it written down |
| 10:16 | erikos | silbe: to me from the outside - I did not see any agreement :/ |
| 10:16 | tomeu | and I don't understand why it needs to be bernie who writes anything down |
| 10:16 | erikos | silbe: (there could have been, just I am not really sure) |
| 10:17 | silbe: anyhow, we should be clear about the process, it is our main process | |
| 10:17 | silbe: I just want to make sure, we avoid confusion | |
| 10:18 | m_stone | so here's a slightly different question. |
| 10:18 | _bernie has encouraged me several times in the past to fork. | |
| 10:19 | erikos | ok, let's get action items, as we are already past the meeting hour |
| 10:19 | m_stone | erikos: I have resisted doing so because I felt that I might be able to reach an acceptable comprimise with you and tomeu by causing some changes to happen and by letting you see that good things were coming of it. |
| 10:20 | erikos | #ACTION I will finish the schedule for 0.90 |
| 10:20 | silbe | erikos, tomeu: http://lists.sugarlabs.org/arc[…]0-May/023920.html |
| 10:21 | "I'm willing to give it a test drive" meant to me "let's try out the new process". | |
| 10:21 | m_stone | erikos, tomeu: at some point, I would like your feedback on bernie's suggestion. |
| 10:21 | since it might make a lot of the confusion that you find so frustrating go away. | |
| 10:21 | erikos | silbe: can you maybe make sure we reach a consensus on the review process? |
| 10:21 | m_stone | (in exchange for a different, but perhaps more palatable cost) |
| 10:22 | erikos | silbe: maybe send a nother mail with a summary etc? |
| 10:22 | silbe | with "try out" including that we don't require it yet (=> don't change the wiki page) |
| 10:23 | erikos: I'm not sure I understand what exactly you want me to do. How can I ensure the consensus of a group of people? And what do you want me to sum up? | |
| 10:23 | erikos | silbe: or maybe as this has been a hot topic for so long |
| 10:24 | silbe | (feel free to rephrase in german, maybe it's easier to understand that way) |
| 10:24 | erikos | silbe: hehe, give me a sec |
| 10:25 | tomeu | silbe, m_stone: maybe you want to make two specific proposals? I'm having a hard time figuring out what you mean |
| 10:25 | silbe | #IDEA Invite Mel Chua to the next meeting and let's discuss only high-level stuff there |
| 10:26 | erikos | silbe: I think someone needs to make a proposal out of this email thread |
| 10:26 | tomeu | silbe: but erikos wanted to discuss some "low-level" stuff about the release, not sure why we need to chose |
| 10:26 | silbe | erikos: so bernies summary mail isn't a proposal? if not, what is missing? |
| 10:26 | erikos | silbe: because I don't know anymore what it the exact proposal is after all this long discussion |
| 10:27 | silbe | s/summary // |
| 10:27 | erikos | silbe: ok, I can read it |
| 10:28 | silbe: what high level topics were you looking for? | |
| 10:28 | tomeu | silbe: we need an amend or a rewrite of http://wiki.sugarlabs.org/go/D[…]_Team/Code_Review so we can say: "this is the process we want". right now all we have done is say "this looks like something we may want" |
| 10:28 | silbe: even if we were able to agree on a new process without having it written down, I don't think we can tell people to follow a process we cannot write down | |
| 10:29 | silbe | erikos: like how to handle the differences between research work and a shippable product |
| 10:30 | tomeu: so before you're even willing to try it out, you want it written down to every single letter? | |
| 10:31 | tomeu | silbe: please, stop the sarcasm, or do you think it helps? |
| 10:31 | m_stone | tomeu: it seemed like a genuine question to me. |
| 10:31 | silbe | and if we notice something needs to be improved, we write it down to the letter again and vote on the new document? |
| 10:31 | tomeu: sorry, I didn't mean to be sarcastic. Please mind that I'm not a native speaker, so my choice of words is limited. | |
| 10:31 | erikos | ok, i don't think this is part of the 0.90 meeting anymore |
| 10:32 | tomeu | bu aren't we writing letters right now? |
| 10:32 | silbe | (or choice of phrases, or whatever) |
| 10:32 | erikos | thanks for attending |
| 10:32 | m_stone | erikos: thanks for sharing your ideas. |
| 10:32 | erikos | #endmeeting |