This actually covers different aspects: A user-facing aspect and an engineering aspect which relates to the nitty gritty technical details of foresight-distro-engineering and how we build Java software. And of course, there is the ever thorny licensing aspect.

• From a user standpoint, using the Sun JRE gives the best user experience, especially when online banking systems are taken into account. Foresight currently does not ship the Sun JRE but rather the IcedTea/OpenJDK JRE per default in group-{kde,xfce,gnome}-dist.
• From an engineering standpoint, building against IcedTea/OpenJDK is by far the preferred option, since everything that will build against and run on IcedTea will run on the Sun JRE. The reverse is not necessarily true. Hence, the preferred option is to keep building our packages against IcedTea/OpenJDK even if we ship Sun’s JRE (in group-{kde,xfce,gnome}-dist) and JDK (group-{kde,xfce,gnome}-dist-devel) per default. The point was also made that the general practice in OSS land is to build against IcedTea and hence we would be better off following that trend.
• It is worth mentioning that while Java apps have build requirements, they don’t have runtime requirements — so whichever JRE owns /usr/bin/java wins. In practice, if both IcedTea and the Sun java stack are installed, then the icedtea java gets consumed byDefault (so a developer who installs IcedTea-{jre,jdk} without uninstalling the Sun-{JRE/JDK} will use the IcedTea-JDK in his local builds, without further action)
• From a licensing standpoint, we are pragmatic enough to not be fussed about shipping Sun software by default, as the IcedTea JRE/JDK is available in the repository for those who cannot stomach the thought of using Sun’s proprietary Java bits. We may have to revisit this, though.

OgMaciel, doniphon and Mark__T all voted in favour of shipping sun-jre by default in group-gnome-dist. doniphon fixed the groups a few minutes later.

Shipping x86 Flash on x86_64 groups by default

• Adobe recommends that x86 be used and not x86_64. To improve the user experience, we should follow what Adobe recommends. However, doniphon notes that the two alternative ways of achieving that create their own set of problems.
  • If we keep xulrunner/ffox 64bits, in order to use x86 flash we need nspluginwrapper (we the have latest version in our repository already) which we used in the past. But nspluginwrapper leaks a lot of memory and this is arguably worse than the issues we have now. Also this would imply no flash in chromium64.
  • We could ship ffox/xulrunner/thunderbird/and everything that depends on those as well as all plugins x86. This wouldn’t be a good idea because it would make groups a lot fatter. We can’t have a mixed stack or we would get different stuff that depends on xulrunner to render flash differently.

  None of these two solutions are acceptable.

• Java has a working 64bit plugin now, and adobe has a somewhat working plugin. We got rid of nspluginwrapper. We believe that flash will eventually be fixed.
• Outside of rBuilderOnline, there’s nothing to say about Flash performance on x86_64. For a distribution that promotes rBuilderOnline as a way of getting into packaging, we’re not in the sweetest of spots regarding 64-bit flash, but no Linux distribution is. That was a design decision at rPath, and while Foresight is tangentially rPath’s baby, we should not dumb anything down to make it work with something that is suboptimal. Real packagers will use rBuild anyways.
• Users can install the x86 version of FL for their desktop if they absolutely must have x86 flash working. We should document the command line instructions for those who want to manually convert their system (as well as ways to get back defaults).
• Given the above points, all three members of the council voted in favour of sticking to x86_64 Flash and waiting for better support from Adobe.

Status update

• KDE is being updated.
• jesse and doniphon are going to bump gnome (2.29/2.30 stuff) in 2-devel (that’s why doniphon promoted to 2-qa last night).
• doniphon thinks that 2-devel is in a better state at the moment than he ever tought it would be possible.

Moving to a fixed release cycle of 6 months to match GNOME’s release cycle

• Release here means shipping ISOs but we will obviously keep the rolling releases.
• We should leverage the work being done by the GNOME Devel Kit project.
• We have always tried to release close to GNOME releases but we haven’t made an impact for a while because we have lacked clear objectives. Council unanimously approves creation of a roadmap with milestones for tentative release dates to be drafted by ermo, afranke and OgMaciel. They are going to build on the existing 2.1.2 ‘roadmap’ and collect issues and post the link to -devel.
• We shouldn’t plan too much into the future. Dates can be changed, the point is to set objectives.
• With a roadmap we can specify a commit freeze. We already have such freezes but they happen informally in #foresight-devel where developers are warned that they shouldn’t commit after some date until stuff is promoted to 2-qa. That needs to be documented and formalised.
• Mark__T is distracted by real life at the moment, so there won’t be noise commits from him. He’s still trying to get his focus back on anaconda and indicator stuff.
• OgMaciel, afranke and ermo will schedule a meeting to draft roadmap, which will include issues as well.

Proposed members/developers

• ermo as developer. Accepted unanimously. Congratulations ermo!
• ermo needs to bug OgMaciel later on to get his new cloak.

FL 2.3.0 release sprint

• Sometimes pulseaudio gets 100% in one core. This sound issue is not enough to block 2.3.0. There is a clear and effective workaround (pulseaudio -k) that we need to document in the release notes. The bug happens randomly and is not reproducible.
• smerp is going to work on a FITS list of issues for PackageKit and doniphon will review that later. Some of these issues are blockers for 2.3, some can wait.
• Transscript
  < smerp> 1. Conary 2.1.8 must be on :2 AHEAD of PackageKit. This is to resolve a temp table problem in Conary fixed in 2.1.8
  < smerp> Those are the *most* important things< smerp> 2. Memory-related fix (using Cache() too much) must be cooked into the version of PK on :2 now (0.4.x)
  < smerp> (and that needs to be in 0.4.x, too)
  < smerp> 3. Update model in PK needs to emulate what updateall does *exactly*, which it currently does not.
  < ermo> this will be useful for the roadmap, btw.
  < smerp> For me, the question of “is packagekit ready?” can be answered by this:
  < smerp> Can a user on :2 update to 2.3.0 with PK without exploding? If so, we win.
  < Mark__T> btw, I will drop ati-fglrx 10.2 and wait for 10.3 (should be released soonish), but 10.1 works fine, so we can go with that one if I don’t get a newer one in time
  < smerp> What this means is that the following things must happen ON :2 before we push the hammer
  < ermo> smerp/doniphon: we need to document how to run the upgrade tests, btw. I tried my hand at a howto on the wiki that describes how to test this.
  < ermo> i.e. the upgrade
  < smerp> ermo: W/R/T update testing: I’m afraid that updating to latest :2 is the only way we can support a real update via PK
  < smerp> people still on 2.0.4… well, I can’t help them
  < smerp> Anyone else besides me use VMware or VirtualBox or something like it?
  < smerp> Best way to test this is to use snapshots and rollbacks in a VM
  < OgMaciel> Mark__T: no voting required… thanks for attending and my apologies for the delayed start from my part
  * OgMaciel could use vmware to test
  < smerp> And, by the way, if PK got into a state where it wasn’t hand-waved as a pain in the ass so that actual power users would use it, that would rock
  < smerp> OgMaciel: please, by all means
  < OgMaciel> smerp: will do
  < smerp> Best thing you can do is get a 1 GiB RAM VM with :2 on it ready to go
  * OgMaciel makes it happen
  < Mark__T> is it PackageKit that’s broken? for me it seems like only gpk is a mess
  * smerp thinks that doniphon should push conary 2.1.8 on to :2 yesterday
  < ermo> So (very) short term, smerp and doniphon get pkgkit sane. Re. sound, we all keep and eye out and make sure to make a note of the snd-card
  < ermo> and document sound workaround in release-notes
  < doniphon> smerp: will coordinate that with mkj
  < OgMaciel> doniphon: so I will test updating current :2 *before* you bump newer conary
  < OgMaciel> for testing purposes
  < doniphon> ok
  < smerp> OgMaciel: it’s likely to break at least once.
  < OgMaciel> I will then give doniphon the go ahead and keep all informed
• ermo is taking care of the polkit/PolicyKit & Gnome System Tools issue. We have traditionally used a scheme where users in the wheel group can elevate privileges using their own password. When we switched to polkit from PolicyKit, our old policies stopped working due to changes in the configuration system in polkit. This leads to the system asking for the root password for authentication. We have no root user, which is obviously a problem. ermo put out a solution so that we’re back to using wheel but something blows up when there are more than one user in the wheel group. The user installing FL is put in the wheel group by default but if you add a new user to the wheel group (with gnome-system-tools or via command line) it goes wrong. This is not a blocker for 2.3.0 because the default case works. We only need to document it as a known issue. ermo will make a new issue for it and report there.

Agenda:

• Announcements
• Proposed members/developers
• Proposed Topics
  1. Membership renewals
  2. Toolchain update
  3. FITS and workflow
  4. Tasks and roles
  5. Reschedule Council meetings
  6. Set up ISO mirrors
  7. Empathy vs Pidgin
  8. Infrastructure overview
• Next weeks agenda

Announcements:

• (Og Maciel) pscott has fixed the web frontend for our Mercurial repositories which can now be accessed via hg.foresightlinux.org as well as the secondary www.foresightlinux.org/hg address.
  - pscott noted that he is keeping an eye out for 404 errors in the logs.
• (Og Maciel) Hostmasks for all approved developers and members have been created.
• (Og Maciel) The new website based on Word Press is now published! I stumbled on a few permission issues initially due to the fact that (apparently) pages created by an admin cannot be edited by anyone else. I ended up creating an editor role account for me and assigned all but one existing pages to this user. I have created editor and admin accounts for the following users:
  • Admins: OgMaciel, doniphon, pcutler and pscott
  • Editors: afranke, ermo and TForsman

  Everyone is encouraged to lend a hand with getting the new site vetted

• (Og Maciel) Minutes for last week’s Council meeting were published to the new web site as a blog post instead of placed in the wiki. This is the first time we do it this way and I’d be very interested in what people thing. I feel that people can send their comments or any corrections as a comment and we can edit. Also, as only people with accounts in the web site can edit posts, it will help us mantain the validity of official announcements.
• (Og Maciel) The process of getting the new web site up and running involved the migration (as in conary migrate) of the existing server to the Lamp Appliance repository, all blessed by doniphon who was around to advise me.
  - Og Maciel had to setup MySQL with a password for the root user, which he will make available to the council later.

Proposed Topics:

1. Membership renewals (TForsman)
   • TForsman renewed as developer by quorum. (pcutler, doniphon, OgMaciel)
   • (OgMaciel) Don’t we need a paragraph on renewal on either of:

     http://wiki.foresightlinux.org/display/community/Home

     http://wiki.foresightlinux.org/display/community/Becoming+a+Member

     http://wiki.foresightlinux.org/display/community/Becoming+a+Developer

   • Links from website to wiki on membership needs to be checked
   • The onus is on the Council to send out membership expiration notices
   • Any (well behaved member/developer who re-applies on their own is automatically accepted?
2. Toolchain progress (doniphon)
   • doniphon was happy to report that the latest toolchain build completed with no errors.
   • Testing of the new toolchain still remains.
   • Discuss toolchain and in particular the issue of how to build the x86 flavour (sse vs. sse2 re. Athlon XP) on list – see FL-1437
3. FITS and workflow
   • Ongoing, draft by doniphon sent to pscott
   • Recommend that a draft be circulated on the -devel list for transparency?
4. Tasks and roles
   • Not started yet. The Council will get this going.
   • pscott and doniphon suggested that this meshes with FITS and workflow
5. Reschedule meetings (MarkT)
   • MarkT cannot attend Council meetings on Fridays, which is inconvenient considering that he is a member of the Council
   • The Council will work on finding a more suitable time for the meeting
   • Next meeting is tentatively scheduled for July 14th
6. Set up ISO mirrors (Ken)
   • The monkey was thrown around and no resolution was made
   • This needs to be done, preferrably yesterday. Any takers?
7. Empathy vs. Pidgin (Ken)
   • Ken will announce it on -devel when he’s got Empathy ready for testing
8. Infrastructure documentation (ermo, IT-83)
   • ermo has documented MLs and examined DNS records. He will update http://wiki.foresightlinux.org/display/teams/Foresight+Infrastructure as appropriate
   • Discussion deferred to next meeting

Agenda:

• Announcements
• Last meeting overview
• Proposed topics
  1. Future foresight version
  2. Current Foresight version (2.1.x series)
  3. Promote WP site to official site location
  4. Need to update Confluence
  5. FITS system accounts and organization
  6. Derive our Identity
  7. Who manages access to infrastructure?
  8. Who do you talk to about getting issues on the council agenda?
  9. Deferred agenda points
• Proposed members/developers
• Next Week’s Agenda

Announcements

• New hostmaks (cloaks) have been created for all new members and developers.. (OgMaciel)
• Paul and I had a nice chat yesterday via Skype and have agreed on several topics related to how to organize and steer the community. More to come. (OgMaciel)

Proposed members/developers

• None.

Proposed Topics

1. Future foresight version
   • doniphon is not yet ready to announce 3.x – the ideas for workflow and creation of herds/teams for redundancy and parallel development need more time to coalesce. For now, the ball is in doniphon’s court.
   • doniphon is still wrestling with the new gcc-4.4.0. It crossbuilds (x86 -> x86_64 and x86_64 -> x86) but it does not build ‘natively’ (x86 -> x86 or x86_64 -> x86_64).
   • If anyone wants to try their hand at fixing the toolchain, they can get in touch with doniphon, who mentioned that the new toolchain is in a (non-public) repo at http://www.rpath.org/web/project/foreplay/. Access and rMake contexts will be granted to anyone willing to actually try to build and understand it. Recipes are well commented for a change.
2. Current Foresight version (2.1.x series)
   • doniphon proposed that we focus on feature freeze and testing packages for the 2.1.2 release.
   • doniphon needs volunteers to help clean up old/dead/broken packages and cross reference with groups so that packages move to -qa properly.
   • Og Maciel and doniphon will work on a plan for how to cut this and announce sprints as appropriate.
   • doniphon added that we should do our best to support current users, but that main efforts should go into enriching the developer base.  This in particular includes developing documentation, so that new developers can jump in and get started in relatively short order.
3. Promote WP site to official site location
   • It was agreed to promote the new WP site to the official site location. Og Maciel will handle this.
   • The council will have admin rights to the site.
   • Og Maciel volunteered to be editor and pcutler will assist him as time permits.
   • ermo, afranke, TForsman and perhaps Stephanie ‘stef’ Watson (we need to ask her) will help move content over.
4. Need to update Confluence
   • Og Maciel talked to gxti in private about the benefits we will see by upgrading the Confluence wiki to a newer version and gxti will look at this over the weekend. We have two issues filed against the wiki – one by pcutler (IT-60) that involves a bug where pasting content drops the formatting and one (IT-77) where Confluence doesn’t handle Chinese characters.
   • From the release notes alone, it appears that upgrading Confluence will both fix security issues, affect performance positively, improve the user experience and allow editing directly in OpenOffice via the office connector.
5. FITS system accounts and organization
   • pscott, doniphon and ermo will work on this (IT-29). Additionally, ermo will be granted admin permissions in FITS.
   • During the discussion, pcutler proposed a team lead type for QA work and that everyone should be responsible for triaging bugs. He also suggested regularly scheduled QA sessions. pscott mentioned that it could be helpful to have a group of users who had triage rights. Doniphon mentioned that he’d like to work on the group/workflow issue as well as it ties into his new workflow and metadata plans for 3.x.
   • In particular, pcutler proposed that the above process should be given a fixed amount of time (on the order of 3-6 months) in terms of putting down a roadmap on how to grow the developer base of foresight.
   • Og has talked to gxti in private, who has promised to look into updating JIRA (the FITS platform) to the newest version. ermo will help Og Maciel drive this.
6. Derive our Identity
   • There was general consensus in the meeting that we need a little more time for this. pcutler suggested that we let it simmer on the ML for a little while yet, until around June 30th (setting a deadline primarily to drive it forward)
7. Who manages access to infrastructure?
   • Currently, it’s been mostly the council (doniphon, ken, pcutler).
   • Og Maciel would like to see a definition of roles – what is a member? A developer?
   • doniphon would like to avoid too much red tape, but would still like to work on workflow tuning. It is clear that this needs some careful thought if on one hand we are to avoid bottlenecks and on the other avoid too many chefs in the kitchen.
   • Discussion ensued, with pcutler noting that we need to figure out what we have, before we figure out what we want. He suggested that we need to document the infrastructure that Foresight currently has as well as who has access to it.
   • ermo will drive the effort to document the current infrastructure. This will be documented in the open on the wiki to encourage accountability per doniphon’s sentiment.
   • pcutler, doniphon and Og Maciel will have a chat about how to define tasks and roles. It should be noted that this ties into the FITS workflow issue discussed above. It will also be discussed who can grant access to resources.
8. Who do you talk to about getting issues on the council agenda?
   • Current practice is for Og Maciel or Paul to send out an announcement on the ML and have a wiki page with the agenda and time+date for meeting.
9. Deferred agenda points
   • The deferred agenda points from last weeks meeting primarily concern workflow improvements, which are adressed implicitly above.
   • TForsman will drive a cleanup of current/retired Foresight developers and present his findings next week.