Re: ChangeLog entries
Hi, On Tue, 2003-08-19 at 00:54, Brian Jones wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > I would certainly made this into three commits but would have just used > > the given separate ChangeLog entries as shown since eacht entry is > > clearly a group of changes that is related. > > My typical usage is: > > 1) Make vast sweeping changes > 2) cd classpath > 3) cvs ci . > > I don't really like that this puts changes to other files in the log > of every file... but it's the easy and simple way not to screw up. > More helpful if cvs grok'd ChangeLog entries and fixed the log as you > go... but oh well. Should I adjust? No, I think this is fine. As long as the "vast sweeping changes" are related to each other. If they change completely different things in the code then it makes sense to copy your classpath cvs checkout working directory and work/test these thing separately so they can easily be committed independently from each other. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, 2003-08-18 at 08:05, Sascha Brawer wrote: > > Here's a question about ChangeLog entries: Would it make sense to have > > separate commits (and thus ChangeLog entries) for unrelated changes? > > Yes for completely unrelated changes they should be committed seperately > (especially when doing a formatting change and a logical change, do them > in two separate commits). But do try to do a commit of as much > things/files that are done at the same time which can logically be seen > as part of the same change/cleanup etc. > > > The guile guidelines do not mention this, but I personally think it can > > be rather unpleasant to sift through dozens of irrelevant lines when > > trying to find out what has happened to a file. > > > > For example, the attached log message does not seem to be very helpful. > > (The author is omitted in order to not pick on anybody in particular). > > IMHO, such bulk commits make it harder to track changes. > > The three log messages that you quote seem logically grouped together. > O, I see you mean that they are actually one commit. > Then it would have made sense to just use the New files/Regenerate entry > since logically it was just the adding of a bunch of new files (that > they were edited offline a couple of times isn't really reflected in out > CVS so it doesn't have to to be mentioned (except maybe if it comes from > resyncing with another tree, like libgcj, then it is a good idea to add > all relevant changes that were done in the other tree to our ChangeLog). > I would certainly made this into three commits but would have just used > the given separate ChangeLog entries as shown since eacht entry is > clearly a group of changes that is related. My typical usage is: 1) Make vast sweeping changes 2) cd classpath 3) cvs ci . I don't really like that this puts changes to other files in the log of every file... but it's the easy and simple way not to screw up. More helpful if cvs grok'd ChangeLog entries and fixed the log as you go... but oh well. Should I adjust? Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Hi, On Mon, 2003-08-18 at 08:05, Sascha Brawer wrote: > Here's a question about ChangeLog entries: Would it make sense to have > separate commits (and thus ChangeLog entries) for unrelated changes? Yes for completely unrelated changes they should be committed seperately (especially when doing a formatting change and a logical change, do them in two separate commits). But do try to do a commit of as much things/files that are done at the same time which can logically be seen as part of the same change/cleanup etc. > The guile guidelines do not mention this, but I personally think it can > be rather unpleasant to sift through dozens of irrelevant lines when > trying to find out what has happened to a file. > > For example, the attached log message does not seem to be very helpful. > (The author is omitted in order to not pick on anybody in particular). > IMHO, such bulk commits make it harder to track changes. The three log messages that you quote seem logically grouped together. O, I see you mean that they are actually one commit. Then it would have made sense to just use the New files/Regenerate entry since logically it was just the adding of a bunch of new files (that they were edited offline a couple of times isn't really reflected in out CVS so it doesn't have to to be mentioned (except maybe if it comes from resyncing with another tree, like libgcj, then it is a good idea to add all relevant changes that were done in the other tree to our ChangeLog). I would certainly made this into three commits but would have just used the given separate ChangeLog entries as shown since eacht entry is clearly a group of changes that is related. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries
Mark Wielaard <[EMAIL PROTECTED]> wrote on Wed, 13 Aug 2003 01:05:31 +0200: >I would really like everybody to follow the ChangeLog entry guidelines >given in: >http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html Here's a question about ChangeLog entries: Would it make sense to have separate commits (and thus ChangeLog entries) for unrelated changes? The guile guidelines do not mention this, but I personally think it can be rather unpleasant to sift through dozens of irrelevant lines when trying to find out what has happened to a file. For example, the attached log message does not seem to be very helpful. (The author is omitted in order to not pick on anybody in particular). IMHO, such bulk commits make it harder to track changes. -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ % cvs log java/awt/font/GlyphVector.java [...] 2003-02-17 [...] * java/awt/dnd/DragSourceContext.java (addDragSourceListener): Added documentation. * java/awt/dnd/DragSourceDragEvent.java (serialVersionUID): New member variable. (getDropAction): Reformated. * java/awt/dnd/DragSourceDropEvent.java (serialVersionUID): New member variable. (dropSuccess): Renamed from success for serialization issues. * java/awt/dnd/DragSourceEvent.java (serialVersionUID): New member variable. * java/awt/dnd/DropTarget.java (serialVersionUID): New member variable. (DropTarget): Implemented, documentation reworked. (setComponent): Documentation added. (getComponent): Documentation added. (setDefaultActions): Documentation added. (getDefaultActions): Documentation added. (addDropTargetListener): Documentation added. * java/awt/dnd/DropTargetContext.java (DropTargetContext): Documentation added. (TransferableProxy.TransferableProxy): New method. (dropComplete): Fixed documentation. (getTransferable): Fixed documentation. (createTransferableProxy): Implemented. * java/awt/dnd/DropTargetDragEvent.java (DropTargetDragEvent): Documentation added. (serialVersionUID): New member variable. (DropTargetDragEvent): Throw exceptions, documentation added. (acceptDrag): Implemented. (getCurrentDataFlavors): Implemented.3yy (getCurrentDataFlavorsAsList): Implemented. (isDataFlavorSupported): Implemented. (rejectDrag): Implemented. * java/awt/dnd/DropTargetDropEvent.java (DropTargetDropEvent): Documentation added. (serialVersionUID): New member variable. (actions): Renamed from srcActions for serialization issues. (isLocalTx): Renamed from isLocalTx for serialization issues. (DropTargetDropEvent): New implementation, throw exceptions, documentation added. (getCurrentDataFlavors): Implemented. (getCurrentDataFlavorsAsList): Implemented. (isDataFlavorSupported): Implemented. (getSourceActions): Implemented. (getDropAction): Implemented. (getTransferable): Implemented. (acceptDrop): Implemented. (rejectDrop): Implemented. * java/awt/dnd/DropTargetListener.java (drop): Fixed documentation. * java/awt/dnd/MouseDragGestureRecognizer.java (MouseDragGestureRecognizer): Documentation added. 2003-02-17 [...] * java/awt/font/FontRenderContext.java, java/awt/font/ShapeGraphicAttribute.java, java/awt/font/MultipleMaster.java, java/awt/font/TransformAttribute.java, java/awt/font/GlyphJustificationInfo.java, java/awt/font/LineBreakMeasurer.java, java/awt/font/TextMeasurer.java, java/awt/font/TextLayout.java, java/awt/font/LineMetrics.java, java/awt/font/TextAttribute.java, java/awt/font/GlyphMetrics.java, java/awt/font/OpenType.java, java/awt/font/GlyphVector.java, java/awt/font/GraphicAttribute.java, java/awt/font/ImageGraphicAttribute.java, java/awt/font/NumericShaper.java: New files. * Makefile.am (awt_java_source_files): Added the following files: java/awt/font/FontRenderContext.java java/awt/font/ShapeGraphicAttribute.java java/awt/font/MultipleMaster.java java/awt/font/TransformAttribute.java java/awt/font/GlyphJustificationInfo.java java/awt/font/LineBreakMeasurer.java java/awt/font/TextMeasurer.java java/awt/font/TextLayout.java java/awt/font/LineMetrics.java java/awt/font/TextAttribute.java java/awt/font/GlyphMetrics.java java/awt/font/OpenType.java java/awt/font/GlyphVector.java java/awt/font/GraphicAttribute.java java/awt/font/ImageGraphicAttribute.java java/awt/font/NumericShaper.java * Makefile.in: Rege
ChangeLog entries
Hi, I would really like everybody to follow the ChangeLog entry guidelines given in: http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html I will try to update out hacking document with some of the style guides later. But maybe a couple of examples are more clear. So here is how I would like to see some of the ChangeLog entries of today: > * java/awt/font/OpenType.java: Remove 'public static final' > from OpenType tags, reverting the change of 2003-08-11. See > Classpath discussion list of 2003-08-11. This should just state: * java/awt/font/OpenType.java: Remove 'public static final' from all member fields. The explanation why should either be in the code or (more appropriate in this case be added to our hacking document. > * java/io/ObjectOutputStream.java : allow putFields be called more than > once Don't make lines longer then 80 characters. And this explains the effect of the change, which should be in a comment in the code if appropriate. The ChangeLog should just explain what changed: * java/io/ObjectOutputStream.java (putFields): Don't call markFieldsWritten(). Only create new PutField when currentPutField is null. (writeFields): Call markFieldsWritten(). Also this patch included more then just the above. It also cleaned up some exceptions. Which is nice, but should probably be a separate patch and the change should be documented in the ChangeLog. (Sidenote. Since Throwables can now be chained it is a good idea to use Throwable.setCause() and not just add the String representation of a exception to another exception.) Hope these examples help. And I do appreciate the fact that writing ChangeLog entries, using a coding style that is not "your own" and the CVS, patch and diff tools do take some time to getting used to. So don't feel like you have to do it perfect right away or that contributions aren't welcome if they aren't 'perfect'. We all learn by doing and interacting with each other. And over time I might actually learn to be a bit less uptight maintainer :) One more thing. I really want to have a pretty open check-in policy. But this means that you should be extra careful if you check something in. If at all in doubt or if you think that something might need extra explaining since it is not completely obvious please make a little announcement about the change on the main classpath mailinglist. And if you do commit something without discussing it first and another GNU Classpath hackers asks for extra explanation or suggests to revert a certain commit then please reply to the request by explaining why something should be so or if you agree to revert it. (Just reverting immediately is OK without discussion, but then please don't mix it with other changes.) All the above is really meant to make sure that GNU Classpath will be maintainable in the long run and to give all the projects that are now using GNU Classpath an accurate view of the changes we make to the code and to see what changed when. If you think that the above "project rules" are impractical or will hinder contributions please contact me. I am happy to do code cleanups and/or write ChangeLog entries for submissions (although that can mean that your contribution takes a bit longer to get into the main tree). And we can always setup a classpath-patches mailinglist to really discuss and/or approve of each change before it gets committed, but I think that will add to much bureaucracy at the moment. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: ChangeLog entries when merging things back from libgcj
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 14. Juli 2003 09:46 schrieb Mark Wielaard: > Hi, > > On Mon, 2003-07-14 at 07:50, Michael Koch wrote: > > * java/net/ServerSocket.java, > > java/net/Socket.java: New versions from libgcj. > > If possible I would like to see the original libgcj ChangeLog entry > when things get merged back into Classpath from libgcj. > > * java/net/ServerSocket.java > (setChannel): New method. > * java/net/Socket.java > (setChannel): New method. > > Is much more descriptive then the above. Sorry to make you troubles. Will do this in the future. Michael - -- Homepage: http://www.worldforge.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/EnRPWSOgCCdjSDsRAlynAJ9jOmnS1CldpRnHy6peT3uOlf2QfwCfX4j1 VmJwnjVOCiw71hz/f0MoaLU= =rlnd -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
ChangeLog entries when merging things back from libgcj
Hi, On Mon, 2003-07-14 at 07:50, Michael Koch wrote: > * java/net/ServerSocket.java, > java/net/Socket.java: New versions from libgcj. If possible I would like to see the original libgcj ChangeLog entry when things get merged back into Classpath from libgcj. * java/net/ServerSocket.java (setChannel): New method. * java/net/Socket.java (setChannel): New method. Is much more descriptive then the above. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
