Re: On Mozilla-* updates
Alexander Sack wrote:
> On Mon, Aug 01, 2005 at 11:42:04AM +0200, Frank Wein wrote:
>
>>As a example lets take the the Bug # from that blog post, Bug 294795.
>>Now lets construct a query and see what we can get. First open
>>http://bonsai.mozilla.org/cvsqueryform.cgi, now in the Branch field you
>>have to enter AVIARY_1_0_1_20050124_BRANCH (that's the
>>Firefox/Thunderbird 1.0.x Branch) and on the bottom of the page you have
>>to enter "[X] Between 2005-05-11 00:00 and 2005-07-19 23:00". Those two
>>are the rough dates when FF 1.0.4 and FF 1.0.6 were released. So run the
>>query and you'll get a list of checkins on that branch between the two
>>releases, now you search on this page for the Bug # (i would say the bug
>># is always noted in the checkin comment except when someone forgets it,
>>but that happens almost never), so 294795. This will point you at the
>>checkin with the comment "Fixing bug 294795. Don't leave references from
>>cloned member functions to the scope where xpconnect creates the
>>functions (safe context). r=bzbarsky[at]mit.edu,
>>sr=brendan[at]mozilla.org, a=dveditz[at]cruzio.com". Now you could
>>either manually merge this checkin by clicking on the version in the 4th
>>column which will display you the diff or check out the new version from
>>the CVS mirror (cvs-mirror.mozilla.org) for example by doing "cvs -j1.11
>>- -j1.11.44 -r AVIARY_1_0_1_20050124_BRANCH
>>mozilla/js/src/xpconnect/src/XPCDispObject.cpp". You can get the version
>>numbers needed by clicking on the version in the 4th column, you'll see
>>the versions then noted at the top.
>
>
> That's the theory and I am aware of it (and I guess eric knows bonsai too).
> In fact, I documented the whole ~650k diff for the thunderbird
> 1.0.2 to 1.0.6 transition that way. I don't want to look at it again,
> but there are definitly checkins that are neither documented to fix some
> bug, nor are they obsolete. Not all checkins are directly named that way.
> For example, checkins needed to fix some security bug are often documented
> as a bug, called a blocker (but not always).
I don't really understand the last sentence. Are you saying that it's
not always possible to find the checkin that relates to a given security
-related bug? If this is because people don't enter the bug number in
the checkin comment, perhaps Mozilla should clamp down on that practice.
If it's because of visibility of security-related bugs, then if we can
get a Debian security team member to have the visibility that would help.
> Just start to do it on your own and you will soon realize that this whole
> thing is not as simple. The only guys that can do it properly are the mozilla
> developers ... by documenting and aggregating patches that are
> actually applied for each single bug or mfsa. In this way they might even be able
> to prevent ABI breakage by accident, like with thunderbird 1.0.5.
Very interesting and helpful post. The theory Frank described is what I
was getting at, but he provided the practice as well. Perhaps if anyone
on the security team has influence in Mozilla development, they could
make a case for documentation (and possibly aggregation) as Alexander
suggested?
I would offer my help, but I think this needs to be done by people who
are better known in both the Debian and Mozilla communities.
Antony
Reply to: