Re: [meeting] notes from 2004-09-28

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

olivier Thereaux <ot@w3.org> wrote:

>Present: Bjoern, Nick, Ville, Olivier, (Jim)

My apologies for droppping out with no warning.


>[1] http://lists.w3.org/Archives/Member/w3c-archive/2004Sep/0107.html
>(member -only)

*sigh*


>* Usage of Bugzilla
>Our usage of bugzilla is rather particular, […]

Suggested improvements?

For much of WMVS, I'm the default owner simply because it used to be that, in
practice, I was responsible for it (in every role; QA, owner, etc.); but this
may no longer accurately reflect reality. Perhaps www-validator-cvs should be
the default owner and Olivier the QA Contact?

I dunno. I have no beefs with the current setup, but I'm also not married to
it; so if the rest of you would prefer or would be more efficient with a
different setup…


>Also a reminder that no issue is "obvious" enough to not be included in
>bugzilla.

[ This bears repeating! :-) ]



* A few notes from the IRC log:

><yod> news on the icons front: the badge batch (+svg versions) is now
>      under review by comm
><yod> they had some comments on the fonts, but globally I think we
>      could expect a resolution of that soon

Make sure they use fonts which can be embedded in the SVG. This lets us strip
the glyphs down to only those we need for the specific badge, and won't run us
into trouble with what fonts people have installed.


><bjoern_> regarding the icons, I dislike that the new generation
>          process would change the actual icons (flat buttons vs
>          the old 3d-style...)

If that's the case then I agree with Björn; the badges should not change as a
result of this. The exception is cleaning up the colors used as at least some
GIF/PNG badges currently use colors outside the updated W3C palette (or so I
think Jim and/or Björn discovered while working on this).


><scop> ditto.  I'm under the impression that xover has quite a big
>       uncommitted workspace

Not really. I touch a god-awfull number of lines, but a lot of it are
mechanical(ish) changes to the config files and the resulting ditto diffs on
“check”. The meat of my uncommitted changes is reasonably small (and see
below).


><bjoern_> He said he is going to postpone that if he does not get around
>          to commit that by today...

Correct. Since it's now been two weeks that I've not actually touched that
code — where I'd planned to clean it up and check it in — I'm going to ditch
it (possibly excepting the config changes, simply to make the diff smaller for
the next release merge). It's not clean enough currently to check in and I'd
judge it preferable to get 0.7.0 out sooner rather than wait for this code to
gel [/me hears the sound of Björn falling over in disbelief and shock ;D].

This also means I'll bump the five related blockers on Bug #856 to the 0.8.0
release (which Bugzilla Target I'll add at the same time). This may also
trickle over to other current blockers that depend on these five bugs.

If anyone wants to make sure a particular bug, currently blocking #856, gets
adressed for 0.7.0 then make sure you make a note to that effect on the
specific bug (possibly even changing its severity to "blocker"); otherwise
I'll unilaterally remove the blocker on my own judgement.


Also, in general, I'm going to reassign all current blockers that get bumped,
to a new “0.8.0” Milestone. If anyone — hi Björn! :-) — wants to argue that
then I'm sure all watchers would prefer we do it here, and before the
inevitable Bugzilla-spam.



><yod> I honestly have, to some extend, trouble grasping the current work
>      on m12n

The current work on M12N is (my take on it):

*  Internal refactoring and cleanup of “check” to make it easier to
   Modularize when the time comes. This is incremental/evolutionary work.
   Ville, Martin, and I are probably chiefly focussed on this.

*  Creating new modules (mostly generic ones, currently) more or less from
   scratch. This is spearheaded by Björn, Martin, and possibly Ville. I
   haven't even touched this area as yet (but planning to, as time allows).

*  Much discussion on the whys, hows, whens, and whos. :-)

   I think this is necessary, even when we all seem to be talking past
   eacheother, because to finally deliver a good product we need to develop
   a common understanding (call it “vision” if you like) of architecture
   and implementation details.

   Björn, Martin, and I seem to have been most vocal on this, but from
   Olivier and Ville's contributions it seems they too have given the
   issue some thought; which you'll hopefully (keep) sharing.

(no particular order implied)

I think that reflects that we're very early in the M12N process as yet, and
thus we seem to be moving rather slowly. But I think once certain things begin
to gel we'll speed up tremendously.

In particular, Björn's work on S::P::O has just been *blazing* along at an
amazing rate. I no longer have any particular qualms about trying to switch
from onsgmls to S::P::O for 0.8.0 or the version after (modulo any specifics
of implementation in “check” that might torpedo it); the module seems close to
complete and has a good number of tests, so stability seems unlikely to be an
issue.

If he keeps producing this quality of code at this rate we'll have a
modularized WMVS in no time! :-)


><scop> anybody know why we still have both REC-html40-971218 and
>       REC-html40-19980424?

Hysterical Raisins. The FPIs are identical IIRC => Nuke it.


><scop> regarding sgml-lib: different versions of HTML specifications
>       have different SGML declarations, but we're currently using one
>       for all.  bug?

Negative. There is one SGML Decl for HTML, it's just gotten bugfixes as new
HTML Recs have come out (that's my story and I'm sticking to it!). We keep
using a single one; you really (*really*) don't want to start futzing with the
SGML Decl depending on FPI!

Ville: If you want to drum up a proposal or fix for this then be my guest, but
I'm very very disinclined to change this.


I'd rather people spent time on going over the sgml.soc, xml.soc, and the DTDs
present and missing. This stuff is a _mess_ after I cleaned out some of the
old cruft (long overdue), but not all of it, and nuked a few things I should
have kept. We're currently missing MathML, SVG, SMIL and similar; and the
sgml-lib is not necessarily in sync with the relevant config file.

Speaking of the config file, I'll try to post a rundown of the new config
stuff some time soon.



HTH, -link


- -- 
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.3

iQA/AwUBQVpw7KPyPrIkdfXsEQL4VACg+m2+pYmoffKsQlVbkSe0oqGMGYUAn0IC
3EA4lPRN1eOVRIRUpPxnECBP
=z6Zm
-----END PGP SIGNATURE-----

Received on Wednesday, 29 September 2004 08:23:16 UTC