Skip site navigation (1)Skip section navigation (2)
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>