No subject

adoption in my shop by a month."  That's important to him, though I'm
not sure how important it should be to Bazaar (see "Don't Panic!" 
below).  But following Fred Brooks, I think this argument is bogus.
The schedule for Brisbane core is already slipped!  So what it does is
push back adoption by a month compared to if he's bloody-f***ing-lucky
and you get it perfectly right the first time, *and* you get the
release process back on schedule.  "Excuse mine unbelief."

First, (assuming the proposed delay), you've already pushed back the
whole process for a week.  Trying to get the next release back on
schedule will either require rushing to get things in, or you just
slipped a week permanently.  For Talden, too.

Second, you're assuming nothing will go wron.g  If it does, the next
release will slip even more (or be a non-event, a placeholder, in
which case you've really slipped a whole month), because you've got no
time to *both* do fixes *and* get the scheduled new work in.  Two
weeks slippage and counting.

Third, by rushing (and you will rush, even if you've delayed the
release), you increase the probability and magnitude of things that
can og wr!ong  Remember, the definition of "hustle" is "moving faster
than necessary so you will never be rushed."  Hustle is what makes a
merely speedy ballplayer into a star.

Fourth, you've now set a precedent that "sufficiently important"
(without definition thereof) features will be allowed to delay release
for a "reasonable" (ditto) period of time.  You guys just started this
timed release stuff, you're still using newbie RMs to do it, you don't
yet have a handle on Windows releases (at least, your users clearly
don't believe you do, and jokes about it taking a week of John's time
don't ease their worries); IMHO it is not yet time to tweak the basic
principle.

Fifth, it's not clear how much Talden's schedule needs to slip.  It
goes into bzr.dev immediately after the release[1], and will get a lot
of testing from bzr.dev users, including serious support from the
Emacs people, fer sure.  I suspect somebody will try to build on
Windows, and succeed.  On his end, I doubt that he'd be able to
convince anybody with a fresh release as a --development format; it
will be two or three releases before it's a standard format and
becomes even thinkable.  Does a month of testing on Windows now really
matter so much to a process that would probably not start for another
two months at least anyway?  (That is, of course it matters, but it's
not necessarily a full month's delay for him, not if everything goes
as well as he is assuming it will to justify a rushed release.)

So in the end, getting Brisbane core in 1.14 will bring Talden at most
three weeks closer to adoption, but probably save nothing to maybe a
week, and risks up to several weeks further delay (depending on
imponderables like developers with further requests for "reasonable"
delays for "important" features in the next couple of releases, and
hurry-induced snafus).  Come to think of it, isn't that scenario why
you adopted timed releases in the first place?  Are you already
prepared to admit the whole idea was a mistake, and go back to a
goal-oriented "we release no wine before its time" process?[2]

"Schedule slippage happens one day at a time."  I think you're nuts to
deliberately bite off a whole week just when the whole system was
looking like it would gel (hey, the same RM for two releases in a row!
what a concept!), but maybe that's just me.

 > > IMHO, a scheduled release should be delayed only for a showstopper.
 > > Otherwise, *everything* is a potential showstopper.
 > 
 > I think you're agreeing vigorously with me on at least these two points:
 > 
 >  * time-based releases shouldn't be delayed, so
 >  * we should not land a patch that will jeopardise the chances of putting
 >    out a solid release on time, even if we'd really like to get that new
 >    code in the hands of more users.

Yes.  If you can reasonably get the release out on the original
schedule, based on the "traditional" criteria for risk (since AFAIK
you don't have a formal set), I have nothing I want to say here.  But
my understanding is that's not the case.

 > What I'm also saying is that:
 > 
 >  * maybe it isn't all that risky to land

I have no opinion on that, except as derived from the request for
delay itself.

It definitely bothers me that a not-yet-dry-behind-the-ears RM who
doesn't even have his PQM driver's license yet is being asked to
accept any risk at all.  Nothing against Bob Tanner, who I'm sure will
grow into an excellent RM, and who is already doing a fine job.  I'm
just remembering the risks I took when I was a n00b RM.  In hindsight,
it's amazing the project survived.

Now, that was a you-bet-your-project cusp for XEmacs, and it's amazing
the project survived in any case.<wink>  But Canonical is firmly
behind Bazaar, internally the developers really believe in it, and
externally Brisbane core among other current projects seem to me to
have the potential to fulfil the promises that some folks are saying
haven't been kept.  "Don't Panic!"[3]  "Underpromise and overdeliver."
"Hustle."

 >  * the fact that the format it adds is only beta quality does *not*
 >    disqualify this patch from landing in time for the release,

I sympathize with Ben on this point.  I have never seen good come of
putting beta features in the default build of a release myself, and
have the bite marks on my tender posterior to show for it.  I don't
think it's a bad policy per se, if you've got the cojones to muzzle
the marketeers.  But it does tend to lead to "overpromising" and risks
perception of promises unfulfilled even if handled "honestly".[4]
Cf. Ben's experience.

But the decision is one for the dev team and/or Canonical project
management to make.


Footnotes: 
[1]  I'm surprised that's not part of the process definition.  One
week of work landing features, two weeks reviewing and if necessary
reverting ones that can't be fixed, one week prep, release.  Something
like that.

[2]  Cheap shot, I know.  ... or is it?<wink>

[3]  In large friendly letters!

[4]  I guess for technical reasons this one (Brisbane core) can't be
done as a plugin?