Mailinglist Archive: opensuse-buildservice (366 mails)

< Previous Next >
Re: [opensuse-buildservice] RFC: enforce commit messages?
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Tue, 14 Aug 2007 12:55:08 +0200
  • Message-id: <20070814105508.GQ17030@xxxxxxx>
On Tue, Aug 14, 2007 at 12:48:53PM +0200, Dirk Stoecker wrote:
> On Tue, 14 Aug 2007, Dr. Peter Poeml wrote:
> 
> > Now that it is possible to specify a commit message, should that be
> > enforced by the user interface? Until now, the -m <msg> argument is optional. 
> > 
> > The question is, whether "osc commit" should open $EDITOR if -m is not
> > used. Just like svn does.
> > 
> > Or if the current behaviour should remain.
> 
> I would vote for enforcement, but there are some other things related to 
> this:
> 
> a) The webinterface commits currently have no commit message:
>    adding new files, deleting files, editing files

Indeed.

> b) Commit messages are only useful, when the RPM changelog can be built 
>    with the help of these messages somehow automatically.

I think they should kept separate (or at least this behaviour should be
made optional).

I regard the commit log as something which may not be what I want to end
up into the rpm changelog. I may need many iterations until I get a
package to build on all targets, and I would clutter the rpm changelog
with those changes. 

Just like the rpm changelog is usually not the same as the changelog of
any upstream source code repository.

For example, IMO it makes sense to the Apache webserver package that
there are really three changelogs:
- the upstream svn changelog (also packaged as CHANGES in the packages)
- the buildservice commit log (making transparent the work of the packager)
- the rpm changelog (documenting user-visible end results)

Of course it can make total sense to derive the rpm changelog
automatically from the commit log, in certain cases -- I agree on that.

Peter
-- 
"WARNING: This bug is visible to non-employees. Please be respectful!"
 
SUSE LINUX Products GmbH
Research & Development
< Previous Next >
Follow Ups