Hi there, what version of GNOME will be integrated into Suse 10.1? Currently there still is 2.12.x in the factory-tree but 2.14 is currently in the final stages of development. Greetings Jens Siebert Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 44,85 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2
Am Dienstag, 28. Februar 2006 12:55 schrieb Jens Siebert:
Hi there,
what version of GNOME will be integrated into Suse 10.1? Currently there still is 2.12.x in the factory-tree but 2.14 is currently in the final stages of development.
Greetings
Jens Siebert
I would guess that, because it hasn't been finalised before 10.1 reached Beta status 2.14 will have to wait for 10.2, or be an unsupported package like 2.12 is with 10.0. Don't forget the SUSE guys have to do a lot of integration work to make sure it works reliably within the framework of SUSE Linux, it isn't just a case of taking the 2.14 source and compiling it and bundling it. There needs to be a lot of internal testing, re-configuration etc. before it would be ready for beta testing, and the beta testing is now on Beta 5, and you can see the problems that throwing the new package manager in at a late stage... If 2.14 doesn't give an overwhelming security reason to upgrade immediately, then it will, I assume, have to wait until it can be safely put into the development production line for 10.2. Forcing it into 10.1 would probably push back the release date unacceptably. Obviously I'm not on the development team, so I can't give an official answer, but that is the logical situation for 12.4... Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On Tue, Feb 28, 2006 at 01:27:03PM +0100, David Wright wrote:
Don't forget the SUSE guys have to do a lot of integration work to make sure it works reliably within the framework of SUSE Linux, it isn't just a case of taking the 2.14 source and compiling it and bundling it. There needs to be a lot of internal testing, re-configuration etc. before it would be ready for beta testing, and the beta testing is now on Beta 5, and you can see the problems that throwing the new package manager in at a late stage...
At a certain moment there is a version freeze. Perhapsd it would be nice to anouce that as well. I believe it was said during FOSDEM when it happens, but I forgot it. As far as I understood, the versions that are in 10.1_B5 will be in the final version as well. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On Tuesday 28 February 2006 13:55, houghi wrote:
At a certain moment there is a version freeze.
Perhaps this date should reevalutated for 10.1. I don't suspect that the current delays due to the packagemanager issues were anticipated at that point. Not only Gnome 2.14 but also KDE 3.5.2 will likely be released before 10.1 the way things are looking. In my opinion it would be worth it, delaying final release a week or two in order to include these. Of course I have very little knowledge of the work that goes into this and organizational problems it might cause. Probably Gnome 2.14 is more of a problem than KDE 3.5.2 since this is only a bugfix-release. SuSE 10.1 could end up appearing "dated" compared to for example Ubuntu 6.04 and FC5. cb400f
On Tue, Feb 28, 2006 at 02:54:00PM +0100, Martin Schlander wrote:
On Tuesday 28 February 2006 13:55, houghi wrote:
At a certain moment there is a version freeze.
Perhaps this date should reevalutated for 10.1.
I don't suspect that the current delays due to the packagemanager issues were anticipated at that point. Not only Gnome 2.14 but also KDE 3.5.2 will likely be released before 10.1 the way things are looking.
In my opinion it would be worth it, delaying final release a week or two in order to include these. Of course I have very little knowledge of the work that goes into this and organizational problems it might cause. Probably Gnome 2.14 is more of a problem than KDE 3.5.2 since this is only a bugfix-release.
Allowing new features now would be a nightmare in itself, so it is very unlikely. Ciao, Marcus
On Tue, Feb 28, 2006 at 02:54:00PM +0100, Martin Schlander wrote:
On Tuesday 28 February 2006 13:55, houghi wrote:
At a certain moment there is a version freeze.
Perhaps this date should reevalutated for 10.1.
I don't suspect that the current delays due to the packagemanager issues were anticipated at that point. Not only Gnome 2.14 but also KDE 3.5.2 will likely be released before 10.1 the way things are looking.
In my opinion it would be worth it, delaying final release a week or two in order to include these. Of course I have very little knowledge of the work that goes into this and organizational problems it might cause. Probably Gnome 2.14 is more of a problem than KDE 3.5.2 since this is only a bugfix-release.
SuSE 10.1 could end up appearing "dated" compared to for example Ubuntu 6.04 and FC5.
There will always be a later whatever with any release. If you wait till mid march (GNOME 2.14 hits the shelves on the 15th of March.) then most likely something else will be worth waiting for. That way you can't release any distro. SUSE sets an aproximate date and whatever is ready at that moment, or close enough will be included. I would also suspect that final release would delay with more then 2 weeks. This does not mean I would mind having it on SUSE. I don't even run Gnome (or KDE) so for me personally there is no loss. :-) houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Am Dienstag, 28. Februar 2006 14:54 schrieb Martin Schlander:
On Tuesday 28 February 2006 13:55, houghi wrote:
At a certain moment there is a version freeze.
Perhaps this date should reevalutated for 10.1.
I don't suspect that the current delays due to the packagemanager issues were anticipated at that point. Not only Gnome 2.14 but also KDE 3.5.2 will likely be released before 10.1 the way things are looking.
In my opinion it would be worth it, delaying final release a week or two in order to include these. Of course I have very little knowledge of the work that goes into this and organizational problems it might cause. Probably Gnome 2.14 is more of a problem than KDE 3.5.2 since this is only a bugfix-release.
The problem is, with something as big as Gnome, it would probably at least a months delay to get everything in and tested - don't forget every Gnome applet has to be installed and thoroughly tested across as many hardware combinations as possible before it can be signed off as working. Plus Gnome itself, ensuring it works with at least gdm and kdm, ensuring KDE still works with gdm, ensuring all the KDE apps still work under Gnome, ensuring the new Gnome apps work under KDE and so forth.
SuSE 10.1 could end up appearing "dated" compared to for example Ubuntu 6.04 and FC5.
The other problem is, by the time the testing on Gnome 2.14 would be complete, somebody else would probably come up with another "must have" upgrade... That is why you have the cut-off date - which is usually pre-beta BTW. Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
houghi <houghi@houghi.org> writes:
On Tue, Feb 28, 2006 at 01:27:03PM +0100, David Wright wrote:
Don't forget the SUSE guys have to do a lot of integration work to make sure it works reliably within the framework of SUSE Linux, it isn't just a case of taking the 2.14 source and compiling it and bundling it. There needs to be a lot of internal testing, re-configuration etc. before it would be ready for beta testing, and the beta testing is now on Beta 5, and you can see the problems that throwing the new package manager in at a late stage...
At a certain moment there is a version freeze. Perhapsd it would be nice to anouce that as well. I believe it was said during FOSDEM when it happens, but I forgot it. As far as I understood, the versions that are in 10.1_B5 will be in the final version as well.
General Version Freeze is with Beta1, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Frank-Michael Fischer <fmfischer@gmx.net> writes:
General Version Freeze is with Beta1,
Andreas
I can't help it, but when will the Version Freeze of the package manager then happen? With 10.2 RC1? ;-)
Should be 10.1 xxx. But with self developed software we have "feature freeze" - so, we increase the version number still but only fix bugs. And yes, this should have happened with Beta1 as it's "feature freeze" as well - and will happen with 10.2 Beta1 again. I'll plan to announce tomorrow the new roadmap, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
General Version Freeze is with Beta1,
As it should be, but then the Beta tree should be branched off Factory, and the latest and greatest versions made available in Factory. (Just IMHO, more details in recent blog entries) -- James Ogley james@usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org
James Ogley <james@usr-local-bin.org> writes:
General Version Freeze is with Beta1,
As it should be, but then the Beta tree should be branched off Factory, and the latest and greatest versions made available in Factory.
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in...
Would it be more likely to happen once the Build Service is up and running, and trusted community packagers are able to contribute to Factory? (i.e. we would be able to contribute to Factory while Novell/SUSE staffers work on the Beta/RC tree) -- James Ogley james@usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org
Hi, On Saturday, March 04, 2006 at 08:54:41, James Ogley wrote:
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in...
Would it be more likely to happen once the Build Service is up and running, and trusted community packagers are able to contribute to Factory?
Get rid of this tree-thinking. Read the build service white paper again or have a look at mls's presentation from FOSDEM. We are not going to have different trees (like core/extras or stable/unstable). Everything will be project based. So your project can be BetaN+Bleeding edge version of project foo. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:
Hi,
On Saturday, March 04, 2006 at 08:54:41, James Ogley wrote:
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in... Would it be more likely to happen once the Build Service is up and running, and trusted community packagers are able to contribute to Factory?
Get rid of this tree-thinking. Read the build service white paper again or have a look at mls's presentation from FOSDEM. We are not going to have different trees (like core/extras or stable/unstable). Everything will be project based. So your project can be BetaN+Bleeding edge version of project foo.
Sure, but we don't know how the repositories will be hosted/assembled yet, do we ? ;) And that's great for experienced users, but for end-users, we should still be able to give them repositories where they can fetch all their stuff from (and not just several repositories per project, which would be far too complex and unmanageable). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFECZVJr3NMWliFcXcRAvVbAKC3iscHN03/e180pw+87sNOeGGlfwCdFxTO b0llsd4BDym5ha2bz5T+URQ= =Tndu -----END PGP SIGNATURE-----
Hi, On Saturday, March 04, 2006 at 14:25:29, Pascal Bleser wrote:
Henne Vogelsang wrote:
On Saturday, March 04, 2006 at 08:54:41, James Ogley wrote:
This would be an option - but currently does not happen since everybody is working on the release tree and therefore nobody puts the latest and greatest in... Would it be more likely to happen once the Build Service is up and running, and trusted community packagers are able to contribute to Factory?
Get rid of this tree-thinking. Read the build service white paper again or have a look at mls's presentation from FOSDEM. We are not going to have different trees (like core/extras or stable/unstable). Everything will be project based. So your project can be BetaN+Bleeding edge version of project foo.
Sure, but we don't know how the repositories will be hosted/assembled yet, do we ? ;)
Well hosting is no problem, its just putting files somewhere ;)
And that's great for experienced users, but for end-users, we should still be able to give them repositories where they can fetch all their stuff from (and not just several repositories per project, which would be far too complex and unmanageable).
Yes. We need to make this project concept fly for end-users. Let me try to explain whats in my mind about this topic. We know a project can consist of packages can be based on other projects. But you can also link packages from other projects to your project. So a project SUSE-unstable could consist of FACTORY + ProjectN bleeding edge packages You would aggregate all things that are bleeding edge to a project which would produce one installation source where people could install from. But that would only be one approach. The better one would be to define such "stamps" (nothing else is a stable/unstable tree concept) on real data. Now we are getting in the realm of the still not even defined trust/rating system. If we do this right then this system brings all data that you need to know for "stamps" like stable/unstable. This would also mean that these stamps function evolutionary and individually. Because stable for pascal means something completely then stable for Henne. So pascal stable could consist of projects with the attributes of * Trusted 99% * Quality 95% * Downloaded more then 100 times * Some other attribute 70% * Some other attribute 50% Of course you could share these "settings" with other users of the build service and they could use pascal's stable settings too. I really think "stamps" like stable/unstable should not be defined by some uberpackager or, god forbid, some committee for everybody. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway
Now we are getting in the realm of the still not even defined trust/rating system. * Trusted 99% * Quality 95% * Downloaded more then 100 times * Some other attribute 70% * Some other attribute 50% Of course you could share these "settings" with other users of the build service and they could use pascal's stable settings too.
Hey, that would be pretty cool, is there any info on when we might see this happen? (Apologies if I've just missed a reference to it) -- James Ogley james@usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org
Hi, On Saturday, March 04, 2006 at 15:06:04, James Ogley wrote:
Now we are getting in the realm of the still not even defined trust/rating system. * Trusted 99% * Quality 95% * Downloaded more then 100 times * Some other attribute 70% * Some other attribute 50% Of course you could share these "settings" with other users of the build service and they could use pascal's stable settings too.
Hey, that would be pretty cool, is there any info on when we might see this happen? (Apologies if I've just missed a reference to it)
Once you and me and all the other peepz that hang around here make it happen! :) We should take this to the opensuse-buildservice mailinglist and discuss it there. Henne -- Henne Vogelsang, http://hennevogel.de "To die. In the rain. Alone." Ernest Hemingway
Am Freitag, 3. März 2006 22:40 schrieb James Ogley:
General Version Freeze is with Beta1,
As it should be, but then the Beta tree should be branched off Factory, and the latest and greatest versions made available in Factory.
(Just IMHO, more details in recent blog entries)
Take a look at the "The Bricks we build with" slide set from the FOSDEM presentation (http://en.opensuse.org/FOSDEM) The slides from page 87 - 92 describe how factory and beta work in conjunction with each other, and it is logical (also slides 28 33 without commentary). If you are putting effort into getting a release stable, you don't want to waste time updating a separate factory stream and trying to get that stable when you should be getting what has been locked off stable enough for release. Breaking Beta out of Factory and letting Factory run on with new versions would cause a lot of headaches and stretch out the Beta process even further - either that or you need to employ more developers to cope with the work load. For those that want to always be on the bleeding edge it can be frustrating, but for the normal user who wants to use/upgrade to a stable environment to do their work in, the current situation is the best compromise. If there is a feature you really can't live without in the new version of a package, there is noting to stop you downloading and compiling the newer version yourself and making it available as an optional package for 10.0 or 10.1 for example. Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On Sat, Mar 04, 2006 at 11:59:53AM +0100, David Wright wrote:
For those that want to always be on the bleeding edge it can be frustrating, but for the normal user who wants to use/upgrade to a stable environment to do their work in, the current situation is the best compromise.
People who want bleeding edge can use Factory, because Beta is replaced with a new version after 1-2 weeks. So your Beta installation is not really bleeding edge. It is on averagae already a week old. Hardly bleeding edge. ;-) houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
People who want bleeding edge can use Factory, because Beta is replaced with a new version after 1-2 weeks. So your Beta installation is not really bleeding edge. It is on averagae already a week old. Hardly bleeding edge. ;-)
Hear hear. As I said there are more details on what I propose in my blog, but for those who don't want to search through it, see: http://rubberturnip.org.uk/index.cgi/2006/02/25 http://rubberturnip.org.uk/index.cgi/2005/09/09 (See also Pascal's comments at http://dev-loki.blogspot.com/2005/09/more-thoughts-on-debian-like-package.ht... ) -- James Ogley james@usr-local-bin.org Packages for SUSE: http://usr-local-bin.org/rpms Make Poverty History: http://makepovertyhistory.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Ogley wrote:
People who want bleeding edge can use Factory, because Beta is replaced with a new version after 1-2 weeks. So your Beta installation is not really bleeding edge. It is on averagae already a week old. Hardly bleeding edge. ;-)
Hear hear.
As I said there are more details on what I propose in my blog, but for those who don't want to search through it, see:
http://rubberturnip.org.uk/index.cgi/2006/02/25 http://rubberturnip.org.uk/index.cgi/2005/09/09
(See also Pascal's comments at http://dev-loki.blogspot.com/2005/09/more-thoughts-on-debian-like-package.ht... )
Note that my comments on this are more in the context of 3rd party package repositories (or whatever the build service will become in terms of repository hosting), not for the "core" distribution (i.e. SUSE Linux) Unfortunately that topic has been drowned during the SUSE 10.0 release preparations and has never been picked up until now, always being "blocked" by the Build Service. Actually the Build Service would give a different approach, as we won't be thinking in terms of distribution trees any more (I guess). Rather, one could pick a branch of every single project that's being managed by the Build Service. Nevertheless, I think we could still end up with stable/unstable/experimental as branches of Build Service projects, for the sake of usability for end-users. Would at least be an idea to explore. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFECZT1r3NMWliFcXcRAtfNAJ0awXvCl9yx6P1AbsmAhCdrgRSvfgCcDDnt LZmB9M5egRcDP8I0g9lb5xY= =ztfa -----END PGP SIGNATURE-----
Am Samstag, 4. März 2006 14:05 schrieb houghi:
On Sat, Mar 04, 2006 at 11:59:53AM +0100, David Wright wrote:
For those that want to always be on the bleeding edge it can be frustrating, but for the normal user who wants to use/upgrade to a stable environment to do their work in, the current situation is the best compromise.
People who want bleeding edge can use Factory, because Beta is replaced with a new version after 1-2 weeks. So your Beta installation is not really bleeding edge. It is on averagae already a week old. Hardly bleeding edge. ;-)
houghi
But that is what James is complaining about, when openSUSE is working on a new release, up to the cut-off for Beta 1, it is bleeding edge, but after that, according to the FOSDEM slides, the Factory is itself "frozen" from new bleeding edge versions to allow the devs to trim the sharp edges off the "bleeding edge" so that it doesn't cut the average user when they install the new version upon release, then Factory reverts to bleeding edge again after the Gold Master has been "cut" for the new release. Dave -- "I got to go figure," the tenant said. "We all got to figure. There's some way to stop this. It's not like lightning or earthquakes. We've got a bad thing made by men, and by God that's something we can change." - The Grapes of Wrath, by John Steinbeck
On 4 Mar 2006 at 14:05, houghi wrote:
On Sat, Mar 04, 2006 at 11:59:53AM +0100, David Wright wrote:
For those that want to always be on the bleeding edge it can be frustrating, but for the normal user who wants to use/upgrade to a stable environment to do their work in, the current situation is the best compromise.
People who want bleeding edge can use Factory, because Beta is replaced with a new version after 1-2 weeks. So your Beta installation is not really bleeding edge. It is on averagae already a week old. Hardly bleeding edge. ;-)
Another thing against bleeding edge: I installed a fresh 10.0 recently wit hKDE, and I found out that the messages are halfway German/English. I would not add a product for release if the translations are so very incomplete as in 10.0's KDE. However, maybe GNOME releases have complete translations, or maybe the latest GNOME release has more complete translations than the older release I don't know... Regards, Ulrich
Am Montag, 6. März 2006 08:53 schrieb Ulrich Windl:
Another thing against bleeding edge: I installed a fresh 10.0 recently wit hKDE, and I found out that the messages are halfway German/English. I would not add a product for release if the translations are so very incomplete as in 10.0's KDE.
What is halfway German/English? If you look at http://l10n.kde.org/stats/gui/stable/de/index.php you will find German KDE is pretty much 100%. So either you spread nonsense or managed to break your installation. Greetings, Stephan
On 6 Mar 2006 at 11:46, Stephan Kulow wrote:
Am Montag, 6. März 2006 08:53 schrieb Ulrich Windl:
Another thing against bleeding edge: I installed a fresh 10.0 recently wit hKDE, and I found out that the messages are halfway German/English. I would not add a product for release if the translations are so very incomplete as in 10.0's KDE.
What is halfway German/English? If you look at http://l10n.kde.org/stats/gui/stable/de/index.php you will find German KDE is pretty much 100%. So either you spread nonsense or managed to break your installation.
So why (just for one example) is the tip of the day in English, while most Applications and the Menus are German? In older Versions, the tips of the day were German as well. I don't know more examples by hand, but I can collect a gallery for you if you wish. Regards, Ulrich
Am Montag, 6. März 2006 13:11 schrieb Ulrich Windl:
So why (just for one example) is the tip of the day in English, while most Applications and the Menus are German? In older Versions, the tips of the day were German as well. I don't know more examples by hand, but I can collect a gallery for you if you wish. It's all german here. It was on 10.0 and it's on 10.1 beta.
Make a little text gallery for me: strace ktip --nofork 2>&1 | grep ktip.mo rpm -qf /opt/kde3/share/locale/de/LC_MESSAGES/ktip.mo rpm -qf /opt/kde3/bin/ktip Greetings, Stephan
On Fri, 2006-03-03 at 21:40 +0000, James Ogley wrote:
General Version Freeze is with Beta1,
As it should be, but then the Beta tree should be branched off Factory, and the latest and greatest versions made available in Factory.
(Just IMHO, more details in recent blog entries)
Sounds like the Debian way of Life(tm) to me ;-) They have three trees (unstable, testing, stable). Works for them so why shouldn't it work out for Suse too? I think it's a great idea... Greetings Jens Siebert
Jens Siebert <jsiebert@arcor.de> writes:
Hi there,
what version of GNOME will be integrated into Suse 10.1? Currently there still is 2.12.x in the factory-tree but 2.14 is currently in the final stages of development.
We will stay with the GNOME 2.12 version. When we started planning, 2.14 would have come out too late for us - and now it's too late to change it, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
participants (12)
-
Andreas Jaeger -
David Wright -
Frank-Michael Fischer -
Henne Vogelsang -
houghi -
James Ogley -
Jens Siebert -
Marcus Meissner -
Martin Schlander -
Pascal Bleser -
Stephan Kulow -
Ulrich Windl