From owner-svn-src-all@freebsd.org Thu Jan 17 23:18:52 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE2A01483552 for ; Thu, 17 Jan 2019 23:18:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A59F8A26E for ; Thu, 17 Jan 2019 23:18:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi1-f180.google.com with SMTP id i6so7586914oia.6 for ; Thu, 17 Jan 2019 15:18:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HALbC2X3d6Vh62ZWNRm+ai/mxF5pQFs2pByi+RlNRzw=; b=g+ah3WAT9dJr8YOdOnHfBo/UrFT/1hRndidLCcLaaCKcIGZgz/v8u4FenzIDOwHUEH F52djfafGkVl2fXQ6R7rij3EYQzm0JVypmOoM5wpu2G8N9zj7u/LL1lR9ugOxRXyRLZ5 A+Bs/EuOyNyLA5AN+X6eWIHeeI3zKnPvbsuTXHxqnWCRhI2KOPd0UK52FSOjUQHZcxub mMnMfc+Ii6LtFJi9nA8+tW56iR/z0GVT6DWMg2VkZtDHS+cQXqgV7oMIBYVLTMr257H7 yfUbKVNuJJq7oyLUIKyVyl8CiKAiaVx7KTjpRcWn7xr6CBMmYd7u9oDvOSKfThGb6fHd UBEQ== X-Gm-Message-State: AJcUukevyaWgjlGmsTeHU1PZv/kVIy1E3gCRx4y+vbAKp2h0fqb4z1rA Mv+GJEXgQ+nhhFMvAuBdvcqPCzkBHiFtZl6zaHEW1g== X-Google-Smtp-Source: ALg8bN7SIF70e3ZzTiGwy3FtwmD6iFowOqS1ihQE7SuKxfDZRBzQsE6JA7L1FBtLO6kQyHS72NnId+MfRxgM5V+5wOw= X-Received: by 2002:aca:c003:: with SMTP id q3mr8343031oif.119.1547767129870; Thu, 17 Jan 2019 15:18:49 -0800 (PST) MIME-Version: 1.0 References: <201901172046.x0HKkvWs011502@slippy.cwsent.com> In-Reply-To: From: Maxim Sobolev Date: Thu, 17 Jan 2019 15:18:39 -0800 Message-ID: Subject: Packaging base system (again) [Was: svn commit: r343118 - in head/usr.sbin: . trim] To: Enji Cooper Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: 8A59F8A26E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.967,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 23:18:52 -0000 On Thu, Jan 17, 2019 at 2:42 PM Enji Cooper wrote: > > Perhaps even by forking the whole ports idea into a smaller > closely-guarged subset. Something like a new baseports repository, which > might have structure like baseports/usr.bin/xxx, baseports/usr.sbin/yyy > etc. Then add some automagic glue to kick in on every commit and transfer > this into valid ports, which is going to be packaged by the poudriere and > such. This way we could reduce amount of port-foo average src committer > needs in order to maintain code. I am almost tempted to sit and write > something over the next weekend or few of thereofs. Using usr.sbin/trim as > an example. > > Please see my above comment. > Well, I don't think your comment really addresses my concerns here. Correct me if I am wrong, but you seem suggesting that every src developer would also need some external account (github in this example) to maintain his or her chunk of code independently of everyone else's. This is pretty much a no-go from starters. There are also many more major issues with such approach, such as completely different branching model for src and ports as an example. ports is a good framework in general, for maintaining software produced by external entities. I don't feel it's very appropriate for maintaining software produced by the Project itself, though, due to complexity inherited with that. We need something simpler and more self-consistent, at the same time I see no reasons why it could not utilize some if not all tooling with we build around ports/Mk over the years. IMHO. -Max