From owner-svn-src-head@freebsd.org Thu Jan 17 23:18:52 2019 Return-Path: Delivered-To: svn-src-head@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 F1E421483553 for ; Thu, 17 Jan 2019 23:18:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 8B5A88A270 for ; Thu, 17 Jan 2019 23:18:51 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi1-f178.google.com with SMTP id j21so7564534oii.8 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=pa9fLNXKkpbhKKoRRPXHIax0cZZyWcnD+crR96hiWP4zfcSDvHG7V+mKhKYSXOXouY MvhPvpYQKkaTjzLfRLIy0IGh32HVbF3AqP733+zbwXETwTzVfpg1qnR1PoWR8Xq3bUNA lhkxjBhnpuqy0vRBHjDDqIGOFqC6hsrAO9oYuImTIx6K9MgTIlstaQRZz6hCj/o/37jR ZEBalZlvTAysc6PfIGjkOGwJ44DkDVoL4oYyR/8M9OPJbf58pS/OTuaQ0aH4MqkaaWx0 D138ePZgZq4KIX4/+q+02ojm/Pessyb5I1i1YtUNG4AXLQaTu4dwTrULYGF+p9lqW39W DaOA== X-Gm-Message-State: AJcUukcepO56yLIVswLxI+ffGZdVHjbhoJreoLVplCPx1ajRq39PPPe/ aTy0bHHqvDHwXVXJSvyUHPkRIMIpgC9fOXN93UG6J36z 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: 8B5A88A270 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-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current 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