Steve Langasek wrote: > > The question is, how can we be proactive about identifying the classes of > changes that do or don't break these packages, so that mozilla can be > checked for compatibility at the time of upload instead of having kazehakase > and enigmail update their conflicts: after the fact? >
I suggest to list all indicators we are currently aware of, in order to get a good list on what needs to be checked before assuming compatibility of a mozilla patch. For now, I can see three classes of mozilla dependents: + extensions + locale packages + gecko dependents Reasons that might break extensions include: + changes to XPCOM interfaces (e.g. .idl) + changes to XUL overlay anchors (e.g. new/removed/renamed XUL element ids). For locale packages, breakage is typically a result of changes to the set of defined dtd entities. So everytime a new dtd entity is introduced we must consider the diff incompatible and try to figure out a way to not introduce that change. For gecko changes, the usual library procedures should apply, right? Maybe someone else can provide a checklist what is actually needed to keep track on incompatible gecko changes? If you are aware of other reasons, please add them to the discussion. The more complete the list is, the better we can check an upstream patch for potential package breakage. Cheers, -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.asoftsite.org | `- http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
