FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-23-2010, 06:01 PM
Peter Robinson
 
Default F-14 Branched report: 20100923 changes

> anjuta-2.31.90.0-1.fc14
> -----------------------
> * Sun Aug 22 2010 Debarshi Ray <rishi@fedoraproject.org> - 1:2.31.90.0-1
> - Version bump to 2.31.90.0.
> ** Initial support for Python plugins.
> ** Language support for Vala got a major update.
> ** Python is now fully supported.
> ** Snippets plugin from Google Summer of Code.
> ** Increase launcher buffer size. (GNOME Bugzilla #624700)
> ** Class generator plugin:
> * *+ Add missing include. (GNOME Bugzilla #626265)
> ** Language support (Vala) plugin:
> * *+ Symbol completion does not work with 'this'. (GNOME Bugzilla #626306)
> ** Project wizard plugin:
> * *+ Add PyGTK project template. (GNOME Bugzilla #608304)
> * *+ Remove cvsignore from templates. (GNOME Bugzilla #625434)
> ** Symbol-db plugin:
> * *+ Display names containing special characters correctly. (GNOME Bugzilla
> * * * * *+ Create temporary symbol database if project directory is read-only.
> * * *(GNOME Bugzilla #622529)
> ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.90.0.news
> - configure fixes accepted by upstream.
>
> * Sun Aug 22 2010 Debarshi Ray <rishi@fedoraproject.org> - 1:2.31.6.1-2
> - Fixed configure to look for vala-0.10.pc and not vala-1.0.pc.
> - Restored 'BuildRequires: graphviz-devel' as the class inheritence plugin
> *was copied over from anjuta-extras.
> - Added 'BuildRequires: sqlite-devel' for the symbol-db benchmarks.
>
> * Fri Aug 06 2010 Debarshi Ray <rishi@fedoraproject.org> - 1:2.31.6.1-1
> - Version bump to 2.31.6.1.
> ** Debugger is now much more polished.
> ** Debugger supports pretty printing now.
> ** Drag and drop of multiple source files. (GNOME Bugzilla #620664)
> ** Project wizard shows better package chooser.
> ** Support for Vala.
> ** Symbol-db is super fast now.
> ** GNOME Goal: removed deprecated GTK+ symbols. (GNOME Bugzilla #572754)
> ** Debug manager plugin:
> * *+ Mouse cursor is a clock in debug mode. (GNOME Bugzilla #515395)
> * *+ Do not create too many variable objects. (GNOME Bugzilla #516112)
> * *+ Documentation for debug interfaces is incomplete. (GNOME Bugzilla
> * * * * *+ Locals column is now configurable. (GNOME Bugzilla #598187)
> * *+ Allow saving the debugger stack trace. (GNOME Bugzilla #617323)
> ** Document manager plugin:
> * *+ Paths with symlinks do not get 'real' absolute paths. (GNOME Bugzilla
> * * * ** File wizard plugin:
> * *+ Create the corresponding header for a C source file. (GNOME Bugzilla
> * * * ** GDB plugin:
> * *+ New 'set next statement' command. (GNOME Bugzilla #494292)
> ** Language support (C, C++, Java) plugin:
> * *+ Race condition leading to crash while editing. (GNOME Bugzilla #618314)
> * *+ Smart brace completion is no longer smart. (GNOME Bugzilla #618955)
> ** Terminal plugin:
> * *+ Do not become unresponsive when child execution fails. (GNOME Bugzilla
> * * * ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.6.1.news
> ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.6.0.news
> ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.5.0.news
> ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.3.0.news
> ** http://download.gnome.org/sources/anjuta/2.31/anjuta-2.31.2.0.news
>
> * Wed Aug 04 2010 Debarshi Ray <rishi@fedoraproject.org> - 1:2.30.2.1-1
> - Version bump to 2.30.2.1.
> ** Document manager plugin:
> * *+ Open .ui files. (GNOME Bugzilla #616739)
> ** Language support (C, C++, Java) plugin:
> * *+ Support more Vim modelines.
> ** Language support (Javascript) plugin:
> * *+ Do not abort when working on a project with Javascript files. (GNOME
> * * *Project #617734)
> ** Symbol-db plugin:
> * *+ Wrong return type recognition. (GNOME Bugzilla #616780)
> ** http://download.gnome.org/sources/anjuta/2.30/anjuta-2.30.2.1.news
> ** http://download.gnome.org/sources/anjuta/2.30/anjuta-2.30.2.0.news
>
> * Thu May 27 2010 Debarshi Ray <rishi@fedoraproject.org> - 1:2.30.1.0-1
> - Version bump to 2.30.1.0.
> ** Do not free the same string twice. (GNOME Bugzilla #615718)
> ** Duplicated shortcut nodes. (GNOME Bugzilla #616740)
> ** Document manager plugin:
> * *+ Close documents by middle click. (GNOME Bugzilla #600083)
> ** GTodo plugin:
> * *+ Deselecting "Hide completed items" does not show completed items. (GNOME
> * * *Bugzilla #614751)
> ** Language support (C, C++, Java) plugin:
> * *+ Javascript plugins use incorrect LDFLAGS and end up having versioned
> * * *shared object files, links, etc.. (GNOME Bugzilla #615341)
> * *+ Completion for . and -> does not work with prefixed &, %, etc.. (GNOME
> * * *Bugzilla #615596)
> ** Project manager plugin:
> * *+ Consider Vala files as sources. (GNOME Bugzilla #616503)
> ** Symbol-db plugin:
> * *+ Improved symbol icons for members. (GNOME Bugzilla #611834)
> ** http://download.gnome.org/sources/anjuta/2.30/anjuta-2.30.1.0.news
> - Updated the GConf scriptlet snippets according to Fedora packaging
> *guidelines.
>
> * Thu May 20 2010 Rakesh Pandit <rakesh@fedoraproject.org> - 1:2.30.0.0-4
> - Bump (to fix a nuisance I created)
>
> * Thu May 20 2010 Rakesh Pandit <rakesh@fedoraproject.org> - 1:2.30.0.0-3
> - Bump to consume latest libgladeui-1.so.9

<snip>

> dovecot-2.0.1-1.fc14
> --------------------
> * Wed Aug 25 2010 Michal Hlavinka <mhlavink@redhat.com> - 1:2.0.1-1
> - dovecot and pigeonhole updated
> - sieve: sieved renamed to sieve-dump
> - when dsync is started as root, remote dsync command is now also executed
> *as root instead of with dropped privileges.
> - IMAP: QRESYNC parameters for SELECT weren't handled correctly.
> - UTF-8 string validity checking wasn't done correctly
> - dsync: Fixed a random assert-crash with remote dsyncing
>
> * Tue Aug 17 2010 Michal Hlavinka <mhlavink@redhat.com> - 1:2.0-1
> - dovecot and pigeonhole updated
> - dict quota didn't always decrease quota when messages were expunged
> - Shared INBOX wasn't always listed with FS layout
>
> * Wed Aug 11 2010 Michal Hlavinka <mhlavink@redhat.com> - 1:2.0-0.21.rc5
> - dovecot and pigeonhole updated
> - Using more than 2 plugins could have caused broken behavior
> - Listescape plugin fixes
> - mbox: Fixed a couple of assert-crashes
> - mdbox: Fixed potential assert-crash when saving multiple messages
> *in one transaction
>
> * Thu Aug 05 2010 Michal Hlavinka <mhlavink@redhat.com> - 1:2.0-0.20.rc4
> - dovecot and pigeonhole updated
> - doveadm mailbox status: Fixed listing non-ASCII mailbox names.
> - doveadm fetch: Fixed output when fetching message header or body
> - doveadm director map/add/remove: Fixed handling IP address as parameter.
> - dsync: A few more fixes

<snip>

> pacemaker-1.1.3-1.fc14
> ----------------------
> * Tue Sep 21 2010 Andrew Beekhof <andrew@beekhof.net> - 1.1.3-1
> - Upstream release of 1.1.3
> *+ High: crmd: Use the correct define/size for lrm resource IDs
> *+ High: crmd: Bug lf#2458 - Ensure stop actions always have the relevant resource attributes
> *+ High: crmd: Ensure we activate the DC timer if we detect an alternate DC
> *+ High: mcp: Correctly initialize the string containing the list of active daemons
> *+ High: mcp: Fix the expansion of the pid file in the init script
> *+ High: mcp: Tell chkconfig we need to shut down early on
> *+ High: PE: Bug lf#2476 - Repair on-fail=block for groups and primitive resources
> *+ High: PE: Do not demote resources because something that requires it can't run
> *+ High: PE: Rewrite the ordering constraint logic to be simplicity, clarity and maintainability
> *+ High: PE: Wait until stonith is available, don't fall back to shutdown for nodes requesting termination
> *+ High: PE: Prevent segfault by ensuring the arguments to do_calculations() are initialized
> *+ High: stonith: Bug lf#2461 - Prevent segfault by not looking up operations if the hashtable hasn't been initialized yet
> *+ High: Stonith: Bug lf#2473 - Ensure stonith operations complete within the timeout and are terminated if they run too long
> *+ High: stonith: Bug lf#2473 - Gracefully handle remote operations that arrive late (after we've done notifications)
> *+ High: stonith: Bug lf#2473 - Add the timeout at the top level where the daemon is looking for it
> *+ High: stonith: Bug lf#2473 - Ensure timeouts are included for fencing operations
> *+ High: Stonith: Use the timeout specified by the user
> *+ High: Tools: Bug lf#2456 - Fix assertion failure in crm_resource
>
> * Mon Jul 26 2010 Andrew Beekhof <andrew@beekhof.net> - 1.1.3-0.1-b3cb4f4a30ae.hg
> - Pre-release version of 1.1.3
> *+ High: ais: Bug lf2401 - Improved processing when the peer crmd processes join/leave
> *+ High: ais: fix list of active processes sent to clients (bnc#603685)
> *+ High: ais: Move the code for finding uid before the fork so that the child does no logging
> *+ High: ais: Resolve coverity CONSTANT_EXPRESSION_RESULT defects
> *+ High: cib: Also free query result for xpath operations that return more than one hit
> *+ High: cib: Attempt to resolve memory corruption when forking a child to write the cib to disk
> *+ High: cib: Correctly free memory when writing out the cib to disk
> *+ High: cib: Fix the application of unversioned diffs
> *+ High: cib: Remove old developmental error logging
> *+ High: cib: Restructure the 'valid peer' check for deciding which instructions to ignore
> *+ High: Core: Bug lf#2401 - Backed out changeset 6e6980376f01
> *+ High: Core: Correctly unpack HA_Messages containing multiple entries with the same name
> *+ High: Core: crm_count_member() should only track nodes that have the full stack up
> *+ High: Core: New developmental logging system inspired by the kernel and a PoC from Lars Ellenberg
> *+ High: crmd: All nodes should see status updates, not just he DC
> *+ High: crmd: Allow non-DC nodes to clear failcounts too
> *+ High: crmd: Base DC election on process relative uptime
> *+ High: crmd: Bug lf#2439 - cancel_op() can also return HA_RSCBUSY
> *+ High: crmd: Bug lf#2439 - Handle asynchronous notification of resource deletion events
> *+ High: crmd: Fix assertion failure when performing async resource failures
> *+ High: crmd: Fix handling of async resource deletion results
> *+ High: crmd: Include the action for crm graph operations
> *+ High: crmd: Make sure the membership cache is accurate after a sucessful fencing operation
> *+ High: crmd: Make sure we always poke the FSA after a transition to clear any TE_HALT actions
> *+ High: crmd: Offer crm-level membership once the peer starts the crmd process
> *+ High: crmd: Only need to request quorum update for plugin based clusters
> *+ High: crmd: Prevent everyone from loosing DC elections by correctly initializing all relevant variables
> *+ High: crmd: Prevent segmentation fault
> *+ High: crmd: several fixes for async resource delete
> *+ High: mcp: Add missing headers when built without heartbeat support
> *+ High: mcp: New master control process for (re)spawning pacemaker daemons
> *+ High: PE: Avoid creating invalid ordering constraints for probes that are not needed
> *+ High: PE: Bug lf#1959 - Fail unmanaged resources should not prevent other services from shutting down
> *+ High: PE: Bug lf#2422 - Ordering dependencies on partially active groups not observed properly
> *+ High: PE: Bug lf#2424 - Use notify oepration definition if it exists in the configuration
> *+ High: PE: Bug lf#2433 - No services should be stopped until probes finish
> *+ High: PE: Bug lf#2453 - Enforce clone ordering in the absense of colocation constraints
> *+ High: PE: Correctly detect when there is a real failcount that expired and needs to be cleared
> *+ High: PE: Correctly handle pseudo action creation
> *+ High: PE: Correctly order clone startup after group/clone start
> *+ High: PE: Fix colocation for interleaved clones
> *+ High: PE: Fix colocation with partially active groups
> *+ High: PE: Fix potential use-after-free defect from coverity
> *+ High: PE: Fix previous merge
> *+ High: PE: Fix use-after-free in order_actions() reported by valgrind
> *+ High: PE: Prevent endless loop when looking for operation definitions in the configuration
> *+ High: Resolve coverity RESOURCE_LEAK defects
> *+ High: Shell: Complete the transition to using crm_attribute instead of crm_failcount and crm_standby
> *+ High: stonith: Advertise stonith-ng options in the metadata
> *+ High: stonith: Correctly parse pcmk_host_list parameters that appear on a single line
> *+ High: stonith: Map poweron/poweroff back to on/off expected by the stonith tool from cluster-glue
> *+ High: stonith: pass the configuration to the stonith program via environment variables (bnc#620781)
> *+ High: Support starting plugin-based Pacemaker clusters with the MCP as well
> *+ High: tools: crm_report - corosync.conf wont necessarily contain the text 'pacemaker' anymore
> *+ High: tools: crm_simulate - Resolve coverity USE_AFTER_FREE defect
> *+ High: Tools: Drop the 'pingd' daemon and resource agent in favor of ocfacemakering
> *+ High: Tools: Fix recently introduced use-of-NULL
> *+ High: Tools: Fix use-after-free defect from coverity


Is it really necessary to include entire package change logs in the
rpm changelog? What is wrong with referencing either the included
changelog or a URL to a changelog that people can go and reference. I
remember this being discussed ages ago but I'm not sure if there was a
packaging policy instigated.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 01:44 PM
"Richard W.M. Jones"
 
Default F-14 Branched report: 20100923 changes

On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> Is it really necessary to include entire package change logs in the
> rpm changelog? What is wrong with referencing either the included
> changelog or a URL to a changelog that people can go and reference. I
> remember this being discussed ages ago but I'm not sure if there was a
> packaging policy instigated.

Along the same lines, why should we have RPM %changelog at all? The
git repo should maintain the changelog which can be automatically
integrated with the binary RPM at build time. At the moment we have
the same information in at least 2 places.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 04:34 PM
Toshio Kuratomi
 
Default F-14 Branched report: 20100923 changes

On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> > Is it really necessary to include entire package change logs in the
> > rpm changelog? What is wrong with referencing either the included
> > changelog or a URL to a changelog that people can go and reference. I
> > remember this being discussed ages ago but I'm not sure if there was a
> > packaging policy instigated.
>
> Along the same lines, why should we have RPM %changelog at all? The
> git repo should maintain the changelog which can be automatically
> integrated with the binary RPM at build time. At the moment we have
> the same information in at least 2 places.
>
We need to have the rpm changelog in the rpm so that the end user's can see
it. We could generate one of the changelogs automatically, though. I would
much prefer to generate the git log from the rpm changelog than vice-versa,
though. THe git log is going to contain more entries than the rpm changelog
as little things get fixed from time to time that deserve a commit in git
but don't deserve a mention in the rpm changelog.


This should be pretty easy to do in fedpkg commit by having that perform its
fedpkg clog action and then automatically adding that information into what
the git message will be... in fact, I haven't used fedpkg commit, it might
already do this. If not, care to send a patch?

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 04:43 PM
Peter Robinson
 
Default F-14 Branched report: 20100923 changes

On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
>> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
>> > Is it really necessary to include entire package change logs in the
>> > rpm changelog? What is wrong with referencing either the included
>> > changelog or a URL to a changelog that people can go and reference. I
>> > remember this being discussed ages ago but I'm not sure if there was a
>> > packaging policy instigated.
>>
>> Along the same lines, why should we have RPM %changelog at all? *The
>> git repo should maintain the changelog which can be automatically
>> integrated with the binary RPM at build time. *At the moment we have
>> the same information in at least 2 places.
>>
> We need to have the rpm changelog in the rpm so that the end user's can see
> it.

For the fact that its gone from version X to version Y yes. For the
actual application changed between version X and version Y they can
see the ChangeLog that's in the %doc or alternatively check the
release notes for the new version upstream (which can be easily
provided as a link in the rpm changelog). I just don't see the point
in duplicating hundreds of line of upstream release notes in the rpm
changelog when all that's actually changed in the rpm is that we've
gone from release X to release Y.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 05:11 PM
Przemek Klosowski
 
Default F-14 Branched report: 20100923 changes

On 09/24/2010 12:43 PM, Peter Robinson wrote:
> On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi<a.badger@gmail.com> wrote:
>> On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
>>> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
>>>> Is it really necessary to include entire package change logs in the
>>>> rpm changelog? What is wrong with referencing either the included
>>>> changelog or a URL to a changelog that people can go and reference. I
>>>> remember this being discussed ages ago but I'm not sure if there was a
>>>> packaging policy instigated.
>>>
>>> Along the same lines, why should we have RPM %changelog at all? The
>>> git repo should maintain the changelog which can be automatically
>>> integrated with the binary RPM at build time. At the moment we have
>>> the same information in at least 2 places.
>>>
>> We need to have the rpm changelog in the rpm so that the end user's can see
>> it.
>
> For the fact that its gone from version X to version Y yes. For the
> actual application changed between version X and version Y they can
> see the ChangeLog that's in the %doc or alternatively check the
> release notes for the new version upstream (which can be easily
> provided as a link in the rpm changelog). I just don't see the point
> in duplicating hundreds of line of upstream release notes in the rpm
> changelog when all that's actually changed in the rpm is that we've
> gone from release X to release Y.

It is extremely useful to see the RPM info on which vulnerabilities
(CVS numbers, etc) were fixed by the update, especially when they are
backported and therefore not reflected in the package version number.

In principle, the system for extracting %changelog from git might work,
with two provisos:

- people understand that git changelogs have slightly different purpose
than RPM changelogs: git records 'what' changed, while RPM should also
tell 'why' it was changed. In other words, we'd be relying on developers
making high-level as well as low-level comments in the 'log.

- the volume of changelog output should not overwhelm useful information
contained in the log.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 05:25 PM
Bruno Wolff III
 
Default F-14 Branched report: 20100923 changes

On Fri, Sep 24, 2010 at 17:43:47 +0100,
Peter Robinson <pbrobinson@gmail.com> wrote:
>
> For the fact that its gone from version X to version Y yes. For the
> actual application changed between version X and version Y they can
> see the ChangeLog that's in the %doc or alternatively check the
> release notes for the new version upstream (which can be easily
> provided as a link in the rpm changelog). I just don't see the point
> in duplicating hundreds of line of upstream release notes in the rpm
> changelog when all that's actually changed in the rpm is that we've
> gone from release X to release Y.

On the otherside, sometimes all there is, is a note that the version changed.
Including a link to the upstream release notes is nice, even if there
isn't anything else that seems important enough to call out.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 05:32 PM
Toshio Kuratomi
 
Default F-14 Branched report: 20100923 changes

On Fri, Sep 24, 2010 at 05:43:47PM +0100, Peter Robinson wrote:
> On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> > On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
> >> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> >> > Is it really necessary to include entire package change logs in the
> >> > rpm changelog? What is wrong with referencing either the included
> >> > changelog or a URL to a changelog that people can go and reference. I
> >> > remember this being discussed ages ago but I'm not sure if there was a
> >> > packaging policy instigated.
> >>
> >> Along the same lines, why should we have RPM %changelog at all? *The
> >> git repo should maintain the changelog which can be automatically
> >> integrated with the binary RPM at build time. *At the moment we have
> >> the same information in at least 2 places.
> >>
> > We need to have the rpm changelog in the rpm so that the end user's can see
> > it.
>
> For the fact that its gone from version X to version Y yes.

Actually, this is normally reflected in the package version which is quite
visible.

> For the
> actual application changed between version X and version Y they can
> see the ChangeLog that's in the %doc or alternatively check the
> release notes for the new version upstream (which can be easily
> provided as a link in the rpm changelog).

rpm -q --changelog
repoquery -q --changelog

Very handy for asking and answering the questions like:

foobar started segfaulting. yum history tells me I updated it, libbaz, and
libzardoz. Any changes in those that could have caused this?

I'm having problems with foobar not being able to connect to https://.
I wonder if the new update in updates-testing might fix that?

> I just don't see the point
> in duplicating hundreds of line of upstream release notes in the rpm
> changelog when all that's actually changed in the rpm is that we've
> gone from release X to release Y.
>
I agree that duplicating hundreds of lines is not productive. To me the rpm
changelog should give me enough information to know if I might be on the
right track when I ask the questions above. Having hundreds of lines of
changelog per entry is counter-productive to that goal:: If I have to wade
through hundreds of lines for each of foobar, libbaz, and libzardoz I might
well miss that one of the changelog entries addressed the problem I'm
looking for.

The rpm changelog should be more like NEWS than a changelog; and usually
a summary of NEWS, at that. (imho, no packaging guidelines currently
mandate this, etc.)

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 05:55 PM
Björn Persson
 
Default F-14 Branched report: 20100923 changes

Toshio Kuratomi wrote:
> I would much prefer to generate the git log from the rpm changelog than
> vice-versa, though. THe git log is going to contain more entries than the
> rpm changelog as little things get fixed from time to time that deserve a
> commit in git but don't deserve a mention in the rpm changelog.
>
>
> This should be pretty easy to do in fedpkg commit by having that perform
> its fedpkg clog action and then automatically adding that information into
> what the git message will be...

Wouldn't that duplicate entries in the Git changelog? If "fedpkg clog" takes
the topmost entry from the RPM changelog, that will be the same entry as last
time in those cases that deserve a commit in Git but don't deserve a mention
in the RPM changelog. It seems to me that fedpkg would have to search the Git
changelog for the text it took from the RPM changelog, and prompt the packager
for another log message if it's already there.

Björn Persson
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 06:55 PM
"Tom "spot" Callaway"
 
Default F-14 Branched report: 20100923 changes

On 09/24/2010 01:32 PM, Toshio Kuratomi wrote:
> The rpm changelog should be more like NEWS than a changelog; and usually
> a summary of NEWS, at that. (imho, no packaging guidelines currently
> mandate this, etc.)

I could swear I had written "don't copy the upstream changelog into the
rpm changelog, summarize in a line or two if you must.", but apparently,
I never did. :/

~spot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-24-2010, 07:04 PM
Adam Williamson
 
Default F-14 Branched report: 20100923 changes

On Fri, 2010-09-24 at 13:11 -0400, Przemek Klosowski wrote:

> In principle, the system for extracting %changelog from git might work,
> with two provisos:
>
> - people understand that git changelogs have slightly different purpose
> than RPM changelogs: git records 'what' changed, while RPM should also
> tell 'why' it was changed. In other words, we'd be relying on developers
> making high-level as well as low-level comments in the 'log.
>
> - the volume of changelog output should not overwhelm useful information
> contained in the log.

It's not really in principle; other distros have been doing this for
years (it's been this way in Mandriva ever since I became a contributor
there). The RPM changelog is generated from SCM commit messages. If you
want an SCM commit message not to show up in the RPM changelog - say
it's just you fixing a stupid mistake in the spec - preface it with
SILENT: . This system always seemed to work fine.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 05:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org