There's been a request to remove infofeed in favor of bodhi's interface as they now duplicate information.
Is anyone against doing this?
https://fedorahosted.org/fedora-infrastructure/ticket/248
-Mike
On Wed, 2008-01-02 at 10:15 -0600, Mike McGrath wrote:
There's been a request to remove infofeed in favor of bodhi's interface as they now duplicate information.
Is anyone against doing this?
infofeed has more information, though. Look at the feeds on the right of the infofeed. Additionally, there's no single feed for all of the updates in bodhi.
I'm not wed to keeping infofeed - but before we remove something we better make sure we provide the same information.
-sv
On Wed, Jan 02, 2008 at 11:21:18AM -0500, seth vidal wrote:
On Wed, 2008-01-02 at 10:15 -0600, Mike McGrath wrote:
There's been a request to remove infofeed in favor of bodhi's interface as they now duplicate information.
Is anyone against doing this?
infofeed has more information, though. Look at the feeds on the right of the infofeed. Additionally, there's no single feed for all of the updates in bodhi.
Yes there is,
https://admin.fedoraproject.org/updates/rss/rss2.0?status=stable
I'm not wed to keeping infofeed - but before we remove something we better make sure we provide the same information.
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description
update notes bug list
rpm changelog
Is this what we want?
luke
On Wed, 2 Jan 2008, Luke Macken wrote:
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description update notes bug list rpm changelog
Is this what we want?
Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example.
-Mike
On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote:
On Wed, 2 Jan 2008, Luke Macken wrote:
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description update notes bug list rpm changelog
Is this what we want?
Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example.
we have it in the repodata. Which is where the infofeed gets it from :)
-sv
On Wed, 2 Jan 2008, seth vidal wrote:
On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote:
On Wed, 2 Jan 2008, Luke Macken wrote:
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description update notes bug list rpm changelog
Is this what we want?
Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example.
we have it in the repodata. Which is where the infofeed gets it from :)
Thats kind of my point actually I know koji stores a lot of this information in it's database even though the rpms themselves have the information. I'd hate to continue to duplicate information that we're already storing all over the place unless there's a real need for it.
-Mike
On Wed, 2008-01-02 at 12:31 -0600, Mike McGrath wrote:
On Wed, 2 Jan 2008, seth vidal wrote:
On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote:
On Wed, 2 Jan 2008, Luke Macken wrote:
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description update notes bug list rpm changelog
Is this what we want?
Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example.
we have it in the repodata. Which is where the infofeed gets it from :)
Thats kind of my point actually I know koji stores a lot of this information in it's database even though the rpms themselves have the information. I'd hate to continue to duplicate information that we're already storing all over the place unless there's a real need for it.
well, to be fair the duplication in the infofeeds are pretty minimal.
-sv
Mike McGrath wrote:
On Wed, 2 Jan 2008, seth vidal wrote:
On Wed, 2008-01-02 at 11:09 -0600, Mike McGrath wrote:
On Wed, 2 Jan 2008, Luke Macken wrote:
It looks like the infofeed has the RPM summary, description, and recent changelog. Bodhi doesn't know about any of these things, so it will require some database changes to store it. I've been meaning to have bodhi grab the recent RPM changelog upon submission for a little while now, so I don't have a problem implementing this, if we care?
If we were to display these fields too, it would end up looking like
name - summary package description update notes bug list rpm changelog
Is this what we want?
Instead of storing this information in the bodhi db is there somewhere else we can get it from? Koji or pkgdb for example.
we have it in the repodata. Which is where the infofeed gets it from :)
Thats kind of my point actually I know koji stores a lot of this information in it's database even though the rpms themselves have the information. I'd hate to continue to duplicate information that we're already storing all over the place unless there's a real need for it.
+1
The packagedb uses information from the repodata as well. ATM I'm using some yum functions to download the repodata and create sqlite databases from it. Then using python-sqlalchemy to grab relevant information from the sqlite dbs.
Relevant files are:: yumrepo.py: http://tinyurl.com/2rvtx4 script that syncs package description and summary with repodata: http://tinyurl.com/2kb75g
-Toshio
infrastructure@lists.fedoraproject.org