Re: [check] Misc. Headsup...

Hash: SHA1

Ville Skyttä <> wrote:

>On Mon, 2003-07-14 at 02:36, Terje Bless wrote:
>>2. I am winding up towards checking in several moderately
>>disruptive/significant changes. They are unlikely to break anything in
>>any major way, but they have plenty potential for smaller breakage.
>>IOW, if you want a stable base to work from, now is the time to get a
>>CVS snapshot (I may create a CVS tag prior to checkins to make this
>What branch do you plan to work in?  Methinks it's about time to get
>HEAD rolling again after The Next Release is out, and use the
>0_6_0-branch only for critical bugfixes...

Well, as mentioned, for various bonehead reasons I can't do this cleanly. HEAD
is borken and will take ages to get into releaseable state. IOW, anything
released soon(ish) will have to come off the validator-0_6_0-branch. But since
we've allready added stuff that is inappropriate for a minor revision (doctype
fallbacks etc.), we do need to bump the version number a bit more.

How about this...

We leave 0.6.1 as the last 0.6.x release for now, and then branch off to
validator-0_7-branch from the validator-0_6_0-branch (instead of branching
from HEAD) and make a 0.7.0 release from there.

validator-0_7-branch then becomes the stable/critical-bugfix-only branch (with
checkin dicipline in effect[0]) and immediately transition to adding new stuff
on HEAD. If HEAD is too borken to easily add a given random minor
feature/change, then that is just a great incentive to _un_break HEAD.

If nobody hollers I'll proceede after that plan (probably beginning tonight).

Oh, and "checkin dicipline"; how about summat like:

  1. Any checkin needs to reference a Bugzilla Bug #.
  2. Any checkin needs to be applied also to HEAD.

(excepting trivial/typo-style stuff onbviously)

Mainly just to remind folks[0] to put stuff where it belongs (i.e. I don't
really want to end up with a real burocracy with Drivers,
Review, and Super-Review etc.).

>>Especially Ville and Frederic; if you want to make sure you have
>>something suitable for release coinciding with a Debian/RedHat
>>milestone (or whatever), y'all need to let me know about it or I'll
>>just keep winding my way as whim takes me on this front. (I bring this
>>up since the last beta took you guys by surprise)
>Thanks.  By the way, is Frederic subscribed to public-qa-dev?

He was, but he may have unsubscribed, been bounced, or not currently have time
to follow the list. This message CCed in the hopes of getting current status.

>Some status on the RPMs: I've updated the specfile in 0_6_0-branch so
>that apart from the version numbers, it should be ready to roll.
>Specifically, the Version:, Release: (reset to 1w3c if the next version
>is > 0.6.2), Source0: and Source1: tags should be updated to match the
>version number.  And a %changelog entry would be nice :)

I assume this is changelog for the _RPM_ and not in general?

>OpenSP 1.5 continues to be a slight PITA on Red Hat.  I won't go into
>details; just a note that their Rawhide (WIP area) contains
>openjade-1.3.2 which includes OpenSP 1.5.  OpenSP 1.5 is not available
>for RH 9 (current release) and earlier versions from RH.

I've asked them to split the packages but twaugh seems disinclined to do so
for whatever reason (it took the -R security issue to get them to upgrade it
at all). I think we need to get upstream to forcibly split the packages before
Red Hat will follow suit. Note that a new OpenSP release (1.5.1) appears to be
in the offing, so that may happen eventually).

>In general, I think that RH release dates should not affect validator's
>release dates at all.

Well, we're not jumping through hoops for them, but if we can teak scheduling
slightly in order to take advantage of new release attention I think that
would be advantageous. e.g. to announce Red Hat 9.1 packages immediately after
they start sending press releases ought to get us a little bit of free

[0] - To keep _me_ from getting lazy/careless; everyone else has been
      exemplary in this regard. :-)

- -- 
I'm [less] than thrilled by the [VM situation]; all sides of it. I [think]
we need a [fork] in that area so that you guys would stop stepping on each
others' toes.  I'm taking no part in your merry 5-way clusterfuck  -- sort
that mess out between yourselves.                -- Alexander Viro on lkml

Version: PGP SDK 3.0.2


Received on Sunday, 20 July 2003 11:33:17 UTC