Council Meeting Minutes 2009-11-20

Here are the minutes from the last Foresight Council meeting.


  • Announcements
  • Proposed members/developers
  • Proposed Topics
    1. Infrastructure updates
    2. Changing from Pidgin to Empathy
    3. Status update
  • Next meeting agenda


  • Web site updated to latest WordPress for security reasons.
  • Mark Trompell has a working Xfce Lite Edition and gave away a couple of prerelease CDs last week. One fedora guy took some too and promised to show Foresight at his LUG.

Proposed members/developers:

  • jyr as developer. Accepted unanimously. Congratulations jyr!
  • fayek as member and developer. Accepted unanimously. Congratulations fayek!

Proposed Topics:

  1. Infrastructure updates
    • mull, smerp and gxti are working on getting https back.
    • doniphon gave dev access to JohnWelborn and blairzajac, from Sony Pictures Imageworks. They are an rPath customer and are using Foresight as their base desktop. They have already made a bunch of contributions.
    • The council unanimously decided to give ermo, afranke and tforsman admin rights in the wiki to be able to clean up spammers and fix structure in few sections.
  2. Changing from Pidgin to Empathy
    • Both are already packaged.
    • Ubuntu, openSUSE and Fedora all moved to Empathy this cycle. We are in ‘minor’ releases mood at the moment so this is less important to us.
    • A smooth way to handle existing user (Pidgin) data migration is mandatory. Empathy has an import dialog, so this is not a problem.
    • Xfce Edition will keep Pidgin unless Mark__T gets a chance to closely look at Empathy at its dependencies.
    • Shipping Empathy in stock groups while not stopping shipping Pidgin by default too has been proposed. Shipping both by default is not such a good idea because, from a user perspective, it’s confusing to have two apps that do the same thing.
    • It’s been decided that we should make a list of pros and cons and reconsider Empathy for GNOME 2.30.
  3. Status update
    1. Our trees are in a minimally sane state. A big promote/update already happened to fl:2 with no major issues. GNOME 2.28.1 / FL 2.3.0 already in fl:2-qa.
    2. Latest gnome et al are in fl:2-qa, which is relatively close to actual 2-devel. Main issue is that the PackageKit UI in qa doesn’t work. Mark__T fixed it somewhat in fl:2-devel but now updates through it come in chunks which is suboptimal. mull is gonna look at it too. Mark__T planned to have a look at our PackageKit backend too and try to somewhat fill the missing backend features mid term (as conary allows to fill them).
    3. Anaconda front is going forward. Kudos to mull, Mark__T and mkj. ermo offered to jump into anaconda too. Extlinux doesn’t support ext4 yet (it works with ext4 but you can’t install on ext4). Looking at syslinux mailing list, it seems that won’t be introduced before syslinux 4. So even with new anaconda, we probably need to make sure /boot isn’t ext4.
    4. Mobile editions are frozen, and forums in a sort of ‘zombie mode’. We should propose people to consider redirects from the mobile editions to main FL for now and a clear announcement on that, and also to drop forums and concentrate on wiki (until we have more man power).
    5. Informal talks are ongoing about what Foresight Linux 3 should be. We need to get it right. Reinventing the wheel given current level of available resources is not an option. The main issue is to jump into something that we (for a minimal/sustainable/predictable value of we) can maintain/develop. More than throwing package after package, main emphasis is on workflow and package/groups lifetime maintenance. That means taking advantage of tools like mirrorball, of not yet available conary features, thinkering with new concepts like reposight, etc. mkj suggests that, in order to take advantage of rPath development, automation for Foresight Linux 3 development be done via extending mirrorball. doniphon suggests that people interested in this topic read and have a look at where there’s food for thought. The goal is to make things more smooth and with less single points of failure, allowing us to just add value instead of redoing stuff that was already done elsewhere. We would have much more granularity and a metadata driven workflow. It has been considered that we just call rpmbuild from a factory/superclass to build straigh from 3rd party repos the stuff we need but not want/care enough to directly maintain.
    6. doniphon’s main worries are
      1. how to get things manageable/supportable on the long term?
      2. how would we differentiate?
    7. We need to have a look at Fedora Community which is a web tool to help package maintainers. We could extend that and use it. It would also be great if the vcs-pkg project made more noise. Things like setting/translating package descriptions shouldn’t be done at the distro level.

Next meeting agenda:

  • To debate a more specific Foresight Linux 3 roadmap and set of deadlines.

Written by Alexandre Franke. Posted in news

Trackback from your site.

Leave a comment