X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id AA683DC17A6 for ; Thu, 29 Oct 2015 10:54:29 +0000 (UTC) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 7395BDC013B for ; Thu, 29 Oct 2015 10:54:29 +0000 (UTC) Received: by qgem9 with SMTP id m9so30295913qge.1 for ; Thu, 29 Oct 2015 03:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to:cc :mime-version:content-type:content-transfer-encoding:message-id; bh=TzlMC5tqlM8mAb9zyKmRlD4ES8IolVTIIdR73KKnpZs=; b=0xVHrezNac+w4TVoOVJ22GKBKwgetBo5ctbUJ3AipflizAjkKlXxN8k64NnKJVVFfv I5xyzbjfp1FqY5nPEvPuRol6gtrM8Ih64oJ3yCSZoA2yGDsgW1XSBMWS+7nDftzuGnwm A32bpkrgc5uMjr8WalEiPb4fgGaF4H8FFTQrhRRccJj2GLiyMBbNeZBMEbRiFU3vJeL1 Fv/7Ls1it/uXT52fyKQSA1KZ8tSZAHvUnMeHSVODMaR2CLw7Kwh2RHiJgwaRi/EcaZvU d4h8EM6jtoqRt1UobL+qa4p7CmK2XOb7gilu3QaOvC0Q2wbv+15RmLaVMWUctjBOFxGn BnWA== X-Received: by 10.140.146.13 with SMTP id 13mr1211146qhs.1.1446116068405; Thu, 29 Oct 2015 03:54:28 -0700 (PDT) Received: from microknoppix.localnet ([117.223.210.73]) by smtp.gmail.com with ESMTPSA id 23sm328459qhy.6.2015.10.29.03.54.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Oct 2015 03:54:27 -0700 (PDT) From: "V.Krishn" Reply-To: vkrishn4@gmail.com To: Leonardo Arena Subject: Re: [alpine-devel] v3.3 feature freeze Date: Thu, 29 Oct 2015 16:24:21 +0530 User-Agent: KMail/1.13.7 (Linux/3.9.6-64; KDE/4.8.4; x86_64; ; ) References: <20151022180104.1feeb73a@ncopa-laptop> <201510291311.01965.vkrishn4@gmail.com> <1446105556.9302.26.camel@df1844j> In-Reply-To: <1446105556.9302.26.camel@df1844j> Cc: alpine-devel@lists.alpinelinux.org X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201510291624.21420.vkrishn4@gmail.com> X-Virus-Scanned: ClamAV using ClamSMTP > On gio, 2015-10-29 at 13:11 +0530, V.Krishn wrote: > > > On lun, 2015-10-26 at 10:12 +0100, Natanael Copa wrote: > > > > On Fri, 23 Oct 2015 03:04:36 +0530 > > > > > > > > "V.Krishn" wrote: > > > > > > Hi, > > > > > > > > > > > > We now need to stop working on new features for the v3.3 release > > > > > > and concentrate on wrapping things up for v3.3 release. Testing > > > > > > and fixing bugs. > > > > > > > > > > > > A few questions: > > > > > > > > > > > > Can we make the 'lua' package be lua5.3? I think everything that > > > > > > needs 5.1 should have depends on 'lua5.1' instead of 'lua'. > > > > > > > > > > > > Can anyone help with upgrading llvm-3.7 and clang? > > > > > > > > > > > > Can anyone help with upgrade xen to 4.6? > > > > > > > > > > > > I'd like to move as much ruby stuff as possible to community, can > > > > > > someone help with that? > > > > > > > > > > > > Are there anything else that needs cleanup for v3.3? > > > > > > > > > > Any thoughts on: > > > > > 1. All desktops except one that we want to keep as default and > > > > > ready to jump on it to fix when update available or broken. > > > > > > > > You mean move to community? > > > > > > > > I'm all for moving as much as possible to community. > > > > > > > > The question was more general, what more cleanup, more than just move > > > > stuff to community, are *needed* before v3.3. Eg the critical stuff, > > > > the things we can not forget. > > > > > > > > > 2. Web application like drupal, phpmyadmin, owncloud i.e pkgs that > > > > > does not require compiling and are sometimes more easier to > > > > > install by downloading the orig tar and just uncompressing in > > > > > web-folders. > > > > > > > > What about those packages? > > > > > > I think we should move to community the packages which don't have > > > stable and maintained releases. This is not the case of ownCloud since > > > is maintained for 1,5 years after release. For example v6.0.0 was > > > released in Dec. 2013 and last update was 6.0.9 on July 2016. v7.0.0 > > > was released July 2014 it's still actively maintained. > > > > > > I think it's handy to have web applications packages for run-from-RAM > > > installations. Also upgrade of packaged web application is faster then > > > tar-based installations. > > > > > > Not sure about drupal maintenance policy, and may be phpmyadmin can be > > > likely moved. > > > > Criteria is not upstream stability release but, > > 1. Does these pkgs' normal updates get backported ? > > 2. If we decide fitting main is one CD or two do we want them in main > > then ? 3. Pkgs like these are easy to maintain and maybe > > tagged/delegated to new or less experienced maintainers. > > 4. Note, there is no stopping for main devs in maintaining community > > pkgs. > > I think to it's one of the relevant criteria. Maintaining a package in a > stable Alpine branch, when upstream does not provide maintenance > releases, puts a load on the Alpine package maintainer that needs to > backport the security patches at least, and possibly other bugfixes too. > > So I think one of the main questions to determine whether the package go > to main/community is: > > - Is the maintainer willing to ensure that package foo-1.1.0 will have > ~2years of security fixes/critical bug fixes available for version 1.1? > If yes, stay in main, if no, go to community, where you are free to bump > to version 2.x. > Or did I get the purpose of community repo wrong? Moving to community does not undermine maintainer's capability. Nor does community undermines pkgs usability. (users only needs to be a bit more aware while using those pkgs). eg. if I were to pkg a group-ware like citadel.org I would let it stay in community, even if I can or am willing to do a "2years of security fixes/critical bug fixes". Just thinking in terms of AL philosophy and things like "Small. Simple. Secure" , security-oriented, lightweight ...etc. I think presently most important is if a main dev+maintainer thinks it goes in main/, that has overriding vote. -- Regards. V.Krishn --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---