Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• releasemanagement

improvement for release style

• Release early. Release often. And listen to your customers.

• We should change Debian "modular" sytle - devided into each component and update them.

• And if we could do, Debian would be most attractive Distribution and get more human resource (test users, developers, translators...) :-)

background

• package and architechture numbers are continueusly growing
• upstreams update their applications often (i.e. GNOME is updated every 6 month)

  • It includes many bug fix and new features (that is, what users' want)

• security holes are found, 0-day attack is not rare.
  • We should fix them as soon as possible.

• Conclusion: We, Debian, need more and more (human) resource to maintain and update our distribution

  • we have enough resource now? (NO - why? why? -> analysis)

analysis

• "Stable" release sometimes nearly equals to "old one"

  • Why? What makes it so?
    • Debian release does not so often happen, and usually late...

      • Why? What makes it so? - It caused by "Giant lock".

• Giant lock is evil.
  • It blocks other processes activities.

    • I say "Giant lock" is "Freeze" in release management in Debian

      • If we have RC bugs in "font" packges, we cannot release new release with new LAMP server packages.
        • but... RC bugs in "font" packages don't affect other packages (loose coupling).
          • one RC bug makes one bottle neck, if we would fix it, then we have two other RC bugs...(oh no)

        • We must improve this lock model as "fine-grained lock"

  • Think about "loose coupling" and "tight coupling"

    • If we would release newest font packages, frozen LAMP server package would get _no_ regression.

    • as same as GNOME and LAMP

      • devide packages into each "component" and think about which component should be released on each time - this is fine-grained lock!

        • this idea is inspired by "etch-and-a-half" release, that was kernel and X upgrade. My idea ("component based release") is on the same but more and more huge vector.

  • Now, Debian's release model is like "Giant lock" model We should change it to "component based - modular (fine-grained lock)" release model

    • It's so flexible! - see X.org, it is modulared one

      • Easy to fix release schedule ever
        • less delay, because of less updated packages.
      • We can release "newest" or "not out-of-date" packages for users
      • It may reduce "Security Backport" and its latency time (because we are always near to upstream).
  • partial upgrade is needed from users.
    • see backports!
    • think why users use apt pinning!
• Time based release is important.
  • We are volunteers, and have each own schedule (they are all different).

    • I want to know when Debconf would begin, and would end

    • I hope my worktime is 9 to 5, not want "I don't know when your worktime is end, maybe 5, 9 or 12 (oh, no...)"

  • Time based (scheduled) release is important for people - test users/developers/tranlsators/debian-based distributors, they can adjust their own issues for release schedule.

    • and component based release make it easier than "Giant lock" release.
• Or just shurink package and architechture numbers?
  • partialy yes, old package and architechture that should be purged from "Official support"
  • but mostly NO, we need them to solve our users' issue

release versioning model

• x.y.z
  • X is major version. If we have major change, X is updated.
  • Y is minor version. Every 2 or 3 month, component based release is done (timing concerns with GNOME, KDE, X or so).
  • Z is fix version. If we would find fault or security problem in release, Z is updated and fixed package is provided (as same as now).

• unstable -> testing criteria change

  • Now: just 10days and dependencies

  • New: + "component is released or not in next release"

    • So... Now we can release "alpha1" "beta2" "RC" for next Debian release! (not just d-i!)

      • It is so important for marketing (Hey, new Debian release is coming!! TEST IT!!!)

        • REMEMBER, most of people don't use non-released (development branch, trunk) one! - it means that bugs would be found after release We need "alpha, beta, RC releases" tags for that.

          • If we make "alpha" "beta" "RC" version, we can get more and more testers, get response from them and can improve release version's quality!

Conclusion

• We, Debian, need more (human) resource to maintain Distribution
  • How we can get more resource?

    • To make Debian most attractive Distribution ever !

      • and we can do it - by component(modular) & time based release.

      • next - How to divide components and handle them?