Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting, 2010-06-30

Index | Today     Channels | Search | Join

All times shown according to UTC.

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

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.