Fast releases demand binary updates.. (Was: Release schedule for 2006)

[Jo Rhett]

On Fri, Jan 06, 2006 at 01:16:36PM -0800, John-Mark Gurney wrote:
> You're trying to target to large of an audience...  You need to get _A_
> committer interested in your work, and get HIM to guide you and commit
> your work...
 
DING!  Now we are FINALLY understanding what my goal for this topic was.

ARE there any committers who agree that binary updates would be good, and
are willing to attempt to acquire enough consensus to get this project
started?

This topic comes up periodically, and the answer was always no.

> stop talking about core...  -core makes absolutely no technical decisions
> about how FreeBSD is..  it is the developers, and previously there was
> a technical review board for settling differences between developers
> that were pure "technical" in nature...  And if you claim you didn't
> know this, then you better read the email you respond to more closely,
> since this has been pointed out to you numerous times..

Yes yes this is known.  Again, exactly who is at the helm makes no
difference if nobody at the helm is interested in the project.  I'm not
trying to change/restructure/ANYTHING! about the FreeBSD project.  I'm
bringing up a topic that comes up periodically but gets shot down, to see
if there is any new interest in the topic.

I am deliberately trolling: not to cause grief, but to see if there are any
bites on the topic.  So far it's just people insulting my intelligence and
cut&pasting web pages to me.

Typical FreeBSD: assume the person is stupid and reply as such.
 
> hmmm...  you really are choosing to completely ignore what people have
> said about core, that at least you did add developers after core, which
> makes it appear less likely that you're talking about -core.. but lots
> of stuff gets done w/o core developers... I did lots of work on -sparc64,
 
Did your changes to -sparc require changes to the mainline freebsd
installation process?  If not, then this requires a lot less buy-in from a
lot less people.  So it's not the same.

And yes, I'm using a macro I call '-core' to refer to group of people who
can absolutely kill something like this because they don't like the food
coloring in it.  It's a convenience for me.

> As for the whole installation thing, you need to talk with re (release
> engineering) as they are the ones to really have final say in what
> installation and releases look like...
 
Yes.  But back when release engineering was interested in packaging the
base installation for exactly the reasons I've listed in other messages, a
great uproar was heard and the entire topic was killed off because 
"freebsd isn't for newbies" and "non-newbies can use make buildworld"
without any regard for all of the real issues that production facilities
face.

In short, there is some group of individuals who can kill projects.  This
group obviously changes over time, but this issue has repeatedly been
killed by some group of people I lazily call "-core"

> FreeBSD isn't commercial, so you can't talk about budgets...  And most
> orgs want some sort of prototypes and feasibility study done before
> they'll commit any budget to it...
 
Ah, yes.  But that requires conversation to happen and consensus about what
kind of results are "feasible" which means that you have to converse first,
and write code later.  You've made my point for me.

> None of this prevents you from getting a basic prototype that works,
> but isn't complete with bells and whistles..  Look at what Colin did
> with FreeBSD update, I didn't see him demanding anyone in FreeBSD to
> sign off on his work...
 
Colin created freebsd-update in spite of not having support for integrating
it.  And he certainly has commit access.

Anyway, Colin (in both freebsd-update and bsdupdates.com) is having to do 
things the very long way around because of the lack of information provided
in the core operating system.  Much as we've had to do here, but we
structured it inside the cfengine framework.

Anyway, the point is that doing it without any chance of integration means
going the VERY long way around, which won't help the core installation.
Colin could tear out a great deal of his code if the core installation
documented versions and checksums at time of installation.  Even more code
if there was a localized backout ability.

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation