Date: Mon, 20 Jul 2015 16:24:02 -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: <20150720232401.GA1982@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>
 <20150720224405.7e6fa89b@ncopa-laptop>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150720224405.7e6fa89b@ncopa-laptop>
User-Agent: Mutt/1.5.23 (2014-03-12)

On Mon, Jul 20, 2015 at 10:44:05PM +0200, Natanael Copa wrote:
> 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.

Ah, I'd somewhat misunderstood the purpose, but that's probably still
the right place for it.
I assumed that non-free was more like Debian: "here's a bunch of
packages we can distribute, but you'd better check the license to make
sure you can use them."
The exact terms and conditions of the software state:
 1. Permission to build and run XEphem from this source code is granted only
 for personal use or for bona fide educational situations or research funded
 by public funds. Permission is expressly prohibited in commercial or military
 situations without prior agreement.
 ...
 4. Redistribution rights: You may redistribute XEphem source code only in its
 entirety and without modification. You may redistribute binaries only if they
 were built from the original source code, or from source code with very minor
 changes made for the purpose of porting and not for the purposes of changing
 functionality.

> > * 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".

I'd gotten that impression from reading your comments, but Nathan's comments
seemed to go the other way.
I don't see any major discrepancies between your proposal and what I
had been thinking of, though I'm not clear on exactly when or whether
packages get deleted from unmaintained.

I'd think some packages should get more leeway than others, depending
on things like whether dependencies build, how much patching they already
have, how far behind they are, and how complicated the build recipe is.
If it's a trivial recipe and it no longer builds, a short stay in 
unmaintained would be good (so those of us who occasionally glance
through there and fix up a package or two get a chance to notice it).
If it's harder to package, a longer stay would be good so that the work
already put in doesn't have to get duplicated...until the package falls
behind. Then it should probably get purged, since forwards-porting a
bunch of workarounds is usually hard.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---