Re: [AD] online SVN change log |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] online SVN change log
- From: Elias Pschernig <elias@xxxxxxxxxx>
- Date: Thu, 15 Jun 2006 10:54:04 +0200
On Thu, 2006-06-15 at 02:38 -0500, Matthew Leverton wrote:
> I've imported the XML SVN change log into the a.cc database and set up
> a minimalistic interface here:
>
> http://www.allegro.cc/svn/log
>
> The obvious reason for this is simply to provide an easy way to search
> through the change logs on A.cc.
>
> However, it might be useful as a way to generate release change logs
> for new versions of Allegro. It's been commented several times that
> creating the change log is the most annoying aspect of doing a new
> release.
>
> (I've not been keeping up with the mailing list recently, so if a
> solution already exists, just kindly ignore the next part.)
No. Only idea that was mentioned is to add a policy to update the
changelog with each commit, instead of having it as a big, boring task
at the end.
> I'm proposing to make this a group task where any trusted user can
> keep the changelog up to date online. When time to release a new
> version of Allegro, one simply needs to supply the proper criteria and
> choose to download the changelog.
>
> It works like this:
>
> * A.cc automatically imports the new items from XML change log as needed.
> * Trusted users go in and mark items as Minor or Major, and provide a
> better description.
> * The release manager downloads the changelog when releasing a new
> version of Allegro.
>
> I set up a few people as admins (Peter W, Elias, Evert) just so you
> can test out the idea. I've only spent an hour on this, so don't judge
> the idea by the current interface. ;) If it's something that will be
> useful, I can refine the interface as needed to make it as simple as
> possible. Right now it's rather cumbersome.
>
> Benefits to this system could include monitoring & notifications, such
> as being alerted whenever a file changes or being reminded to go
> through the unclassified items, etc.
I think this will be very useful. I'm not sure about the current
interface though. For example:
5812 elias added XInitThreads and [xkeyboard] to example config 2006-May-21
5811 elias documented XInitThreads config variable 2006-May-21
5810 elias call XInitThreads in the X11 driver, to make Mesa-OpenGL work together ... 2006-May-21
Or:
5809 elias i think my previous patch broke binary compatibility with 4.2.0, this ... 2006-May-20
5808 elias fixed previous commit 2006-May-20
5807 elias Actually implemented al_ffblk_size 2006-May-20
5806 elias deprecated file_size and al_ffblk->info in favor of sile_size_ex ... 2006-May-20
5805 elias Replaced file_size with file_size_ex, which uses a 64-bit return types ...
This I would like to convert it so it appears as two entries:
* Added an XInitThreads call to the X11 driver, to make Mesa-OpenGL work
together with Allegro.
* Added a file_size_ex function which can handle file sizes > 2GB.
With the ability to edit logs and mark some as minor, I could mark
everything but 5805 and 5810 as minor right now, and have my two log
messages in 5805 and 5810. Of course, this would not be optimal: The
minor messages would be quite useless, and contain things like "fixed
previous commit", and two (5805 and 5810) also would be missing.
So, maybe there should be a "merge" option, where multiple revisions can
be grouped into one (reformulated) log entry? Maybe also a "delete"
option, to simply delete something like "fixed a typo in a comment" -
which would not even count as minor.
The (possibly) merged entries then could be either minor or major.
90% of log messages probably don't need this and a log message simply
corresponds to a ChangeLog entry. The above two cases though would need
it (and I really do hope it's coincidence that both recent bad examples
are committed by me..).
--
Elias Pschernig