Time to plan for 1.0

[Eric S. Raymond]

Ian Bruene <ianbruene at gmail.com>:
> On 08/08/2017 09:01 AM, Eric S. Raymond wrote:
> >Strictly speaking you can't do that.  It's the PM's decision whether
> >we want to drop the feature or change the schedule.  We're pretty informal
> >here, but you need to know where those lines of authority are, because
> >many other projects (especially in corporate-land) aren't.
> 
> Ah, I misunderstood the structure. Also forgot that there is something
> called a PM and it exists for a reason....

We're a bit unusual that way, a hybrid of normal open-source practice with
the way things are done in corporate shops.  Most open-source projects don't
have a PM, because they don't have funding that needs PM-style oversight.

The role may be partly filled by a senior dev with the defined role of
"release manager" (Battle for Wesnoth, for example, does it that way),
but under those circumstances it is in fact more likely that a
subsystem or feature owner would get to make the call about what
release first code ships in.

(In this context you are the subsystem owner of the Python tools. I dropped
that on you because you seemed ready for it.)

> I am Officially Suggesting that SNMP support be allowed to slip 1.0 unless I
> can make major progress in the next couple weeks.

Thank you, that is correct procedure.  Acting in Mark's absence I
concur; we'll slip it if you don't have it done.  Mark has the
privilege to override this decision but I will be quite surprised if
he does.

> NTPc having broken SNMP support was a major factor in my willingness to slip
> for rightness, I wasn't aware that it was so bad the maintainer urged you to
> remove it.

Yes.  The Classic code was a prototype written before RFC 5907
("Definitions of Managed Objects for Network Time Protocol Version 4")
and nobody ever got around to syncing the behavior to the RFC after it
issued.

Frankly, it should have been deleted from the Classic tree long before
I nuked it from ours, but they for whatever reasons never removed old
cruft.

> >I think our support can wait for 1.1.  Possibly Mark might do an
> >override on this, but I doubt it.
> 
> Is there any idea on how long that would be after 1.0? I'm not saying
> anything about "plenty of time", already eating my "plenty of time till 1.0"
> statement.

Mmmm...I think 90 to 120 days would be a reasonable guess.

In any case, my direction to you is "all deliberate speed". I get that
you like to work hard and respect that, but I don't want you knocking
yourself out for a feature that's not urgent, especially when ICEI
might want to second you for work on Hathi or Fabricode that really do
have deadlines.

Unless something in the external conditions of the project changes
(like, say, a wealthy donor with an urgent desire for SNMP support)
the main near-term value of this particular feature is staff
development - that is, improving your skills. That's why I don't
mind the yak shaving.  The yak shaving is almost the point here.

It's not quite the same case as the Python client tools, where having
them by damn *work* is more important than using them to advance
your training.  Thus, I would step in to fix things if you weren't
up to it. You haven't made that necessary.

Your priorities should be, in this order, (1) Any NTPsec tracker
issues you can close, (2) Any deadline-sensitive work you are seconded
to on other projects, (3) AgentX. Just tell us when it's done.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.