Re: [AD] online SVN change log

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/