Package building for -current (Was: Re: HEADS UP: Merge of binutils 2.17)

I'm happy to have a discussion about this topic either publicly, or 
privately, your choice. Since your message went to -current_at_, that's 
where my reply is headed. I've also cc'ed ports_at_ since the topic is 
relevant there too.

Meanwhile, I've snipped some of what you wrote to focus on the issues 
that I think are most relevant. I value and respect both your opinion 
and your experience in these issues, but I have some rather profound 
disagreements with your conclusions.


On 01/07/2011 21:48, Ade Lovett wrote:
>
> On Jan 07, 2011, at 17:37 , Doug Barton wrote:
>> On 01/07/2011 13:54, Ade Lovett wrote:
>>>
>>> Most likely it's low priority given all the other exp-runs that
>>> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and
>>> a bunch of other infrastructure stuff.  Not to mention the
>>> impending 7- and 8- RELEASEs.
>
> Before I start on this, I would like a few things noted for the
> record:
>
> 1.  I have set Reply-To to developers_at_ (this should be a major hint)
> 2.  I am not a current member of portmgr_at_ 3.  I requested, and
> served, for a very short time, on the first portmgr
>
>
>> That may very well be the case, but if so then it's incumbent on
>> portmgr to communicate that. If you check the audit trail you will
>> find that they did not.
>
> Horsecrap.  You are taking an individual PR history without reference
> to the whole host of things that were also going on at the same time.
> Like it or not, when it comes to ports, -STABLE wins over -CURRENT
> every single time.

I disagree rather profoundly on this point. We have a 
tolerance/expectation of our leadership just plain not communicating 
with us that has gone way past unhealthy. It takes 30 seconds to respond 
to a PR and say "We can't get to this before the pending releases, here 
is a suggested course of action." That's a perfectly reasonable thing 
for a person to expect in response to a request. In addition to not 
responding just being plain rude, it fosters the attitude of "Why should 
I bother communicating with portmgr, they never respond anyway."

Not to mention the fact that occasionally the fact that portmgr doesn't 
like to communicate can sometimes create actual problems, such as when 
they removed the MD5 checksum stuff without warning, and therefore broke 
all the ports management and other tools that depended on them. I was 
glad of the action to finish the change, but the action came after 
months of no communication about it at all.

>> IMO this is a total red herring, and has been for several years
>> now. I run -current every day on my real-work system, and barring
>> the occasional hiccup it's been buildable nearly every time I've
>> tried.
>
> Apologies for not being able to drive my email client appropriately.
> The issue at hand is one of running -CURRENT.
>
> There is a distinct, and fundamental difference between running
> -CURRENT on a single system, as opposed to a cluster of systems that
> are tightly interlinked.

Believe it or not, I understand that. I also get that sometimes running 
package building on -current stresses it in ways that cause it to break. 
That's a good thing. :)

My point is that YEARS of ignoring the problem is not acceptable, and 
needs to change. For a long time portmgr griped about not having enough 
systems for the build cluster. Now they have plenty of hardware 
available, but the problem is that the system is too pointy-hat centric. 
Apparently significant progress has been made in that area, but none of 
it seems to have trickled down to actually getting more packages built 
for more platforms better and faster.

I do, honestly, get that this is a hard problem. But if portmgr needs 
help, it needs to ask for it. It asked for and received more hardware, 
so clearly the foundation and the FreeBSD community at large is ready to 
step up to help. I think it's pretty obvious at this point that the 
gating factor is person-hours, so portmgr needs to be a lot more 
aggressive in developing new volunteers, asking for help with specific 
tasks, etc. etc. The fact that they are dealing with hard problems is no 
longer an acceptable excuse for years of failure to solve them.

> Sadly, the only thing I can say to your 4-step procedure, and with
> utmost politeness, is that your src-centric views are completely
> missing the point.  "4. start building ports" is in fact a 20- or
> 30-step process to ensure no cross-contamination.

Once again, I get that bit too. Since we do, in fact, already have a 
package building cluster I was handwaving it because I was trying to 
address your red herring about "we can't find a version of -current we 
like so we can't even try." The essential points that I'm trying to 
communicate are:

1. Most of the time HEAD works pretty well nowadays
2. Very few ports care that deeply about the guts of the system they are 
running on

> I look forward to your input and total solutions on how to make this
> better.  I do.

See above. I would love it if the foundation wanted to fund me to spend 
the amount of time it would take to actually step in and do the work, 
but I myself cannot do it alone as a volunteer. That's even if portmgr 
would accept my help which I find rather highly unlikely. My point is 
not, "I know all the answers," my point is that the solution is not 
going to come from continuing to ignore the problem; and if portmgr does 
not currently have the people-bandwidth necessary to address it then it 
ought to be reaching out to develop it.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/