Date: Mon, 20 Jul 2015 11:26:42 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Nathan Angelacos <nangel@alpinelinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] reorganize the repositories
Message-ID: <20150720112642.2249096f@ncopa-desktop.alpinelinux.org>
In-Reply-To: <55AC44D0.60002@alpinelinux.org>
References: <20150717165916.5f26f656@ncopa-desktop.alpinelinux.org>
	<CAFaTuVZZQ5U+4G-WfG2Awu3FnGh90hfkusvfBMNHiTcgvRnHew@mail.gmail.com>
	<20150718112059.4a5d518f@wallander.lan>
	<55AC44D0.60002@alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, 19 Jul 2015 20:46:08 -0400
Nathan Angelacos <nangel@alpinelinux.org> wrote:

> On 07/18/2015 05:20 AM, Bart*omiej Piotrowski wrote:
> >
> >> It might be great! But i think we'll need to keep track of packages
> >> purged just in case someone requests a package that were in staging
> >> for a period and was purged
> > Everything resides in git history. No need to worry about it.
>=20
> Yeah, but someone asks for ZorkmidMiner2000, checking git history=20
> wouldn't be the first place I'd look to see if we have an old APKBUILD. =
=20
> See below.
> I'm not disagreeing, just saying that its not the first thing I would=20
> think of.
> >
> >> About the 'staging' repo: I like this name but I also like NetBSD's
> >> idea of *wip* (stands for *w*ork *i*n *p*rogress). Maybe staging
> >> could be called *wip* repository.
> > It is not exactly "wip". I just felt that testing is wrong name,
> > given how many packages rot there for releases. Staging gives clear
> > indication that we want to know if package works good enough to move it
> > to "stable" repositories.
>=20
> Agreed on the rot thing.  I actually prefer the "unmaintained"=20
> repository we had for a while.

I don't have strong opinions regarding "unmaintained" repo. One
argument for removing it would be that we keep the tree cleaner by
remving non-functional stuff.

> As Natanael mentions, "Main" is BIG - it doesn't exactly scream "small=20
> and simple" and that calls into question secure.  But hey - if all of=20
> those packages are actually the latest upstream.  Cool.
>=20
> I also like staging - because it means "its about to go somewhere else" =
=20
> I'd see staging for edge only - stuff that is up for acceptance.
>=20
> Community to me says "this is stuff that main developers don't maintain,=
=20
> so we don't sign off on it, but someone cares enough to keep it updated,=
=20
> at least every other release or so."
>=20
> I wonder it we create a 4th repo "abandoned" or "unowned"  - That would=20
> give everyone a clear indication of packages that need an owner. =20
> Someone new comes along and says "how can I help?"  we point them to=20
> "unowned" and say "take ownership" - they do? it goes to "community."=20
> They prove it works, it goes to "staging."   They lose interest in the=20
> project? Back to "unowned"

I kinda like this idea. "unmaintained" or "unowned" could serve as a
final stage before things gets purged. Then we purge stuff things that
has been there for a certain amount of time.

> Probably we should have some criteria for pushing things from community=20
> to unowned.  For example: "Upstream source is updated more than 6 months=
=20
> ago... move from community to unowned"
>=20
> So as a user, setting my repositories would be:
>=20
> main - if it doesn't work, I can file a bug report and it will get fixed

And you can expect getting security fixes for those packages for 2 years.

> staging - same, but there is a stronger possibility it won't work

And there will be no packages in "staging" repo in the stable branches,
simply because we don't ship things to stable that is not ready.

> community - if it doesn't work, I'll almost definitely have to 1) send=20
> the patch, or 2) become the maintainer

I think you should be able to file a bug and expect it be fixed, even
if it is in community. However, you might not be able to do so for
anything else but edge and latest stable.

The community repo will be available from stable branches too, however,
you may or may not get security fixes.

> unowned - here be dragons.  I will almost definitely step up and become=20
> the maintainer.

And the build servers will not even try build those, so you will have
to build it yourself.

The unmaintained has been a place we push things that gets in the way
for us. Things that does not build, and nobody take the time to fix.
=20
> ----
>=20
> Of course, I could have read Natanael's proposal all wrong, and he's=20
> thinking of moving stuff like=20
> abiword/asterisk/claws-mail/firefox/kamailio/xfce out of "main" and
> into "community." Then Alpine goes back to its "roots" of being a
> headless network appliance.

No, I think you got it right. The examples you mention:

abiword, asterisk, claws-mail kamailio and xfce are good candidates for
"main". They are slow moving projects. They provide fixes for older
stable and they don't give us headache to fix security bugs in older
maintained stable branches.

Firefox on the other hand is an interesting case. They do provide long
term support with the ESR variant, thus, firefox ESR may be a candidate
for "main".

However the normal firefox releases often pull in new libs as
dependencies, or often require newer non-ABI compatible versions of
dependency libs. Maintaining those for long time is a problem, thus, it
belongs to "community".

Other example for typical "community" packages is qemu. They often
don't provide backports of fixes for their older qemu versions and
sometimes I have not been able to provide security fixes for qemu for
older stable branches.

All those packages where upstream say "just use latest git" instead of
providing proper releases are not suitable for "main" and belongs in
"community".

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---