[11:23] <walterbender> dnarvaez_: I think we need an irc discussion of the release schedule [11:23] <walterbender> email is too slow for a discussion [11:24] <gonzalo_odiard> walterbender, +1, i just was thinking the same [11:24] <dnarvaez_> I'm happy to have an irc discussion when I'm around [11:24] <walterbender> lets see if gonzalo_odiard is here? [11:24] <gonzalo_odiard> dnarvaez_, what time is better for you? [11:24] <dnarvaez_> now? :) [11:25] <walterbender> some background: [11:25] <walterbender> (1) we have a gaussian distribution of deployments regarding how often they update [11:25] <gonzalo_odiard> dnarvaez_, is k for me, but may be is better organize something for tomorrow, and then interested people can participate [11:25] <walterbender> some never, most every couple of years, some all the time [11:26] <walterbender> gonzalo_odiard: tomorrow won't work for me :( in transit to .PY [11:26] <gonzalo_odiard> true [11:26] <dnarvaez_> gonzalo_odiard: the problem is, I can't commit to a fixed time for meetings [11:27] <dnarvaez_> gonzalo_odiard: I'm happy to discuss when I'm around, I just don't know if I will be around tomorrow :) [11:27] <gonzalo_odiard> dnarvaez_, not even one specific meeting [11:27] <gonzalo_odiard> ? [11:27] <gonzalo_odiard> let define, next monday? [11:28] <gonzalo_odiard> dnarvaez_, the problem with doing it, "when you can" is difficult to organize other people based on that [11:28] <dnarvaez_> heh it sucks, but I don't know if I will be around next monday [11:29] <dnarvaez_> gonzalo_odiard: I know, I'm not saying it's good, just saying that's the best I can do [11:29] <gonzalo_odiard> understand [11:29] <walterbender> dnarvaez_, gonzalo_odiard let's talk some now, and summarize for the list [11:29] <dnarvaez_> that's fine with me [11:30] <gonzalo_odiard> walterbender, ok [11:30] <walterbender> so... again to summarize the situation [11:30] <walterbender> see (1) ^^ [11:31] <gonzalo_odiard> dnarvaez_, usually deployments not update more than one time by year [11:31] <walterbender> (2) we've followed the Fedora release cycle in the past [11:31] <gonzalo_odiard> dnarvaez_, depending if they are at the north or south, have different school schedules [11:32] <walterbender> with an expectation that we'd get releases out for testing every 6 months but only occasionally recommend a major release for updates [11:32] <walterbender> (3) while sugar 100 is buggy, it is much improved over Sugar 98 [11:32] <gonzalo_odiard> walterbender, that helped us to sync with gtk and other dependencies, and add a little help with testing [11:33] <dnarvaez_> walterbender: not sure to understand "only occasionally recommend.." [11:33] <walterbender> dnarvaez_: we had an informal convention that only every other release was deployment friendly [11:33] <gonzalo_odiard> dnarvaez_, at times, olpc publish a version as a preview [11:33] <dnarvaez_> walterbender: upstream? never heard about that [11:34] <gonzalo_odiard> dnarvaez_, like when a new archtecture was added [11:34] <dnarvaez_> what is the latest deployment friendly release? [11:34] <gonzalo_odiard> 13.2.0 [11:34] <gonzalo_odiard> was suagr 0.98 [11:34] <walterbender> dnarvaez_: upstream didn't really take much notice... it was the deployments who used OLPC as an intermediary who cared [11:35] <walterbender> no one deployed sugar 0.96 afaik [11:35] <dnarvaez_> ok, I see [11:36] <gonzalo_odiard> walterbender, to be fair, 0.96 was not a problem of sugar itself [11:36] <walterbender> gonzalo_odiard: yes... but it was useful for testing/debugging regardless of whether or not OLPC deployed it [11:36] <gonzalo_odiard> walterbender, was more as how the "distros", olpc/dextrose images pick fedora/sugar/and all [11:36] == GitHub78 [~GitHub78@192.30.252.49] has joined #sugar [11:36] <GitHub78> [sugar] dnarvaez opened pull request #105: Remove sugar-xo.svg (master...python2) http://git.io/cH_L5w [11:36] == GitHub78 [~GitHub78@192.30.252.49] has left #sugar [] [11:37] <walterbender> let's set aside Dextrose since they don't work with upstream [11:38] <walterbender> but we will not see an OLPC build for F19 [11:38] <walterbender> maybe F21? [11:39] <dnarvaez_> (/me waiting for walterbender to finish is summary) [11:39] <gonzalo_odiard> i hope so [11:40] <walterbender> there are other things we leveraged in the periodic release process [11:40] <walterbender> getting strings translated [11:40] == Mokurai [~mokurai@2601:d:880:5d0:dd2d:1ba1:a926:74aa] has joined #sugar [11:40] <walterbender> the translators tend to work in batch mode, not continuously [11:41] <walterbender> and for activity developers, it sets a deadline for making updates [11:41] <walterbender> e.g., pulling in all the new strings and making a new release [11:42] <dnarvaez_> in general, I don't think it's useful to have a "why we should switch to continuos development" discuss now. We are not ready for that on development side, which is why I haven't proposed it yet. [11:42] <walterbender> so, while contiuous releases may be good for the Sugar dev team, I think there are other external reasons to consider periodic releases [11:43] <walterbender> dnarvaez_: I thought you had proposed it [11:43] <dnarvaez_> there are of course advantages in the time based releases, I think there are more in the continous model but... it needs to be properly detailed [11:44] <walterbender> dnarvaez_: in terms of short term tactics [11:44] <dnarvaez_> walterbender: not until January at least [11:44] <quidam> there is one reason for dextrose being behind upstream, which is that we work with already published versions of sugar, for stability. a continuous release cycle would be very hard for a deployment to implement [11:44] <quidam> (sorry for jumping int the middle of this :) [11:45] <walterbender> we'd like to get a sugar 100 (with some additional features) on F18 into some schools by the end of this month [11:45] <dnarvaez_> walterbender: it's more of my vision for the future, we are not at the point yet where I feel like making an official proposal [11:45] <quidam> I'd rather see a long-term-support kind of cycle [11:45] <dnarvaez_> quidam: with which resources? :) [11:46] <walterbender> dnarvaez_: hopefully we will get lots of feedback on that image [11:46] <quidam> dnarvaez_: well, we could help there, what we do is maintaining old releases instead of working on the new ones [11:46] <walterbender> and use that feedback to inform/improve a january release [11:46] <dnarvaez_> walterbender: what I think is useful to discuss is what to do exactly from here to January [11:46] <dnarvaez_> quidam: good to know :) [11:47] <gonzalo_odiard> dnarvaez_, +1 [11:47] <walterbender> dnarvaez_: so, for january, I'd like to have a schedule that includes an opportunity to add a few new features if possible [11:48] <quidam> as you guys were commenting, some versions get deployed (0.94, 0.98) and others skipped (0.96). I think it would be good for deployments to do that in an official way, and extend support to the versions that are in the field [11:48] <walterbender> relatively minor ones [11:48] <walterbender> dnarvaez_: but would that be 102? or 100++ or does it matter? [11:49] <dnarvaez_> walterbender: that's a break with the 6 months releease cycle you guys want to have though :) [11:49] <gonzalo_odiard> quidam, that is a good plan, but you need improve in the upstreaming of your work [11:49] <walterbender> dnarvaez_: we are already off that cycle. how to get back on [11:49] <quidam> gonzalo_odiard: that is for sure [11:50] <gonzalo_odiard> quidam, and i am happy to help [11:50] <dnarvaez_> walterbender: even if we was on the cycle you wouldn't have been able to have a stable release with some new feature by January (I think) [11:50] <quidam> gonzalo_odiard: but the fact that we usually work with older sugar versions doesn't make it easy sometimes [11:50] <gonzalo_odiard> quidam, of course [11:50] <quidam> that is partially just an excuse, though. we do need to improve [11:51] <walterbender> dnarvaez_: OK... so we will maintain the new features outside of 100 and plan to upstream them after 100 is released [11:51] <dnarvaez_> walterbender: the problem is that we are unable to commit to a time based 0.100 [11:51] <walterbender> I guess the other disconnect is dealing with the Fedora cycle [11:51] <quidam> but it is important to know that deployments prefer stability to new features, and they want long term cycles [11:51] <gonzalo_odiard> walterbender, the january you suggested is because of a Rangan request? [11:51] == MelinaSnche-573f [~urk@201.221.57.211] has joined #sugar [11:51] == MelinaSnche-573f [~urk@201.221.57.211] has quit [Read error: Connection reset by peer] [11:52] <dnarvaez_> walterbender: and that makes it difficult to take that stratgy for example, becausse you have no idea when we will be able to release [11:52] <walterbender> gonzalo_odiard: yes... trying to take into account the needs of a deployment [11:52] <dnarvaez_> to me the big problem is that we are on a time based schedule but we are unable to stick to it [11:52] == kushal [~kdas@fedora/kushal] has joined #sugar [11:52] <walterbender> dnarvaez_: I guess this is the crux of the issue [11:52] <dnarvaez_> that really cant work [11:53] <walterbender> we have been somewhat stymied in testing because of the lack of an OLPC build [11:53] <dnarvaez_> I feel forced into a continous cycle really [11:53] <dnarvaez_> because that doesn't require schedules [11:53] <walterbender> gonzalo_odiard: has recently remedied that situation [11:53] <dnarvaez_> and allows to land minor features if we want [11:53] <walterbender> but only for F18... [11:54] == jvonau [~jvo...@wnpgmb0311w-ds01-160-199.dynamic.mtsallstream.net] has joined #sugar [11:54] <gonzalo_odiard> dnarvaez_, i don't think continues cycle solves the resources problem [11:54] <walterbender> we will not be able to keep Fedora up to date on OLPC without more help [11:54] <dnarvaez_> keeping the features out of the tree for an undefined period of time is bas :( [11:54] == jvonau [~jvo...@wnpgmb0311w-ds01-160-199.dynamic.mtsallstream.net] has left #sugar [] [11:54] <quidam> dnarvaez_: the problem is keeping up with fedora's cycle? [11:54] * satellit I see a gradual separation of sugar on the XO's and Soas in fedora....: ( [11:54] <walterbender> satellit: it is not gradual. it is abrupt [11:55] <walterbender> it has already happened [11:55] <satellit> : / [11:55] <dnarvaez_> gonzalo_odiard: of course it doesn't. It just deals with it a little more naturally. In fact small projects that cannot commit stable resources usually doesn't really have a cycle like our. [11:55] <walterbender> that is imho a big reason why we have lagged in testing this cycle [11:56] <quidam> what about targeting for a sugar release each two fedora cycles? that would make roughly one release a year, which could go well with school schedules [11:56] <dnarvaez_> quidam: the problem is that we are on a 6 months cycle but we are unable to stick to it because we have no resources [11:57] <gonzalo_odiard> quidam, in the practice, we pointed to that, but with a intermediate release, to not push all together once in the year [11:57] <dnarvaez_> quidam: imo the problem is not the lenght of the cycle. With the current releases we just have no idea how lont it would take to get out of the bgfixing phase [11:57] <gonzalo_odiard> quidam, usually deployments select one [11:58] <dnarvaez_> walterbender: I'm not too sure that's the issue. I mean gonzalo_odiard rpms didn't particularly improve the situation [11:58] <walterbender> dnarvaez_: I disagree. only with gonzalo_odiard 's rpms can we test in a school with XOs [11:58] <gonzalo_odiard> dnarvaez_, what can else you think can improve? [11:59] <walterbender> that will improve things (at least in terms of bug discovery) [11:59] <gonzalo_odiard> dnarvaez_, what else you think can improve? [11:59] * satellit (listening but on #schoolserver) [11:59] <dnarvaez_> walterbender: yeah, what I mean is that community didn't really test those rpms... [11:59] <dnarvaez_> walterbender: I'm hopeful getting them in a school will imrpove it [11:59] <dnarvaez_> gonzalo_odiard: getting images in a school, I hope [12:00] <gonzalo_odiard> dnarvaez_, i finished building a image for xo-4 last friday [12:00] <walterbender> dnarvaez_: historically, the real bug reports come from schools/deployments [12:00] <gonzalo_odiard> i can prepare xo-1.5/1.75 images to get more people inviolved [12:01] <dnarvaez_> on the testing side I think what we should focus on is to get new images in a school [12:01] <gonzalo_odiard> but i am already testing/ trying to fix bugs... [12:01] <walterbender> quidam: one thing AC could do to help is post sugar bugs in the sugar tracker [12:02] <satellit_XO> vitualbox images? valid for testing [12:02] <walterbender> satellit_XO: yes... but not valid for a school deployment [12:02] <dnarvaez_> I'm not sure what's the strategy to get bugs triaged and fixed though [12:02] <quidam> walterbender: I was thinking the same. we mostly deal with old versions but in many cases the bug is still in the new ones [12:03] <walterbender> dnarvaez_: I think triage is where we fall short of late [12:03] <Cerlyn> Unfortunately I've been pulled to the "other project" for the foreseeable future [12:03] <dnarvaez_> we really just depend on avilable resources there I guess, which doesn't seem to be many these days? [12:03] <gonzalo_odiard> walterbender, can we ask help to the nz group? [12:03] <gonzalo_odiard> tabitha & co [12:03] <walterbender> dnarvaez_: OLPC used to have someone (erikos) who ran regular triage meetings [12:03] <dnarvaez_> walterbender: but the reason I've been unmotivated to triage is that no one is fixing :) [12:04] <walterbender> gonzalo_odiard: tabitha just had a baby so she is probably not available for the moment [12:04] <gonzalo_odiard> ahh [12:04] <Cerlyn> we should get the other NZ group (karora's team) to work on the laptop [12:04] <walterbender> dnarvaez_: I think that is a little harsh... not everyone is as prolific as you :) [12:04] == nitika [~nitika@122.162.55.32] has joined #sugar [12:05] <walterbender> dnarvaez_: I've fixed a few... gonzalo_odiard many... manuq many :) [12:05] <dnarvaez_> walterbender: I'll admit that my expectations are probably a bit too igh :) [12:05] <walterbender> dnarvaez_: I've been mired in fixing some activity bugs too :P [12:06] <dnarvaez_> if the triaging is being useful I can try to do more of it... [12:06] <walterbender> dnarvaez_: I think triage to help focus our limited resources is important [12:06] <dnarvaez_> mostly I had the feeling no one was looking at the list nayway [12:06] <walterbender> dnarvaez_: I only look every couple of days... [12:07] <walterbender> dnarvaez_: to be honest, I have been in travel hell the past two months [12:07] <walterbender> no end in sight [12:07] <gonzalo_odiard> dnarvaez_, i think improving the quality in the bug database is vital. I have closed more than 50 tickets [12:07] <dnarvaez_> ok, I think we can agree to do more triaging [12:07] <gonzalo_odiard> but do not have inmediate effects [12:07] <dnarvaez_> it's really matter to deal with the backlog... [12:08] <dnarvaez_> because incoming buugs are very little, it won't be a prob to deal with those [12:09] <dnarvaez_> release wise, I honestly don't see a way to get back on the 6 months cycle though [12:09] <gonzalo_odiard> ok, i think all can agree in bug triagging is needed [12:10] <satellit> they are discussing a longer f21 I think [12:10] <dnarvaez_> I'm not sure we will have something we can ship and also you guys want to land new features [12:11] <gonzalo_odiard> dnarvaez_, if we do not define a schedule is really difficult for us make plans [12:11] <walterbender> dnarvaez_: the new features are pretty trivial and mostly pretty self-contained [12:11] <dnarvaez_> gonzalo_odiard: I understand that, but what do you propose if we are unabel to make the schedule? Release anyway? [12:11] <gonzalo_odiard> dnarvaez_, yes [12:11] <walterbender> dnarvaez_: I think it is human nature to be more responsive to a deadline than open-ended [12:12] <dnarvaez_> walterbender: sure I'm more saying that if we follow the 6 months cycle we won't be able to add features [12:12] <walterbender> and people can plan around a deadline [12:12] <dnarvaez_> gonzalo_odiard: ok. personally I don't want to do that... but if I'm the only one... [12:12] <walterbender> and it is what it is when the deadline is reached [12:13] <gonzalo_odiard> dnarvaez_, if you have by example, 2 months to land features, you can push people, and if the time ended, he/she knows will need wait 4/6 months [12:13] <walterbender> and if it is deployable or not will be decided by the deployments [12:13] <walterbender> as long as we are clear about what we have... what works... what is broken [12:13] <dnarvaez_> so I suppose what you guys are proposing is to release 0.100 now and go back to the 6 months cycle, opening features up? [12:14] <walterbender> dnarvaez_: or resync to fedora, whenever that would be ... a phase shift [12:14] <quidam> walterbender: what about maintenance for already published versions? [12:14] <walterbender> quidam: I thought you volunteered for that :) [12:15] <gonzalo_odiard> quidam, yeah, that is a role to fill [12:15] <quidam> I sure did :) what I mean is how would that be managed or scheduled [12:15] <walterbender> quidam: the big issue I see with old versions is that we still need more performance improvements for GTK3 on XO 1 [12:15] <dnarvaez_> quidam: do you need anything special schedule wise? I suppose you couold do continous development on branches for that? [12:15] <walterbender> otherwise, I think the effort should be on the newer bits... the way to fix 0.98 is to go to 100 [12:15] <quidam> walterbender: hmmm, does that pay off? [12:16] <walterbender> quidam: I think we cannot do much more for the XO 1 machines, actually [12:16] <quidam> dnarvaez_: that is ok [12:16] <walterbender> but we also don't have the resources to keep sugar 0.94 current [12:16] <dnarvaez_> quidam: I would post about that on the ml btw, it's only useful if people knows about it :) [12:17] <walterbender> so peru needs to step up to the plate somehow [12:17] <walterbender> those machines are 6 years old!! [12:18] <gonzalo_odiard> dnarvaez_, after we finish this talk, i have a question for you related with performance [12:18] <quidam> dnarvaez_: +1 [12:18] <dnarvaez_> heh funnily what you are proposing is somewhat similar to continuos development [12:19] <walterbender> dnarvaez_: I need to better understand how continuous development will work [12:19] <quidam> dnarvaez_: yes, but for stable versions. to be honest I don't care much for new features [12:19] <walterbender> how does a deployment decide when to jump in and grab fresh bits? [12:20] <quidam> walterbender: when they are hassle free [12:20] <walterbender> quidam: I am not convinced that most of the changes to sugar are driven by new features [12:20] <dnarvaez_> walterbender: they don't need to jump in, we do release every n number of weeks and they get them automatically [12:20] <walterbender> I think it is more a matter of swimming with our upstream so that we can keep our systems maintainable [12:21] <quidam> walterbender: the gtk3 migration and html5 have driven development recently [12:21] <walterbender> dnarvaez_: that is tricky for schools [12:22] <walterbender> they don't like change [12:22] <quidam> precisely [12:22] <walterbender> quidam: gtk3 for two reasons: touch support and stability/maintainability [12:22] <dnarvaez_> imo making small incremental changes is less disruptive than one big change every two years [12:22] <gonzalo_odiard> dnarvaez_, that can work in environments with good connectivity. sadly, most of our users are not in that situation. [12:23] <walterbender> dnarvaez_: I agree, but I am not sure deployments would [12:23] <walterbender> dnarvaez_: but let's discuss it more [12:23] <quidam> walterbender: I know, but what I mean is that big changes have happened in recent releases. it would be nice to have some releases focused on little change and improving performance and stability [12:23] <walterbender> AU might be willing to be a test ground for this [12:23] <dnarvaez_> walterbender: if we don't break them too often I think they would agree :) [12:23] <dnarvaez_> of course infra is a problem as gonzalo_odiard pointed out [12:24] <gonzalo_odiard> dnarvaez_, also, a non resolvable error (like sugar not starting) could be a horror in a hundred of thousand users [12:24] <walterbender> dnarvaez_: prob. something like this might work: continuous development to a small set of designated test schools [12:24] <dnarvaez_> for me it's more a target to work towards then something to switch to in n months [12:24] <dnarvaez_> it is challenging both for development and infra [12:24] <dnarvaez_> it needs to be tried out etc [12:24] <walterbender> and periodic global updates to all schools [12:24] <dnarvaez_> I just think it's the best experience both for users and dvelopers [12:25] <dnarvaez_> so, if we can do it, or move towards it, it will be a huge improebemnt [12:25] <dnarvaez_> if we can ) [12:25] <walterbender> that is essentially what we are doing in AU with the October/January release model [12:25] <dnarvaez_> gonzalo_odiard: you need to make absolutely sure that doesn't happen :) [12:25] <dnarvaez_> walterbender: yes, doing it with some schools sounds like a good idea [12:26] <walterbender> dnarvaez_: I could see a deployment working with continuous development on a small scale and then choosing when to propagate a instance more widely [12:26] <walterbender> but we could be doing continuous development [12:27] <walterbender> still there are some of the other issues, e.g., i18n scheduling, that would need to be worked out. [12:27] <gonzalo_odiard> walterbender, in that way, we are translating testing responsability to deployments, i do not see how can this improve [12:27] <walterbender> and we need some sort of naming convention for debugging, QA, etc [12:27] <dnarvaez_> gonzalo_odiard: imo putting test reponsibility on deployments is the only way forward [12:27] <walterbender> gonzalo_odiard: I think deployments need to decide themselves when to update... but we can make recommendations [12:27] <dnarvaez_> in general, not just about continos development [12:27] <gonzalo_odiard> walterbender, dnarvaez_, i think with the resources we have, we need a more disciplined schedule [12:28] <dnarvaez_> community is not testing and won't test [12:28] <dnarvaez_> the best testers are the people that depends on the product [12:28] <dnarvaez_> we are doing 0 dogfooding [12:28] <dnarvaez_> that's the main reason quality is low imo [12:29] <gonzalo_odiard> dnarvaez_, sadly, deployments do not have the technical resources to fill tickets if is what you want [12:29] <quidam> dnarvaez_: that is easier to say than to do... [12:29] <dnarvaez_> I understand it's hard to do [12:29] <dnarvaez_> I just don't think there is an alternative [12:29] <dnarvaez_> it doesn't have to be all the deployments of course [12:29] <quidam> gonzalo_odiard: and if they fill tickets they want they fixed right away, not the next cycle [12:30] <dnarvaez_> doing it with a couple of schools in Australia would be a huge improbement already [12:30] <gonzalo_odiard> quidam, yes, and is logic [12:30] <walterbender> in my experience, most user bug reports are activity-based [12:30] <dnarvaez_> quidam: exactly, that's why we should do continous development :P [12:30] <walterbender> and those can be fixed out of cycle [12:31] <quidam> dnarvaez_: ...on stable releases :) [12:31] <gonzalo_odiard> dnarvaez_, but that is much easier with a library, or with a web site [12:31] <gonzalo_odiard> in fact activities are continuos developed [12:31] <dnarvaez_> gonzalo_odiard: yes, but I don't think it's impossible with something like sugar [12:31] <gonzalo_odiard> but because are mostly auto contained [12:31] <dnarvaez_> browsers are basically OSes these days [12:31] <quidam> dnarvaez_: AU would be the exception I guess, but deployments would not be testing the version being developed but the one before that [12:32] <dnarvaez_> and they are doing continous development [12:32] <gonzalo_odiard> dnarvaez_, i would like to have the development resources mozilla or chrome have :) [12:32] <dnarvaez_> quidam: not if the latest version is all what there is :) [12:33] <dnarvaez_> gonzalo_odiard: I don't think it's matter of resources, we would do very slow continous development ;P [12:33] <quidam> dnarvaez_: that is all very good from the upstream POV, but for a deployment is a big effort, and sometimes as gonzalo_odiard said you don't even have the network for it [12:33] <dnarvaez_> quidam: infra problems aside, I don't see why it's a big effort for a deployment [12:34] <dnarvaez_> quidam: as long as the chanegs they get are good, they wil be happy with them [12:34] <gonzalo_odiard> dnarvaez_, no [12:34] <dnarvaez_> of course we shouldn't be redesigning UI every two weeks [12:34] <quidam> dnarvaez_: think of several thousand laptops in a country, each one using slightly different versions [12:34] <gonzalo_odiard> dnarvaez_, they have documentation, training and so [12:35] <dnarvaez_> but I don't see why they shouldn't be happy to get bug fixes for example [12:35] <quidam> dnarvaez_: and then give them support [12:35] <dnarvaez_> quidam: why would they be using each a slightly different version? [12:35] <quidam> dnarvaez_: what a deployment usually wants is a rock solid image once a year, even if it is slightly old [12:35] <gonzalo_odiard> quidam, +1 [12:36] <quidam> dnarvaez_: if you bring updates in a continuous way they will get into each machine in a different time [12:36] <dnarvaez_> quidam: they won't get it with the current release cycle. They will get something very little tested every 1 year [12:36] <dnarvaez_> quidam: I don't understand why, they would all pull the update at roughly the same time [12:37] <dnarvaez_> maybe we should wrap this up [12:37] <dnarvaez_> the continous dev discussion is interesting to me but... I suppose what we really need is a shory time plan :) [12:37] <quidam> dnarvaez_: you are assuming a reliable network [12:37] <gonzalo_odiard> dnarvaez_, because good connectivity is not common [12:38] <dnarvaez_> yeah, I'm abstracting from infra issues at the moment :) [12:38] <gonzalo_odiard> dnarvaez_, you can't [12:38] <dnarvaez_> I do think there are ways to work those around but... surely it would have be thought through [12:38] <dnarvaez_> and tested and all :) [12:39] <dnarvaez_> it's a vision, not a proposal yet [12:39] <gonzalo_odiard> dnarvaez_, like you said, is not constructive at this moment use time in discuss that [12:39] <walterbender> well... let me post this discussion to the list... [12:39] <dnarvaez_> yes [12:40] <walterbender> the one thing we agreed on is to do more triage :) [12:40] <dnarvaez_> I wish manuq was here [12:40] <gonzalo_odiard> haha [12:40] <dnarvaez_> walterbender: we are also clear on what you guys are proposing for the release cycle I think [12:40] <gonzalo_odiard> manuq said he will be off for a few days [12:40] <dnarvaez_> walterbender: we are also clear on what you guys are proposing for the release cycle I think [12:40] <gonzalo_odiard> manuq said he will be off for a few days [12:42] <dnarvaez_> ok so [12:42] <dnarvaez_> I think we should make the next release 0.100 [12:42] <dnarvaez_> on 31/10 [12:44] <dnarvaez_> Then we should have the new features discussion [12:44] <dnarvaez_> I tend to think we should do mostly bugfixing for 0.102 but we will see about that [12:44] <walterbender> fair enough [12:45] <dnarvaez_> we can schedule 0.102 in 6 months [12:46] <walterbender> yes [12:46] <walterbender> in January, for AU, we'll distribute a patched 100 (mostly bug fixes and a few essential features) [12:46] <dnarvaez_> I suspect if we want Australia to be successfull we will need to keep 0.101 pretty stable [12:47] <dnarvaez_> ah [12:47] <walterbender> make sense? [12:47] <dnarvaez_> walterbender: I sort of wish you guys used 0.101 but I see you might not want to take that risk [12:48] <dnarvaez_> if you really don't want 0.101 I'd at least work on a branch upstream though [12:48] <walterbender> dnarvaez_: I'd be more than happy to go with 101 [12:49] <dnarvaez_> rather than patching [12:49] <walterbender> I am not anxious to maintain patches outside of upstream ________________________________ [12:49] <dnarvaez_> walterbender: that would be awesome
-- Walter Bender Sugar Labs http://www.sugarlabs.org _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel