Date: Mon, 20 Jul 2015 11:31:47 -0700
From: Isaac Dunham <ibid.ag@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: Nathan Angelacos <nangel@alpinelinux.org>,
	alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] reorganize the repositories
Message-ID: <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>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150720112642.2249096f@ncopa-desktop.alpinelinux.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

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.)

* 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

Further, the proposal is to have "community" and "main" as the only ones
that are part of a release.
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.
 - Why would a core maintainer adopting a "community" package result in it
   moving out of a released repository before it moves to main?

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.
-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.
-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.

For what it's worth, "contrib" would be more traditional than
"community".

> > 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".

(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
---