Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

On Friday, July 13, 2012 11:36:11 am Doug Barton wrote:
> Also, please keep in mind that I was criticized for *not* speaking up
> about the OPTIONS changes, now I'm being criticized *for* speaking up
> prior to pkg going live. In spite of the fact that I'm doing my best to
> (repeatedly) be clear that I'm not against the project, I just want to
> know more about it.

To clarify, you are not being criticized for speaking up, you are being
criticized for the way in which you are speaking up (an accusatory tone) and
for blowing off a pointer to a talk that would perhaps answer some of your
questions.

> > Also, when other 
> > people have taken time to explain an large decision because you are too lazy 
> > to invest the time doesn't really help your case).
> 
> Um, I'm too lazy? I've read everything that's been written on pkg to
> date. Have you? 90% of it is "how to" type stuff that doesn't address
> what we need. The other 10% is so vague and general as to be useless as
> a project plan.

Hmm, that is not my distinct impression.  However, I do have the advantage of
having been part of several in-person meetings and discussions (for example,
the ports working group at the developer summit for BSDCan where a lot of
discussion and planning took place about the future of packages).

> You're an experienced project manager John. If someone who worked for
> you came to you with a plan this vague ("modern" foo, "decent" bar), for
> a critical system, how would you respond? (And yes, I realize that no
> one around here works for me, that isn't my point at all.)

My understanding of this plan is far less vague.  In practice, pkgng hasn't
really been happening under a rock.  There have been multiple announcements
and calls for testing and I know that many folks are testing it and working
with it.  Large projects such as this can be a bit bumpy in FreeBSD land, and
I expect that there will be things that crop up that have to be fixed as a
result of wider testing.  (For example, I agree with you that the nvidia driver
packages have to work correctly as that is a non-starter for me as well).
However, I am confident that pkgng and the new packages model is aiming at the
right target based on my own interactions with Erwin, Baptiste, and others,
and I think we need to push this forward and gain wider testing to make
progress, even if there are bumps in the road.

> > In terms of the first feature (binary upgrades), the truth is that if you have 
> > more than 5 machines to manage, our current pkg tools completely suck.  There 
> > is no automated upgrade mechanism.  If you want one you have to write your own 
> > set of infrastructure to do the right collection of pkg_delete/pkg_adds.  
> > Certainly there is no support in the current package tools for doing batch 
> > upgrades (i.e. upgrading from one completely package set to another).  pkgng 
> > adds that feature, and I find it a must for supporting large installations of 
> > machines that need automated management.
> 
> And as I wrote previously, I've been there and done that, so yes, I'm
> interested in the feature. But I'd like to know more about the plans for
> it so that those of us who *do* have experience in this topic can share
> that, and we can avoid having to reinvent the wheel. Or worse, putting
> out something half-assed that uses up a lot of developer cycles and
> doesn't get the job done.

Well, what I can tell you is that many of us who do have experience with that
model have been discussing this in various fora, initially in e-mails, IRC
discussions, informal discussions during the "hallway track" at conferences,
etc.  To build a broader consensus, portmgr_at_ has been holding larger, more
formal discussions in the form of devsummit working groups, presentations at
conferences, etc.  I personally have been petitioning anyone's ear I could
bend for package sets for example.

I realize, btw, that not all of those discussions have occurred on public
mailing lists.  The fact is, there is a tradeoff between informal
communication (such as in-person commucation) and mails to a mailing list.
In-person communication especially offers far higher bandwidth and can be far
more effective for reaching consensus and working through alternatives, but
it has a more limited audience.  Being a volunteer project distributed all
over the globe, we are somewhat stuck with that tradeoff.  We attempt to
mitigate that tradeoff somewhat by making more of these informal discussions
more formal (e.g. adding working groups at the devsummit which include wiki
pages with summaries of the agenda and slide decks used to present the wg
summary to the full complement of attendees so there is at least some
information availble for folks who were not able to attend).  However, it
does mean that just because you were not personally involved in a discussion
or did not see a long and tedious thread, you should not assume that no
discussion has taken place at all.

Back to my original e-mail: FreeBSD is a big project.  I try to keep a pulse
on as much of it as I can (mostly by reading/skimming a _lot_ of e-mail each
day), but even with all that there is a lot going on that I don't know the
intimate details of.  Instead, I choose to trust my fellow developers to
best manage the areas over which they have expertise and detailed knowledge
until given strong evidence to assume otherwise.  My humble suggestion to you
would be to adopt a similar strategy.

-- 
John Baldwin