Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 10:31:40PM -0500, Branden Robinson wrote: On Wed, Jun 11, 2003 at 08:49:32AM +1000, Daniel Stone wrote: On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Well, I rudely purged your changelog entries from the 4.3.0/sid branch, so I don't see them and they don't bother me. :) Well, yeah. Behold, an example. :P -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgp0.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 02:20:45PM -0400, Joey Hess wrote: Branden Robinson wrote: * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? I tend to changelog everything I do as I do it, then when I'm about to commit I copy the working changelog aside and trim debian/changelog down so that the diff shows only one changeset. After I commit, I move the working changelog back. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. It can; use the -v option. I do tend to err towards verbose log messages anyway, though. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. Ditto. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 10:31:40PM -0500, Branden Robinson wrote: On Wed, Jun 11, 2003 at 08:49:32AM +1000, Daniel Stone wrote: On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Well, I rudely purged your changelog entries from the 4.3.0/sid branch, so I don't see them and they don't bother me. :) Well, yeah. Behold, an example. :P -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpOdltq7g8Od.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 02:20:45PM -0400, Joey Hess wrote: Branden Robinson wrote: * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? I tend to changelog everything I do as I do it, then when I'm about to commit I copy the working changelog aside and trim debian/changelog down so that the diff shows only one changeset. After I commit, I move the working changelog back. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. It can; use the -v option. I do tend to err towards verbose log messages anyway, though. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. Ditto. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: proposed X Strike Force commit/changelog policy
On Wed, Jun 11, 2003 at 05:52:43AM -0500, Colin Watson wrote: On Tue, Jun 10, 2003 at 02:20:45PM -0400, Joey Hess wrote: Branden Robinson wrote: * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. It can; use the -v option. I do tend to err towards verbose log messages anyway, though. Ooh, that's nice. I wish -v were the default. Still, I continue to advocate the format I advised above. I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. Ditto. And as I told Joey, please speak up anytime. -- G. Branden Robinson| Debian GNU/Linux | Ab abusu ad usum non valet [EMAIL PROTECTED] | consequentia. http://people.debian.org/~branden/ | pgpuJE5adMB5R.pgp Description: PGP signature
proposed X Strike Force commit/changelog policy
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. * Sometimes we are simply doing a review of existing code or documentation, not reacting to a problem or bug report. In such cases sometimes the best thing to do simply commit all changes to a file in one change set. For example, overhaul Xsession.5 manpage. This is a matter of discretion. When deciding what should go into your commit (a.k.a. change set), ask yourself how much extra work will be made if anything in your commit has to be reverted in the future. It is unlikely that a typo fix will be reverted, but if your typo fixes are mixed in with the addition of a new chunk of code that may be reverted later, then that reversion will mean the typo fixes have to be re-committed. Worse, the person reverting your change may forget to re-commit the typo fixes! * When committing a merge operation, identify in the commit log which range of revisions is being merged onto the branch (or the trunk, if you're merging onto the trunk). For example: merging revisions 156--170 from trunk onto branches/4.3.0/sid * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. For example, I did an svn log branches/4.3.0/sid this morning and saw this: rev 172: ishikawa | 2003-06-10 06:44:45 -0500 (Tue, 10 Jun 2003) | 3 lines always disable FontLibSharedFreeType rev 170: branden | 2003-06-09 15:29:19 -0500 (Mon, 09 Jun 2003) | 2 lines install the unstripped library in /usr/X11R6/lib/debug, not /usr/X11R6/lib rev 169: branden | 2003-06-09 15:27:36 -0500 (Mon, 09 Jun 2003) | 2 lines import 4.2.1-8 changelog and clean up 4.3.0 entries rev 168: ishikawa | 2003-06-09 14:08:23 -0500 (Mon, 09 Jun 2003) | 3 lines Imake waring fix rev 166: ishikawa | 2003-06-09 11:02:36 -0500 (Mon, 09 Jun 2003) | 3 lines resync with 4.2.1-8 rev 138: branden | 2003-06-04 08:06:54 -0500 (Wed, 04 Jun 2003) | 2 lines usr/X11R6/lib/modules/libint10.a is back for IA-64 rev 129: daniel | 2003-06-03 07:49:48 -0500 (Tue, 03 Jun 2003) | 2 lines i830 fix from Egbert Eich - apparently it's completely unusable without this. That's not as useful as it could be. Look at how the Subversion guys do commit messages: Regression test for issue #1353: handle twice-deleted file. Also, fix some bugs discovered in the process of making the new test. This twice-deleted file issue is quite similar to the one described in issue #1302; but there are enough variables between the two that an isolated regression test is a good idea. * tools/cvs2svn/cvs2svn.py (make_path): Fix bug in handling of top-level files.
Re: proposed X Strike Force commit/changelog policy
* When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. -- see shy jo pgp0.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Tue, 10 Jun 2003, Branden Robinson 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. [SNIP] It is more than fine for me. Thanks Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 02:20:45PM -0400, Joey Hess wrote: * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? When I find myself forking into two different changesets, I save the file I'm editing with a .new extension and then undo the changes that aren't relevant to one of the change sets. I then finish change set #1, document it in debian/changelog if necessary, and commit. I then mv the .new file on top of the original. It should now just have a diff for change set #2. If need be, I edit it to continue working on that change. When I'm done with that change set, I document it in debian/changelog if necessary, and commit. That's just my approach. I don't know if others would find it palatable. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. Yes, and I'm tempted to agree about the output of svn log when run on a directory, but I still think documenting the specific changes done to each file is a good diea. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. No problem at all. Please chime in whenever you like. -- G. Branden Robinson| Men are born ignorant, not stupid. Debian GNU/Linux | They are made stupid by education. [EMAIL PROTECTED] | -- Bertrand Russell http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Wed, Jun 11, 2003 at 03:59:09AM +0900, ISHIKAWA Mutsumi wrote:
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.'
I agree entirely. The current format is just a holdover from when I
needed to be able to hand-revert changes on a file-by-file basis.
Revision control makes that unnecessary.
Thanks!
--
G. Branden Robinson| One man's magic is another man's
Debian GNU/Linux | engineering. Supernatural is a
[EMAIL PROTECTED] | null word.
http://people.debian.org/~branden/ | -- Robert Heinlein
pgp0.pgp
Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
[hurried reply] On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Anyway, as to the point at issue, I don't think there is anything wrote with ISHIKAWA-san's update to debian/changelog. It was a fairly important change to the build process. My apologies for misunderstanding; I'm glad it's out in the clear now. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgp0.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Wed, Jun 11, 2003 at 08:49:32AM +1000, Daniel Stone wrote: [hurried reply] On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Well, I rudely purged your changelog entries from the 4.3.0/sid branch, so I don't see them and they don't bother me. :) -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
proposed X Strike Force commit/changelog policy
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. * Sometimes we are simply doing a review of existing code or documentation, not reacting to a problem or bug report. In such cases sometimes the best thing to do simply commit all changes to a file in one change set. For example, overhaul Xsession.5 manpage. This is a matter of discretion. When deciding what should go into your commit (a.k.a. change set), ask yourself how much extra work will be made if anything in your commit has to be reverted in the future. It is unlikely that a typo fix will be reverted, but if your typo fixes are mixed in with the addition of a new chunk of code that may be reverted later, then that reversion will mean the typo fixes have to be re-committed. Worse, the person reverting your change may forget to re-commit the typo fixes! * When committing a merge operation, identify in the commit log which range of revisions is being merged onto the branch (or the trunk, if you're merging onto the trunk). For example: merging revisions 156--170 from trunk onto branches/4.3.0/sid * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. For example, I did an svn log branches/4.3.0/sid this morning and saw this: rev 172: ishikawa | 2003-06-10 06:44:45 -0500 (Tue, 10 Jun 2003) | 3 lines always disable FontLibSharedFreeType rev 170: branden | 2003-06-09 15:29:19 -0500 (Mon, 09 Jun 2003) | 2 lines install the unstripped library in /usr/X11R6/lib/debug, not /usr/X11R6/lib rev 169: branden | 2003-06-09 15:27:36 -0500 (Mon, 09 Jun 2003) | 2 lines import 4.2.1-8 changelog and clean up 4.3.0 entries rev 168: ishikawa | 2003-06-09 14:08:23 -0500 (Mon, 09 Jun 2003) | 3 lines Imake waring fix rev 166: ishikawa | 2003-06-09 11:02:36 -0500 (Mon, 09 Jun 2003) | 3 lines resync with 4.2.1-8 rev 138: branden | 2003-06-04 08:06:54 -0500 (Wed, 04 Jun 2003) | 2 lines usr/X11R6/lib/modules/libint10.a is back for IA-64 rev 129: daniel | 2003-06-03 07:49:48 -0500 (Tue, 03 Jun 2003) | 2 lines i830 fix from Egbert Eich - apparently it's completely unusable without this. That's not as useful as it could be. Look at how the Subversion guys do commit messages: Regression test for issue #1353: handle twice-deleted file. Also, fix some bugs discovered in the process of making the new test. This twice-deleted file issue is quite similar to the one described in issue #1302; but there are enough variables between the two that an isolated regression test is a good idea. * tools/cvs2svn/cvs2svn.py (make_path): Fix bug in handling of top-level files.
Re: proposed X Strike Force commit/changelog policy
* When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. -- see shy jo pgpLXVuwkLplz.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
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]
Re: proposed X Strike Force commit/changelog policy
On Tue, 10 Jun 2003, Branden Robinson 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. [SNIP] It is more than fine for me. Thanks Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: proposed X Strike Force commit/changelog policy
On Wed, Jun 11, 2003 at 03:59:09AM +0900, ISHIKAWA Mutsumi wrote:
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.'
I agree entirely. The current format is just a holdover from when I
needed to be able to hand-revert changes on a file-by-file basis.
Revision control makes that unnecessary.
Thanks!
--
G. Branden Robinson| One man's magic is another man's
Debian GNU/Linux | engineering. Supernatural is a
[EMAIL PROTECTED] | null word.
http://people.debian.org/~branden/ | -- Robert Heinlein
pgpgZ92upI3wT.pgp
Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Tue, Jun 10, 2003 at 02:20:45PM -0400, Joey Hess wrote: * When doing a commit that should be logged in the debian/changelog file, edit the debian/changelog file before doing the commit and commit the change to it along with the rest of your change set. As a point of interest, do you ever find yourself working on more than one thing at a time in the same checkout, and how do you juggle the debian/changelog changes then? When I find myself forking into two different changesets, I save the file I'm editing with a .new extension and then undo the changes that aren't relevant to one of the change sets. I then finish change set #1, document it in debian/changelog if necessary, and commit. I then mv the .new file on top of the original. It should now just have a diff for change set #2. If need be, I edit it to continue working on that change. When I'm done with that change set, I document it in debian/changelog if necessary, and commit. That's just my approach. I don't know if others would find it palatable. * Here's a new one that I myself didn't realize was important until this morning: always include the name of each file being changed in your commit log. This seems redundant until you realize that svn log operations can be run on directories. Of course subversion knows what files that change touched. This sounds more like a deficiency of svn log; it should be able to list the files. Yes, and I'm tempted to agree about the output of svn log when run on a directory, but I still think documenting the specific changes done to each file is a good diea. What do you guys think? I'm not part of your team, but I have some interest in subversion and some of the same issues, so pardon me for weighing in.. No problem at all. Please chime in whenever you like. -- G. Branden Robinson| Men are born ignorant, not stupid. Debian GNU/Linux | They are made stupid by education. [EMAIL PROTECTED] | -- Bertrand Russell http://people.debian.org/~branden/ | pgpUo53YVy1AW.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
[hurried reply] On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Anyway, as to the point at issue, I don't think there is anything wrote with ISHIKAWA-san's update to debian/changelog. It was a fairly important change to the build process. My apologies for misunderstanding; I'm glad it's out in the clear now. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpNiUwbjalWU.pgp Description: PGP signature
Re: proposed X Strike Force commit/changelog policy
On Wed, Jun 11, 2003 at 08:49:32AM +1000, Daniel Stone wrote: [hurried reply] On Tue, Jun 10, 2003 at 12:22:01PM -0500, Branden Robinson wrote: 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. That's what I meant, really. Right now, some of the changelogs (like the 293-line changelog for 4.3.0-0ds4) are pretty unnavigable. Well, I rudely purged your changelog entries from the 4.3.0/sid branch, so I don't see them and they don't bother me. :) -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgp86Ks1og97i.pgp Description: PGP signature
