[Sugar-devel] [MINUTES] Development team meeting --- 1. Nov 2011 (15:00 UTC)

[Simon Schampijer]

Hi,

this was the first development team meeting after a long time, I am 
happy we made this happen. This will be a weekly meeting, those who have 
not joined this week can start doing next week.

This week's meeting was about getting developers up to speed that had 
not have the chance to attend the hackfest in Praha [1]. So we gathered 
questions related to the work that has been done [2].

Furthermore we discussed what is important for activity authors when 
doing new releases, which branch they should work in and what is 
expected to be present in the gtk-2 based branch. The discussion has 
been gathered in the activity porting guide [3]. In short:
* bug fix work should happen on a separate branch, we recommend naming 
that 'sugar-0.94'
* dotted versions for bug fix releases, major releases for future releases
* pootle will only handle the master branch by default, activity authors 
are discouraged to push new strings to their bug-fix branch

The action items for this week are:
* check if ASLO supports well having different activity versions, dotted 
versions and major versions
* check which activities uses a drawable which has to be replaced by 
cairo calls
* write up cairo porting guide (walter)

Logs can be found at [4] (I did start the bot late, full log at the end 
of the mail).

Next meeting will be the 8th of November 15:00 (UTC) in #sugar-meeting.

Regards,
     Simon

[1] http://wiki.sugarlabs.org/go/Marketing_Team/Events/Gtk3_Hackfest_2011
[2] http://wiki.sugarlabs.org/go/Features/GTK3/Development
[3] http://wiki.sugarlabs.org/go/Features/GTK3/Porting
[4] 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-11-01T15:54:34.html

- Tuesday November 01 2011, 15:59 -
garycmartin: erikos: hi
erikos: garycmartin: hey!
walterbender: hi everyone
  * erikos prepares for the development team meeting
garycmartin: hi walterbender
erikos: who is here for the meeting?
  * garycmartin raises hand
walterbender: me too
  - gonzalo_ - gonzalo -
erikos: gonzalo_: and manuq should be here too
  * manuq is here
erikos: let's gibe it three more minutes if anyone else shows up
erikos: marcopg might be travelling...
manuq: erikos: marco started the theming port, right?
erikos: manuq: benzea did, yes
manuq: ok
erikos: (benjamin)
erikos: topic: http://wiki.sugarlabs.org/go/Features/GTK3/Development
erikos: manuq: benjamin did the old theme as well
erikos: ok, let's start
  * walterbender needs to update the wiki from the activity POV
erikos: walterbender: yes, good point, maybe we can give it a shot after 
the meeting
erikos: so maybe we can start with questions, this first meeting should 
be about bringing up the people whoi have not been in prague
  - gonzalo_ - gonzalo -
erikos: garycmartin: manuq, gonzalo_: please ask anything you are 
interested in
erikos: (I hope there have been good information by email and wiki page 
already to start with)
garycmartin: erikos: I noted in one of the screen shots of a gtk3 
activity, that the toolbar had text hints below each icon. Was this 
intended or just work in progress?
erikos: garycmartin: just work in progress
walterbender: garycmartin: there was no intention at this point to make 
deisgn changes... just get things working
erikos: garycmartin: we have two main areas that are 'broken' at the moment
manuq: what is the state of the theme port? there is a plan or a schedule?
erikos: palettes (benjamin and marco have been working  on that)
erikos: and the theme
garycmartin: erikos: Also only just realised that GTK3 drops all it's 
drawing/image bits, and recommends moving over to ciaro. I'll need to do 
that for Moon (it's been something I intended to do anyway), I wonder 
how many other activities may be using GTK2 drawing primitives...
erikos: manuq: ben has been working on it and will continue, I presume, 
but help is welcome of course
erikos: manuq: and I presume needed as he is a volunteer
erikos: garycmartin: correct, walter did work on TA for that
erikos: garycmartin: he will post some help about that later
erikos: garycmartin: (should be as well in his repo) walterbender^^
  - dsd_ has joined the room
manuq: I wonder if there is a need to change Paint also
manuq: I will check
erikos: manuq: garycmartin: yes, maybe someone can go through the 
activities and make alist which ones need porting to cairo
manuq: ok
erikos: maybe for now, just check the ones that are in an olpc build to 
start with
walterbender: I ported Abacus to gtk-3 (with lots of benzea help)
erikos: takers for that task?
walterbender: and I am almost done with TA for gtk-3
erikos: hey dsd_ (everything packed already?)
walterbender: but I made no UI changes
garycmartin: erikos: I can do some quick grep actions and see what 
activities I spot using GTK2 drawing.
erikos: garycmartin: great, thanks
manuq: walterbender: that's great news!
erikos: I will grab benzea to see what he says about the theme and he 
has some unpushed palette code
walterbender: garycmartin: I suspect that many if not all use Drawable
manuq: yeah, Paint does
  - bertf has joined the room
garycmartin: walterbender: Ouch. OK.
walterbender: garycmartin: I have a pretty good handle on the transition 
to cairo
erikos: walterbender: and performance wise you were happy, too - right?
walterbender: garycmartin: the strategy is to get it to be cairo only in 
gtk-2 and then switch to gtk-3
walterbender: erikos: well...
walterbender: erikos: with abacus, yes...
erikos: ahh, ok
walterbender: erikos: but I have a concern re TA
walterbender: erikos: TA in GNOME is very fast
walterbender: but less fast in Sugar
garycmartin: erikos: So a general question about activity authors 
intentions. Future Sugar will support both GTK2 and GTK3 for a 
transition period (~year). During that transition period will authors 
try to support both existing users (GTK2), and hold of on GTK3 work as 
late as feasible?
  * erikos did add Abacus to the repos list: 
http://wiki.sugarlabs.org/go/Features/GTK3/Development#Repos
walterbender: garycmartin: the idea is to branch and do future 
development on gtk-3 and only maintenance on gtk-2
erikos: walterbender: ok, we should investigate why that is the case
walterbender: erikos: give me 24 hours...
erikos: garycmartin: yes, the toolkit-gtk2 will be around for ~1 year, 
but will only see bug fixes if at all
erikos: walterbender: heh, not that much of a rush
garycmartin: garycmartin: will need to go learn how to do git branch 
workflow type things – have mostly avoided that complexity up to now.
erikos: garycmartin: and yes, activity authors can do work and releases 
in the following way:
manuq: so, is there a proposal on how we should do the maintenance of 
both branches, maybe a convention in the naming of the branches?
dsd_: garycmartin: i think thats up to the maintainer and their preference
dsd_: personally i would prioritise GTK3 work and future-facing 
developments, leaving the previously released versions for those who 
dont run the new stuff
walterbender: dsd_: yes...
erikos: - maintainers should start there wrk by branching of the las 
stable release, for example Memorize
dsd_: but others might have different views and want to keep doing 
releases for GTK2 users for years to come
walterbender: dsd_: we need to give activity developers guidence
erikos: - last stable release 30
erikos: - branch of the 'sucrose-0.94' branch
erikos: - make a bugfix in 'sucrose-0.94' branch
erikos: - make a release in the 'sucrose-0.94' branch branch --> 30.1
erikos: - port to gtk3 in master branch
erikos: - make a new release ---> 31
erikos: so point releases for bug fix releases (GTK2)
erikos: and major releases for the new GTK3 stuff
garycmartin: erikos: I'm also wondering about version numbers of such 
activities that do decide to fork development. I guess we end up with 
one stuck on a version number 12.1, 12.2, 12.3, while the GTK3 versions 
get 13, 14, 15?
erikos: of course a maintainer can name their branch how they like, but 
I would suggest them to choose the same name
erikos: (maybe 'sucrose-0.94' branch, so it is easy for someone that 
looks at the branches)
erikos: garycmartin: exactly
erikos: garycmartin: happy with that versioning approach?
garycmartin: erikos: so new features will end up in a bug fix version 
number?
erikos: and yes, the git workflow and the conventions would be written 
on the 'port your activity to gtk3' page
erikos: garycmartin: that is dependent on the author
  * cjl thinks lots of activity branching is probably going to impact 
L10n and Pootle. . .
erikos: garycmartin: maybe bugfix branch is more correct for sugar
erikos: garycmartin: if an activity author wants to put a new feature in 
a gtk2 and the gtk3 release he is welcome to
erikos: does that make sense?
walterbender: cjl: not sure that it will have too much impact... gettext 
works the same AFAIK
garycmartin: erikos: hmmm, so the assumption is that we generally won't 
add any new features for existing GTK2 folks, bug fixes for them only.
cjl: walterbender: Poolte points at specific branches for POT refresh 
and commit.
erikos: garycmartin: do you mean on the sugar platform? or for activities?
garycmartin: erikos: sorry, activities.
cjl: It's not a function thing, but a Poolte git thing
erikos: garycmartin: well, I would not recommend it
garycmartin: :-)
manuq: I think we should prioritize gtk3 development in order to reach 
the goal, there are not many hand for development
erikos: garycmartin: if an author has the time to do it, up to him really
erikos: manuq: yes, espacially for the activities the core team deals with
garycmartin: erikos: OK, I'm just thinking about the general dev author 
recommendations we'll make for this (Activity Team)
erikos: garycmartin: yes, is important
garycmartin: erikos: and what deployments may/will expect from 
activities they use (and likely maintained be folks in Activity Team)
erikos: are people happy with recommending the branch name: 
'sucrose-0.94' for the stable branch?
manuq: erikos: I know "sucrose-0.94" is more specific than "sugar-0.94", 
but the latter is simpler IMHO
erikos: garycmartin: I think if the new release rocks and has general 
advantages (including sugar goodies itself) we can recommending updating 
to the new platform
erikos: manuq: is fine with me
erikos: does sugar-0.94 speak to others as well?
gonzalo_: erikos, yes, would be good if all the branches are named equal 
if possible
garycmartin: erikos: I'd go for sticking with the names as used already, 
I assume that is 'sucrose-0.94'?
erikos: I prefer slightly to 'sucrose-0.94' because that is the name of 
the stable sugar-toolkit branch
cjl: I'd like to avoid branching in Pootle, so hopefully people will be 
okay with dealing with their own backporting of Po files.  I'll keep 
Poolte focused on master
  - cjl - cjb -
erikos: cjl: sure
erikos: actually the pootle stuff is another good reason not to port 
back features (likely including new strings)
erikos: should we vote quickly for the name?
erikos: we have up 'sugar-0.94' and 'sucrose-0.94'
manuq: as I'm new, I didn't knew that 'sucrose-094' was used previously, 
if that is the case we should continue using it
manuq: sorry for the interruption
  * cjl abstains
erikos: manuq: http://git.sugarlabs.org/sugar-toolkit/mainline
gonzalo_: erikos, about versions, i am thinking about how will work aslo 
and the activity updater in actual (non gtk3) sugar
gonzalo_: may be we need do a more specific filter to avoid breaking 
usuers experience
erikos: manuq: i think in general sugar-0.94 works slightly better for 
activity authors in that it is shorter and sugar is clearer than sucrose 
to many
garycmartin: gonzalo_: yea I'm worried about that as well. ASLO will be 
fine, but not the activity updater (I haven't used that in a year or so)
erikos: manuq: but yeah as we have used it already and the stable branch 
of the sugar-toolkit will be 'sucrose-0.94', I guess this makes sense
gonzalo_: garycmartin, aslko show you the last version
erikos: manuq: if an author wants to look in the git repo of the toolkit 
he might more likely find it
  - gonzalo_ - gonzalo -
garycmartin: gonzalo_: ASLO allows a developer to set what version of 
Sugar an activity works with.
gonzalo_: garycmartin, yes, but the users do not care about that :-(
erikos: gonzalo_: garycmartin: good point we need to check that, so I 
thin kit should be fine
  - gonzalo_ - gonzalo -
erikos: gonzalo_: users or activity authors?
  - gonzalo_ - gonzalo -
  - gonzalo_ - gonzalo -
garycmartin: Hmmm, actually… does ASLO allow a developer to release more 
than one activity with the same bundle identifier??
gonzalo_: erikos, users
erikos: gonzalo_: if your system is 0.94 and you go to aslo it should 
not offer you an activity that is marked 0.96 only
garycmartin: gonzalo_: If a user visits ASLO with Browse it shows them 
the latest activity version for their current Sugar build.
erikos: but ok, we should verify
manuq: erikos: let's use the 'sucrose-0.94' recomendation!
gonzalo_: garycmartin, yes?
erikos: 10 more minutes to go
  * erikos had the recommendation to keep this to an hour MAX so 
externals can prepare for attending
gonzalo_: manuq, sucrose is specific to a group of modules
erikos: ok, anyone against the 'sucrose-0.94' recomendation?
gonzalo_: sugar is general
gonzalo_: erikos, i am for sugar-0.94
erikos: uff :-)
gonzalo_: damn chemist! :-)
  * garycmartin doesn't mind much either way.
erikos: ok, let's vote
erikos: I think the most important thig is that activity authors go for 
the recommendation and that we end up with same baranch names
erikos: being consistent
erikos: if people think we have better chances to reach that with 0.94
erikos: with sugar-0.94
erikos: ...
  - gonzalo_ - gonzalo -
erikos: manuq: garycmartin, walterbender, gonzalo_ your votes please
erikos: dsd_: you as well
gonzalo_: erikos, +1 to sugar-0.94
  * erikos forgot about the bot :-/
erikos: startmeeting
  * erikos forgots syntax
manuq: ok, let's start again
erikos: #startmeeting
meeting: Meeting started Tue Nov  1 15:54:34 2011 UTC. The chair is 
erikos. Information about MeetBot at http://wiki.debian.org/MeetBot.
meeting: Useful Commands: #action #agreed #help #info #idea #link #topic 
#endmeeting
gonzalo_: ha ha
erikos: branch name: sugar-0.94 or sucrose-0.94 ?
  * garycmartin it momentarily confused… next version of Sugar will 
still be GTK3+ compatible
walterbender: garycmartin: that is the hope
garycmartin: so should the branch name be sugar-0.96, the last working 
build?
  * garycmartin or am I very confused.
manuq: ok, I'll give +1 to sugar-0.94 as the convention name for an 
activitie's branch that works on GTK-2, as it's simpler from the devs 
point of view
cjl: gasry name is for the gtk2 version remaining behind
gonzalo_: erikos, the plan is move sugar module to use instrospection in 
0.96 cycle?
manuq: garycmartin: we are voting the convention name for the branch of 
activities, not for sugar
erikos: #action check if ASLO supports well having different activity 
versions, dotted versions and major versions
cjl: garycmartin: The gtk3 version just becomes master (if branched at 
all)  the gtk2 branch will have a recommended naming standard
erikos: garycmartin: you will work for gtk3 on the master branch, no 
forking needed
  * cjl thinks he got that right
erikos: garycmartin: you can fork again for GTK4 :-)
  - gonzalo_ - gonzalo -
garycmartin: isn't the activity branch for indicating the last gtk2 
compatible sugar it will run on?
erikos: gonzalo_: you mean, that we access GTK3 through introspection in 
the sugar-toolkit?
gonzalo_: erikos, yes
  - gonzalo_ - gonzalo -
erikos: gonzalo_: the new toolkit already does that, there are no static 
bindings anymore, so we have to :-)
erikos: garycmartin: the 'sucrose-0.94' will be the gtk2 branch, master 
will be the future branch (new features GTK3)...
gonzalo_: erikos, yeah, but sugar module, need be ported to the new 
sugar-toolkit
  - gonzalo_ - gonzalo -
gonzalo_: the views, journal...
erikos: gonzalo_: the shell? ok...
  - gonzalo_ - gonzalo -
erikos: gonzalo_: if we have time, we do yes, otherwise the shell 
(sugar) accesses the old toolkit
  - gonzalo_ - gonzalo -
  * garycmartin is now positive he's very confused about branches and 
naming.
erikos: gonzalo_: lets see how fast we move on with the toolkit porting 
and with the activity work
gonzalo_: erikos, ok
erikos: garycmartin: I can write it up in the porting guide and show you 
the example in the hello-world activity, is that fine?
garycmartin: erikos: sure.
gonzalo_: erikos, i have another concern related to branches, and pootle 
specifically
erikos: #action check which activities uses a drawable which has to be 
replaced by cairo calls
erikos: #action write up cairo porting guide (walter)
  - gonzalo_ - gonzalo -
erikos: gonzalo_: shoot
gonzalo_: erikos, right now pootle is using projects related to 
branches, if we create a sugar-0.94 branch in every ported activity, we 
will need document the developer should report to pootle maintainers
  - gonzalo_ - gonzalo -
erikos: gonzalo_: yes
gonzalo_: and pootle mainteiners will need create a honey094 project
gonzalo_: and add every activity
gonzalo_: right?
cjl: gonzalo I don't think I want to do that.  I think we keep Pootle 
focused on master
cjl: Id someone doesn't branch, it is still pointed at the right place.
  - gonzalo_ - gonzalo -
erikos: gonzalo_ yes I think focusing on master is ok
  - gonzalo_ - gonzalo -
cjl: If someone does (and wants t orelease a gtk2 backport), they can 
deal with pomerge themselves.
gonzalo_: cjl, we can agree in a "no string changes" in the old branch
erikos: gonzalo_ we just should tell the activity author to not port 
back stuff with strings
erikos: right
cjl: gonzalo_  Iwould say strign changes on gtk2 branch will nto be 
supported in Poolte.
erikos: ok, let's wrap up, we are already over time
erikos: I will work on the porting instructions after the meeting, help 
welcome
gonzalo_: cjl, the problem will be all the user in gtk2 we will have for 
a few years
erikos: espacially when there are questions that come up while following 
the guide
gonzalo_: we have users using sugar 0.84 now (and probably 0.82 too)
cjl: gonzalo_ we can discuss more after meeting
erikos: and I will send it for review etc of course
garycmartin: erikos: So I guess as we move an activity over to GTK3, we 
can also strip out all the backwards compatibility tweaks for old Sugar 
toolbars and suck like as well.
erikos: garycmartin: yes
erikos: garycmartin: we can do the bg cleanup
erikos: ok, as noted in the mail, this will be a weekly meeting, so we 
will see again next week
erikos: I ant to keep the meetings short so externals can easily plan 
and participate
erikos: if people want to chat more after the meeting, ok, and great
walterbender: weekly or biweekly ? devel team meetings inbetween?
erikos: walterbender: weekly, this is the devel team meeting
gonzalo_: ok
walterbender: erikos: OK...
cjl: walterbender: you asre thinking alternating desgn and activ ity 
team perhaps?
erikos: thanks everyone for attending!
erikos: 5
erikos: 4
erikos: 3
erikos: 2
erikos: 1
erikos: #endmeeting
meeting: Meeting ended Tue Nov  1 16:14:12 2011 UTC. Information about 
MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
meeting: Minutes: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-11-01T15:54:34.html
meeting: Log: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-11-01T15:54:34
  * erikos gets tea for the next round
  * walterbender heads to lunch
cjl: s ogonzxalo, I'm happy to have my thinking on Poolte challenged.
garycmartin: erikos: thanks
  * garycmartin tea and pizza here!
cjl: What I am thinking is that existing older Sugar deployments have 
the L10n they want for the most part.
cjl: We sholul keep Pootle focused on master t okeep it simple and 
encourage migration.
gonzalo_: cjl, may be
  - dogi has joined the room
cjl: What Sugar is Peru using?
gonzalo_: cjl, i want see how hard/easy is port the activities....
gonzalo_: cjl, i don't know what are theyusing now
gonzalo_: cjl, i am going to lunch now, can we continue later?
walterbender: gonzalo: take a look at the abacus cairo and gtk-3 branches
cjl: gonzalo_ I hope you know that in the end of the day, I will support 
what is necessary to get people the strings we can, I'm hoping for the 
simplest answer though.
gonzalo_: cjl, of course, i know
cjl: gonzalo_ sure, bon apetit
walterbender: gonzalo_: I first migrate to cairo and then to gtk-3
cjl: gonzalo_ I g3enuinely welcome havign my thinmking challenged, 
because I'll be the first to admit that I am 'shooting from the hip".
  * cjl is also typing with his thumbs apparently
- 17:29 -
cjl: I know gonzalo_ is at lunch, but I will go ahead and try to 
articulate my thoughts for later
cjl: The basic idea would be to have one PO file maintained under the 
master branch.
cjl: If the activity doesn't branch, ther eis no issue.
cjl: If the activity branches and a gtk2 version is desired, most 
strings should hopefully remain the same, so the master branch PO file 
should be usable for packaging a build of the activity.
cjl: If there are string differences between master and the gtk2 branch, 
perhaps the dev can hang the differing gtk2 strings in the master code 
in such a way that it gets picked up by POT generator, but does not 
really do anything in the code.
cjl: That way, the gtk2 strings would be present in the single POT and 
get localized without any complexity in Poolte.
cjl: The activity dev would use the master branch PO files for the gtk2 
build and hopefully everything works out jsut fine.
cjl: That is my wish for how this might work.
cjl: Whether it can really work tha tway is to be determined.
cjl: gonzalo_   ^^^^
  - walterbender has disconnected (Remote host closed the connection)
- 17:41 -
garycmartin: cjl: seems to make sense to me. This is with the assumption 
that a developer who makes a GTK2 bug fix release wants to pick up any 
new translations available – if not then they will still have the old 
pot files in their old branch.
  - dogi has disconnected (Ping timeout: 240 seconds)
cjl: garycmartin: yes
cjl: That was my earlier point tha deployments usign older Sugar 
releases may already have hte L10n they need.
cjl: As they will not be under Poolte control, the dev can do whatever 
they need t odo on th ebranched /po directory.
cjl: Ther eare suitable tools like pomerge, etc.
cjl: Whast I want to do is come to an understanding tha we do not have t 
ogo out of our way t osupport L10n of the gtk2 branch version.
cjl: Although I am happy to offer ad hoc suggestions of how to achieve 
tha with any developer that feels they need it.
garycmartin: cjl: I think most developers who are focused on supporting 
existing users/deployments will hold off branching for a while, at least 
until gtk3 offers them some really exciting shiny feature they just have 
to include ;-)
garycmartin: cjl: I know that's likely not what the Development Team 
would want to hear, as it will mean GTK3 Sugar will not be so heavily 
tested with real activities for a while, and that there might be a 'last 
minute' rush to port some activities once GTK2 support gets close to 
disappearing.
cjl: I suspect yo uare right, whcih is another reason to maintain focus 
on master
  - walterbender has joined the room
- 17:59 -
  - dirakx has joined the room
- 18:13 -
erikos: garycmartin: 
http://wiki.sugarlabs.org/go/Features/GTK3/ActivityPorting
  - dogi has joined the room
erikos: garycmartin: maybe this makes it a bit clearer
erikos: garycmartin: let me know if things are still unclear
  * erikos has to run
garycmartin: erikos: thanks!
  * garycmartin will go read.
dsd_: erikos: please merge that into 
http://wiki.sugarlabs.org/go/Features/GTK3/Porting