Hi,

I wonder if there is any policy about adding packages from edge (main or 
community) to a stable branch. (In Debian this would not be allowed but 
they have the backports repository which could be used for that.)

For non-binary packages (i.e. pure python stuff) it is possible to use 
package pinning to use packages from edge on a stable release. But this 
might break for binary packages due to linking against libraries etc.

Using edge package pinning feels to unstable for me to use them on 
productive systems (read: running a stable release) since the staging 
from edge to stable is missing. There seems to be a low chance of 
breaking something in stable by just adding *new* packages.


Example: Would a merge request adding the ifstate package to 3.12 
accepted (and what (commit|MR) title should I use)?


TIA,
Thomas

Hello,

the procedure for adding new packages to a stable release are:

1. Make sure the package has a maintainer (if not, someone has to adopt
it)
2. Move the package to community from testing. git mv testing/$pkgname
community/ and then git add community/$pkgname && git commit -m
"community/$pkgname: move from" should do the trick for that. Keep in
mind that all {make,}depends of the package also need to be in
community or main, packages in community can't pull in packages from
testing.
3. Make a merge request

However, new packages for community only end up in the next stable
release, so in this case it'd end up in 3.13. We want to avoid adding
new, potentially not well tested packages to new releases if posssible.
As such I'd recommend you to move things you want in a stable release,
tested and can maintain to community before the next stable release.

I hope that helps,

Rasmus Thomsen

On Sun, 2020-07-19 at 16:06 +0200, Thomas Liske wrote:
> Hi,
> 
> I wonder if there is any policy about adding packages from edge (main
> or 
> community) to a stable branch. (In Debian this would not be allowed
> but 
> they have the backports repository which could be used for that.)
> 
> For non-binary packages (i.e. pure python stuff) it is possible to
> use 
> package pinning to use packages from edge on a stable release. But
> this 
> might break for binary packages due to linking against libraries etc.
> 
> Using edge package pinning feels to unstable for me to use them on 
> productive systems (read: running a stable release) since the
> staging 
> from edge to stable is missing. There seems to be a low chance of 
> breaking something in stable by just adding *new* packages.
> 
> 
> Example: Would a merge request adding the ifstate package to 3.12 
> accepted (and what (commit|MR) title should I use)?
> 
> 
> TIA,
> Thomas

On Mon, Jul 20, 2020 at 05:11:36PM +0200, Rasmus Thomsen wrote:
> Hello,
> 
> the procedure for adding new packages to a stable release are:
> 
> 1. Make sure the package has a maintainer (if not, someone has to adopt
> it)
> 2. Move the package to community from testing. git mv testing/$pkgname
> community/ and then git add community/$pkgname && git commit -m
> "community/$pkgname: move from" should do the trick for that. Keep in
> mind that all {make,}depends of the package also need to be in
> community or main, packages in community can't pull in packages from
> testing.
> 3. Make a merge request
> 
> However, new packages for community only end up in the next stable
> release, so in this case it'd end up in 3.13. We want to avoid adding
> new, potentially not well tested packages to new releases if posssible.
> As such I'd recommend you to move things you want in a stable release,
> tested and can maintain to community before the next stable release.
> 
> I hope that helps,
> 
> Rasmus Thomsen
> 
> On Sun, 2020-07-19 at 16:06 +0200, Thomas Liske wrote:

And to add to that, we do not have a backports repo like debian does,
though, you could always build such a repo yourself with the packages
you need.

Kevin

Hi,

On 20.07.20 19:06, Kevin Daudt wrote:
>> On Sun, 2020-07-19 at 16:06 +0200, Thomas Liske wrote:
> 
> And to add to that, we do not have a backports repo like debian does,
> though, you could always build such a repo yourself with the packages
> you need.

Home-brew repository are possible in most linux distributions but this 
is a more complex process and other user (community) do not benefit from 
building them. I think it would be nice to have a backports repository 
(used with pinning) for stable releases for alpine some day.

This would allow maintainers/contributors to make edge packages/releases 
available for stable releases. The difference is that those packages are 
compiled against the libraries from stable so there is no problems like 
edge runs on musl 1.2 but stable is on 1.1. This would be similar to 
debian's bpo approach.


Regards,
Thomas