|
From: Tony R. <tb...@gm...> - 2008-10-05 20:07:54
|
I should add that I think all of the core developers already do these things well. I just meant to bring up the issue for posterity. Also, it helps me when I have to compile a changelog for a forthcoming release (and can't remember what changes we made since the last release 12 months ago). The bottom line is that the more communication we have about what is being done and what has been done, the better. -Tony On Sun, Oct 5, 2008 at 1:02 PM, Tony Reina <tb...@gm...> wrote: > >> > Nevertheless, I think that whenever a developer (core or not) commits >> > significant changes to SVN, that they should let the list know about >> > it and give a brief description of the changes. Of course, simple bug >> > fixes don't need such formaility. The rule of thumb: If you think >> > someone will object to your commit, then ask first. >> >> But we do need to actively appraise these changes. I have unfortunately >> seen that a lot of work has gone into something only to have it vetoed >> much later than needed. (not speaking necessarily of this project) I >> think to reduce this as much, then we have to enforce a time scale. I am >> aware that not everyone spends as much time with the computer as I (not >> that I am programming the whole time) so waiting for longer than a day >> for a reply from me is usually rare (except when SF/my provider screws >> around - I received a mail today that I mailed to a list Friday), but we >> do have to at least try to monitor the mailings daily. Patches should be >> examined, and tested. There is a lot we can do to make developing this a >> pleasurable fun experience. We should try to keep it that way. >> >> > No, I don't think it needs to be appraised unless it's a major change in > how the architecture looks or how the IDE behaves (e.g. API changes, config > file changes, etc.). What I was thinking of is just an email message (or > maybe some sort of developer forum) where we post a little detail on the > change. My thought is that sometimes SVN comments are pretty limited and > there might not be enough room in them to fully explain how something new > works. For example, in an API change, you really want a more detailed > message to the developers so that everyone is aware of the change. Or, if > there's a major bug fix, it might be useful to other developers to know that > something was coded wrong (e.g. in wxDev-C++ we found that the plugins count > variable wasn't equal to 1 when it should have been-- this might not just > affect the specific code that was patched; with that knowledge Esteban might > be prompted to check all of the occurrences of the variable to make sure > that there aren't other lingering bugs associated with it). > > -Tony > > > |