X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id DEC701426318 for ; Sun, 3 Jul 2011 19:48:26 +0000 (UTC) Received: by gyf3 with SMTP id 3so2297250gyf.13 for ; Sun, 03 Jul 2011 12:48:25 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.236.115.163 with SMTP id e23mr6050474yhh.287.1309722505164; Sun, 03 Jul 2011 12:48:25 -0700 (PDT) Received: by 10.236.176.74 with HTTP; Sun, 3 Jul 2011 12:48:25 -0700 (PDT) In-Reply-To: <4E10B85F.7060206@affolter-engineering.ch> References: <1309703716-18526-1-git-send-email-fabian@affolter-engineering.ch> <4E10B85F.7060206@affolter-engineering.ch> Date: Sun, 3 Jul 2011 14:48:25 -0500 Message-ID: Subject: Re: [alpine-devel] [PATCH] Initial APKBUILD for mr From: William Pitcock To: Fabian Affolter Cc: alpine-devel@lists.alpinelinux.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, 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. =A0however, 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@, tdtrask@, and fabled@ 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 (nl.alpinelinux.org), 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 mentors.debian.org. 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. william --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---