Hello :-) one of the things we need to do in the future, and it's not trivial, is to give a clue of the changes from a distribution to the other (that is, for example from SUSE 10.0 to 10.1). I don't mean only say "we got kde 5.8.3", but what this changes for the user. For example, I'm a pretty heavy photo user. I mostly use Gimp, but if I do many photos I make few edits (I like to make good photos with the camera, not the computer). So I don't at all master Gimp (nor Photo shop, for that matter). this morning, to show yesterday night photos to my wife, I opened Konqueror but the default display is not very convenient, so I right clic and discovered "showphoto" - said to be the photo application for kde. and not only there is a viewing mode extremely friendly but also many photo modification very simple. that is to say Linux is moving still very fast and it's easy to miss interesting apps, or interesting enhancements to apps (I have yet to know what Gimp 2 have more than Gimp 1 - I'm sure they are, but could not find time to search) So a "enhancement" page on the wiki would be very nice. I know, however (for already having tried to do such things) that it's a very hard work. jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
So a "enhancement" page on the wiki would be very nice.
I know, however (for already having tried to do such things) that it's a very hard work.
I was thinking the same thing would be nice for the apt repositories. So often there is a new build of something showing up in the apt repositories... but no list of the delta/changes between the installed/previous version and the new version. I've never spoke up asking for it because I know that a lot (most) of the stuff I use from apt is user contributions, and I'm grateful it's there... and as you say, it's a lot of hard work to add the delta info (even if you're the developer). C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Clayton wrote:
So a "enhancement" page on the wiki would be very nice. I know, however (for already having tried to do such things) that it's a very hard work.
I was thinking the same thing would be nice for the apt repositories. So often there is a new build of something showing up in the apt repositories... but no list of the delta/changes between the installed/previous version and the new version. I've never spoke up asking for it because I know that a lot (most) of the stuff I use from apt is user contributions, and I'm grateful it's there... and as you say, it's a lot of hard work to add the delta info (even if you're the developer).
It certainly is.
IMHO the best option is to have RSS/RDF/Atom feeds, like on my site:
http://linux01.gwdg.de/~pbleser/rss.php
or as on Packman:
http://packman.links2linux.de/rdf/packman_en.rdf
The problem is that what actually needs to be shown as for "delta information" comes from the
software authors, not from the packager, because a newer package is almost always because of a new
upstream version (sometimes also because of bugfixes to the package itself, but that's maybe 5%).
There is Changelog information inside RPM packages (e.g. "rpm -q --changelog sed") but that's for
changes applied to the package itself, not to the software that's being packaged, so it's usually
quite pointless to show that information.
What makes it tedious is the fact that the packager would have to manually write the change
information that applies to the new version.
And it has to be done manually because:
- - there's no common structure as where that information is stored: some have ChangeLog, some have
NEWS, some only on their website, some have none (!)
- - ChangeLog files are quite common but they're much too fine grained, noone wants to read all that
(and it's not very helpful to end-users)
- - NEWS files are not always present (I'd say in 30% of the projects, at most) and there's no
standardized format and no way to automatically retrieve change information from those files (unless
you do some really nasty text file parsing magic, but that'll never work for more than 70% of such
files)
So, to summarize:
1) either the packager has to manually collect the change information from various sources,
2) or the authors of the software have to come up with some standardized, machine-parseable (e.g.
XML-based) file format that could automatically be aggregated.
(1) is tedious
(2) probably will never be possible, as all the FOSS authors would have to include such a file (and
we'd already be happy if they would all integrate the patches we have to apply to their sources)
IMHO the only real chance to have that in a near future is to:
1) bring all the 3rd party SUSE Linux packagers together
2) aggregate their repository information on opensuse.org (which also means defining a common
infrastructure, technically speaking, such as providing Atom feeds of their package updates)
3) avoid duplication of RPM packages amongst those repositories, to reduce the amount of work every
packager has, which will then give some more time to spend on adding such change information ;)
RSS/RDF/Atom feeds seem to be the best fitting "technology" for such information.
If every 3rd party package repository had such a feed, it could be aggregated into a single one on
opensuse.org
- From there on, we'd need to have it integrated into YaST2 and enable one-click installation of the
packages that show up (including their dependencies).
That would also involve things as YaST2 prompting "The suser-guru repository is currently not in
your list. Do you want to add it ?", etc etc etc...
But here we're coming back to the discussion on
- - how to aggregate 3rd party package repositories
- - how to define common policies and quality guidelines
- - how to handle security, trust level and QA of those repositories (voting, cross-signing, ...)
- - how to categorize them into stable/unstable/experimental
etc etc etc...
(read the many mails about that thread on this mailing-list)
Personally, I have quite a lot of very palpable ideas on how to implement those processes, and I
hope we'll be able to discuss them all, together (at least for people who have some background on
packaging and maintaining such repositories), once the SUSE staff has some time to spend on it.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
Personally, I have quite a lot of very palpable ideas on how to implement those processes, and I hope we'll be able to discuss them all, together (at least for people who have some background on packaging and maintaining such repositories), once the SUSE staff has some time to spend on it.
I was thinking of a must simpler thing (not to say yours is not good, but it's a Rolls :-) trhat is a wiki page where users can say what they discover (there is a small starting point yet on open suse) like "What do you found new in..." you know the developper is not always the best source to know what a programm is best for. One can often find uses devs never think of :-)) jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote:
Pascal Bleser wrote:
Personally, I have quite a lot of very palpable ideas on how to implement those processes, and I hope we'll be able to discuss them all, together (at least for people who have some background on packaging and maintaining such repositories), once the SUSE staff has some time to spend on it. I was thinking of a must simpler thing (not to say yours is not good, but it's a Rolls :-)
It's not, it's the wheels we need to integrate 3rd party packagers. And that's crucial to improve SUSE Linux' user community. Believe me, it's really not a "rolls". We must find a way to provide those features. Maybe you don't see yet how it will affect/improve the end-user experience with SUSE Linux, but it's one of the major issues.
trhat is a wiki page where users can say what they discover (there is a small starting point yet on open suse) like "What do you found new in..." you know the developper is not always the best source to know what a programm is best for. One can often find uses devs never think of :-))
We're talking about different things then.
BTW, I provide over 500 packages in my repository, with around 100 being active with regular updates.
How do you want to handle that information if it's not automated and provided by the packagers ? ;)
End-users must definately be involved into that process, based on the data that's provided by the
packagers:
- - sending bug reports
- - a simple (web-based (?)) voting system to say whether the package worked for them or not
- - adding comments, user experiences about packages
Personally, I envision opensuse.org as being a big aggregator for all of this.
Future shall tell ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
Believe me, it's really not a "rolls". We must find a way to provide those features. Maybe you don't see yet how it will affect/improve the end-user experience with SUSE Linux, but it's one of the major issues.
I see, but I never make an assumption like "we must" when speaking of others work :-( if we could have developpers do enhanced changelog I would be very pleased, but when I see how difficult it is to make FSH used in packages, I doubt.
BTW, I provide over 500 packages in my repository, with around 100 being active with regular updates. How do you want to handle that information if it's not automated and provided by the packagers
of course. How many users do you think SUSE Linux will have? and many packages have not users interesting updates. a year ago or so I was subscribed to a newsletter from a freshmeat clone (icewalker or so) and received a notice for all packages submitted this day. One notice a day. I stopped receiving this because a mail failure and neglected to resubscribe. I know fresmeat makes something similar. I read some hardware magazines. For each new product, they enphasise on what is new, what is good. It's something like this we need. not too big, for nobody will read it, made by real users, able to say what is really usefull in all the new stuff. more a news paper than a true log.
End-users must definately be involved into that process, based on the data that's provided by the packagers: - - sending bug reports - - a simple (web-based (?)) voting system to say whether the package worked for them or not - - adding comments, user experiences about packages
_this_ is a hole different thing from what I asks for. I want to know "what is worth going from Gimp 1 to Gimp 2" right now I see only problems (different menus layout), because I only try to use the same fonctions again and again, may be missing the real point. (this is only an example, don't answer the question :-)
Personally, I envision opensuse.org as being a big aggregator for all of this. Future shall tell ;)
we need also this jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote:
Pascal Bleser wrote:
Believe me, it's really not a "rolls". We must find a way to provide those features. Maybe you don't see yet how it will affect/improve the end-user experience with SUSE Linux, but it's one of the major issues. I see, but I never make an assumption like "we must" when speaking of others work :-(
- From my experience as a packager, I think I can say that ;)) ...
a year ago or so I was subscribed to a newsletter from a freshmeat clone (icewalker or so) and received a notice for all packages submitted this day. One notice a day. I stopped receiving this because a mail failure and neglected to resubscribe. I know fresmeat makes something similar.
Indeed, freshmeat.net has such information. It's very short and consise, e.g. http://freshmeat.net/projects/iptraf/?branch_id=4549&release_id=207199 "This release includes major changes to the filtering system, including recognition of CIDR notation, additional protocol recognition, and automatic protocol name lookup. Interface support has also been expanded." The good thing with freshmeat.net is that the information is available in a machine-readable format: http://freshmeat.net/projects-xml/iptraf/iptraf.xml?branch_id=4549 Unfortunately, that "change" information does not seem to be included.
I read some hardware magazines. For each new product, they enphasise on what is new, what is good. It's something like this we need. not too big, for nobody will read it, made by real users, able to say what is really usefull in all the new stuff. more a news paper than a true log. ... _this_ is a hole different thing from what I asks for. I want to know "what is worth going from Gimp 1 to Gimp 2" right now I see only problems (different menus layout), because I only try to use the same fonctions again and again, may be missing the real point. (this is only an example, don't answer the question :-)
Ok, now I see what you mean.
Would rather be some kind of "openSUSE newsletter", something similar to what Georg Greve does with
his "brave GNU world": http://www.gnu.org/brave-gnu-world/issue-59.en.html
but about new packages on SUSE Linux, of course.
Would be interesting as a monthly newsletter, written by various members of the openSUSE community,
where anyone could take some time an submit an article like "hey, I found this interesting package"
or "what's new in ...".
Good idea indeed, but we'd need a lot of committed people to do something like that on a regular
basis. As always, it's up to having committed people ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
Pascal Bleser wrote:
basis. As always, it's up to having committed people ;)
in the beginning, a wiki page... jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
On Mon, Sep 19, 2005 at 03:54:01PM +0200, jdd wrote:
Pascal Bleser wrote:
basis. As always, it's up to having committed people ;)
in the beginning, a wiki page...
What is the URL? (No better time then the present) houghi -- Quote correct (NL) http://www.briachons.org/art/quote/ Zitiere richtig (DE) http://www.afaik.de/usenet/faq/zitieren Quote correctly (EN) http://www.netmeister.org/news/learn2quote.html
houghi wrote:
On Mon, Sep 19, 2005 at 03:54:01PM +0200, jdd wrote:
Pascal Bleser wrote:
basis. As always, it's up to having committed people ;) in the beginning, a wiki page...
What is the URL? (No better time then the present)
houghi
this page was probably http://www.opensuse.org/Product_Highlights but it evolved in a slightly different thing (a feature lisy) Could be "breaking news" :-) but I can participate, but not lead such a project (sorry, too busy :-) jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
On 19/09/05, jdd
What is the URL? (No better time then the present)
houghi wrote: this page was probably
http://www.opensuse.org/Product_Highlights
but it evolved in a slightly different thing (a feature lisy)
Could be "breaking news" :-)
but I can participate, but not lead such a project (sorry, too busy :-)
I can invisage a monthly newsletter on the wiki: 1. Summary of recent project events - with submission from attendees to conferences, launches etc 2. Upcoming project developments in the upcoming month 3. General user submissions on any relevant topic 4. openSUSE in the news - which could spawn discussions (has anybody been to the bloggers at ZDnet? Why are they so Anti-openSUSE?) 5. Featured Wiki article - a community selected article that is of outstanding quality. 6. and I nearly forgot, for jdd, a What's new in packages...:-) I would create each monthly newsletter with the name and year in the page name something like: [[openSUSE:Newsletter October 2005]] we could then have a redirect on a page just called [[Newsletter]] to the current month's newsletter. This way we can collaborate on the Newsletter during the month, and come to a consensus, and then on the first of the month, change the redirect, and maybe produce an email version at that point as well, and add brief summary on the front page of openSUSE.org. We would probably also want to lock the wiki newsletter at the point of publishing it. Peter 'Pflodo' Flodin.
Peter Flodin wrote:
I would create each monthly newsletter with the name and year in the page name
may we say "a regular newsletter" and send it as soon as a given length is reached? ob the beginning, this should not be often, but with the time... jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
Hello, Am Montag, 19. September 2005 15:17 schrieb Pascal Bleser:
jdd wrote:
Pascal Bleser wrote: [...] a year ago or so I was subscribed to a newsletter from a freshmeat clone (icewalker or so) and received a notice for all packages submitted this day. One notice a day. I stopped receiving this because a mail failure and neglected to resubscribe. I know fresmeat makes something similar.
Indeed, freshmeat.net has such information. It's very short and consise, e.g. http://freshmeat.net/projects/iptraf/?branch_id=4549&release_id=207199
"This release includes major changes to the filtering system, including recognition of CIDR notation, additional protocol recognition, and automatic protocol name lookup. Interface support has also been expanded."
The good thing with freshmeat.net is that the information is available in a machine-readable format: http://freshmeat.net/projects-xml/iptraf/iptraf.xml?branch_id=4549
Unfortunately, that "change" information does not seem to be included.
Maybe there's another way to get it ;-) Some time ago, I've written a script to split the daily freshmeat newsletter into one file per project. (I planned to do some "negative" filtering (category-based) and read the announcements of the remaining projects, but didn't really do it because of a lack of time.) However, a "positive" filter would be quite easy: just look if one of the projects you maintain as RPM has announced a new version (when using my script, a file with the project name [freshmeat unix name] will appear). It should be quite simple to extract the "changes" block from that file. If you are interested in my script, just ask. They were my first try in programming perl which means that they aren't perfect. But hey, they work ;-) [...]
Would be interesting as a monthly newsletter, written by various members of the openSUSE community, where anyone could take some time an submit an article like "hey, I found this interesting package" or "what's new in ...".
*looking optimistic* Given enough packagers and/or newsletter authors, a monthly newsletter would become too large - make it weekly ;-) Advantages of a more frequent newsletter: - not too large in size - so people really read it ;-) - news are published faster - with a monthly newsletter, they can be 29 days old until they get published... Regards, Christian Boltz -- Die Erde ist ein Würfel, das weiß doch wirklich jeder - und Amerika geht über drei Ecken davon, darum ist dort alles ein bißchen komisch. [Stefan Hundhammer in suse-programming]
On Tue, Sep 20, 2005 at 12:20:32AM +0200, Christian Boltz wrote:
However, a "positive" filter would be quite easy: just look if one of the projects you maintain as RPM has announced a new version (when using my script, a file with the project name [freshmeat unix name] will appear). It should be quite simple to extract the "changes" block from that file.
It could also be a filter to see what programs are not yet on the Repo server. However the most instesting thing is to get the makers of the programs adding their programs. No idea how to achive this. Now idea how Debian does it, but that is something we should look at. Now I do see a lot of programs that do have deb or source, but hardly ever rpm, let alone SUSE rpm's.
If you are interested in my script, just ask. They were my first try in programming perl which means that they aren't perfect. But hey, they work ;-)
The can't be perfect, they are perl scripts. ;-) houghi -- Quote correct (NL) http://www.briachons.org/art/quote/ Zitiere richtig (DE) http://www.afaik.de/usenet/faq/zitieren Quote correctly (EN) http://www.netmeister.org/news/learn2quote.html
Op maandag 19 september 2005 10:33, schreef Clayton:
I know, however (for already having tried to do such things) that it's a very hard work.
I was thinking the same thing would be nice for the apt repositories. So often there is a new build of something showing up in the apt repositories... but no list of the delta/changes between the installed/previous version and the new version. I've never spoke up asking for it because I know that a lot (most) of the stuff I use from apt is user contributions, and I'm grateful it's there... and as you say, it's a lot of hard work to add the delta info (even if you're the developer).
For your information the fresh rpms webpage has been refreshed, it is now framed and the url is: http://linux01.gwdg.de/apt4rpm/freshrpms/ -- Richard Bos Without a home the journey is endless
participants (7)
-
Christian Boltz -
Clayton -
houghi -
jdd -
Pascal Bleser -
Peter Flodin -
Richard Bos