Ars Technica review of rBuilder

November 21, 2008 appliance-creator, conary, rbuilder, rpath Comments Off

Ars Technica just posted a review of rBuilder, check it out.

Submission deadline for 2.5

November 17, 2008 Foresight, GNOME, Geek, PackageKit, conary Comments Off

Now that we have all had a few days to digest this, lets get down to business. I have created a wiki page outlining the process and listing the objectives for 2.5 in a table of FITS issues.

Road map

Please look over it, if you have other objectives you would like to add, please file issues assigning the fix version to 2.5. That will make them show up in the table on the wiki page. I am setting a deadline of Wednesday, Nov 19 1200 UTC. To find the time in UTC, run ‘date -u’.

Please get your submissions in! We will quickly review the submissions and update the issues to reflect fix version. I want to start the planning stages pretty quickly after the deadline, gathering requirements and designing the solutions. Please include as much detail as possible in the issues, and please review the issues we already have adding comments. The more information the better.

We want you!

November 12, 2008 Foresight, GNOME, General, conary Comments Off

Foresight Linux release planning

The road to Foresight 2.5 includes you!  Historically we have not provided the level of transparency needed to enable more people to participate in Foresight’s core development.  I am very excited about the packagers that have joined in to help, but I suspect them and others have trouble figuring out what is needed.  They have done a great job of packaging new applications and helping to grow our repositories, and we appreciate that.  However, Antonio (doniphon) and I do most of the distro work, and that is our fault.  We tend to have a good understanding of what needs to be done, and we just do it.  This leaves others either not knowing what they can help with, or feeling like they might step on our toes.

So what do we need to do?  Log all issues we are working on, or plan to work on in FITS (Foresight Issue Tracking System) and continually log our progress on tasks.  Not only does this provides us a high level view of where we are, and what needs to be done, but it also provides a wider audience a list of tasks they can step up and accomplish.

We are going with short 1-2 month sprints instead of long 6 month development cycles.  During these sprints we will continually push features into mainline, continually delivering innovation.

  • Sprint Kick off/planning cycle
    • A larger meeting to discuss major objectives for the sprint
      • Break it down into the top level objectives and create issues for them in FITS
      • Hopefully find a driver for each top level objective
    • Organize smaller planning discussions, ideally done via FITS
      • Break down the top level objective into smaller issues in FITS
      • Document requirements of success for each objective
      • Assign a mentor
      • Assign a due date.
      • Create Use Cases for testing
  • Tracking and status reporting
    • Each assignee will continue to update the progress of tasks via FITS
    • Regular blogging of your progress on your piece of the road map, lets make this fun!
    • Weekly status reports
  • Mentoring
    • We should have some more experienced people available to act as mentors.
    • Sounding board for ideas
    • Contribute to and approve designs
    • Help define measurement for success
    • Review/approve completed tasks before pushing to mainline

The key for success is maximum transparency, this means using FITS and the foresight-devel mailing list as much as possible. If you would like to participate, please send an email to our development mailing list. You can find information on the lists here.

For a list of objectives we are already thinking of for Foresight 2.5, check out this list