Date: Mon, 20 Jul 2015 22:44:05 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Isaac Dunham <ibid.ag@gmail.com>
Cc: Nathan Angelacos <nangel@alpinelinux.org>,
 alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] reorganize the repositories
Message-ID: <20150720224405.7e6fa89b@ncopa-laptop>
In-Reply-To: <20150720183146.GA1873@newbook>
References: <20150717165916.5f26f656@ncopa-desktop.alpinelinux.org>
	<CAFaTuVZZQ5U+4G-WfG2Awu3FnGh90hfkusvfBMNHiTcgvRnHew@mail.gmail.com>
	<20150718112059.4a5d518f@wallander.lan>
	<55AC44D0.60002@alpinelinux.org>
	<20150720112642.2249096f@ncopa-desktop.alpinelinux.org>
	<20150720183146.GA1873@newbook>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 20 Jul 2015 11:31:47 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Mon, Jul 20, 2015 at 11:26:42AM +0200, Natanael Copa wrote:
> > 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:
> > > >> 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.
> > > 
> > > Agreed on the rot thing.  I actually prefer the "unmaintained" 
> > > 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 
> > > and simple" and that calls into question secure.  But hey - if all of 
> > > those packages are actually the latest upstream.  Cool.
> > > 
> > > I also like staging - because it means "its about to go somewhere else"  
> > > I'd see staging for edge only - stuff that is up for acceptance.
> > > 
> > > Community to me says "this is stuff that main developers don't maintain, 
> > > so we don't sign off on it, but someone cares enough to keep it updated, 
> > > at least every other release or so."
> > > 
> > > I wonder it we create a 4th repo "abandoned" or "unowned"  - That would 
> > > give everyone a clear indication of packages that need an owner.  
> > > Someone new comes along and says "how can I help?"  we point them to 
> > > "unowned" and say "take ownership" - they do? it goes to "community." 
> > > They prove it works, it goes to "staging."   They lose interest in the 
> > > 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.
> 
> Overall, the "four branches" proposal does sound good, but there are some
> points where I'm not sure it makes sense or would like clarification.
> 
> * Currently, the aports tree has four subdirectories:
>  main
>  non-free
>  testing
>  unmaintained
> I assume that the proposal is not deleting non-free, but merely ignoring
> it because it's not in the main flow of packages.
> (By the way...I've been thinking that I'd like to package "xephem", but
> it needs to go in non-free, and I'm not sure where it should start.)

Yes non-free would stay as is. Here we put stuff that we are not
allowed to provide binaries for, but still want make it easy for people
to build a package themselves if they want.

> * If I'm reading the latest proposal right, the package flow would be:
> new or fresh from unmaintained -> community
> main developers adopt: community -> staging
> becomes stable: staging -> main

sorry for being unclear. What I propose is that the flow is:

new package -> staging.

Depending on who ends up maintaining it and for how long, it goes from
staging to either "community" or "main".

That is, if there is a package that i do use and don't mind maintain
(for example qemu/libvirt/virt-manager), but I don't can (or want)
provide security fixes for 2 years, then I would add myself as
maintainer and place it in "community".

> Further, the proposal is to have "community" and "main" as the only ones
> that are part of a release.

Currently we have only "main" as a part of a release. The proposal is
that we do both "main" and "community"

> I don't think this makes sense, given the flow:
>  - A newly fixed or repaired package should probably spend *at least* one
>    revision in a repository where it's available for testing but not part
>    of the release, regardless whether the core maintainers adopted it.
>    In other words, it's good to have something before community.

What I had in mind was that "staging" could be entry point for all new
packages. That way we could bring in a new package into the system, and
test it a bit before deciding what kind of support we want give it.

>  - Why would a core maintainer adopting a "community" package result in it
>    moving out of a released repository before it moves to main?

If a core maintainer is prepared to support it for 2 years then it is
qualified for "main". A core developer might want maintain the package
but as more a best-effort, then it would still be in "community". You
cannot expect security fixes in more than latest stable branch.

> In short, I'm thinking that switching the order of community and staging
> seems better:
> -Any package that someone makes build goes in "staging", regardless who
> the packager is; so do proposed major updates.

I don't mind pushing major updates directly to edge/main if the plan is
to include this in next major release.

The problem with always pushing new major releases of a package to
"staging" first is that an ABI breakage might require rebuild of *many*
packages. I would prefer not copy all the packages that needs rebuild
to staging, build them there and then copy them back to main (or
"community").

I do see the value of it, but I think it costs more work. What I am
trying to do is reduce amount of work.

We have the recent example with udev -> eudev. I did push it to testing
first (proposed to be renamed to "staging") but I did not copy all the
50+ packages that needed rebuild. Doing so would have prevented
breakages for edge users (unless you had edge/testing in your repo
ofcourse). They could been there for a a week or two while sorting out
the issues before moving it to main.

But that would also meant that none of the updates, minor or major of
any of those 50 packages would go to main til all eudev issues was
resolved or I would have to update same package twice. That is what I
wanted avoid.

> -When someone can confirm that the package as built works, it goes into
> community. (We might have a maintainer requirement.)
> -When a core developer is happy with the packaging and how it works, and
> is willing to handle support, it can go into main.

when someone confirm it works it could got to either main or community,
depending on who wants be maintainer and depending on what kind of
support the maintainer is prepared to provide for it.

I don't think there is any point that a package with good support needs
to go via community before going to main.

> -If a package outside main ceases to build, it drops to "unmaintained";
> if a package in main ceases to build, the maintainer may move it to
> unmaintained if they don't wish to deal with fixing it; if a maintainer
> announces intent to orphan a package, it will be moved to unmaintained
> if it isn't adopted before the next release.

The idea was, if a maintainer is no longer interested in maintaining a
package it would go to "unmaintained" as an orphaned package.

I do like the idea of purging those when preparing next release. We
should probably clean the "unmaintained" directory before starting the
builders for a new release because when building a release is a time
when you typically discover that a package no longer builds - and a
time when maintainers are already super busy.

> For what it's worth, "contrib" would be more traditional than
> "community".

Might be. But I think core developers might want be interested in
maintaining some of those packages. At least I am.

What i think is:
main = longer term support, 2 years.
community (or contrib) = only latest stable is supported. older than
that are best-effort only.


> > > Probably we should have some criteria for pushing things from community 
> > > to unowned.  For example: "Upstream source is updated more than 6 months 
> > > ago... move from community to unowned"
> 
> That's a bit naive.
> I use a window manager that last saw a release a little under 5 years ago,
> but it's still quite functional.
> 
> I'd say it's necessary to add some qualification such as 
> "homepage or download gone" or "no longer builds".

I agree. I would not mind maintaining a package "main" that has not got
any new release in 5+ years. Specially if upstream still provide
security fixes in a git branch, even if they don't do new releases.

> (By the way...the sourceforge-hosted packages may be unbuildable for a while.)
> 
> Thanks,
> Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---