[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proposed X Strike Force commit/changelog policy



>>>>> In <[🔎] 20030610172201.GO6716@deadbeast.net> 
>>>>>	Branden Robinson <branden@debian.org> 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
 <ishikawa@linux.or.jp>, <ishikawa@debian.org>, <ishikawa@netvillage.co.jp>



Reply to: