-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
First, let me say what an awesome job John (jjmcd) and others have been doing on the Release Notes. We continue to get kudos from the readers out there, which is most awesome.
Earlier today we did get a bit of "I wish I could have seen X in your RNs"[1]. The requester's problem is not that we didn't talk about the new backup solution but rather we didn't talk about the fact that the old solution went away.
What I envision is a categorical representation of changes. This means, in this case, that the default backup solution for Fedora changed. We should not only document the change but also talk about what's going to happen to the previous default and maybe a migration path.
This is going to take better communication with developers and probably RELENG. I'm open to ideas, though!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=600249
- --Eric
It was brought up on IRC that it is hard for us to keep track of what packages have been removed from the repos, and getting dev's and packagers to let us know when this happens would more then likely not end in much success. Everyone is busy work on things and this would just be another task (not to mention I would imagine that a lot of the packages that get removed are orphaned).
The best solution that I brought up is to use Bohdi to proved this information, and instead of adding this information to the RN, we could put it on a dynamic webpage. I also think that the Fedora Community section would be the best place for it because the system is already setup to interact with Fedora's infrastructure. The issue with this would be making sure the page was publicly accessible (not needing a FAS account). I don't believe it would be an issue but its something we would need to talk to someone about before hand.
Zach
On Fri, Jun 4, 2010 at 4:49 PM, Eric "Sparks" Christensen sparks@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
First, let me say what an awesome job John (jjmcd) and others have been doing on the Release Notes. We continue to get kudos from the readers out there, which is most awesome.
Earlier today we did get a bit of "I wish I could have seen X in your RNs"[1]. The requester's problem is not that we didn't talk about the new backup solution but rather we didn't talk about the fact that the old solution went away.
What I envision is a categorical representation of changes. This means, in this case, that the default backup solution for Fedora changed. We should not only document the change but also talk about what's going to happen to the previous default and maybe a migration path.
This is going to take better communication with developers and probably RELENG. I'm open to ideas, though!
[1] https://bugzilla.redhat.com/show_bug.cgi?id=600249
- --Eric
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMCRJrAAoJEDbiLlqcYamxBwAP/itpakCFuebz6lrR8eCTeKsy x73p07J+nSbs2Iwi6vn3rzMZXT/uSWOgKB8GrNKDZlfuX0Q8hmBUwrqe8Mpdg0fz 6Bi7oMSW8gnyo98U+1hpzYApDgoHp4MuMSxG7wuwrXVZAGQY1YPKr29YM7S+02A5 JLvVNwjBQFNTHxE1cmmPN7DHokd2Mz02ytNBtDH66E4lCdb4Tux+0vopDnCuGqqr hJmNm5Np+8wLxtvjpM7W+QCuI5ypvo6wx+muSqXyzfwJsH8rVWJs8ZXJBWBNO5Xr R1oFDyraWOxZ9hfJYx4quHV1R7urxSZV2oTKqIDYu9fEsoKDPKXE7wXar/SdXVxD 2XgYfeoIM+u5PgABz5dnWDmYpAEetC59+YbrYz1ImGQSX57FI9558WHSfjuOE9gf z1XkWtz9MPMYFdOkHyyMOJ43P1M5KG7wLsytY+cvXPwm//v1mFsHJ4H8fk2yDjBL cLwcfkeC7DCXabWBGwbMLoqRawRXhtyZNEYD3gc9rP/Wp6dliR+ESB2NCJqov5fm 3b49PMmWvHB8nySvl8BpzUoTXhg1sF9d/h/6+uUEhnhoBU8u/xdDJH1ZITbhXweT bMmiBQg5AmutVCNeRUcXnOzum3OFQUd+3bvfdnzD++P5nW1ZsA6S/LFM/UUEbu0Y bLsOOrA3gWWtd8h89Kwn =Mk0Q
-----END PGP SIGNATURE-----
docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
On Fri, Jun 04, 2010 at 19:40:38 +0200, Zach Oglesby oglesbyzm@gmail.com wrote:
It was brought up on IRC that it is hard for us to keep track of what packages have been removed from the repos, and getting dev's and packagers to let us know when this happens would more then likely not end in much success. Everyone is busy work on things and this would just be another task (not to mention I would imagine that a lot of the packages that get removed are orphaned).
The best solution that I brought up is to use Bohdi to proved this information, and instead of adding this information to the RN, we could put it on a dynamic webpage. I also think that the Fedora Community section would be the best place for it because the system is already setup to interact with Fedora's infrastructure. The issue with this would be making sure the page was publicly accessible (not needing a FAS account). I don't believe it would be an issue but its something we would need to talk to someone about before hand.
You can probably do something with a few repoqueries.
Do you only want to see stuff that has been dropped without being obsoleted? Or should obsoleted stuff be included as well? (Maybe as a separate report?)
I can probably show you something simple (and maybe not super efficient) to run from the command line to run to do this. That might help you figure out what you want / need.
Beyond that, you can make a Fedora Engineering Services ticket to ask for help with something like this, if the expertise isn't available in your team. FES relies on someone to volunteer to do it, so for time critical stuff it might not work well.
On Fri, 2010-06-04 at 13:05 -0500, Bruno Wolff III wrote:
You can probably do something with a few repoqueries.
I think I need to clarify a few things.
The Fedora Technical Notes are produced about 90% automatically. Each release I save a copy of primary.sqlite from the repo. Some time back we decided that we needed to show differences release to release rather than from some midpoint in the old version's repo to the new.
Unfortunately, primary.sqlite has some sort of a SHA1 or something prepended to the name which prevents me from downloading it automatically (OK, maybe a little more logic I could do it, but right now I only do it 3 or 4 times during the lead up to a release so not worth it).
Then I compare the primary.sqlites. The Fedora Technical Notes shows the old and new version. If a package is new, then only the new version shows, and the "old" column shows "new". If the same version of the package appears in both Fedora releases, or if the package is missing from the most recent release, the package doesn't show in the document.
The Fedora Technical Notes are not installed, but are available on docs.fedoraproject.org. Those same tables are also provided on the wiki during the collection of release notes content for the benefit of the beat writers.
It wouldn't be a huge leap, and probably worthwhile, to make a separate table with those packages that have disappeared.
If there is a better approach than the repos than I am all ears, but I am looking for more automatic approaches. With over 15K packages, there is no manual option that is reasonable.
--McD
On Fri, Jun 04, 2010 at 14:36:52 -0400, "John J. McDonough" wb8rcr@arrl.net wrote:
On Fri, 2010-06-04 at 13:05 -0500, Bruno Wolff III wrote:
Unfortunately, primary.sqlite has some sort of a SHA1 or something prepended to the name which prevents me from downloading it automatically (OK, maybe a little more logic I could do it, but right now I only do it 3 or 4 times during the lead up to a release so not worth it).
repomd.xml has the name to use. So if you wanted to automate this you could first grab repomd.xml for the repo and then extract the name from it to use for getting primary.sqlite.
If you pull these from the Everything repo, they shouldn't change once a release has occured.
Then I compare the primary.sqlites. The Fedora Technical Notes shows the old and new version. If a package is new, then only the new version shows, and the "old" column shows "new". If the same version of the package appears in both Fedora releases, or if the package is missing from the most recent release, the package doesn't show in the document.
So this is the step you would change. Probably it is a simple change.
It wouldn't be a huge leap, and probably worthwhile, to make a separate table with those packages that have disappeared.
If there is a better approach than the repos than I am all ears, but I am looking for more automatic approaches. With over 15K packages, there is no manual option that is reasonable.
That sounds pretty reasonable. I would have suggested doing something pretty similar.
It might be useful to also list obsolete information for new and dropped packages. I don't know if it is worth the initial setup to get it working. You'd need to do queries against the newer repo for the new and dropped lists to pick up the obsoletes information.
I sent the first version of this to only John by mistake.
On Fri, Jun 04, 2010 at 14:36:52 -0400, "John J. McDonough" wb8rcr@arrl.net wrote:
If there is a better approach than the repos than I am all ears, but I am looking for more automatic approaches. With over 15K packages, there is no manual option that is reasonable.
I took a look at repodiff yesterday. I think it might provide an easier way to do what you want. It will give you a list of new packages, removed packages and information about updates.
When I tested this yesterday I ran into a bug triggered by a nonascii character in one of the new packages. Seth fixed this upstream almost immediately, but a new version might not get pushed for a while. You can fix /usr/bin/repodiff yourself by changing the line: print ' %s' % pkg.summary To: print ' %s' % to_unicode(pkg.summary) As indicated in the upstream commit at: http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=b99d9f7985e4c0e...
To compare the F12 release to the F13 release you can run the following command: repodiff --old=http://mirrors.kernel.org/fedora/releases/12/Everything/source/SRPMS --new=http://mirrors.kernel.org/fedora/releases/13/Everything/source/SRPMS
I couldn't get repodiff to use the mirrorlist redirect links, so you'll want to use a mirror convenient for you, though the kernel mirrors are normally pretty good.
If you don't have repodiff installed, you can get it by installing the yum-utils package.
docs@lists.stg.fedoraproject.org