- From: Terje Bless <link@pobox.com>
- Date: Sun, 20 Jul 2003 17:32:57 +0200
- To: QA Dev <public-qa-dev@w3.org>
- cc: Ville Skyttä <ville.skytta@iki.fi>, Frederic Schutz <schutz@mathgen.ch>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skyttä <ville.skytta@iki.fi> 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 >>easier). > >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 Mozilla.org-style 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. Frederic...? >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 attention. [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 -----BEGIN PGP SIGNATURE----- Version: PGP SDK 3.0.2 iQA/AwUBPxq2KKPyPrIkdfXsEQK1+ACg2sTL+iUBF8twNTrpIqqvWaN5nBoAoJzy UYpgyJk9MfjUUjPe2T3yJf/J =3mHr -----END PGP SIGNATURE-----
Received on Sunday, 20 July 2003 11:33:17 UTC