Andreas Vetter writes:

On Tue, 7 Feb 2006, Andreas Jaeger wrote:

...

* the package manager in beta4 will only have reduced functionality

Can you elaborate? Will "yast2 sw_single" be able to add and remove packages and resolve dependencies?

If it does not, I'm not shipping beta4 ;-) It will allow adding and removing of single packages but maybe not adding of a complete "selection". Most of the "filters" you have on the left will not work in beta4 - they will only work again with beta5. Resolving has to work.

...

We're still working on the integration of "libzypp" into our tree and hope to have both update and new installation working.

Together with libzypp, we get the zmd daemon, the rug command line interface, the zen-updater, zen-remover, zen-installer packages. They all handle YUM sources and additionally Zenworks servers as installation sources.

Is there some documentation that explains zen-updater and what to use instead of susewatcher? - and how to ;-)

We'll add infos and pointers to the release notes. If you have anything to add or need, please file a bugreport against the component "Release Notes" of SUSE Linux 10.1, 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

On Tue, Feb 07, 2006 at 10:51:28PM +0100, Christian Boltz wrote:

Could you please post this information (or where we can find it) here? It doesn't need to be a perfect text for now, but it would help to get "familar" with the new applications.

I guess there will be several questions about this in the suse-* mailinglists when 10.1 final is out - it would be very useful if some people already know what has changed and how it works so that they can explain it if somebody asks ;-)

If there are large changes, I think it might be a good idea to have this information available. Not only for the email list, but also for Usenet forums and any other medium. houghi -- "The voters have spoken, the bastards ..."

On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:

new concept/documentation again comes too late.

Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.

Am Mittwoch, 8. Februar 2006 08:28 schrieb Michael 'buk' Scherer:

On Wed, 8 Feb 2006, Silviu Marin-Caea wrote:

...

On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:

...

new concept/documentation again comes too late.

Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.

If its not ready, why does it get 'productive'? You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.

Greetings, Stephan

On Wed, 8 Feb 2006, Robert Schiele wrote:

On Wed, Feb 08, 2006 at 09:26:41AM +0100, Stephan Kulow wrote:

...

You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.

Stephan, I think you are partially right here but partially wrong as well. It is correct that one has to expect things breaking in development or test releases. But nobody explained why this breakage has to be provided intentionally by removing the old method before the new method was in-place at all.

And it is astonishing, that such a change is made after 3 betas. I would expect such a change in beta1 or in the alpha releases. It is always said, that a version update of this and that program can't be done, because it _could_ break other things. On the other side the package manager is changed at that late stage and it is known, that it _will_ break things. Bye, -- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de

Am Mittwoch, 8. Februar 2006 11:16 schrieb Robert Schiele:

On Wed, Feb 08, 2006 at 09:26:41AM +0100, Stephan Kulow wrote:

...

You seem to misunderstand the phrases Beta and FACTORY. If you don't want to take part in testing and reviewing early development phases, I guess you're subscribed to the wrong mailing list.

Stephan, I think you are partially right here but partially wrong as well. It is correct that one has to expect things breaking in development or test releases. But nobody explained why this breakage has to be provided intentionally by removing the old method before the new method was in-place at all. Even when there is a reason for that it should be explained. The problem here was as well that this problem was known to responsible people (they even confessed that it was intentional) but not announced. Instead all people testing from outside SUSE hat to find themselves that the mechanism was broken.

Giving no information about such problems or giving the information very slowly provides the public with a very bad impression on what is going on. Typically I adhere to the saying: "Never attribute to malice what can be adequately explained by stupidity." --- If you don't want people think you are doing stupid things you should give them the chance to understand decissions that are not obviously correct and thus could be considered stupid.

So the whole story here is not about expecting or not expecting bugs in software but about not communicating known bugs and doing questionable decissions without explaining the reasons for the decissions. If you had reasons for the decissions and communicated them at least for the smart people it is likely that they accept them. If you didn't have reasons for the decission but there are known reasons against it the decission was obviously wrong and there is no point in blaming other people not having understood something completely unrelated.

Robert

Agreed, the whole point of a Beta test is to test the product is stable enough for release, so the users who join the Beta program should be searching through the program for areas which don't work properly so they can be tidied up before release... Therefore, they need to know what is new and what is know to have problems, without this information they are wasting their time. OK, Public Beta testing isn't like System Testing or User Testing for a custom application, so the beta testers aren't usually working from a test script to test specific areas, but they need to know what areas to give a specific look at. Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases... David

On Wed, 8 Feb 2006, Marcus Meissner wrote:

We just have to do it due to new SLES 10 requirements.

That's obvious, and that makes it even worse. Having trust in nld/sles which is based on a distribution with such changes is not easy. Bye, -- Andreas Klein Andreas.C.Klein@physik.uni-wuerzburg.de

i think there would be much less bitching if major changes such as this were explained ahead of time instead of after the fact. for example: We are removing subfs because its no longer maintainable and we are replacing it with X, Y, and Z. Please test these replacement subsystems. just my nickels worth :-\ -- michael On Wed, Feb 08, 2006 at 01:48:21PM +0200, Silviu Marin-Caea wrote:

On Wednesday 08 February 2006 13:41, Andreas Klein wrote:

...

On Wed, 8 Feb 2006, Marcus Meissner wrote:

...

We just have to do it due to new SLES 10 requirements.

That's obvious, and that makes it even worse. Having trust in nld/sles which is based on a distribution with such changes is not easy.

Then we would just be so very much more helpful if we don't bitch but rather download the beta4,5,rc1 and test them really well + reports the bugs.

I myself will do just that.

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

On Wed, Feb 08, 2006 at 12:28:54PM +0100, David Wright wrote:

Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases...

Well, for all we know, SUSE might have changed everything in the past up untill the RC 27 or whatever. It is just that now we see it. It would however be nice if we could get some more insight as to why it has been done. I say: if it means improvement, bring it on. I don't see a release date after RC 1 and testing, so I am not sure what preasure there is timewise. Also what has changes could be explained better (perhaps with a HTML file on the Alpha/Beta CD's or some other form) so people know where to look and where NOT to look. OTOH not having any information will let people wander around and the absence of a guideline could bring up bugs that a more structured testing would not show. houghi -- If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

David Wright writes:

[...] Also putting something new in late in the beta phase is not usually a smart thing to do. At this point in the development cycle we should be looking at a system which is relatively stable and the differences between the Beta releases should be bug fixes for what is already there. Major new functionality should be waiting for the internal development and first alpha releases...

Yes, I agree completely to your paragraph - but the package manager did not make the deadline and we really wanted to have it in 10.1, so decided to get it in really late (planned for beta3 but that schedule was not met). I do hope that this kind of major functionality change will not happen in future releases again, 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

Hi, On Wed, 8 Feb 2006, Silviu Marin-Caea wrote:

On Wednesday 08 February 2006 04:18, Eberhard Moenkeberg wrote:

...

new concept/documentation again comes too late.

Maybe because it's not ready, they don't have it. As I understand they're in the process of working out the new functionality. Cannot document it if it's a moving target.

It seems you did not understand my critics. Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)

Op woensdag 8 februari 2006 21:45, schreef Christoph Thiel:

We are not using YUM -- we are using the metadata format that YUM uses as well. Calling those installation repors "YUM sources" might be a bit misleading. Actually they should be called "RPM Metadata" or RepoMD or something like that...

I would vote for repomd as it is metadata for an rpm repository. It is not metadata for an rpm package. -- Richard Bos Without a home the journey is endless

On Thu, 9 Feb 2006, Hans-Peter Jansen wrote:

...

What I don't understand: Why do you want to support YUM now and wanted to drop APT? Everybody I know uses APT instead of YUM, because YUM is very slow, when refreshing package lists e.g. Even most Red Hat/ Fedora users are fed up with YUM...

Do you believe, what you writeh here? Do YOU measured it, or derives your knowledge from others using ancient yum stuff?

Anybody really measured the speed of yum versus apt? I bet, it's approx. en par. After that, please compare the nr. of source code lines ;-)

...

Consider also, that many people switched to apt with 10.0. Is much faster than YaST. Do you want them to switch to Zen-whatever? Will Zen-Updateer be as fast and easy as APT?

Sure, yum is much faster than YaST/YOU here, too, but flexibility in repo mgmt (including self maintained ones), and ease of root strapping are even more valuable in my book..

... but again, we are _not_ using YUM (the tool), but our own implementation to access the same repository format that YUM uses* ;) Regards Christoph *) http://linux.duke.edu/projects/metadata/, with some SUSE-specific extensions.