Date: Thu, 3 Dec 2015 08:53:44 +0100 From: John Marino <freebsd.contact@marino.st> To: Alexey Dokuchaev <danfe@FreeBSD.org>, marino@freebsd.org Cc: Andrey Chernov <ache@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r402813 - head/misc/astrolog Message-ID: <565FF508.7030508@marino.st> In-Reply-To: <20151203034439.GB25120@FreeBSD.org> References: <201512020629.tB26TbDb060296@repo.freebsd.org> <565E9DFA.6050502@marino.st> <565EAB52.6010301@freebsd.org> <565EAD1E.8080805@marino.st> <565EB1AC.4000508@freebsd.org> <565EB3B7.8030208@marino.st> <20151203034439.GB25120@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/3/2015 4:44 AM, Alexey Dokuchaev wrote: > On Wed, Dec 02, 2015 at 10:02:47AM +0100, John Marino wrote: >> On 12/2/2015 9:54 AM, Andrey Chernov wrote: >>> 3) Contact the person who does most commits to this port. >> >> I think this is a dream. I don't expect people to sort through the >> history and try to figure out a commit pattern, plus the presence of a >> prior commit doesn't imply a willingness for a future commit. > > Again, this (that checking prior history is a dream) is our problem. > Andrey is totally right here, that's what version control for and that's > what responsible developer does. The fact that lots of us do not care > to go through the history, to an extent of neglecting to properly repo- > copy or move ports, essentially using SVN as kind of FTP, does not mean > that we're doing it correctly. > > So yeah, I'd expect people to sort through the history. If they don't, > they should learn something about collaborative software development > first. For ports committers, it must be a part on their obligatory > introductory course they receive while being mentored. (Again, IMHO we > are not doing good job mentoring people, given the quality of commits.) You're missing the most common case. The case were commit X has detected 20 broken ports and has relatively little time. In that time he can either a) fix one port to these standards and leave 19 untouched and still broken or b) mark then all broken and let others fix them as they are discovered (which is exactly what happened here). A side benefit of b) is that we get ports broken for 6 months and now we have a pool of ports that clearly aren't popular. I'm taking b) every time. You cannot do both (fix well and fix all). You got overwhelmed extremeely quickly on the MAKE_JOBS_UNSAFE fixing; they can faster than you could fix, so you should understand the deluge scenario. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?565FF508.7030508>