1

Topic: Hyperbola packaging and releases

Hi, I have read the packaging guidelines but still have a few questions.

- What is the planned duration of Hyperbola's release cycle (e.g. two years like Debian)?

- What exactly is the process for a new stable release? Is there a beta release? Does testing have a freeze period like Debian's?

- How does Hyperbola testing differ in content from Parabola?

- In a situation where a free Arch package has no target in Hyperbola stable because it was first included in Arch after the snapshot date, is this a valid reason to request that the package be backported?

- When an Arch package must be modified to address freedom/privacy/branding issues, how is this does done? Is there any documentation on this to help contributors get started?

Thanks.

2

Re: Hyperbola packaging and releases

chaosmonk wrote:

- What is the planned duration of Hyperbola's release cycle (e.g. two years like Debian)?

- What exactly is the process for a new stable release? Is there a beta release? Does testing have a freeze period like Debian's?

Please see the article about our releases for further details.

chaosmonk wrote:

- How does Hyperbola testing differ in content from Parabola?

Hyperbola isn't a distribution based on Parabola. White Hole (AKA testing) is our development environment for the next version of our current release (currently Milky Way) or the next release (if it was announced from our main site, mailing lists and forums). See our roadmap development for further details.

chaosmonk wrote:

- In a situation where a free Arch package has no target in Hyperbola stable because it was first included in Arch after the snapshot date, is this a valid reason to request that the package be backported?

Yes of course, you can fill a request about that package in our HyperTask. Anyway we need adapt it following our packaging guidelines.

chaosmonk wrote:

- When an Arch package must be modified to address freedom/privacy/branding issues, how is this does done? Is there any documentation on this to help contributors get started?

In this case, a dev must check entire source code and fix those issues. You can see our PKGBUILDs and patches from our git repositories [0][1[2][3] as example to see how it's done by us.

chaosmonk wrote:

Thanks.

You're welcome, if you have any question, please don't hesitate to send through our forums. smile