Date: Thu, 17 Jan 2019 15:18:39 -0800 From: Maxim Sobolev <sobomax@freebsd.org> To: Enji Cooper <yaneurabeya@gmail.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Packaging base system (again) [Was: svn commit: r343118 - in head/usr.sbin: . trim] Message-ID: <CAH7qZfsx7jpZMuGjtr1iqrkvhNKmPe9wgc1Ug%2BH=fS_PPMyN0g@mail.gmail.com> In-Reply-To: <EB1F82C3-B704-42C7-B6EA-ED7E49559FFC@gmail.com> References: <cem@freebsd.org> <CAG6CVpX78rHMtWTm97We50qy_D2jX79upn-9TjMy90cZeyVecQ@mail.gmail.com> <201901172046.x0HKkvWs011502@slippy.cwsent.com> <CAH7qZftZnugWaerpBdjCDapYfwmbm85r4fXQkR0eze02DkcyuQ@mail.gmail.com> <EB1F82C3-B704-42C7-B6EA-ED7E49559FFC@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 17, 2019 at 2:42 PM Enji Cooper <yaneurabeya@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZfsx7jpZMuGjtr1iqrkvhNKmPe9wgc1Ug%2BH=fS_PPMyN0g>