Precedence: list
MIME-Version: 1.0
In-Reply-To: <20170901193628.GB31533@alpine.my.domain>
References: <1498870383-12828-1-git-send-email-assafgordon@gmail.com>
 <20170829085033.6002c914@vostro.util.wtbts.net> <20170901193628.GB31533@alpine.my.domain>
From: William Pitcock <nenolod@dereferenced.org>
Date: Fri, 1 Sep 2017 19:10:31 -0500
Message-ID: <CA+T2pCEibyTTECMMyM96-3RWrXFctE0gun69nWXNDfaLCzHYGA@mail.gmail.com>
Subject: Re: [alpine-devel] Alpine ports layout
To: =?UTF-8?B?Q8OhZw==?= <ca6c@bitmessage.ch>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Sep 1, 2017 at 2:36 PM, C=C3=A1g <ca6c@bitmessage.ch> wrote:
> Timo Teras wrote:
>
>> New aports should start in 'testing'. We don't usually accept direct
>> contributions to 'main' or 'community'. In most cases 'community' will
>> be the right place for package, and I suspect this will be datamash's
>> place when matured. Packages in 'main' are expected to have long
>> maintained stable release branches.
>
> I think that these conditions are vague. When should a testing port
> become a community one and a community one become main?

The testing repository is really similar in spirit to pkgsrc's "wip" reposi=
tory.
Packages leave testing when a developer decides to sponsor a changeset
that moves it to community or main (usually community).
In some cases, packages move from testing to main, but moving a
package to main implies that the core team has more authority over the
package, so usually packages that are from contributors stay in
community.
Another difference between community and main is that adding packages
to main is restricted to developers, while instead, community packages
can be maintained directly by maintainers (which have only a limited
subset of commit rights and no other rights that developers get).
We hope to make this, as well as the procedures for contributing
packages as a contributor, gaining maintainer rights, and becoming a
developer, in a developer's manual shortly.

> How about splitting ports into categories, so gcc would be lang/gcc,
> vim would be editors/vim and firefox would be www/firefox? Those that
> aren't stable could land in wip, like in pkgsrc.

This type of layout is very BSD/Gentoo-like.  Alpine is not either of
these things.

A better system would be to attach metadata to packages, which would
allow us to tag them.
So, a package could have in it's metadata:

   pkgname=3D"firefox"
   scope=3D"browser toolkit:gtk3"

Or similar.  Then we could use something like "apk search
--field=3Dscope browser" to list the packages that are tagged as
browsers.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---