From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6B3DC138247 for ; Tue, 14 Jan 2014 23:23:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D43E5E09A7; Tue, 14 Jan 2014 23:22:54 +0000 (UTC) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 83241E093A for ; Tue, 14 Jan 2014 23:22:53 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id er20so839201lab.7 for ; Tue, 14 Jan 2014 15:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=mRAiJ9D2RTTKbLHUmdy62K3sYOE8DAPzhMicX7LsPJg=; b=u03wYtDO03WbEnXph29A/d2RnfDRUkWOJVqKKv9ktWjkFMFCtwZ5+rWx0ZODA/uCSP V3FiBIgv3sxQhLCa2cHqzaaXYZ0OFFTgy2pI4fzcgJzyoKdklI4mCTVD07qNa/FpvaqX DFahltGxfFnpmASjBovHv22mVNmyuoiNRY+r2lTpe1WPUVG7CfE0k2F8FIEFuSeNr1uN XuUigAzGGMeUavcXKpbJ5GJghRbwvEqT64FwcJMawi10qsBIGp5aUJ4DKYlYspHtyK6k pS2bjExVLmzo3twPD6RQGWsWFUvm8J+Hjk1dxlAyGzJRmGv3DVzHkFuLnplQQkrRwoZY l4qA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.112.164.40 with SMTP id yn8mr22682lbb.88.1389741771845; Tue, 14 Jan 2014 15:22:51 -0800 (PST) Sender: jdhore1@gmail.com Received: by 10.112.225.10 with HTTP; Tue, 14 Jan 2014 15:22:51 -0800 (PST) In-Reply-To: <20140114231113.GA3393@laptop.home> References: <20140114213719.GA2684@laptop.home> <52D5B2CA.5030407@gentoo.org> <20140114223312.GA3337@laptop.home> <52D5BDAD.4030808@gentoo.org> <20140114231113.GA3393@laptop.home> Date: Tue, 14 Jan 2014 18:22:51 -0500 X-Google-Sender-Auth: X6FmeYQCCw6reQd3vRRehUFmDjA Message-ID: Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy From: Jeff Horelick To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a11c34308a3f39b04eff67806 X-Archives-Salt: 0920815e-7e53-455d-a891-0aa6186a2c33 X-Archives-Hash: b14b34843ca369b2de12cad8956ebf8a --001a11c34308a3f39b04eff67806 Content-Type: text/plain; charset=ISO-8859-1 On 14 January 2014 18:11, William Hubbs wrote: > On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote: > > On 01/14/2014 05:33 PM, William Hubbs wrote: > > > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: > > >> On 01/14/2014 04:37 PM, William Hubbs wrote: > > >>> > > >>> 2. I would like to see the policy below applied to all arch's [2]. > > >> > > >> [ ] Yup > > >> [X] Nope > > > > > > The reverse of this would be to let maintainers stabilize on all arch's > > > after 90 days, then they are allowed to remove all but the latest > stable > > > version. This isn't good though because maintainers would be > stabilizing > > > packages on arch's where they can't test. > > > > > > The stable tree is significantly behind because the arch teams are so > > > short staffed, and this prooposal is an attempt to fix that. > > > > It's attempting to fix a headache with a bullet. The arch teams are > > lagging behind, you're annoyed, I get it. Give 'em hell. But don't break > > stable to make a point. > > > > For users, both options are worse than the status quo. > > The first option would start reverting things back to ~ and users would > have to unmask them. > > The second option would introduce new things to stable which may not be > stable due to not being tested on the arch. > > The second option is worse than the first imo, that's why I didn't > propose it first. > > The status quo is not good, because we are forced to keep old, and > potentially buggy, versions of software around longer than necessary. > > William > > I think the simplest short-term solution might be to add teams that are looking for ArchTesters to the Staffing Needs page on the wiki and promote that page like crazy. I'd be more likely to do a lot more stabilizations if it wasn't just me going on my experience and running through the AT procedures myself (they're also a bit lengthy if you follow them properly, which I prefer to). I do feel some arches should be a bit deprecated. Not quite as severely other arches the council deprecated a few months back, but something. Also, to ease the burden on Arches, it'd be nice if the maintainer would do some of the archtesting work on all their available arches rather than making the AT's/arch teams do it...For example, almost everyone who has a amd64 system, can easily make a x86 chroot (or VM) to test in. Another option (and I don't mean to step on any toes or call anyone out here, these are just examples) may be to just deprecate stabilizing certain software. Packages such as the stuff in app-vim/ or app-emacs/ or some games or some scientific software. For the editor plugins, most people do not get them from the package manager I feel and a Vim plugin requires almost as much arch testing work as a new version of grep, for example... --001a11c34308a3f39b04eff67806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 14 January 2014 18:11, William Hubbs = <williamh@gento= o.org> wrote:
On T= ue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote:
> On 01/14/2014 05:33 PM, William Hubbs wrote:
> > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote:=
> >> On 01/14/2014 04:37 PM, William Hubbs wrote:
> >>>
> >>> 2. I would like to see the policy below applied to all ar= ch's [2].
> >>
> >> [ ] Yup
> >> [X] Nope
> >
> > The reverse of this would be to let maintainers stabilize on all = arch's
> > after 90 days, then they are allowed to remove all but the latest= stable
> > version. This isn't good though because maintainers would be = stabilizing
> > packages on arch's where they can't test.
> >
> > The stable tree is significantly behind because the arch teams ar= e so
> > short staffed, and this prooposal is an attempt to fix that.
>
> It's attempting to fix a headache with a bullet. The arch teams ar= e
> lagging behind, you're annoyed, I get it. Give 'em hell. But d= on't break
> stable to make a point.
>
> For users, both options are worse than the status quo.

The first option would start reverting things back to ~ and use= rs would
have to unmask them.

The second option would introduce new things to stable which may not be
stable due to not being tested on the arch.

The second option is worse than the first imo, that's why I didn't<= br> propose it first.

The status quo is not good, because we are forced to keep old, and
potentially buggy, versions of software around longer than necessary.

William




I think the simplest short-term solution might be to add teams that are = looking for ArchTesters to the Staffing Needs page on the wiki and promote = that page like crazy. I'd be more likely to do a lot more stabilization= s if it wasn't just me going on my experience and running through the A= T procedures myself (they're also a bit lengthy if you follow them prop= erly, which I prefer to).

I do feel some arches should be a bit = deprecated. Not quite as severely other arches the council deprecated a few= months back, but something.

Also, = to ease the burden on Arches, it'd be nice if the maintainer would do s= ome of the archtesting work on all their available arches rather than makin= g the AT's/arch teams do it...For example, almost everyone who has a am= d64 system, can easily make a x86 chroot (or VM) to test in.

Another option (and I don't mean t= o step on any toes or call anyone out here, these are just examples) may be= to just deprecate stabilizing certain software. Packages such as the stuff= in app-vim/ or app-emacs/ or some games or some scientific software. For t= he editor plugins, most people do not get them from the package manager I f= eel and a Vim plugin requires almost as much arch testing work as a new ver= sion of grep, for example...
--001a11c34308a3f39b04eff67806--