Date: Tue, 07 Apr 2015 17:04:27 +0200 From: John Marino <freebsd.contact@marino.st> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Sunpoet Po-Chuan Hsieh <sunpoet@FreeBSD.org>, svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, Adam Weinberger <adamw@adamw.org> Subject: Re: svn commit: r383472 - head/audio/muse Message-ID: <5523F1FB.6040508@marino.st> In-Reply-To: <20150407085803.GA82210@FreeBSD.org> References: <201504061859.t36IxK0v000969@svn.freebsd.org> <20150407012902.GA22994@FreeBSD.org> <91AB85D3-A8DE-491C-A2D7-4E8D7E1CDC12@adamw.org> <20150407023204.GA44784@FreeBSD.org> <552376AD.7010903@marino.st> <20150407070711.GA90710@FreeBSD.org> <552386FA.7030007@marino.st> <20150407075154.GA58322@FreeBSD.org> <55238F29.1010404@marino.st> <20150407085803.GA82210@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/7/2015 10:58, Alexey Dokuchaev wrote: > On Tue, Apr 07, 2015 at 10:02:49AM +0200, John Marino wrote: >> "maintained by community" means "maintained by nobody" and you only have >> to look at pkgsrc to see how successful this approach is. > > Interesting. Given your DragonFly experience, can you elaborate a bit on > the situation with pkgsrc, which I think was used as primary collection for > third-party software, yet later had switched (back?) to dports? Or point > me to some article or blog entry (WRT "how successful this approach is"). Well, I don't really want to go into all bits that went into the decision of officially switching to dports (it started as an experiment with no particular goal that was so successful that dillon made the switch unilaterally and unexpectedly), but the comment above was aimed at their philosophy for unmaintained ports. Basically the equivalent is "pkgsrc-users@netbsd.org" and unlike ports, new ports can be created without a maintainer. If fact, this is quite common. I haven't done analysis on maintained vs unmaintained numbers, but it always felt like 30/70 (30% maintained). Anyway, the "pkgsrc-users@" maintainer means "community maintained", not "unmaintained. These ports are typically never updated to a newer versions, only getting touched when an infrastructure change breaks them (or an automated revbump). Typically they are several releases behind upstream. The problem is partly compounded by purging practice. pkgsrc purges like 12 ports a year. Bapt will do that before breakfast. :) Anyway, "community" ports are neither upgraded nor purged, so there is a huge percentage of out-of-date ports. The other issue is this "obligation" for community ports. I didn't sign up for those, any the ports with my name on it and a select few others. The idea that a committer is expected to also care for those (often trashy) ports as an obligation is not pleasant. My subjective take is that the concept of "community" port is nice but doesn't work in practice. You can have 100 committers and all assume that somebody else will do it and nobody does. Have "ports@freebsd.org" ports being considered endangered is a strength for the Ports collection. If people really care, they'll pick up it. > >> I'll continue work under the concept "ports@FreeBSD.org" ports are >> unloved and fair game. I don't think I'm alone. > > Another solution is team-maintainership; I still do not quite understand > why it did not work out with games@ (several months ago, all games@ ports > were reset to ports@). There was some discussion AFAIR, but I didn't find > it convincing (nor can remember it now). In the specific case of games@, it had effectively dropped to a one-person team, yet that person carried the obligation of performing full maintainership responsibilities on all the ports that team had claimed. In reality the games@ team only wanted a heads-up on new PRs or the right to clean up the ports without having full maintainer obligations, so bugzilla was enhanced by mva to ping the games@ team as CC: whenever a games PR came in, but with no further obligation. In reality, it's just moved towards the original concept. Many teams are also disfunctional, but some are still working. I'm very wary of teams and I think they should be on a rather short lease with period review to ensure they are still operational. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5523F1FB.6040508>