Mail archive

Re: [alpine-devel] [PATCH] Initial APKBUILD for mr

From: William Pitcock <>
Date: Sun, 3 Jul 2011 14:48:25 -0500


On Sun, Jul 3, 2011 at 1:43 PM, Fabian Affolter
<> wrote:
> On 07/03/2011 08:20 PM, William Pitcock wrote:
>> this has been committed.  however, since there is no maintainer field
>> set, it cannot enter main even though it works fine.
> Thanks William for your time to give me feedback about my packages.
> Are the only requirements to get packages into main that it's working,
> that there is a maintainer and that somebody did a review? If so, I
> would be happy to be the maintainer because I'm maintaining this package
> in another distribution already.

well, we should look at the lifecycle of the main alpine repository
(one of the project goals is to allow teams to create their own
repositories for specialised packaging topics) and how testing fits
into this.

first, alpine releases are branched from edge at a specific time each
year. to facilitate this, we impose a soft freeze on the edge
repositories a few weeks before we do the actual branch. this allows
us to get bugs fixed in main before we do the branch, which makes
things easier for the stable release maintainers (ncopa_at_, tdtrask@,
and fabled_at_ are the main people who touch the release trees at this
point). i guess, in a way, you can think of edge in the same way that
you would think of 'rawhide' in fedora. it is more like rawhide than
it is like 'sid' in debian for example, where the next version of the
distribution is mathematically set-derived from what is in 'sid'. so,
basically, edge is like 'rawhide', and then edge gets branched into
alpine-2.3 or whatever, just like 'rawhide' will get branched into
fedora 16 at some point.

alright, so, when edge is branched, we only take main and non-free
sections. testing is deleted in the branching process and the
buildservers which build the branched distribution never see testing
packages as we do an archive-wide rebuild when the branch occurs in
order to ensure that all of the packages are clean. there is usually
a few days of fixing APKBUILDs to handle any incomplete transitions
that happened in edge (e.g. where we missed a package in the
transition, which can happen in large ones) and then the initial
version of the distribution release is built and pushed to our
internal mirror (, which then fans out to the
mirrors in the mirror network over a day or so.

so then, this means that testing only exists in edge and is not part
of any actual release. why would we provide such a repository?

well, the reason why is because testing plays a similar role to
NetBSD's pkgsrc-wip, or it allows us to push
things that are works in progress and users can opt in to test early
builds of packages.

this brings me to how a package gets from testing to main or non-free.
 to do that, the package maintainer when she is satisfied that her
package is in a finalized state (in other words, it mostly works and
there's no showstopper bugs), then she moves it to the appropriate
place in the repository and pushes it which causes the package to be
rebuilt and included in main or non-free.

however, without a package maintainer, a package cannot enter main
because nobody has stepped up to maintain the package and make the
decision to move it into main. this has a good side effect, that
packages without maintainers (thusly packages that are not maintained)
do not enter an actually released distribution.

this also means, that in some cases, it is possible for a package
maintainer who has direct push access to place a package directly in
main. well, it is also possible for a package maintainer that does
not, if they can get someone to sign off on it.


Received on Sun Jul 03 2011 - 14:48:25 UTC