>>>>> In <[EMAIL PROTECTED]>
>>>>> Branden Robinson <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 10, 2003 at 11:35:30PM +1000, Daniel Stone wrote:
>> > On Tue, Jun 10, 2003 at 10:11:17PM +0900, ISHIKAWA Mutsumi wrote:
>> > > I believe changelog is a changelog, not a bug closer ;)
>> >
>> > Yeah. Branden and I discussed it a while back, and our conclusion was
>> > that we should only use the changelog for major events/news/bug-closing,
>> > not everything. The current xfree86 changelogs are massive, and we have
>> > our revision control system to fully log everything. Plus, crediting
>> > people right is a pain - what if two people work on something? Should
>> > Branden be credited? How much contribution gets a credit? That sort of
>> > thing. :)
>> I think you are misremembering a little bit, or misapplying our
>> agreement to the instant case.
>> Here's my proposal for commit and changelog handling for the X Strike
>> Force. These points are not very well organized because I'm writing
>> this mail in a hurry. If there is agreement on these points I'll add
>> them to the top-level README.
>> * When committing new code (that is, not merging), do so in discrete
>> change sets. A change set is a collection of edits that have the same
>> purpose. For example, "stepped optimiziation level down to -O from
>> -O2 for the entire build" and "fix typos in Xsession.5 manage" are
>> distinct changes and should be committed separately. A change set can
>> affect multiple files, and can include operations such as adding,
>> removing, or renaming files. The import thing is that all the changes
>> in the commit are directed towards achieving the same goal.
>> What do you guys think?
>> The goal is NOT to make the package changelogs less massive. The goal
>> is to make them more useful. My package changelogs have been doing
>> double-duty for years because I didn't have them under revision control.
>> Now they simply need to do what a changelog should do -- log changes.
It is very nice proposal :-)
I think changelog is very important to work together and tell
`What kind of work we are done(and what is not yet)' to users.
Here is one more detail proposal to write each entry of
debian/changelog. What do you think about this?
Currently, we wrote each entries in debian/changelog to to file
oriented, for example:
* debian/control:
- Change all references to libstdc++5-dev to be
libstdc++5-dev | libstdc++-dev, allowing libstdc++5-3.3-dev to satiffy
the dependency, and thus allowing gcc3.2 to be removed.
(Closes: #194136)
- New xlibmesa-drm-src package. (Closes: #139817)
But our work will be changeset oriented, so I think that it will
probably be better to write each entry in debian/changes to changeset
oriented. For example:
* Use external Xft, Xrender and Xcursor libraries [ISHIKAWA Mutsumi]
- patch #058, #059, #060: new;
- patch #909: remove (reimplemented as above patches);
- xlibs{,-dbg,-dev}.*, shlibs*: drop Xrender and Xcursor related entry
- debian/control: add Build-Depends: libxrender-dev, libxcursor-dev
On each entry would describe:
- Short title of changeset.
- some more short descriptions
- bug close entry (if needed)
- some more detail document pointer (if needed)
- (Committed revision of this changeset for more detail)?
Perhaps debian/changelog will be clear to describe
`this release contains what kind of changes.'
--
ISHIKAWA Mutsumi
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
