[Sugar-devel] Next release

[Walter Bender]

[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 at 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 at 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 at 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 at 201.221.57.211] has joined #sugar
[11:51] == MelinaSnche-573f [~urk at 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 at 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
[~jvonau at 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
[~jvonau at 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 at 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