[opensuse-project] Boxed editions slipping on release dates (3 weeks in some cases)
Starting last night I've begun to see people on both the support
mailinglist and the forums complain they've received an email from the
Novell Shop telling them their pre-ordered boxed editions won't ship
until January 5th.
Does anyone know what's going on? I've seen this happen with previous
versions of openSUSE, but I thought there was something done to correct
the problem. It seems to me people paying $60USD then not receiving
their product until 3 weeks after the free download will think twice
about buying the box again.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
2008/12/18 Kevin Dupuy
Starting last night I've begun to see people on both the support mailinglist and the forums complain they've received an email from the Novell Shop telling them their pre-ordered boxed editions won't ship until January 5th.
It's almost as if there's some sort of holiday between now and January the 5th. -- Benjamin Weber -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 2008-12-18 at 21:13 +0000, Benji Weber wrote:
2008/12/18 Kevin Dupuy
: Starting last night I've begun to see people on both the support mailinglist and the forums complain they've received an email from the Novell Shop telling them their pre-ordered boxed editions won't ship until January 5th.
It's almost as if there's some sort of holiday between now and January the 5th.
Mmm... No. Just checked the calendar. Ground Hog Day doesn't happen until February. :-)
-- Benjamin Weber -- Bryen Yunashko openSUSE Board Member
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 2008-12-18 at 21:13 +0000, Benji Weber wrote:
It's almost as if there's some sort of holiday between now and January the 5th.
Ha ha.
The point is, people have pre-ordered this boxed edition with the
expectation of receiving it at the same time or not too far after the
free public release. This appears to not be happening. What happens if
someone bought the box as a Christmas gift, only now to find out it's
not showing up until 2 weeks after Christmas?
I think all these people would like is an explanation, to the best of
the Project's ability, as to what is going on, and what we are/can do to
help prevent this from happening again.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
On Friday 19 December 2008 03:09:02 Kevin Dupuy wrote:
The point is, people have pre-ordered this boxed edition with the expectation of receiving it at the same time or not too far after the
Who do they expect it? Was it written somewhere/said by someone? I only remember "free shipment if you pre-order" alike. Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 22 December 2008 02:54:42 am Stephan Binner wrote:
On Friday 19 December 2008 03:09:02 Kevin Dupuy wrote:
The point is, people have pre-ordered this boxed edition with the expectation of receiving it at the same time or not too far after the
Who do they expect it? Was it written somewhere/said by someone? I only remember "free shipment if you pre-order" alike.
What is written in contract will not bring paying customer back, if actual action doesn't make him happy. Contract protects company from legal problems, but has no meaning in customer retention. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 22 December 2008 13:25:05 Rajko M. wrote:
What is written in contract will not bring paying customer back, if actual action doesn't make him happy. Contract protects company from legal problems, but has no meaning in customer retention.
What are you talking about? A contract about delivery time? Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 22 December 2008 04:38:19 pm Stephan Binner wrote:
On Monday 22 December 2008 13:25:05 Rajko M. wrote:
What is written in contract will not bring paying customer back, if actual action doesn't make him happy. Contract protects company from legal problems, but has no meaning in customer retention.
What are you talking about? A contract about delivery time?
Relation between buyer and company that delivers goods is kind of contract. Part of that contract is delivery time. You are right, that delivery time is fixed, but many that are asking for reason are not happy because they wanted to have it before holidays, so they can give it as a present, install it, and iron out problems during holidays. Delay spoiled their plans and they would like to know the reasons. IMHO, that is not big deal to wite a sentence that will explain, and quit discussion. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
delivery time is fixed ... delivery time is not fixed ...
-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008 02:42:55 Rajko M. wrote:
that is not big deal to wite a sentence that will explain, and quit
What else than the generic "Please note that due to shipment (Germany -> US), custom etc. and the holiday season openSUSE 11.1 boxes for North America won't be delivered prior to Jan 5th." from the web page do you want to hear? If you want to know something more specific contact "Digital River" or who- ever is handling your shipment. Maybe also someone from some Novell sales department who is in contact with them knows but it's holiday time and that someone is very likely not on this list. To demand an explanation or even "an apology from the openSUSE project" when it's not involved in the box production and even less in its distribution is IMHO kind of odd. Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, 2008-12-22 at 09:54 +0100, Stephan Binner wrote:
On Friday 19 December 2008 03:09:02 Kevin Dupuy wrote:
The point is, people have pre-ordered this boxed edition with the expectation of receiving it at the same time or not too far after the
Who do they expect it? Was it written somewhere/said by someone? I only remember "free shipment if you pre-order" alike.
Bye, Steve
Quoting from the confirmation email I got from Digital River: Product SKU: 662644473598 Product Name: openSUSE 11.1 (Pre-Order) (Pre-Ordered) Anticipated Released Date: December 18, 2008 Qty Ordered: 1 Amount: $59.95 "Anticipated Released Date: December 18, 2008" certainly implies (to me anyway) shipment well in advance of 5 January. I have been buying the boxed edition since 9.0, mostly to encourage SuSE/Novell to keep packaging it this way, since I could obviously just download it or get it from the likes of LinuxCD in France. I don't understand why you can't go to your local Radio Shack and pick up a boxed edition or order it from Amazon. This is how I first discovered SUSE, and the existence of a boxed edition with actual printed manuals was crucial in convincing some of the people I worked for to let me install it on university-owned systems. The subsequent acquisition by Novell also helped, since this was a name they knew. The fact that you can only get it via DR is really crappy marketing, and the delay without explanation or apology, accompanied with snark from SUSE people (as above) piles the s**t even deeper. Buying the box is one of the few ways many of us can contribute to the distro. I'm re-thinking this now since it hasn't made any difference. -- N. B. Day N 39° 28' 25" W 119° 48' 37" 1404 meters up Aurelius up 4 days 18:24, 2 users, load average: 0.00, 0.02, 0.00 2.6.25.18-0.2-default x86_64 GNU/Linux openSUSE 11.0 (X86-64) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
The fact that you can only get it via DR is really crappy marketing, and the delay without explanation or apology, accompanied with snark from SUSE people (as above) piles the s**t even deeper. Buying the box is one of the few ways many of us can contribute to the distro. I'm re-thinking this now since it hasn't made any difference.
I've given up on buying the box set... not out of lack of interest... out of a total lack of ability to get what I want.. the box set in English. I used to live in the NL and getting the English box there was easy - every reseller carried both Dutch and English versions... I bought every release. I have since moved to Germany, and now... I either order and English copy from outside of Germany and pay outrageous shipping costs, or I buy it in Germany... except it's ONLY available in German when you buy it in Germany.... English version is not an option at all resellers, and online stores that I've checked. C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 22 December 2008 18:42:27 Clayton wrote:
except it's ONLY available in German when you buy it in Germany....
You obviously didn't try to buy it at all: suseshop.de, amazon.de, ixsoft and I bet several others all sell the English openSUSE box in Germany. Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
except it's ONLY available in German when you buy it in Germany....
You obviously didn't try to buy it at all: suseshop.de, amazon.de, ixsoft and I bet several others all sell the English openSUSE box in Germany.
OK... now that you said this... I went and looked again... this time searching on opensuse instead of following the front page links. If I search on suseshop.de, I do find English versions. I did not do that last time I looked... I just followed the links through the site and only saw German versions. I stand corrected. C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 22 December 2008 16:38:46 N B Day wrote:
The point is, people have pre-ordered this boxed edition with the expectation of receiving it at the same time or not too far after the Who do they expect it? Was it written somewhere/said by someone? I only Quoting from the confirmation email I got from Digital River:
I doubt that you ordered something in expectation of a certain shipping date mentioned in the order confirmation you received later.
"Anticipated Released Date: December 18, 2008" certainly implies (to me anyway) shipment well in advance of 5 January.
Release date != shipping date != date it arrives at you. If you make up the latter if there is no statement from the merchant (like "will arrive at you before christmas if you order before xx") then do not blame the merchant.
I don't understand why you can't go to your local Radio Shack and pick up a boxed edition or order it from Amazon. This is how I first
There are not enough boxes sold anymore in most countries that it's profitable for merchants. Alternatively Novell would have to pay a likely hugh fee to buy shelf space to get openSUSE boxes placed => not profitable for Novell.
Buying the box is one of the few ways many of us can contribute to the
No, http://en.opensuse.org/How_to_Participate Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, 2008-12-22 at 23:54 +0100, Stephan Binner wrote:
I doubt that you ordered something in expectation of a certain shipping date mentioned in the order confirmation you received later.
In the recent past, boxes have shipped to US addresses very shortly (a day or two at most) after the official release. If this was going to change this time, the "pre-order" process should have made it clear.
"Anticipated Released Date: December 18, 2008" certainly implies (to me anyway) shipment well in advance of 5 January.
Release date != shipping date != date it arrives at you. If you make up the latter if there is no statement from the merchant (like "will arrive at you before christmas if you order before xx") then do not blame the merchant.
Weasly lawyer talk! Boxes in other countries have shipped. Why not in North America? All I'm asking for is some reason why. It is a good product and I'm perfectly content to wait for it; just want to know why there is a delay when it has shipped elsewhere.
I don't understand why you can't go to your local Radio Shack and pick up a boxed edition or order it from Amazon. This is how I first
There are not enough boxes sold anymore in most countries that it's profitable for merchants. Alternatively Novell would have to pay a likely hugh fee to buy shelf space to get openSUSE boxes placed => not profitable for Novell.
Translation: we can't sell boxes because we don't try to sell boxes.
Buying the box is one of the few ways many of us can contribute to the
I've got more money than time, unfortunately. -- N. B. Day N 39° 28' 25" W 119° 48' 37" 1404 meters up Aurelius up 5 days 2:53, 2 users, load average: 0.00, 0.02, 0.00 2.6.25.18-0.2-default x86_64 GNU/Linux openSUSE 11.0 (X86-64) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, 22 Dec 2008 16:03:04 -0800, you wrote:
Translation: we can't sell boxes because we don't try to sell boxes.
No! Translation: We're in the market to make money, not loose it. Novell is a commercial company, not a charity. Philipp -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 02:23 +0100, Philipp Thomas wrote:
On Mon, 22 Dec 2008 16:03:04 -0800, you wrote:
Translation: we can't sell boxes because we don't try to sell boxes.
No! Translation: We're in the market to make money, not loose it. Novell is a commercial company, not a charity.
Precisely! That's the very reason that Novell should make it interesting for clients to buy the box, and buy again next year. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklQSysACgkQtTMYHG2NR9UtrACcD4nHX3jrd54Arc5e1FKISqf0 jdUAnR8Lu9KT/priDxcxFUslqCLnBYQj =kPPI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008 03:21:28 Carlos E. R. wrote:
On Tuesday, 2008-12-23 at 02:23 +0100, Philipp Thomas wrote:
On Mon, 22 Dec 2008 16:03:04 -0800, you wrote:
Translation: we can't sell boxes because we don't try to sell boxes.
No! Translation: We're in the market to make money, not loose it. Novell is a commercial company, not a charity.
Precisely! That's the very reason that Novell should make it interesting for clients to buy the box, and buy again next year.
Unfortunately that's not easy with the way the retail business in the US works. We've been there and learned from it... For openSUSE the retail business is not the top 1 prio - distribution to many people is more important. If we would want to make money with retail, we would need to invest in the retail channel, would need to deliver the free version of openSUSE later or in different packaging as the retail version etc. It did not work out for us... Andreas -- Andreas Jaeger, Director Platform/openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tuesday 23 December 2008 01:03:04 N B Day wrote:
In the recent past, boxes have shipped to US addresses very shortly (a day or two at most) after the official release. If this was going to
This may have happened for 11.0, but IIRC it was not the case for 10.3.
Release date != shipping date != date it arrives at you. If you make up Weasly lawyer talk!
Not lawyer talk - I would call it basic shopping knowledge. :-)
Boxes in other countries have shipped. Why not in North America?
America is not Europe. America is not European Union, ... Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, 2008-12-22 at 23:54 +0100, Stephan Binner wrote:
I doubt that you ordered something in expectation of a certain shipping date mentioned in the order confirmation you received later.
As I said earlier, there is an expectation that paying customers would at least be treated as well as normal users who download the product and receive their package on or near the same date as release.
"Anticipated Released Date: December 18, 2008" certainly implies (to me anyway) shipment well in advance of 5 January.
Release date != shipping date != date it arrives at you. If you make up the latter if there is no statement from the merchant (like "will arrive at you before christmas if you order before xx") then do not blame the merchant.
Release date on December 18th (thurs.), 1-2 day processing, UPS Next Day Air (1-2 days), that's at the latest Christmas Eve delivery (which UPS & other shipping companies do make, it's one of their busiest days). There was no message about shipping being delayed. To Novell's credit there is a message up now, and an apology for those who have already ordered it.
I don't understand why you can't go to your local Radio Shack and pick up a boxed edition or order it from Amazon. This is how I first
There are not enough boxes sold anymore in most countries that it's profitable for merchants. Alternatively Novell would have to pay a likely hugh fee to buy shelf space to get openSUSE boxes placed => not profitable for Novell.
This is an entire other thread in which I agree with N B Day. At the very least, the box should be able to be purchased from other merchants, even online, like Amazon or BustBuy.com. This would improve the experience at least, as those merchants would already have the box in hand and be able to ship it out on time.
Buying the box is one of the few ways many of us can contribute to the No, http://en.opensuse.org/How_to_Participate
Not everyone has the time. I can understand that.
The thing is that we've partly got what we wanted: an explanation from
Novell. For that, I thank them and whoever put that up. What needs to be
done is to figure out how to prevent this in the future: these long wait
times happen for every openSUSE release I've purchased, 10.2, 10.3, and
11.0. If the customs & shipping between the two countries is the
problem, then let's get the pre-orders shipped out early enough to get
them in user's hands by release day or the Friday after.
Actually, speaking of customs & shipping, if that's the major problem,
I've got two openSUSE boxes: SUSE Linux 10.0 and SUSE Linux 10.1 that I
purchased at Best Buy here in the U.S. (the last two boxes to be on
American shelves), that both have a label "Made in USA". The three
latest boxes, openSUSE 10.2, 10.3, 11.0; all say Made in Germany (they
weren't on store shelves, and showed up four weeks after the release).
So there was a manufacturing switch for the North American boxes, and
that's when these problems started.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
On Tuesday 23 December 2008 04:47:12 Kevin Dupuy wrote:
As I said earlier, there is an expectation that paying customers would at least be treated as well as normal users who download the product and receive their package on or near the same date as release.
Nothing can beat the ease and speed of online software distribution :-) - the reason why traditional software retail businesses are declining for years.
At the very least, the box should be able to be purchased from other merchants, even online, like Amazon or BustBuy.com.
I'm pretty sure we had this discussion also with last releases (search the archives?) and iirc there was no wholesaler found for this distribution.
What needs to be done is to figure out how to prevent this in the future
Do you want to suggest to delay public availability to three weeks after GM? Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Moin, first, please calm down. As the product manager of openSUSE I'd like to give some backround information on the retail box in general and give some explanation of the late delivery in North America (see #6) 1) the market for Linux distributions changed heavily over the last 3-5 years in direction of free downloads. Reasons for that are mainly the availability of broad band and the fact that literally all distributions are available for free download. 2) the fact that we started the openSUSE project in summer 2005 with free download from day one combined with the availability of most Linux distributions for free made our retail sales numbers spiralling down 3) Sales numbers in NA became so low that it was tough to get into retail shops anymore, eg. to be in BestBuys on the shelf you need to stuff 600 shops with 5 boxes each and you'll receive after the sales period kind of 50% back as in retail you can get on the shelf only if you give full return right. 4) We need to be realistic. An operating system for a retailer is not as important as digital cameras, music players, game consoles etc. which are purchased by consumers like mad. A Linux OS is a niche product in retail. And in general the software space (beside of games) has dramatically shrunken down in the past years). I visited the other day a retailer in my area and had a chat with a sales guy there. They seized down the software area by 2/3 compared to 2005 and even security software and Windows OS was tough to find. 5) With Sales numbers going down over all, production of boxes in NA became more and more expensive per unit. To stay at least little profitable we do the production meanwhile in Germany. And to keep the retail box available in NA we offer it only through shopNovell as the retail box is not interesting anymore for retailers in NA. At least not for the vast majority. 6) Through production in Germany we had from 10.2 on always a delay between delivery to Germany and EMEA and especially to North America due to air freight, customs, delivery to stock etc. The delay to North America has been always around 5-8 working days. Unfortunately this time we have Christmas + the vacation period - which nobody could have foreseen :-( - which lead to a much longer delay. 7) Beside others Novell's and openSUSE's goal is to increase the distribution of our Linux distribution. As the retail market is an challenging and expensive place to be and the portion of retail has shrunken to less then 5% (and kind of 90% of them are purchased Germany) out of all installations our focus is clearly on the download version. I hope the explanation helps. And sorry for no better news for box lovers. If we'd seen a way to sell again many boxes in a profitable way we definitely would. Our Exec's would love this as with that openSUSE directly could sponsor the openSUSE project. With today's set up my biggest concern is how to get openSUSE into the hands of people living in areas with no or limited broad band access? Those people - and there are many - can't buy a box nor download openSUSE. This is something zonker, Martin and others are working currently on. Best Michl On Tuesday 23 December 2008, Stephan Binner wrote:
On Tuesday 23 December 2008 04:47:12 Kevin Dupuy wrote:
As I said earlier, there is an expectation that paying customers would at least be treated as well as normal users who download the product and receive their package on or near the same date as release.
Nothing can beat the ease and speed of online software distribution :-) - the reason why traditional software retail businesses are declining for years.
At the very least, the box should be able to be purchased from other merchants, even online, like Amazon or BustBuy.com.
I'm pretty sure we had this discussion also with last releases (search the archives?) and iirc there was no wholesaler found for this distribution.
What needs to be done is to figure out how to prevent this in the future
Do you want to suggest to delay public availability to three weeks after GM?
Bye, Steve
-- Michael Löffler, Product Management SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 14:10 +0100, Michael Loeffler wrote: ...
I hope the explanation helps. And sorry for no better news for box lovers. If we'd seen a way to sell again many boxes in a profitable way we definitely would. Our Exec's would love this as with that openSUSE directly could sponsor the openSUSE project.
Some have said they would buy the box if it included the complete admin book. Others would like to buy the book alone. Or you could sell the book with a DVD included - ie, the other way round. Me, I would prefer a delivery of the box a month later than the download - with patches included. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklQ6j8ACgkQtTMYHG2NR9XK0wCfY20HZHz5moq72Xc2zp7kdYGD V1kAni+Vc6y0oJGsq5/N7lCSNUpxbvCr =Cl6R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008, Carlos E. R. wrote:
On Tuesday, 2008-12-23 at 14:10 +0100, Michael Loeffler wrote:
...
I hope the explanation helps. And sorry for no better news for box lovers. If we'd seen a way to sell again many boxes in a profitable way we definitely would. Our Exec's would love this as with that openSUSE directly could sponsor the openSUSE project.
Some have said they would buy the box if it included the complete admin book. Others would like to buy the book alone. Or you could sell the book with a DVD included - ie, the other way round.
Me, I would prefer a delivery of the box a month later than the download - with patches included. Some have said..., Me, I would prefer... Those are expression I slightly struggle as we need many if not the mayority of users to want something and then go an buy a box again. Manuals for example, we asked at least twice in openSUSE surveys (espcially prior to removing the costly printed admin guide) and manuals always were rated last in in the list of "what's important for you".
I'm sure some people would buy a book with the DVD. I just doubt there are enough to make this effort profitable. And don't forget there are already books on the market doing the same concept. And from 11.1 on I guess more will do so as our new licence allow eactly this - write a book about openSUSE, add a openSUSE DVD and publish it. No approval needed. And maybe publishers are better in this as we would be. So let them this market and concentrate on our strength - building a Linux distribution. Best Michl
-- Cheers, Carlos E. R.
-- Michael Löffler, Product Management SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 15:52 +0100, Michael Loeffler wrote:
Some have said they would buy the box if it included the complete admin book. Others would like to buy the book alone. Or you could sell the book with a DVD included - ie, the other way round.
Me, I would prefer a delivery of the box a month later than the download - with patches included. Some have said..., Me, I would prefer... Those are expression I slightly struggle as we need many if not the mayority of users to want something and then go an buy a box again.
Well, I remember an entire thread about that, and even a serious intent to get an independent printer to print it, a year or two ago.
Manuals for example, we asked at least twice in openSUSE surveys (espcially prior to removing the costly printed admin guide) and manuals always were rated last in in the list of "what's important for you".
About the surveys... not everybody even knows they exist. I don't remember that one, for instance. What I know for certain is that the question of the admin book comes now and then in the lists.
I'm sure some people would buy a book with the DVD. I just doubt there are enough to make this effort profitable. And don't forget there are already books on the market doing the same concept.
Your book is very good, IMO.
And from 11.1 on I guess more will do so as our new licence allow eactly this - write a book about openSUSE, add a openSUSE DVD and publish it. No approval needed. And maybe publishers are better in this as we would be.
Could be. There is hope yet >:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklRBZMACgkQtTMYHG2NR9URfQCgjhNypJ4nszrDgqZ2m5U/wG9W zEEAnjyvcSGg9IBQWtZkI3Bmfii4Ox8W =uVuT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On 12/23/2008 at 2:10 PM, Michael Loeffler
wrote: Moin, With today's set up my biggest concern is how to get openSUSE into the hands of people living in areas with no or limited broad band access? Those people - and there are many - can't buy a box nor download openSUSE. This is something zonker, Martin and others are working currently on.
That's actually a very interesting goal. Maybe we (from the richer part) could 'sponsor' shipments to such regions? Maybe in a simple way like: buy a box: it includes - 1 DVD for you - 1 Manual for you - the charity for Novell to send a DVD (maybe not as boxed with booklet and so on) to any region in the world, which is not stuffed as heavily with BroadBand as other regions. Could be an option, no? Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Michael Loeffler a écrit :
With today's set up my biggest concern is how to get openSUSE into the hands of people living in areas with no or limited broad band access? Those people - and there are many - can't buy a box nor download openSUSE. This is something zonker, Martin and others are working currently on.
the way ubuntu do: giving away demo cd (these people often can't read dvd) by mail free order. You could make the order free by surface delivery (cheap) or with some fee for airmail delivery (much more expensive) jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Dec 23, 2008 at 10:10 AM, jdd
the way ubuntu do: giving away demo cd (these people often can't read dvd) by mail free order.
We're working on distributing more demo DVDs, but free mail order as Ubuntu does it is very cost prohibitive. What I'd like to offer very soon is an inexpensive way to order the DVD or live CDs. More on that shortly, I hope. Best, Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Dec 24, 2008 at 1:16 AM, Joe 'Zonker' Brockmeier
We're working on distributing more demo DVDs, but free mail order as Ubuntu does it is very cost prohibitive. What I'd like to offer very soon is an inexpensive way to order the DVD or live CDs. More on that shortly, I hope.
Sell it in a paper sleeve, at costs. Let people pick between the live CDs and the DVDs. Pick the shipping method, quantity and give them a (hopefully small) quote. Even if it does work out at 5-10 dollars, it's not too bad when you consider the fact that they already need the hardware to run it. If I could order a dozen copies for a reasonable prices (I imagine they'd have to be shipped together) I'd be doing right away -- and give them to people with a casual interest in trying Linux. There's something nice about a professionally "printed" CD / sleeve. Regards, Eric Springer -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Eric Springer wrote:
On Wed, Dec 24, 2008 at 1:16 AM, Joe 'Zonker' Brockmeier
wrote: We're working on distributing more demo DVDs, but free mail order as Ubuntu does it is very cost prohibitive. What I'd like to offer very soon is an inexpensive way to order the DVD or live CDs. More on that shortly, I hope.
Sell it in a paper sleeve, at costs. Let people pick between the live CDs and the DVDs. Pick the shipping method, quantity and give them a (hopefully small) quote. Even if it does work out at 5-10 dollars, it's not too bad when you consider the fact that they already need the hardware to run it.
If I could order a dozen copies for a reasonable prices (I imagine they'd have to be shipped together) I'd be doing right away -- and give them to people with a casual interest in trying Linux. There's something nice about a professionally "printed" CD / sleeve.
Regards, Eric Springer
I was just thinking the same thing! Could we add to the "Get" page, an option to order DVD's using Paypal or credit cards? I received dozens of the live 10.3 from that promotion and handed them out like hotcakes, I now have too many people asking for my help. That is a good thing. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, Dec 23, 2008 at 10:44 AM, Eric Springer
We're working on distributing more demo DVDs, but free mail order as Ubuntu does it is very cost prohibitive. What I'd like to offer very soon is an inexpensive way to order the DVD or live CDs. More on that shortly, I hope.
Sell it in a paper sleeve, at costs. Let people pick between the live CDs and the DVDs. Pick the shipping method, quantity and give them a (hopefully small) quote. Even if it does work out at 5-10 dollars, it's not too bad when you consider the fact that they already need the hardware to run it.
You may see something like that... :-)
If I could order a dozen copies for a reasonable prices (I imagine they'd have to be shipped together) I'd be doing right away -- and give them to people with a casual interest in trying Linux. There's something nice about a professionally "printed" CD / sleeve.
Yep. Back in the day, I worked for a now-defunct outfit called LinuxMall.com - we sold the heck out of cheap CDs and I suspect that they contributed greatly to the spread of Linux in the early days before broadband was popular. The boxed sets were the staple of the big distros income stream then, but many people were hesitant to plunk down $30 - $50 for a retail box when they'd never tried Linux... but their next order was often a retail box so they could get the manual. Anyway - thanks for the suggestion. We are looking at a number of ways to spread openSUSE and I expect we'll be doing much more on that front in 2009. Best, Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Joe 'Zonker' Brockmeier a écrit :
Anyway - thanks for the suggestion. We are looking at a number of ways to spread openSUSE and I expect we'll be doing much more on that front in 2009.
don't forget stickers... nearly free advertisement jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 2008-12-23 at 17:58 +0100, jdd wrote:
Joe 'Zonker' Brockmeier a écrit :
Anyway - thanks for the suggestion. We are looking at a number of ways to spread openSUSE and I expect we'll be doing much more on that front in 2009.
don't forget stickers... nearly free advertisement
jdd
-- What do stickers really bring for us in terms of marketing? They're cheap, easy to distribute but I still don't see stickers as being what gets people to try out openSUSE. I think stickers have a greater impact when they're used by wide mainstream people.
Bryen Yunashko openSUSE Board Member
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Bryen a écrit :
What do stickers really bring for us in terms of marketing? They're cheap, easy to distribute but I still don't see stickers as being what gets people to try out openSUSE. I think stickers have a greater impact when they're used by wide mainstream people.
why do you think Msoft sticks its brand on any new computer? The word "Linux" is very well known, now, but is "openSUSE"? making the name known is very important A very important spreading support are magazines (at least in France), but people buy things they know. I have a tux sticker on y laptop, but no openSUSE one (the last I got was the samurai, much too large for my laptop) I would easily buy a sheet fo some € jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mardi 23 décembre 2008, à 11:10 -0600, Bryen a écrit :
What do stickers really bring for us in terms of marketing? They're cheap, easy to distribute but I still don't see stickers as being what gets people to try out openSUSE.
But they help build a strong community: people will just love the openSUSE project more if they have stickers. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008 18:16:30 Joe 'Zonker' Brockmeier wrote:
On Tue, Dec 23, 2008 at 10:10 AM, jdd
wrote: the way ubuntu do: giving away demo cd (these people often can't read dvd) by mail free order.
We're working on distributing more demo DVDs, but free mail order as Ubuntu does it is very cost prohibitive. What I'd like to offer very soon is an inexpensive way to order the DVD or live CDs. More on that shortly, I hope.
My ideal would be a "Distributors/Retailers pack" a box with the manual and maybe 12 to 20 DVDs in sleeves that I could buy in the same way that the "Boxed set" is available now. These would be ideal for the small high street Computer Retailer. Each disk would have it's own key so that the client could register online post-install for a support package, for a price of course. Best Buy and Amazon rarely establish markets, they tend to follow trends. Trends are established by bricks and Mortar operations because they are face to face with the clients. Build slow from grassroots. I agree with the Novell guys, there is no point pushing with volume retailers until there is a volume market. Until then make it easy for small retailers and OEMs to get, distribute and make a profit from the DVDs/Installs. Perhaps the Marketing team needs to come up with a booklet that demonstrates how small retailers can make make a buck from OpenSuSE. I've done the Novell Sales Professional course. Maybe something along those lines aimed at this market. Make no mistake, many small retailers are unsure about OpenSource because they can't see how to make a buck out of it, think about it, the most well known Linux Distro will send you a CD for free, they're not sure how to compete with that. What's our added value proposition then? We make the effort to educate them about why their customers will be willing to pay and thence how to make a profit and we put in place systems that support that, that's our added value.
Best,
Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/
Cheers GL -- Graham Lauder, OpenOffice.org MarCon (Marketing Contact) NZ http://marketing.openoffice.org/contacts.html INGOTs Assessor Trainer (International Grades in Office Technologies) www.theingots.org OOoGear: For the Well dressed OOo Advocate http://ooogear.co.nz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Mon, Dec 22, 2008 at 10:47 PM, Kevin Dupuy
This is an entire other thread in which I agree with N B Day. At the very least, the box should be able to be purchased from other merchants, even online, like Amazon or BustBuy.com. This would improve the experience at least, as those merchants would already have the box in hand and be able to ship it out on time.
Stocking through those merchants is non-trivial. I don't recall offhand the hurdles to Amazon, but I know BestBuy requires some minimum volume and typically there's an expectation of additional fees related to Best Buy's marketing & being on shelves. Best Buy, for example, doesn't just want a cut of the retail price - they want a stocking fee, they want kickbacks for marketing and being in their fliers. To justify the overhead that goes with being on Amazon, in Best Buy and really making a major push to be in a large number of shops, we'd need to have several multiples of the sales we have now. (Sure, there's the "well, you *would* sell several multiples of current sales if you were in those outlets, but experience so far hasn't borne that out since many people are quite happy to download openSUSE without paying for a box at all.) Physical distribution is fairly complicated, and dealing with major outlets like Amazon and Best Buy even more so. Without major sales volume, it's simply not worth the hassle or costs. I wish we could do more in this area, but there are many areas we need to focus on and we have to choose where we can be most effective in terms of distributing openSUSE. I'm really sorry that we've missed the shipping date for purchasers of the openSUSE 11.1 box. Assuming there will be a box, we will try to ensure that the 11.2 retail box doesn't have the same issue. If we don't have a release date that falls between a few major holidays, I think that will help us be more successful. Best, Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 2008-12-23 at 10:14 -0500, Joe 'Zonker' Brockmeier wrote:
I'm really sorry that we've missed the shipping date for purchasers of the openSUSE 11.1 box. Assuming there will be a box, we will try to ensure that the 11.2 retail box doesn't have the same issue. If we don't have a release date that falls between a few major holidays, I think that will help us be more successful.
Thanks, that's all I wanted. I'd just like to say again that a professionally boxed and produced DVD is, in my experience, a great comfort to people who want to try Linux but are skeptical because they've learned from the mass media that Linux comes from weird people with big bushy beards and sandals-with-sox who live in their mother's basement. This is especially true of small business people and academics. Distribution via download only is like preaching to the already converted. If it isn't profitable or convenient to have a boxed release simultaneous with the general release, then why not do a box mid cycle or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out here in the vast emptiness where the phone lines tend to be nailed to the fence-posts who would gladly be six months out of phase if they could have a really solid, bug-free OS. Or, maybe just find some way to market SLED to these folks! -- N. B. Day N 39° 28' 25" W 119° 48' 37" 1404 meters up Aurelius up 5 days 19:06, 2 users, load average: 0.01, 0.01, 0.00 2.6.25.18-0.2-default x86_64 GNU/Linux openSUSE 11.0 (X86-64) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008 17:16:54 N B Day wrote:
or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey). Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/23 Stephan Binner
On Tuesday 23 December 2008 17:16:54 N B Day wrote:
or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey).
Now Stephan that is sad, you must feel like you cannot win. I see these reviews, prob by tech's who write with nostalgia over the sets with the manuals, and good source of info (still usable). So that's provided, and then ppl gripe. Without those type of in depth manuals, I struggle to find a reason to have the media ordered, certainly not for 'stickers'. Yet in old days, I'd subscribe to every release, even those I'd not install, because of the priceless info in updates. I could have downloaded, but I purchased anyway... My experience with 10.3 (lots of buggy drivers in kernel) really puts me off buying media of the initial release. 11.1 is better, and the updates *fingers crossed* in the new year will sort out most of the hardware issues (except for pata_pdc202xx_old) and I think most stuff has workrounds, for the experienced installer. But 11.1 isn't something I'd want to give to friends and relations. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 19:42 +0100, Stephan Binner wrote:
On Tuesday 23 December 2008 17:16:54 N B Day wrote:
or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey).
I had that one, and I missed a note about what was the second dvd for. I simply expected Yast to ask for it, but I never really knew what it was for. How could it be appreciated? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklRevUACgkQtTMYHG2NR9WBtgCgi+7BRAyVWSG2uajlxA+unGy4 KbgAn0d+DkxkQSsCoNZN3Gh+L0ZdUYb0 =ieW5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Mittwoch, 24. Dezember 2008 schrieb Carlos E. R.:
On Tuesday, 2008-12-23 at 19:42 +0100, Stephan Binner wrote:
On Tuesday 23 December 2008 17:16:54 N B Day wrote:
or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey).
I had that one, and I missed a note about what was the second dvd for. I simply expected Yast to ask for it, but I never really knew what it was for. How could it be appreciated?
The box had a in big letters: 16GB of software. And yast would have asked for it, if you installed software only on the second DVD. Seems you didn't. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 13:28 +0100, Stephan Kulow wrote:
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey).
I had that one, and I missed a note about what was the second dvd for. I simply expected Yast to ask for it, but I never really knew what it was for. How could it be appreciated?
The box had a in big letters: 16GB of software.
I saw that. And I liked it on sight.
And yast would have asked for it, if you installed software only on the second DVD. Seems you didn't.
No, I think that Yast simply preferred to download stuff not in the first dvd from the oss/nonoss online repos instead. The DVDs were used during the initial upgrade, but not later. I think, that was over a year ago. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklSOiAACgkQtTMYHG2NR9Vi5QCggxDDgsuFBfADfkfgS5OEGxg0 v4cAn0mdDQ3iH90AwUN/3qbT8D3v/KYj =ShK5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 24 Dec 2008, Stephan Kulow wrote:
Am Mittwoch, 24. Dezember 2008 schrieb Carlos E. R.:
On Tuesday, 2008-12-23 at 19:42 +0100, Stephan Binner wrote:
On Tuesday 23 December 2008 17:16:54 N B Day wrote:
or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out
Same as with admin manual: we had that (iirc 10.3 had a second DVD with full rest of openSUSE repo) and it was not appreciated (reviews, survey).
I had that one, and I missed a note about what was the second dvd for. I simply expected Yast to ask for it, but I never really knew what it was for. How could it be appreciated?
The box had a in big letters: 16GB of software. And yast would have asked for it, if you installed software only on the second DVD. Seems you didn't.
I really loved the 2 DVD's. It really made it easy to install on other
computer's. It was really nice. I loved it. I thought others really
liked it and appreciated it. Thanks for letting us know why it was not
continued.
--
Boyd Gerber
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 08:16 -0800, N B Day wrote:
I'd just like to say again that a professionally boxed and produced DVD is, in my experience, a great comfort to people who want to try Linux but are skeptical because they've learned from the mass media that Linux comes from weird people with big bushy beards and sandals-with-sox who live in their mother's basement. This is especially true of small business people and academics. Distribution via download only is like preaching to the already converted.
True.
If it isn't profitable or convenient to have a boxed release simultaneous with the general release, then why not do a box mid cycle or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out here in the vast emptiness where the phone lines tend to be nailed to the fence-posts who would gladly be six months out of phase if they could have a really solid, bug-free OS. Or, maybe just find some way to market SLED to these folks!
Possibly. I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklRfJQACgkQtTMYHG2NR9UeOACfQe80WGe46B601wROeSEMj85A 2TEAn28aoI+eA+WOwYJES3cOiWUCw4AI =hqMj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 2008-12-24 at 01:04 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2008-12-23 at 08:16 -0800, N B Day wrote:
I'd just like to say again that a professionally boxed and produced DVD is, in my experience, a great comfort to people who want to try Linux but are skeptical because they've learned from the mass media that Linux comes from weird people with big bushy beards and sandals-with-sox who live in their mother's basement. This is especially true of small business people and academics. Distribution via download only is like preaching to the already converted.
True.
If it isn't profitable or convenient to have a boxed release simultaneous with the general release, then why not do a box mid cycle or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories? I know several people out here in the vast emptiness where the phone lines tend to be nailed to the fence-posts who would gladly be six months out of phase if they could have a really solid, bug-free OS. Or, maybe just find some way to market SLED to these folks!
Possibly.
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
- -- Cheers, Carlos E. R.
It does add value to the box, for sure. But how would we ensure consumers know this is the "Less-bug" version? And would there be confusion if a consumer also happens to have the downloaded version from previously? Would we call all such boxed releases 11.1.1 and so on? -- Bryen Yunashko openSUSE Board Member -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 19:05 -0600, Bryen wrote:
On Wed, 2008-12-24 at 01:04 +0100, Carlos E. R. wrote:
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
It does add value to the box, for sure. But how would we ensure consumers know this is the "Less-bug" version?
Dunno. The labeling would be very important.
And would there be confusion if a consumer also happens to have the downloaded version from previously?
Those chaps would know how to know :-)
Would we call all such boxed releases 11.1.1 and so on?
Yep, perhaps. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklRkMwACgkQtTMYHG2NR9Vt1QCgiivHU2Ks1g39usmM55brXZmQ dosAn2PW3PDO/fug+mDo08ffaIQDXLWH =93ih -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 23 December 2008 07:30:45 pm Carlos E. R. wrote:
Would we call all such boxed releases 11.1.1 and so on?
Yep, perhaps.
It would take time for people to get used to idea of 11.1.1 and start using benefits, but that would help a lot everyone that want to install openSUSE on friends computer. Now, you install in 20-30 minutes and then run all updates. With basic broadband it can take some time after half year of bugfixes. After that, you can test that all important stuff actually work, and show new user perks that come in mind. This limits opportunities to present openSUSE to times when you and potential new user have some half day free. It would be much better to have pretty clean installation with few MB of updates, so that all doesn't take more then 1 hour. Combined with professionally printed DVD face and couple of stickers, all in paper pack something like AOL, it will make better impression. To me is much easier to present openSUSE as real goodie, when I bring DVD from box, or better a whole box with manual. People that know that I use something called Linux, usually have no idea what is that, and make assumptions about quality based on package. Home brewed stuff doesn't cut well in that case. BTW, this can be the answer how to organize development. One year cycle with release x.x.0 and then half year after x.x.1 with bugfixes as retail box, or simple DVD, with visit us on http://www.novell.com/products/opensuse/ printed on packaging, and browser that opens on that page, similar to Knoppix. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 2008-12-23 at 22:07 -0600, Rajko M. wrote:
On Tuesday 23 December 2008 07:30:45 pm Carlos E. R. wrote:
Would we call all such boxed releases 11.1.1 and so on?
Yep, perhaps.
It would take time for people to get used to idea of 11.1.1 and start using benefits, but that would help a lot everyone that want to install openSUSE on friends computer.
Now, you install in 20-30 minutes and then run all updates. With basic broadband it can take some time after half year of bugfixes. After that, you can test that all important stuff actually work, and show new user perks that come in mind. This limits opportunities to present openSUSE to times when you and potential new user have some half day free. It would be much better to have pretty clean installation with few MB of updates, so that all doesn't take more then 1 hour.
Combined with professionally printed DVD face and couple of stickers, all in paper pack something like AOL, it will make better impression.
To me is much easier to present openSUSE as real goodie, when I bring DVD from box, or better a whole box with manual. People that know that I use something called Linux, usually have no idea what is that, and make assumptions about quality based on package. Home brewed stuff doesn't cut well in that case.
BTW, this can be the answer how to organize development. One year cycle with release x.x.0 and then half year after x.x.1 with bugfixes as retail box, or simple DVD, with visit us on http://www.novell.com/products/opensuse/ printed on packaging, and browser that opens on that page, similar to Knoppix.
-- Regards, Rajko
I very much like the idea of an openSUSE boxed version with the initial bug fixes included. But there are several things I wonder about: 1) As the x.x.x version is specifically marketed as a perfected version, we're selling an expectation to potential customers. The expectation being that this version really does work and is better than the original version x.x. That means we would have to go through a testing process to ensure the validity of our claim. Because this is specifically designed for situations where money changes hands, we have to back up the marketing claim of the media. How do we do this in a way that doesn't conflict or become a drag on our regular x.x testing process? 2) The obvious goal here is to increase purchases of packaged openSUSE (in whatever format is decided upon.) If we do this, how do we market it? It is already determined that stocking shelves has become cost-prohibitive. There's also the problem that the media may not consider it a big enough story to write about like they do for standard releases. So there's no guarantee that we'll get the publicity we need to boost sales. I do think we should adopt a model that many software companies are adopting in which they leave most sales in the hands of resellers. Community members can be considered as resellers. They can purchase packaged media in bulk at a discount rate and then resell them at whatever venue or face-to-face they choose, and at a price they choose. It has two benefits: 1) Potential resellers are more motivated to push openSUSE to the masses and 2) Potential resellers understand their local markets better than any mass global marketing effort could. (okay, not always) -- Bryen Yunashko openSUSE Board Member -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Dec 24, 2008 at 2:34 PM, Bryen
1) As the x.x.x version is specifically marketed as a perfected version, we're selling an expectation to potential customers. The expectation being that this version really does work and is better than the original version x.x. That means we would have to go through a testing process to ensure the validity of our claim. Because this is specifically designed for situations where money changes hands, we have to back up the marketing claim of the media.
How do we do this in a way that doesn't conflict or become a drag on our regular x.x testing process?
Well, it will be happening 1+ month(s) after the x.x release. And the only changes would be stuff that have been pushed to x.x (which presumably means it has been tested). We're just updating a few packages and rebuilding the image. In fact, I don't see why we can't do this every month -- for downloaded copies too. Why make someone download/get the old version, to only have to update it immediately -- when he have a capable and automated build service. And I must admit, I'm not a big fan of the whole x.x.x naming idea -- it seems too long and unintuitive for users to understand. Why not recycle a bit of terminology from the Windows world, "Service Pack". When it gets to a critical level, we whip up a new image AKA a new "openSUSE x.x service pack x". It'll help people understand that x.x.x is a not a new release compared to x.x, and use the same term Windows users are familiar with.
2) The obvious goal here is to increase purchases of packaged openSUSE (in whatever format is decided upon.) If we do this, how do we market it? It is already determined that stocking shelves has become cost-prohibitive.
Through existing openSUSE fans/users. As I said earlier, I'd personally buy a couple dozen copies (if it's got a nice little paper sleeve, and a nice looking DVD) and hand them out. (Perhaps even ask for the money I paid, if I was feeling particularly cheap).
There's also the problem that the media may not consider it a big enough story to write about like they do for standard releases. So there's no guarantee that we'll get the publicity we need to boost sales.
True, but there are no such guarantees now -- and it's important to not compromise too many good practices in search of short term publicity.
I do think we should adopt a model that many software companies are adopting in which they leave most sales in the hands of resellers. Community members can be considered as resellers. They can purchase packaged media in bulk at a discount rate and then resell them at whatever venue or face-to-face they choose, and at a price they choose.
It has two benefits: 1) Potential resellers are more motivated to push openSUSE to the masses and 2) Potential resellers understand their local markets better than any mass global marketing effort could. (okay, not always)
It's not a bad idea, but it's targeting the wrong people in my opinion. Very few people care about their operating system, or would be willing to change it. And those people will tend to find it on their own. Our advantage is price, and end users have already paid it. They are the wrong market. We should be targeting OEMs, schools, universities and work places. I know of a (not so large) businesses that has budgeted over $100,000 _per year_ towards software licensing (+ the cost of a couple fulltime windows sysadmins). They do nothing that requires any of this crap. I'm sure they'd be happy to pay $100,000 up front for a smooth migration to Linux. That's a 100% return in a year! And something a few Novell staff could manage in a week. The main resistance will come from FUD from existing sysadmins because they don't know how to use Linux and don't want to learn it. I'm sure the case for Universities is no different. And for the life of me, I can't see why OEMs aren't falling over themselves to slash $80+ (depending on the edition of windows) off the prices of their machines. If doing saw causes Windows to start charging them more on the Windows they do sell, I believe it would be a textbook antitrust case. But leave that to the OEMs, we should target them heavily. Let's find out what they want, and lets do it. But I'll stop now, as I've somehow ended up talking Novell business strategy rather than openSUSE. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2008-12-23 at 22:34 -0600, Bryen wrote: ...
I very much like the idea of an openSUSE boxed version with the initial bug fixes included. But there are several things I wonder about:
1) As the x.x.x version is specifically marketed as a perfected version, we're selling an expectation to potential customers. The expectation being that this version really does work and is better than the original version x.x. That means we would have to go through a testing process to ensure the validity of our claim. Because this is specifically designed for situations where money changes hands, we have to back up the marketing claim of the media.
Not really... it is just packaging the versions that are already in the update repo, and thus, are already tested. More tested than factory is. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklSO3UACgkQtTMYHG2NR9U1qwCfbncxnBC0V1d/sVjqnSqgFfb2 5dEAn0YN4weC7c4b22z+rB9uFajYe3kY =kdpT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tue, 2008-12-23 at 22:07 -0600, Rajko M. wrote:
Now, you install in 20-30 minutes and then run all updates. With basic broadband it can take some time after half year of bugfixes.
To be fair, those updates don't take all that long now (nothing like
10.2 and 10.3 when I set a machine to update, went to dinner, when we
got back it was half-way done). Plus, they install in the background,
it's not like we're releasing with major desktop bugs that are extremely
obvious while showing someone openSUSE (at least on the GNOME side,
which I have experience with) As I and others have said, if bugs are the
problem, let's get those fixed *before* the release, right now we're
talking about aiming low.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
2008/12/24 Kevin Dupuy
On Tue, 2008-12-23 at 22:07 -0600, Rajko M. wrote:
Now, you install in 20-30 minutes and then run all updates. With basic broadband it can take some time after half year of bugfixes.
To be fair, those updates don't take all that long now (nothing like 10.2 and 10.3 when I set a machine to update, went to dinner, when we got back it was half-way done). Plus, they install in the background, it's not like we're releasing with major desktop bugs that are extremely obvious while showing someone openSUSE (at least on the GNOME side, which I have experience with)
No it's shipping with bugs that prevent installation, or require time consuming work rounds, possibly even need to open the case. Also there's an issue, because if a release is made in September say, it won't have the latest GNOME release, and in meantime you lose all the extra feedback that could have been obtained on things like the kernel, latest KDE, OpenOffice and lots of other packages that have to be integrated. Not enough ppl will run alpha's and beta's, and some software packages, can be updated later in the cycle without knock on effects, to say server side, or the other desktop environments etc. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, Dec 24, 2008 at 01:04:35AM +0100, Carlos E. R. wrote:
Possibly.
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
Every such snapshot we produce takes valuable time and resources off from development we do. For openSUSE we can do it only once per release. (Ok, in SL10.1 we did a respin, but it was desperately necessary.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release? It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
+1
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
I think this is the nub of the problem. Factory often *is* difficult to test - either un-installable or inconsistent. Maybe if snapshots were taken when it is known to be in a (basically) complete state, with just the last n such snapshots held on a server (unless I misunderstand this, the numbers are low enough that the redirector / mirror structure is not really relevant here). I do try to use factory, mainly via "zypper dup", but it's so painful. For 11.1 I did manage to run all the alphas and betas after alpha0, and on a range of platforms, finding quite a few bugs (some of which were already reported). Of course, on PPC only RC1 was installable - that didn't help much. Happy Christmas / festive greetings / Merry Yule as appropriate to everyone -- Cheers Richard (MQ) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Am Mittwoch, 24. Dezember 2008 schrieb Vincent Untz:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on. Not exactly. Many problems we see are specific to DVD installs, updating to factory won't help you.
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mercredi 24 décembre 2008, à 13:31 +0100, Stephan Kulow a écrit :
Am Mittwoch, 24. Dezember 2008 schrieb Vincent Untz:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on. Not exactly. Many problems we see are specific to DVD installs, updating to factory won't help you.
Ah, this is good to know. Do you mean "specific" as in "related to the installation process or the default configuration"? I guess I'm more focused on other bugs that are different -- I wonder in which category fall the bugs that are really annoying to users... Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 14:31 +0100, Vincent Untz wrote: ...
I guess I'm more focused on other bugs that are different -- I wonder in which category fall the bugs that are really annoying to users...
Depends on which user you ask, and at what moment ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklShewACgkQtTMYHG2NR9VB3QCfcA5tqW5YqJhTuESVn7lqxPE3 MCwAnAtLIU6rM+ByCFBlHEPyrTiR1CyR =8aat -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 12:13 +0100, Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
Yes, that would be ideal, but...
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
...and this is the "but". You will not get that number of testers, IMO. People simply expect "others" to do the testing, few take the plunge and go ahead. You need experienced people to do the testing. Factory is not easy to follow. No, I don't think you can make it much easier. There are problems, difficulties, it can stop working... What problems? Let me see, I'll list mine: - You need a good Internet connection. Factory changes so fast that I have serious difficulties doing a "zypper dup", because it changes before I have time to download. - You need a separate machine so not to disrupt your work. Or you need a separate partition (and remember that the number of partitions is now more limited than they were). There is some danger of what you install in factory partition breaking things in your main partition. - You can end with broken hardware (Intel network!) - You may be affected by bugs that for you are "blockers" but not for others. I was. I have been a month without being able to run factory at all, because it crashed (reiser and beagle problem reborn!). I had things I wanted to test and have been unable to. Not even now. - Testers have to be experienced, so that they can solve some problems on their own. - Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier. - They have to be able to read and write English. Yes, there are testers who don't. - ... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklSOMcACgkQtTMYHG2NR9VshwCaA6IxHc8Bkx5AkuJPtKwI4sp7 q6gAnRUokNgxIS0AQqMd02rJksIN+Q0V =Jc3P -----END PGP SIGNATURE-----
Le mercredi 24 décembre 2008, à 14:27 +0100, Carlos E. R. a écrit :
What problems? Let me see, I'll list mine:
- You need a good Internet connection. Factory changes so fast that I have serious difficulties doing a "zypper dup", because it changes before I have time to download.
That's because of the huge amount of stuff you need to download, while not everything has changed. This is hard to solve, but we can try to solve it.
- You need a separate machine so not to disrupt your work. Or you need a separate partition (and remember that the number of partitions is now more limited than they were). There is some danger of what you install in factory partition breaking things in your main partition.
Indeed, I wouldn't recommend to people to use Factory on their work machine (unless you work on openSUSE). But people can still do this on some other machine, or in a virtual machine, or as you mention, on a separate partition. We won't get as many users as for a stable release, but that should still be enough.
- You can end with broken hardware (Intel network!)
True. How often does this happen, though?
- You may be affected by bugs that for you are "blockers" but not for others. I was. I have been a month without being able to run factory at all, because it crashed (reiser and beagle problem reborn!). I had things I wanted to test and have been unable to. Not even now.
That's the hard thing. I don't have a magic solution here :/
- Testers have to be experienced, so that they can solve some problems on their own.
Is this really an issue? (less testers, but that's still fine since we don't expect to have everybody running Factory)
- Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier.
Chicken and egg problem :-) If you don't get testers earlier, you don't get stability earlier.
- They have to be able to read and write English. Yes, there are testers who don't.
Nod. This would limit the number of testers, but it doesn't mean we can't get more testing. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 14:43 +0100, Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 14:27 +0100, Carlos E. R. a écrit :
What problems? Let me see, I'll list mine:
- You need a good Internet connection. Factory changes so fast that I have serious difficulties doing a "zypper dup", because it changes before I have time to download.
That's because of the huge amount of stuff you need to download, while not everything has changed. This is hard to solve, but we can try to solve it.
This round I had to concentrate on installing the minimum set of packages I can live with. Instead of having both kde and gnome, I installed only gnome. Even so, a "dup" meant about 1 gigabyte. If, when the dup succeeded, I saw I needed a certain extra package, installing it was impossible, as the repo had runaway again. What I think is needed, is the repo not changing for a day or more. If you need to push changes, do so to another repo. I don't know how to do this: perhaps a repo that changes fast, and another that has snapshots taken on certain known days, so that we have some time to install and test.
- You need a separate machine so not to disrupt your work. Or you need a separate partition (and remember that the number of partitions is now more limited than they were). There is some danger of what you install in factory partition breaking things in your main partition.
Indeed, I wouldn't recommend to people to use Factory on their work machine (unless you work on openSUSE). But people can still do this on some other machine, or in a virtual machine, or as you mention, on a separate partition. We won't get as many users as for a stable release, but that should still be enough.
The problem is, every hurdle adds on, so there remain fewer testers that survive. I mentioned partitions. I know some folks that have to repartition their machines because they are over the limit - and this means they will scrap the factory partition.
- You can end with broken hardware (Intel network!)
True. How often does this happen, though?
I know. But it sends chills down my spine, even though my network card is not Intel. Some other hardware may break one year and I'd be affected.
- You may be affected by bugs that for you are "blockers" but not for others. I was. I have been a month without being able to run factory at all, because it crashed (reiser and beagle problem reborn!). I had things I wanted to test and have been unable to. Not even now.
That's the hard thing. I don't have a magic solution here :/
None has. The point is perhaps that this testing round has been too fast, too short.
- Testers have to be experienced, so that they can solve some problems on their own.
Is this really an issue? (less testers, but that's still fine since we don't expect to have everybody running Factory)
Well, it is an issue if you want more testers. Just an idea: what about providing a ready made vmware image, ready for testers to test applications?
- Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier.
Chicken and egg problem :-) If you don't get testers earlier, you don't get stability earlier.
I know. But not having a dedicated machine, I feel that testing earlier is too risky for me.
- They have to be able to read and write English. Yes, there are testers who don't.
Nod. This would limit the number of testers, but it doesn't mean we can't get more testing.
As I said, it is one stone more in the road. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklSg8gACgkQtTMYHG2NR9XBFQCbBsxOOw+G+WQPbpzKCi/n7tXf QqoAnAlKleL+UkZLaiKdFJHCQpMY7ydd =N2EO -----END PGP SIGNATURE-----
Carlos E. R. escribió:
Even so, a "dup" meant about 1 gigabyte. If, when the dup succeeded,
This is because of what Vicent told you, when a single vital component is rebuilt, everything dependent on it is as well, and that is expected and how it should work, however what is not really expected is the bandwidth waste that is produced when that rebuilds produce identical binaries with diffent rpm release numbers...
What I think is needed, is the repo not changing for a day or more. If you need to push changes, do so to another repo.
The process is already complex enough to add yet another step... -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-01-02 at 01:35 -0300, Cristian Rodríguez wrote:
Carlos E. R. escribió:
Even so, a "dup" meant about 1 gigabyte. If, when the dup succeeded,
This is because of what Vicent told you, when a single vital component is rebuilt, everything dependent on it is as well, and that is expected and how it should work, however what is not really expected is the bandwidth waste that is produced when that rebuilds produce identical binaries with diffent rpm release numbers...
I know that, but knowing does not change the problem we on the receiving side have. There is nothing us, on this side, can do.
What I think is needed, is the repo not changing for a day or more. If you need to push changes, do so to another repo.
The process is already complex enough to add yet another step...
Then do something else. Do you want more testers or do you not? If you do, then help us. As it is now, sometimes it takes me weeks to update factory. Then, I start testing whatever I was going to test, I discover I have to install something else; but the repo has again changed, so I have to start again the process, and another week is lost. Instead of testing for bugs, I have to spend my also valuable time attempting to do dups. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklesMMACgkQtTMYHG2NR9VQdQCeMXev7I2OT3GojEYr4zBEro9G bjAAn2fC2y+9P+f9b2FrZu2/WMGGZNaQ =l+4x -----END PGP SIGNATURE-----
Carlos E. R. escribió:
I know that, but knowing does not change the problem we on the receiving side have. There is nothing us, on this side, can do.
AFAIK, this problem is being worked on, in theory, identical binaries with newer rpm release numbers have to be discarded BEFORE they reach testers.. however in practise it is not that easy ;) Just to give you a cruel example, if you build package "very-complex-tool" with the same compiler, same libraries, etc but you just change the actual machine where it is getting build ( aka, build in host1 rather than host2) you may get different binaries.. <:) -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Carlos E. R. escribió:
I know that, but knowing does not change the problem we on the receiving side have. There is nothing us, on this side, can do.
AFAIK, this problem is being worked on, in theory, identical binaries with newer rpm release numbers have to be discarded BEFORE they reach testers.. however in practise it is not that easy ;)
Just to give you a cruel example, if you build package "very-complex-tool" with the same compiler, same libraries, etc but you just change the actual machine where it is getting build ( aka, build in host1 rather than host2) you may get different binaries.. <:)
I know :-( How about deltas? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklfU1gACgkQtTMYHG2NR9UjDACeNUBgklHI4y0I1qjQ6DYDnEkM nSMAnj9nRBjddVp9gyEg3xky10V3bOUy =0Drr -----END PGP SIGNATURE-----
Hello, on Mittwoch, 24. Dezember 2008, Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 14:27 +0100, Carlos E. R. a écrit :
- You need a separate machine so not to disrupt your work. Or you need a separate partition (and remember that the number of partitions is now more limited than they were). There is some danger of what you install in factory partition breaking things in your main partition.
Indeed, I wouldn't recommend to people to use Factory on their work machine (unless you work on openSUSE).
Well, basically I agree, but...
But people can still do this on some other machine, or in a virtual machine, or as you mention, on a separate partition. We won't get as many users as for a stable release, but that should still be enough.
If I would follow this advice, there would be less testing (and bugreports) from me. I usually don't have enough time to do testing in a separate installation separate from my productive work, so my way of betatesting is to "just use" the newest beta or RC. Of couse this method hits in some (fortunately rare) cases, but IMHO it's the best method to do real-life testing *g* But hey, maybe I'm already counted as "working on openSUSE" with 49 bugreports against 11.1 and a total of about 765 against the various SUSE Linux/openSUSE releases since 9.2. (not counting the AIs I entered while IRC meetings) ;-)
- You may be affected by bugs that for you are "blockers" but not for others. I was. I have been a month without being able to run factory at all, because it crashed (reiser and beagle problem reborn!). I had things I wanted to test and have been unable to. Not even now.
That's the hard thing. I don't have a magic solution here :/
My solution is to read the list of most annoying bugs. And not to update if I need to have a working system the next day. Even if the update usually works: You know Murphy?
- Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier.
Chicken and egg problem :-) If you don't get testers earlier, you don't get stability earlier.
I prefer early testing (as in "beta") because this gives me a good chance to have most of "my" bugs fixed in the final release. If you start with RC, you'll have to live with most of "your" bugs until the next release ;-) Regards, Christian Boltz -- My Trash Can is also a shortcut for Amarok... I guess the Amarok team must have had some wild thoughts about the features of their program =) [Benjamin Bach in opensuse] -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Fri, 2008-12-26 at 00:11 +0100, Christian Boltz wrote:
Hello,
<- Snip ->
But hey, maybe I'm already counted as "working on openSUSE" with 49 bugreports against 11.1 and a total of about 765 against the various SUSE Linux/openSUSE releases since 9.2. (not counting the AIs I entered while IRC meetings) ;-)
Damn! I only entered 747 reports with the earliest one being against NLD9 :-) Cheers, Magnus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2008-12-26 at 00:11 +0100, Christian Boltz wrote:
- Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier.
Chicken and egg problem :-) If you don't get testers earlier, you don't get stability earlier.
I prefer early testing (as in "beta") because this gives me a good chance to have most of "my" bugs fixed in the final release. If you start with RC, you'll have to live with most of "your" bugs until the next release ;-)
This round I did that, I tested earlier. And I found I could not even test my pet set of bugs (some several years unsolved), because I found new bugs that impeded me from continuing testing. When I wanted to go and test "my" bugs, I always found a new important bug in the way. I had to test if certain feature survived hibernation? Impossible, hibernation crashed. Wanted to test that feature in Gnome? Impossible, the machine crashes or locks. Even now I can not use 11.1, because it crashes, everytime. (I had a simple bug that made me waste many dozens of hours, arguing it, till IBM came into the fry and turned the table round in a day. Bug solved). No, factory is not for novices. I ended quite tired this round... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklUOm0ACgkQtTMYHG2NR9UEAACdG+J0RVCRlhhov5pGsBMUfyKB 1Q0AnAx21atmpfPc7fZJjnZkn1JZZEIo =/xpn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 Carlos E. R.
- Some testers wait till the RC phase before testing. I myself wait till beta, I don't consider myself hardy enough to test earlier.
It's been pointless waiting for -RC, as there's too little time to get faults found, fixed and into the GM release; that's partly due to release schedule planning. Then there's the lack of quality estimations on calendar based stuff, in Koolo's words some Alpha's are more stable than some RC's. Virtual box testing, is fine for application functionality, but doesn't get kernel hardware driver issues found. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 2008-12-24 at 14:27 +0100, Carlos E. R. wrote:
You need experienced people to do the testing. Factory is not easy to follow. No, I don't think you can make it much easier. There are problems, difficulties, it can stop working...
I'll agree with that. I followed Factory this year (which I usually
don't) to test openSUSE 11.1. Usually, I'll just install the released
Alpha/Beta DVD or CDs and upgrade to specific packages in Factory to
test fixes for bugs.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
2008/12/24 Vincent Untz
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
That's the problem, that alternative release cycle suggestions in other threads, are intended to address.
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
Perhaps it's just very hard to keep a working version, if absolutely everything can be changed and de-stabilised all at once. Rather than using OBS to test a new package's function and integration into a working system. I really hate testing, or developing software on a system with too much up in the air. For instance, the 10.3 release was terrible for me, until about a month after it's first release, because every machine I tried it, had different hardware or driver issues. In some cases, my stability problems, moved, with network card, that I need for example, for 1 gateway box. Later on after a kernel update which contained many fixes, it became possible to focus and isolate, individual problems, and also explain symptoms of some bugs away, as they were no longer reproducible. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
It is attempt to find the way around basic problem how to get more testers involved and have something that is very usable, and needs fewer patches during lifetime. Creating patches is developer time. From openSUSE/Novell perspective there is very small difference between that time used before release, and after, but user experience is very different. Well, here is what I see. Problems in development release that scare 99% of todays users: 1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else) 2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden. 3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode") 4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu, 6) ... Uaesrs need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed. Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now. It is nice to have many new kernel features included, but if that means broken result, what is use of those features? Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows. Then slow down a bit whole process, please. I barely had time to download and install some releases and it already was time for a new one, before I had setup to test with. I don't think that I'm special in this respect. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rajko M. a écrit :
It is attempt to find the way around basic problem how to get more testers
very goos thniking, but best open a new thread. I do, see "organised debugging" with a copy paste of part of this mail thanks jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 jdd
Rajko M. a écrit :
It is attempt to find the way around basic problem how to get more testers
very goos thniking, but best open a new thread. I do, see "organised debugging" with a copy paste of part of this mail
As the purpose of a development release, is testing; it seems to be 100% on topic to me, and belonging in the thread. You run a development release, in order to help test new stuff. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rajko M. wrote:
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
This part of the thread seems to be trying to solve the wrong issue (IMHO). Instead of waiting one month after the release to get patches for major bugs in the release, why not have those bugs identified and fixed before the release?
It is possible. It "only" involves having more people testing Factory. If Factory is difficult to test, then that's the issue we have to focus on.
It is attempt to find the way around basic problem how to get more testers involved and have something that is very usable, and needs fewer patches during lifetime. Creating patches is developer time. From openSUSE/Novell perspective there is very small difference between that time used before release, and after, but user experience is very different.
Well, here is what I see.
Problems in development release that scare 99% of todays users: 1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else) 2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden. 3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode") 4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu, 6) ...
Uaesrs need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed.
Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now.
It is nice to have many new kernel features included, but if that means broken result, what is use of those features?
Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows.
Then slow down a bit whole process, please. I barely had time to download and install some releases and it already was time for a new one, before I had setup to test with. I don't think that I'm special in this respect.
In another thread "release as an add-on" we ended up talking about changing the release cycle to something like 12.0 major revamp and early adopter aka factory = full dvd 12.1 version updates,bug fixes,security = upgrade dvd and\or patch cd 12.2 major bug fixes and security updates = upgrade dvd and\or patch cd 12.3 stable lts version and SLE RC1= full dvd How about we work towards the 3 goals at once. We could do this: 12.0 major revamp and early adopter aka factory = "1-click" upgrade repository or upgrade cd\dvd -no full dvd 12.1 version updates,bug fixes,security = "1-click" upgrade repository or upgrade cd\dvd -no full dvd 12.2 major bug fixes and security updates = dvd or patch cd and "1-click". End all feature changes, spend next nine months on stabilization 12.3 stable lts version and SLE RC1 = full dvd \ Boxed release with 24 months of updates. This reduces time spent on building DVD's , increases openSUSE functionality testing by producing an online upgrade for "bleeding edge" components and produces a Boxed version to give to Grandma or "insert computer illiterate person's name here". What I read with every release is the review that starts " I've been a SuSE fan since (insert 1.0 - 9.3), and I've tried all the releases since Novell bought them, yet I run (insert other distro here) because I have to fix(insert fiddled with component here) to get (insert component name here) running." We need to get the idea out there that, the community aka bleeding edge versions are just that, and that the x.3's are what Novell is considering as SLE replacement's. (Make public references to SLED which could even drive SLED sales) This tells the average "Joe Plumber" that if He downloaded or purchased x.3, He's getting some really well "polished" stuff and he gets 24 months of updates which takes him to the next SLE /_*candidate*_/(never committing to an inevitable SLE status), He says "That is some cool stuff. Enterprise quality software at bargain pricing." This is the kind of reputation Ubuntu is building. example: My brother (MCSE) was so sick of Windows he bought a MAC, he asked me what I would do with his old PC hardware. I said "I would build an openSUSE server for music and videos and put a copy on the laptop too" He decided to try it out. openSUSE 10.3 , would not load on his Toshiba laptop. He installed Ubuntu then called me and said "Hey, I couldn't get that stuff you suggested to boot after install, but, I found this Ubuntu distro and it did. A few weeks later he said, "I wanted more multimedia stuff so I installed Linux Mint, man this Ubuntu stuff is cool. what do you think of MythBuntu?" Imagine my heartbreak. Now I know with a few minutes on the phone I probably could have gotten him running, but, he isn't that weak of a computer guy so He just Googled his way onto Ubuntu. JT -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 James Tremblay aka SLEducator
Rajko M. wrote:
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
We need to get the idea out there that, the community aka bleeding edge versions are just that, and that the x.3's are what Novell is considering as SLE replacement's. (Make public references to SLED which could even drive SLED sales) This tells the average "Joe Plumber" that if He downloaded or purchased x.3, He's getting some really well "polished" stuff and he gets 24 months of updates which takes him to the next SLE /_*candidate*_/(never committing to an inevitable SLE status), He says "That is some cool stuff. Enterprise quality software at bargain pricing."
This is the kind of reputation Ubuntu is building. example: My brother (MCSE) was so sick of Windows he bought a MAC, he asked me what I would do with his old PC hardware. I said "I would build an openSUSE server for music and videos and put a copy on the laptop too" He decided to try it out. openSUSE 10.3 , would not load on his Toshiba laptop. He installed Ubuntu then called me and said "Hey, I couldn't get that stuff you suggested to boot after install, but, I found this Ubuntu distro and it did. A few weeks later he said, "I wanted more multimedia stuff so I installed Linux Mint, man this Ubuntu stuff is cool. what do you think of MythBuntu?" Imagine my heartbreak. Now I know with a few minutes on the phone I probably could have gotten him running, but, he isn't that weak of a computer guy so He just Googled his way onto Ubuntu.
Yep, but someone's made a good suggestion. To have a solid kernel from previous release available as a fall back, for the installer. Then a booting kernel might be available from update, and the older installed kernel could be put on to, as the "Fall back" in that case. Ubuntu has weaknesses, it drove me crazy, but the large user base, means that it attracts spins and software developed for it, making it appear to "just work" for many users. Are ppl installing 8.04.1 (LTS) now, in general I think not, and fit pc who ship with Ubuntu pre-installed move to new release, despite it's shorter support cycle. I don't think ppl will install a release that offers : kernel 3 or 4 versions out of date KDE/GNOME that is 1 or 2 versions out of date I know it's sad, but I just don't think a community distro can spend 9 months doing purely stability and integration testing. Most ppl who run Debian on desktop end up with "unstable", at least from what I've seen at LUGs, because new shiny things, that need newer release are just too hard to resist. Having interim, short term throw away releases, ppl can use online update to leave behind, don't suffer from the staleness factor. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE wrote:
2008/12/24 James Tremblay aka SLEducator
: Rajko M. wrote:
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
We need to get the idea out there that, the community aka bleeding edge versions are just that, and that the x.3's are what Novell is considering as SLE replacement's. (Make public references to SLED which could even drive SLED sales) This tells the average "Joe Plumber" that if He downloaded or purchased x.3, He's getting some really well "polished" stuff and he gets 24 months of updates which takes him to the next SLE /_*candidate*_/(never committing to an inevitable SLE status), He says "That is some cool stuff. Enterprise quality software at bargain pricing."
This is the kind of reputation Ubuntu is building. example: My brother (MCSE) was so sick of Windows he bought a MAC, he asked me what I would do with his old PC hardware. I said "I would build an openSUSE server for music and videos and put a copy on the laptop too" He decided to try it out. openSUSE 10.3 , would not load on his Toshiba laptop. He installed Ubuntu then called me and said "Hey, I couldn't get that stuff you suggested to boot after install, but, I found this Ubuntu distro and it did. A few weeks later he said, "I wanted more multimedia stuff so I installed Linux Mint, man this Ubuntu stuff is cool. what do you think of MythBuntu?" Imagine my heartbreak. Now I know with a few minutes on the phone I probably could have gotten him running, but, he isn't that weak of a computer guy so He just Googled his way onto Ubuntu.
Yep, but someone's made a good suggestion. To have a solid kernel from previous release available as a fall back, for the installer. Then a booting kernel might be available from update, and the older installed kernel could be put on to, as the "Fall back" in that case.
It's not just the Kernel it's application software availability too.
Ubuntu has weaknesses, it drove me crazy, but the large user base, means that it attracts spins and software developed for it, making it appear to "just work" for many users.
Are ppl installing 8.04.1 (LTS) now, in general I think not, and fit pc who ship with Ubuntu pre-installed move to new release, despite it's shorter support cycle.
Can we get download statistics, I am willing to bet this is the gauge that Canonical uses to justify it's LTS version. I use and install SLE because I want it to work. Novell is starting to make money this way, I'm not suggesting we cut into SLE but 24 months vs 5 years is not likely to hurt Novell's SLE sales.
I don't think ppl will install a release that offers :
kernel 3 or 4 versions out of date KDE/GNOME that is 1 or 2 versions out of date
I'm not sure I can agree with discounting a a slightly "stale" release. Specific examples can be seen already, "Joe Plumber" made Microsoft extend the life of XP which was already 7+ _/*years*/_ , not weeks, old. As a test, why not add a release to the 11.0 series after 11.3 called "11 Boxed!" and market it as a test of openSUSE LTS. If it generates a lot of attention then we could start an independent release schedule for the Boxed version and include longterm package availability as a bonus.
I know it's sad, but I just don't think a community distro can spend 9 months doing purely stability and integration testing.
some portion of the community can and should if it wants to achieve market ubiquity.
Most ppl who run Debian on desktop end up with "unstable", at least from what I've seen at LUGs, because new shiny things, that need newer release are just too hard to resist.
LUG's do not include "Joe Plumber"
Having interim, short term throw away releases, ppl can use online update to leave behind, don't suffer from the staleness factor.
This was the point of the "release as an add on", the day after each release, Factory could be added as a repo for those who wish bleeding edge and continued updating. By extending the life of one release via a "Boxed" release, shorter 6 months cycles can be made more acceptable as interim releases AKA community\developer releases. There are ,without a doubt two distinct user types, to date we have been turning a blind eye to the needs of 'Joe Plumber" who wants to install the OS \ configure e-mail\ add gnucash\ add music tools\ bookmark wholesale plumbing parts Web 2.0 sales pages \ bookmark his banks web page and be able to Google the occasional "how to" on some new gadget. He doesn't want to reinstall \ update\ learn to be a bleeding edge software specialist. Basically when this guy comes to me pissed that his XP is yet again corrupted by the latest Malware AKA "the Yoog" search engine hijack - http://www.google.com/support/forum/p/Toolbar/thread?tid=39df7b2e91520c5b&hl=en - discovered this month. I want to install something I'm not going to have to maintain very 6 months or further piss this guy off by having to answer his questions regarding "I heard they made a new release, what was wrong with the old one? Can I trust it? Do we need to upgrade me? How much now?" SLE is a great answer to this problem except for one thing, the 10.1 repo is not online anymore and I can't install GNUCash from the SLE DVD's or other sources. http://forums.opensuse.org/archives/sls-archives/archives-suse-linux/archive... http://forums.opensuse.org/archives/sls-archives/archives-suse-linux/archive... http://packages.opensuse-community.org/index.jsp?searchTerm=gnucash The oldest package here is for 10.2 http://wiki.gnucash.org/wiki/SuSE So I must waste time compiling and if I'm doing it in front of the customer and something goes wrong or takes to long, my customer thinks I'm an idiot and that Linux software is to much of a pain because he could have gotten Quickbooks installed on his own by now. I tried to warn the project of this issue when the discussion to terminate the 10.1 repo was on the table. Basically if we don't build a path for the average guy to either buy SLED and install what he needs throughout it's lifetime(aka maintain the openSUSE equivalent application repo)or use an openSUSE for long enough to feel he gets his money's worth, (because I charge to install and support) he stays on XP or worse wants Ubuntu. The openSUSE project in my mind needs to think about the commercial implications of it's product as much as it's hobbyist's desires. There is a huge gap between Enterprise support and Community usability. We can widen our target just a little. My IBM r51 laptop runs well with 11.0 and it probably will through the whole series, but what if it doesn't. what if 11.1 won't load? What do I do, if I stay on 11.0 and in 1-2 years I decide to re-purpose the laptop from my current use of testing and developing openSIS to just correspondence and billing , will I be able to find the GNUCash package then? Will my admittedly aging 1.5 Ghz laptop be useless even though it runs well and suffers no external damage. This is the target for the ideal that computers need not be obsoleted merely due to software availability or because they offer an older processing platform. What is the processor speed of the Intel Atom, 1.1 and 1.6 Ghz? I would have to say that the market for such a device is widening not narrowing. Building towards the newest hardware isn't in our best interest if we inadvertently disable mainstream hardware and diminish our install base.
2008/12/27 James Tremblay aka SLEducator
Rob OpenSuSE wrote:
2008/12/24 James Tremblay aka SLEducator
: Yep, but someone's made a good suggestion. To have a solid kernel from previous release available as a fall back, for the installer. Then a booting kernel might be available from update, and the older installed kernel could be put on to, as the "Fall back" in that case.
It's not just the Kernel it's application software availability too.
The fall back kernel though, increases chances of a successful install, to get to the point of having updates.
Ubuntu has weaknesses, it drove me crazy, but the large user base, means that it attracts spins and software developed for it, making it appear to "just work" for many users.
Are ppl installing 8.04.1 (LTS) now, in general I think not, and fit pc who ship with Ubuntu pre-installed move to new release, despite it's shorter support cycle.
Can we get download statistics, I am willing to bet this is the gauge that Canonical uses to justify it's LTS version. I use and install SLE because I want it to work. Novell is starting to make money this way,
Rather than download, it's installation usage that would be most meaningful. If you already have 8.04.1 LTS, you won't re-download it
I don't think ppl will install a release that offers :
kernel 3 or 4 versions out of date KDE/GNOME that is 1 or 2 versions out of date
I'm not sure I can agree with discounting a a slightly "stale" release. Specific examples can be seen already, "Joe Plumber" made Microsoft extend the life of XP which was already 7+ _/*years*/_ , not weeks, old.
M$ doesn't have a competitor releasing a Vista, less resource hogging, with more complete drivers and more stable.
There are ,without a doubt two distinct user types, to date we have been turning a blind eye to the needs of 'Joe Plumber" who wants to install the OS \ configure e-mail\ add gnucash\ add music tools\ bookmark wholesale plumbing parts Web 2.0 sales pages \ bookmark his banks web page and be able to Google the occasional "how to" on some new gadget.
Does that sort of user, install an OS at all? Don't they just take what they get on the machine pre-installed?
"I heard they made a new release, what was wrong with the old one? Can I trust it? Do we need to upgrade me?
"Rolling Release" with software packages getting upgraded, keeping most users on same version avoids that issue. In general, a lot of the new Installations of 11.1 have been of the "because it's there" variety, something newer has come out, and folk don't like to be on last years 'model'. Many are upgrading too early and being disappointed, leading to much vocal comment in forum and email lists.
So I must waste time compiling and if I'm doing it in front of the customer and something goes wrong or takes to long, my customer thinks I'm an idiot and that Linux software is to much of a pain because he could have gotten Quickbooks installed on his own by now. I tried to warn the project of this issue when the discussion to terminate the 10.1 repo was on the table.
So SLE does not include all the packages it might, which leads to installing openSUSE rpm's, which later become unsupported?
Basically if we don't build a path for the average guy to either buy SLED and install what he needs throughout it's lifetime(aka maintain the openSUSE equivalent application repo)or use an openSUSE for long enough to feel he gets his money's worth, (because I charge to install and support) he stays on XP or worse wants Ubuntu.
As I understand it, SLE has a subsciption model for even security updates, acting effectively as a rent. Generally such "average guy" have been provided with security updates free of charge, automatically downloaded and installed, yet still too many Windows systems do not get patched. Unsupported SLE systems in such hands might become attractive targets for worms and other malware.
My IBM r51 laptop runs well with 11.0 and it probably will through the whole series, but what if it doesn't. what if 11.1 won't load? What do I do, if I stay on 11.0 and in 1-2 years I decide to re-purpose the laptop from my current use of testing and developing openSIS to just correspondence and billing , will I be able to find the GNUCash package then? Will my admittedly aging 1.5 Ghz laptop be useless even though it runs well and suffers no external damage. This is the target for the ideal that computers need not be obsoleted merely due to software availability or because they offer an older processing platform.
I've installed 11.1-RC1 on machine with dual 450 Mhz CPU (also 1Ghz single only 256MiB RAM), and it runs fine; however without workrounds, it can't boot the install CD. The install CD kernel is the key there, and the drivers configured in it. In a commercial environment, however, I would look to consolidate such a server machine onto newer, faster hardware for reliability and power consumption reasons. Machines like that, won't "just work" if most of the wider alpha & beta release testing is done in Virtual Boxes, and modern laptop and desktop machines. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE wrote:
2008/12/27 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
2008/12/24 James Tremblay aka SLEducator
: Yep, but someone's made a good suggestion. To have a solid kernel from previous release available as a fall back, for the installer. Then a booting kernel might be available from update, and the older installed kernel could be put on to, as the "Fall back" in that case.
It's not just the Kernel it's application software availability too.
The fall back kernel though, increases chances of a successful install, to get to the point of having updates.
agreed and appreciated
Ubuntu has weaknesses, it drove me crazy, but the large user base, means that it attracts spins and software developed for it, making it appear to "just work" for many users.
Are ppl installing 8.04.1 (LTS) now, in general I think not, and fit pc who ship with Ubuntu pre-installed move to new release, despite it's shorter support cycle.
Can we get download statistics, I am willing to bet this is the gauge that Canonical uses to justify it's LTS version. I use and install SLE because I want it to work. Novell is starting to make money this way,
Rather than download, it's installation usage that would be most meaningful. If you already have 8.04.1 LTS, you won't re-download it
Does Canonical have a registration process? Can we get those stats?
I don't think ppl will install a release that offers :
kernel 3 or 4 versions out of date KDE/GNOME that is 1 or 2 versions out of date
I'm not sure I can agree with discounting a a slightly "stale" release. Specific examples can be seen already, "Joe Plumber" made Microsoft extend the life of XP which was already 7+ _/*years*/_ , not weeks, old.
M$ doesn't have a competitor releasing a Vista, less resource hogging, with more complete drivers and more stable.
XP was M$ own competition, the point being "Joe Plumber" wanted new hardware not a new OS. This is traditional reaction from "Joe" , it was the same with w2k when XP was released. In the long run, I still think it's easiest to capture "joe's" heart if he knows he can count on things not changing so quickly.
There are ,without a doubt two distinct user types, to date we have been turning a blind eye to the needs of 'Joe Plumber" who wants to install the OS \ configure e-mail\ add gnucash\ add music tools\ bookmark wholesale plumbing parts Web 2.0 sales pages \ bookmark his banks web page and be able to Google the occasional "how to" on some new gadget.
Does that sort of user, install an OS at all? Don't they just take what they get on the machine pre-installed?
After 7 years of XP , you would be amazed at how many people I have run into that have reinstalled per the vendors request. M$ sells thousands of copies of Vista in a box at Staples,Best Buy, Circuit City, etc.. Who is doing those installs? With the YaST "cloning" utility we could easily add a "user home" backup tool to the clone process and do everything M$ does with it's migration utility. Never mind the fact that by default we put "home" on it's own partition.
"I heard they made a new release, what was wrong with the old one? Can I trust it? Do we need to upgrade me?
"Rolling Release" with software packages getting upgraded, keeping most users on same version avoids that issue. In general, a lot of the new Installations of 11.1 have been of the "because it's there" variety, something newer has come out, and folk don't like to be on last years 'model'. Many are upgrading too early and being disappointed, leading to much vocal comment in forum and email lists.
Players don't like last years model, "Joe" just wants to run his little plumbing business on the most stable,reliable,affordable,expandable computer he can get. "joe" sees stable as not being "reworked", repaired, reinstalled or obsoleted. Joe has what I call "Toaster Syndrome" he wants to plug it in and make toast, never to think about the toaster again not even to clean it. He would even find rolling updates annoying, He wants to think less about the computer and more about the computing he needs make his money. He really does want a boxed set that won't "need" replacing due to expired support. Some Joe's will want the cheaper openSUSE 2 years, some will want the SLE 5-7 years.
So I must waste time compiling and if I'm doing it in front of the customer and something goes wrong or takes to long, my customer thinks I'm an idiot and that Linux software is to much of a pain because he could have gotten Quickbooks installed on his own by now. I tried to warn the project of this issue when the discussion to terminate the 10.1 repo was on the table.
So SLE does not include all the packages it might, which leads to installing openSUSE rpm's, which later become unsupported?
Correct. SLE comes with very little outside the distributed package set. Worse, not to many people care to build RPM's for it either. Even the OBS rarely has RPM's for SLE. The SLE build should not be a choice, it should be a default. GNUCash is in the OBS, but without an SLE package. The OBS should be able to produce, without to much extra attention, an RPM for SLE , No? Yes?
Basically if we don't build a path for the average guy to either buy SLED and install what he needs throughout it's lifetime(aka maintain the openSUSE equivalent application repo)or use an openSUSE for long enough to feel he gets his money's worth, (because I charge to install and support) he stays on XP or worse wants Ubuntu.
As I understand it, SLE has a subsciption model for even security updates, acting effectively as a rent. Generally such "average guy" have been provided with security updates free of charge, automatically downloaded and installed, yet still too many Windows systems do not get patched. Unsupported SLE systems in such hands might become attractive targets for worms and other malware.
Joe may not do his updates or worry about his anti-virus, but, should he have to? We have a setting in the auto update system to update without "interactive" packages. I am assuming this means "go ahead and update unless the package needs a human being to install" ,if not, it should. If we set this as the default and engage the auto-update service on install, we can easily outperform ms updates. leaving us only to eliminate as many of the "interactive" packages as possible. When impossible a nag screen isn't to out of the ordinary. Joe can easily understand and appreciate the need for updates ( 15+ years of M$) he will buy this feature and if the above is true will appreciate the automation.
My IBM r51 laptop runs well with 11.0 and it probably will through the whole series, but what if it doesn't. what if 11.1 won't load? What do I do, if I stay on 11.0 and in 1-2 years I decide to re-purpose the laptop from my current use of testing and developing openSIS to just correspondence and billing , will I be able to find the GNUCash package then? Will my admittedly aging 1.5 Ghz laptop be useless even though it runs well and suffers no external damage. This is the target for the ideal that computers need not be obsoleted merely due to software availability or because they offer an older processing platform.
I've installed 11.1-RC1 on machine with dual 450 Mhz CPU (also 1Ghz single only 256MiB RAM), and it runs fine; however without workrounds, it can't boot the install CD. The install CD kernel is the key there, and the drivers configured in it. In a commercial environment, however, I would look to consolidate such a server machine onto newer, faster hardware for reliability and power consumption reasons.
Machines like that, won't "just work" if most of the wider alpha & beta release testing is done in Virtual Boxes, and modern laptop and desktop machines.
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/28 James Tremblay aka SLEducator
Rob OpenSuSE wrote:
2008/12/27 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
2008/12/24 James Tremblay aka SLEducator
: Rather than download, it's installation usage that would be most meaningful. If you already have 8.04.1 LTS, you won't re-download it
There's an optional survey like Debian, which is the application popularity thing. Of course there's the connections for update, which might give usable stats.
Does that sort of user, install an OS at all? Don't they just take what they get on the machine pre-installed?
After 7 years of XP , you would be amazed at how many people I have run into that have reinstalled per the vendors request. M$ sells thousands of copies of Vista in a box at Staples,Best Buy, Circuit City, etc.. Who is doing those installs?
Firstly often the vendor include a recovery partition, which puts machine back the way it was when delivered. The Vista DVD I received, actually would have been a preferable option, if it had had an easy way to get the vendor driver updates, because it was sans all the Crap-ware, with it's registration nagging, and threats made by software vendors, who seemed to presume non-subscriber was pirate, rather than an evaluator. Secondly, doesn't that undermine somewhat the idea that the users "just want stability". Frankly what I generally see, when I look at Windows machines are ones, un-upgraded hardware, OS same as purchase (or one installed by an 'expert' likely illegitimately), and very frequently without the security updates, despite all the nagging.
"I heard they made a new release, what was wrong with the old one? Can I trust it? Do we need to upgrade me?
"Rolling Release" with software packages getting upgraded, keeping most users on same version avoids that issue.
Doesn't simply having SUSE 12, with 12.0.0, 12.0.1, 12.1.0, 12.1.1, 12.2.1, 12.3.0 all updating themselves live to 12.3.1 (FINAL) avoid that trust problem. The idea of then having 12 (FINAL) being the core base for SLE, which provides solid OS and support for years, makes sense to me; but there's the problem of security updates. Charging for those to non-enterprise Home user types, would probably result in low take up, and unpatched machines, even if an Upgrade to a 13.X Release was possible.
the new Installations of 11.1 have been of the "because it's there" variety, something newer has come out, and folk don't like to be on last years 'model'. Many are upgrading too early and being disappointed, leading to much vocal comment in forum and email lists.
He would even find rolling updates annoying, He wants to think less
Viruses, worms, mal-ware are all annoying; security updates are a must, and probably the default should be to have them installed automatically if they have not been applied within 72 hours. The delay, permits patch updates, or recall in event of it causing trouble of kind, that should be avoided.
So SLE does not include all the packages it might, which leads to installing openSUSE rpm's, which later become unsupported?
Correct. SLE comes with very little outside the distributed package set. Worse, not to many people care to build RPM's for it either. Even the OBS rarely has RPM's for SLE. The SLE build should not be a choice, it should be a default.
Makes sense to me, openSUSE is sponsered by Novell, so I would hope they'd benefit from OBS. There may be a problem if software depends on new libraries however, not sure how they handle that. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE wrote:
2008/12/28 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
2008/12/27 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
2008/12/24 James Tremblay aka SLEducator
: Rather than download, it's installation usage that would be most meaningful. If you already have 8.04.1 LTS, you won't re-download it
There's an optional survey like Debian, which is the application popularity thing. Of course there's the connections for update, which might give usable stats.
Does that sort of user, install an OS at all? Don't they just take what they get on the machine pre-installed?
After 7 years of XP , you would be amazed at how many people I have run into that have reinstalled per the vendors request. M$ sells thousands of copies of Vista in a box at Staples,Best Buy, Circuit City, etc.. Who is doing those installs?
Firstly often the vendor include a recovery partition, which puts machine back the way it was when delivered. The Vista DVD I received, actually would have been a preferable option, if it had had an easy way to get the vendor driver updates, because it was sans all the Crap-ware, with it's registration nagging, and threats made by software vendors, who seemed to presume non-subscriber was pirate, rather than an evaluator.
Secondly, doesn't that undermine somewhat the idea that the users "just want stability". Frankly what I generally see, when I look at Windows machines are ones, un-upgraded hardware, OS same as purchase (or one installed by an 'expert' likely illegitimately), and very frequently without the security updates, despite all the nagging.
Yup, and then they go get the latest "Quickbooks" .
"I heard they made a new release, what was wrong with the old one? Can I trust it? Do we need to upgrade me?
"Rolling Release" with software packages getting upgraded, keeping most users on same version avoids that issue.
Doesn't simply having SUSE 12, with 12.0.0, 12.0.1, 12.1.0, 12.1.1, 12.2.1, 12.3.0 all updating themselves live to 12.3.1 (FINAL) avoid that trust problem.
Would be a good thing if and only if you could guarantee no more broken releases\ sub releases. We both know this is impossible. Otherwise I wouldn't turn the auto update feature on for my customers. I would still rather have the opportunity to buy an "11 Boxed" and know that my customer and I where going to be, from the first moment, on a platform that was the best of the previous 18-24 months work. While being able to count on the ability to get the packages built for that version for longer than the service period of the distro.
The idea of then having 12 (FINAL) being the core base for SLE, which provides solid OS and support for years, makes sense to me; but there's the problem of security updates. Charging for those to non-enterprise Home user types, would probably result in low take up, and unpatched machines, even if an Upgrade to a 13.X Release was possible.
the new Installations of 11.1 have been of the "because it's there" variety, something newer has come out, and folk don't like to be on last years 'model'. Many are upgrading too early and being disappointed, leading to much vocal comment in forum and email lists.
Community members should expect this , there have never been any guarantee's of ubiquitous compatibility and this is definitely a well known fact. I expected that when I moved to 11.1, I would be
as far as I and many others are concerned; http://forums.novell.com/novell-product-support-forums/suse-linux-enterprise... http://forums.novell.com/novell-product-support-forums/suse-linux-enterprise... http://forums.opensuse.org/archives/sls-archives/archives-suse-linux/archive... The 10.1 repository should still be live, for at the very least, to service those of us who have sold the distro to SMB's and home users. Today, If I want to set up a customer with SLED, I had better be able to compile or install anything not on the DVD's from my own collection. How does that help "take up"? The "11 Boxed" idea is that the system has been optimized in preparation for SLE and the applications that are available, be available for installation on i.e. a new machine brought into the office or for SLE when it comes on the new laptop purchased from Lenovo or HP. I get it that SLED is an enterprise version and therefore I am to expect that FF still be in the 2.x versions unless the SP updated it, I am ok with this, but I would like to see the ability to add non-system (aka application) packages. Do these results make sense? http://packages.opensuse-community.org/index.jsp?searchTerm=sled I can sell a $50.00 OS, NO PROBLEM, I just can't sell it if I can't configure it with the same flexibility as when it first came out. troubleshooting. I have done and do this because I care about the future of both Novell and openSUSE. My concern is the missing layer in the current release model of both distro's namely, application package availability over the service lives of both SLE and openSUSE.
He would even find rolling updates annoying, He wants to think less
Viruses, worms, mal-ware are all annoying; security updates are a must, and probably the default should be to have them installed automatically if they have not been applied within 72 hours. The delay, permits patch updates, or recall in event of it causing trouble of kind, that should be avoided.
A really nice Idea and I agree, but it's not really a problem in SLED, updates rarely cause any issue.
So SLE does not include all the packages it might, which leads to installing openSUSE rpm's, which later become unsupported?
Correct. SLE comes with very little outside the distributed package set. Worse, not to many people care to build RPM's for it either. Even the OBS rarely has RPM's for SLE. The SLE build should not be a choice, it should be a default.
Makes sense to me, openSUSE is sponsered by Novell, so I would hope they'd benefit from OBS. There may be a problem if software depends on new libraries however, not sure how they handle that.
-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/1 James Tremblay aka SLEducator
Rob OpenSuSE wrote:
Doesn't simply having SUSE 12, with 12.0.0, 12.0.1, 12.1.0, 12.1.1, 12.2.1, 12.3.0 all updating themselves live to 12.3.1 (FINAL) avoid that trust problem.
Would be a good thing if and only if you could guarantee no more broken releases\ sub releases. We both know this is impossible. Otherwise I wouldn't turn the auto update feature on for my customers.
Rather than get hung up on version numbers, and having large scale changes in every release. I presume releases as they stand now, are going to be broken! 10.3 had almost a year, yet was just as bad as 11.1 for me, and with one very problematic kernel update shortly after initial release. So longer release cycle in my view does nothing to improve release quality. Therefore, I'm presuming it'll always be better to make a stability release 11.1.1 (in effect) which is 11.1 done acceptably right for most users. It sucks if the install ISO's don't get updated, leaving many boxes with boot problems. As many users, who have commented on 11.1 in forum or on the opensuse mail list, as well as "Release Cycle" survey, are asking for more quality, I think some change is desirable. Similarly I'd be happier to buy a box set, if it had decent release notes, and disks that would actually work, and enable getting to the state of the art, rather than a prematurely frozen ISO, which had to be shipped "As Is" thanks to calendar pressures and release politics. Thus I've been making a case for rapid follow up releases, actually the real thing, with what now passes for a main release, being a short term product, that however via online update, will be the "solid" version. As the version numbers for SUSE have long been meaningless, and no indicator of underlying changes to the distro, nor to quality, I'd be happy to have USTS (Ultra-Short-Term-Support) versions given a minor number, rather than the more honestly meaningful, 11.1.0 and 11.1.1. One attractive feature to me, of your first post, was that the "Solid" release, could be tied into SLE with a predictable version number. It would seem desirable to me, for openSUSE to lead into SLE in some manner, with OS 12 and SLE 12 sharing core versions of things. Having releases move via live update in small steps, and switch paths onto the LTS of SLE on subscription model would superficially at least appear attractive. Hopefully now it is clearer the assumptions I've been using, when responding.
Today, If I want to set up a customer with SLED, I had better be able to compile or install anything not on the DVD's from my own collection. How does that help "take up"?
Whilst I'm sympathetic to issues with the reality of supporting SLE in long term (there's a reason I have all the updates from SuSE 8.2 on disk still); I'm not sure it's an issue that openSUSE can solve directly. What I do see, is that focussing on key major versions, which become inputs to SLE, increase the user base for software used by SLE and would hopefully improve quality, and economies of scale and focus would act to relieve that issue. Personally I doubt that, building or finding rpm's that would work, is really difficult initially at least, surely it is the implications of LTS for a huge number of packages, where upstream loses interest, that makes only subsets of repositories feasible. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/1 James Tremblay aka SLEducator
: Rob OpenSuSE wrote:
Rather than get hung up on version numbers, and having large scale changes in every release. I presume releases as they stand now, are going to be broken! 10.3 had almost a year, yet was just as bad as 11.1 for me, and with one very problematic kernel update shortly after initial release. So longer release cycle in my view does nothing to improve release quality.
Therefore, I'm presuming it'll always be better to make a stability release 11.1.1 (in effect) which is 11.1 done acceptably right for most users. It sucks if the install ISO's don't get updated, leaving many boxes with boot problems.
I'm confused , it's sounds to me that you are advocating for all users to remain on the same release platforms\schedule. If they choose to avoid the "dev" levels they would have to know which is which.
As many users, who have commented on 11.1 in forum or on the opensuse mail list, as well as "Release Cycle" survey, are asking for more quality, I think some change is desirable. Similarly I'd be happier to buy a box set, if it had decent release notes, and disks that would actually work, and enable getting to the state of the art, rather than a prematurely frozen ISO, which had to be shipped "As Is" thanks to calendar pressures and release politics.
Thus I've been making a case for rapid follow up releases, actually
the real thing, with what now passes for a main release, being a short term product, that however via online update, will be the "solid" version.
As the version numbers for SUSE have long been meaningless, and no indicator of underlying changes to the distro, nor to quality, I'd be happy to have USTS (Ultra-Short-Term-Support) versions given a minor number, rather than the more honestly meaningful, 11.1.0 and 11.1.1.
One attractive feature to me, of your first post, was that the "Solid" release, could be tied into SLE with a predictable version number. It would seem desirable to me, for openSUSE to lead into SLE in some manner, with OS 12 and SLE 12 sharing core versions of things. Having releases move via live update in small steps, and switch paths onto the LTS of SLE on subscription model would superficially at least appear attractive.
Hopefully now it is clearer the assumptions I've been using, when responding.
Maybe I need to be clearer, If the system was that "11 boxed" (aka SLE 12) and openSUSE12.0 where the same ISO (with branding and repo changes)and If I wanted to test, I could install with the 12 iso which had "factory-update" as a repo , then 12.1 could be an update\add-on\upgrade, the same for 12.2, etc, at whatever schedule. "Factory" could be the "devs" repo and provide 12.0.x, etc , until 12.1. I'm suggesting three layers of community; 1 dev, 1 tester , 1 "Joe Plumber". Joe, doesn't have to think much , he goes straight for "boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us.
Whilst I'm sympathetic to issues with the reality of supporting SLE in long term (there's a reason I have all the updates from SuSE 8.2 on disk still); I'm not sure it's an issue that openSUSE can solve directly.
What I do see, is that focussing on key major versions, which become inputs to SLE, increase the user base for software used by SLE and would hopefully improve quality, and economies of scale and focus would act to relieve that issue.
Personally I doubt that, building or finding rpm's that would work, is really difficult initially at least, surely it is the implications of LTS for a huge number of packages, where upstream loses interest, that makes only subsets of repositories feasible.
if 11 boxed\SLE12\openSUSE 12 shared all the same code, SLE could have GNUCash indefinitely by having the OBS build SLE packages by default and then make them available in a subscription repo like the NLD9 stuff was or at opensuse so that Novell wouldn't have to support them. My idea tries to get the openSUSE\SLE team to work less and produce more. If we remove the need to provide security patches for the "tester" layer , while always working on the next "boxed",every month could be an "upgrade" release to the testers i.e. 12.0.1-12.0.6. They could then spend time adding security updates to the original installation package code for the end of the month upgrade to testers. (eliminate delta patching at the tester level). In the end 12.3.6 or 9 could be optimized for "12 boxed". Boxed and SLE would get the same security updates as long as boxed was live and then SLE could fork. -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/4 James Tremblay aka SLEducator
Rob OpenSuSE wrote:
2009/1/1 James Tremblay aka SLEducator
:
Therefore, I'm presuming it'll always be better to make a stability release 11.1.1 (in effect) which is 11.1 done acceptably right for most users. It sucks if the install ISO's don't get updated, leaving many boxes with boot problems.
I'm confused , it's sounds to me that you are advocating for all users to remain on the same release platforms\schedule. If they choose to avoid the "dev" levels they would have to know which is which.
No, they'd just install OS 11, OS 12, OS 13 whatever. There could be 1 major version increase per year, with an initial version that gets "improved" as projects like KDE & GNOME are integrated. Getting a wider user base for the 'core', than the current alpha & beta releases do.
Maybe I need to be clearer, If the system was that "11 boxed" (aka SLE 12) and openSUSE12.0 where the same ISO (with branding and repo changes)and If I wanted to test, I could install with the 12 iso which had "factory-update" as a repo , then 12.1 could be an update\add-on\upgrade, the same for 12.2, etc, at whatever schedule. "Factory" could be the "devs" repo and provide 12.0.x, etc , until 12.1. I'm suggesting three layers of community; 1 dev, 1 tester , 1 "Joe Plumber". Joe, doesn't have to think much , he goes straight for "boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us.
The problem is that the quality of the current openSUSE release is too poor, it's more a large beta test. Just look around at the issues, with 11.1 that are commonly occuring. So unless there's a change, to implement a strategy to get more feedback earlier, get kernel driver issues sorted, and fixes into upstream codebases, I cannot see how quality will improve. At one time, there was a big quality advantage with Linux distro's, over a widely used commercial OS, right now that just is not there. Things that used to work don't.
if 11 boxed\SLE12\openSUSE 12 shared all the same code, SLE could have GNUCash indefinitely by having the OBS build SLE packages by default and then make them available in a subscription repo like the NLD9 stuff was or at opensuse so that Novell wouldn't have to support them.
What happens when commercial customers, find there GNU Cash version has a security issue, and the upstream don't backport a fix to the version included? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
As a test, why not add a release to the 11.0 series after 11.3 called "11 Boxed!" and market it as a test of openSUSE LTS. If it generates a lot of attention then we could start an independent release schedule for the Boxed version and include longterm package availability as a bonus.
[snip]
There are ,without a doubt two distinct user types, to date we have been turning a blind eye to the needs of 'Joe Plumber" who wants to install the OS \ configure e-mail\ add gnucash\ add music tools\ bookmark wholesale plumbing parts Web 2.0 sales pages \ bookmark his banks web page and be able to Google the occasional "how to" on some new gadget. He doesn't want to reinstall \ update\ learn to be a bleeding edge software specialist.
You're on to something. This is EXACTLY the people who are coming to me and asking about Linux. Once it's installed, and working, they aren't even remotely interested in tinkering like we are (those of us participating on Project, Factory, Users etc). They don't care if they have the bleeding edge versions, and aren't even interested that there is a new version of anything. This user type is totally ignored... even by Ubuntu.. the "everyman's/woman's Linux" as some people call it. A box set aimed directly at this target market is something pretty much every non-computer geek I help out with Linux is actually looking for when they come to me looking for alternatives to Vista. They want something they can install easily (from purchased disks), and then forget about updating to the latest bleeding edge versions. C. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 Rajko M.
On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
Problems in development release that scare 99% of todays users:
1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else)
Do you mean specific advice for Factory? Because there is a Wiki page on what "boot configurations" are known to work reliably eg) small ext2 in primary or logical partition.
2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden.
I like the "No Splash!" idea :) Often an older Live CD will boot, and allow info to be collected, in a pleasant way. Perhaps a special Network Install disk, with logging set up to go to another machine would help testers?
3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode")
Please make a simple obvious way to get to text mode, it may not be something you'ld market, but it'd be help a lot when sleuthing troubles, on forum and such.
4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu,
I filed a Bugzilla on that already (useability). https://bugzilla.novell.com/show_bug.cgi?id=461690 If you'ld care to check it over and add any comments.
6) Uaesrs need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed.
Actually yes; GREAT POINT!!! What is wrong with including the 11.0 kernel on the ISO disk, for the installation, so that it can work, to the point where the ISO's can install an updated kernel from the net. That would reduce the effect of kernel driver regressions.
Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now.
Yes, I like to have kernel, gcc or glibc change, or new application software, but not two of those at same time.
It is nice to have many new kernel features included, but if that means broken result, what is use of those features?
In old SuSE days, it was not unknown to ship with multiple kernel versions eg) 2.0 and 2.2; or 2.2 and 2.4.0 kernel (SuSE 7.1).
Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows.
openSUSE isn't responsible for testing all the packages, thoroughly. Things like gcc, perl, come with a test suite, which aid packagers. Really the distro needs to do configuration and integration testing. There's not much point having 100 ppl, installing X.Y into Virtual Box, and all saying "yes it's fine". Perhaps online update could use a stored hwinfo/smolt profile, to appeal for testers for the new release in a more targetted way; rather than have it installed on clone-like systems.
Then slow down a bit whole process, please. I barely had time to download and install some releases and it already was time for a new one, before I had setup to test with. I don't think that I'm special in this respect.
That's clear, the schedule discussion and feedback in general from 90% of ppl is that 6 months is too short. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 24 December 2008 11:47:27 am Rob OpenSuSE wrote:
2008/12/24 Rajko M.
: On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
Problems in development release that scare 99% of todays users:
1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else)
Do you mean specific advice for Factory? Because there is a Wiki page on what "boot configurations" are known to work reliably eg) small ext2 in primary or logical partition.
I actually meant boot configuration when it is a problem it is a big problem. It is like a black box. One has to know how it works and has to have bootable system to reach files and fix configuration. We should have boot loader tests done before release, that needs wide testing, hits the road. A little of organization among testers would be very helpful. Article on wiki will help to see what kind of configuration is tested, so that new guy don't test same thing again.
2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden.
I like the "No Splash!" idea :)
No splash is just small help to first line helpers on mail lists and forums to skip explanation how to remove splash, and we actually need reports from users that know about booting so little, but can read the screen.
Often an older Live CD will boot, and allow info to be collected, in a pleasant way. Perhaps a special Network Install disk, with logging set up to go to another machine would help testers?
Logging on another machine, floppy, USB stick, existing partition, anything that will survive crash.
3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode")
Please make a simple obvious way to get to text mode, it may not be something you'ld market, but it'd be help a lot when sleuthing troubles, on forum and such.
GUI is important to majority, but it is not advertised at all that it Failsafe GUI exists. I found that out on bugzilla. Since then I haven't stumbled over any other word about it. It is the same GUI used for installation, so it will work. There is not many that can use text mode email client, or web browser, to get help, so anybody that tried openSUSE and couldn't get in GUI is lost for us. Try Google "friendly linux" and second hit is Ubuntu! Guess where those that are disappointed will go.
4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu,
I filed a Bugzilla on that already (useability). https://bugzilla.novell.com/show_bug.cgi?id=461690 If you'ld care to check it over and add any comments.
That is actually how I noticed that. I use that very seldom, and it will take time to notice that is missing, but it should be better visible.
6) Users need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed.
Actually yes; GREAT POINT!!!
What is wrong with including the 11.0 kernel on the ISO disk, for the installation, so that it can work, to the point where the ISO's can install an updated kernel from the net.
That would reduce the effect of kernel driver regressions.
It will. Once upon a time there was more than one version. Hard disks are not that small, and that would be good to have even on kernel update.
Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now.
Yes, I like to have kernel, gcc or glibc change, or new application software, but not two of those at same time.
It is nice to have many new kernel features included, but if that means broken result, what is use of those features?
In old SuSE days, it was not unknown to ship with multiple kernel versions eg) 2.0 and 2.2; or 2.2 and 2.4.0 kernel (SuSE 7.1).
Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows.
openSUSE isn't responsible for testing all the packages, thoroughly. Things like gcc, perl, come with a test suite, which aid packagers. Really the distro needs to do configuration and integration testing.
From new Linux user perspective distro is the one to blame for every misbehavior, and vice versa, distro get all the glory if all is fine, so every bug removed ahead of release makes double points.
There's not much point having 100 ppl, installing X.Y into Virtual Box, and all saying "yes it's fine". Perhaps online update could use a stored hwinfo/smolt profile, to appeal for testers for the new release in a more targetted way; rather than have it installed on clone-like systems.
Smolt project is the beginning.
Then slow down a bit whole process, please. I barely had time to download and install some releases and it already was time for a new one, before I had setup to test with. I don't think that I'm special in this respect.
That's clear, the schedule discussion and feedback in general from 90% of ppl is that 6 months is too short.
-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 Rajko M.
On Wednesday 24 December 2008 11:47:27 am Rob OpenSuSE wrote:
2008/12/24 Rajko M.
: On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :
Do you mean specific advice for Factory? Because there is a Wiki page on what "boot configurations" are known to work reliably eg) small ext2 in primary or logical partition.
I actually meant boot configuration when it is a problem it is a big problem. It is like a black box. One has to know how it works and has to have bootable system to reach files and fix configuration. We should have boot loader tests done before release, that needs wide testing, hits the road. A little of organization among testers would be very helpful. Article on wiki will help to see what kind of configuration is tested, so that new guy don't test same thing again.
http://en.opensuse.org/Bootloader/Scenarios
2) kernel will not boot on certain hardware, how to debug this. Reporting this requires a lot of text to be copied, once you make to the usable configuration. Some simple numeric indicator like line number, or breakpoint number will help much more. It is easy to note on the paper, and easy to post. Splash screen during first phase of development that can have kernel crashes, should be forbidden.
I like the "No Splash!" idea :)
No splash is just small help to first line helpers on mail lists and forums to skip explanation how to remove splash, and we actually need reports from users that know about booting so little, but can read the screen.
Most of my kernel bug reporting, has involved booting certain way, running commands like lspci, or smartctl, may be monitoring tools, and copying log files, and hwinfo output. Very basic CLI, and you need files, not copy and paste (which can easily miss bits off), in order to attach them to the bugzilla report.
Often an older Live CD will boot, and allow info to be collected, in a pleasant way. Perhaps a special Network Install disk, with logging set up to go to another machine would help testers?
Logging on another machine, floppy, USB stick, existing partition, anything that will survive crash.
3) X crashes, and nothing tells that Failsafe option offers a GUI (it should be named "Failsafe Graphic Mode")
Please make a simple obvious way to get to text mode, it may not be something you'ld market, but it'd be help a lot when sleuthing troubles, on forum and such.
GUI is important to majority, but it is not advertised at all that it Failsafe GUI exists. I found that out on bugzilla. Since then I haven't stumbled over any other word about it. It is the same GUI used for installation, so it will work.
I'm not sure what you mean, I think may be a VESA driver mode? Perhaps you have a link that explains it?
There is not many that can use text mode email client, or web browser, to get help, so anybody that tried openSUSE and couldn't get in GUI is lost for us. Try Google "friendly linux" and second hit is Ubuntu! Guess where those that are disappointed will go.
Oh the kind of kernel problem you're thinking of is worse under Ubuntu, as without run levels, it's not non-graphical but single user mode, and start up the networking yourself via command.
4) will not log in default desktop, or desktop crashes, but alternative to change desktop is in the login screen at the bottom left corner, but how many will click on barely visible text (kdm). This is good for release. Please make life of a tester easier, and provide list, not drop down menu,
I filed a Bugzilla on that already (useability). https://bugzilla.novell.com/show_bug.cgi?id=461690 If you'ld care to check it over and add any comments.
That is actually how I noticed that. I use that very seldom, and it will take time to notice that is missing, but it should be better visible.
Heheheh, glad to know someone reads the things :) It must have had a good title to interest you!
6) Users need fallback options to usable alternatives, example is what Knoppix and derivatives offer on a boot screen. Press function key and get list of cheat codes, or other kernels that can be used to boot a system. Later, when all seems to work OK, that can be removed.
Actually yes; GREAT POINT!!!
What is wrong with including the 11.0 kernel on the ISO disk, for the installation, so that it can work, to the point where the ISO's can install an updated kernel from the net.
That would reduce the effect of kernel driver regressions.
It will. Once upon a time there was more than one version. Hard disks are not that small, and that would be good to have even on kernel update.
Yes, actually I make sure I "rpm -i" an alternative fallback kernel on any install I've put some effort into and plan to use, as I've been bitten by kernel update failures too many times.
Development should be focused as much as it is possible. Today we test new kernel, tomorrow X, or libc, or whatever, and so on. Having to debug interaction between change in libc and the rest of the system can mean a lot of work, but it is easier then what we have now.
Yes, I like to have kernel, gcc or glibc change, or new application software, but not two of those at same time.
It is nice to have many new kernel features included, but if that means broken result, what is use of those features?
In old SuSE days, it was not unknown to ship with multiple kernel versions eg) 2.0 and 2.2; or 2.2 and 2.4.0 kernel (SuSE 7.1).
Probably some testing of skills provided by openSUSE will help to get a picture what can be tested by community and what methods and tools have to be provided as a help. Reliance on unknown number of testers, with unknown skills will not move us from current status where number of hidden errors grows.
openSUSE isn't responsible for testing all the packages, thoroughly. Things like gcc, perl, come with a test suite, which aid packagers. Really the distro needs to do configuration and integration testing.
From new Linux user perspective distro is the one to blame for every misbehavior, and vice versa, distro get all the glory if all is fine, so every bug removed ahead of release makes double points.
I don't think that'll be practical. A strategy is needed to get more experienced ppl, to migrate and help shake down releases before they reach the masses. How to do it, without some promise of a "Rolling Update", nobody likes re-installing their important machines, nor risking Distro upgrade. The sheer number of problem posts, in the forums Thurs, Fri and Sat were overwhelming, pages and pages.
There's not much point having 100 ppl, installing X.Y into Virtual Box, and all saying "yes it's fine". Perhaps online update could use a stored hwinfo/smolt profile, to appeal for testers for the new release in a more targetted way; rather than have it installed on clone-like systems.
Smolt project is the beginning.
Using it is the thing, and getting feedback out to ppl who might help, if they knew that testing their PCI card would make a real difference. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 24 December 2008 03:17:55 pm Rob OpenSuSE wrote:
2008/12/24 Rajko M.
: ... http://en.opensuse.org/Bootloader/Scenarios
Thanks. ...
GUI is important to majority, but it is not advertised at all that it Failsafe GUI exists. I found that out on bugzilla. Since then I haven't stumbled over any other word about it. It is the same GUI used for installation, so it will work.
I'm not sure what you mean, I think may be a VESA driver mode? Perhaps you have a link that explains it?
When you reboot computer start it Failsafe mode, if you have boot parameter 'x11failsafe' in menu.lst then it will boot using /etc/X11/xorg.conf.install . ...
Smolt project is the beginning.
Using it is the thing, and getting feedback out to ppl who might help, if they knew that testing their PCI card would make a real difference.
Tell them to use command line tool "smoltSendProfile -d" instead of GUI and wait until administrator password appear. Make note of password and URL where profile is located. That password allows you to change some fields in report, when you visit smolt page, and GUI currently doesn't provide it. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
"OpenSuse 11.1 needed more testing" http://forums.opensuse.org/install-boot-login/402849-opensuse-11-1-needed-mo... I remember thinking that way... it's kind of amusing, but he is making reasonable points. The expecation was that 11.1 would be production quality, whereas we in this thread, all acknowledge that there's a large number of unfixed bugs, in what was shipped. 10.3 had a longer release cycle 10 months, but it was in at least as bad state, may be worse, as some of the problems were things like intermitent faults with some network drivers, which would lead to very strange and frustrating problems running applications. In a way, refusing to boot, or obvious breakage saves you time :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, Dec 25, 2008 at 9:07 AM, Rob OpenSuSE
"OpenSuse 11.1 needed more testing" http://forums.opensuse.org/install-boot-login/402849-opensuse-11-1-needed-mo...
It didn't need more testing. The issues were well identified and reported. What we needed was: a) to fix it or b) to swallow our pride and revert back to a working, stable driver. We didn't do anyone any favors by pushing a crap driver. I know it's all be done and said, but we should avoid doing it again.
I remember thinking that way... it's kind of amusing, but he is making reasonable points. The expecation was that 11.1 would be production quality, whereas we in this thread, all acknowledge that there's a large number of unfixed bugs, in what was shipped.
10.3 had a longer release cycle 10 months, but it was in at least as bad state, may be worse, as some of the problems were things like intermitent faults with some network drivers, which would lead to very strange and frustrating problems running applications. In a way, refusing to boot, or obvious breakage saves you time :)
What we need, is to put a lot more effort into the user-friendliness of factory. It should be easier to install, easier to upgrade to. Easier to report bugs. It shouldn't be in inconsistent states so often and we should be trying to keep it as stable as possible. I've had no problems using Fedora's rawhide as a production desktop, but I couldn't even consider the same thing with openSUSE's development versions. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Eric Springer wrote:
What we need, is to put a lot more effort into the user-friendliness of factory. It should be easier to install, easier to upgrade to. Easier to report bugs. It shouldn't be in inconsistent states so often and we should be trying to keep it as stable as possible.
Amen! When I read the factory list, I sometimes have the impression that the devs dump everything into factory as soon as it barely compiles. This may be nice for the devs, because they do need a place to dump their code, but it is absolutely horrible for testers. Which is also the reason why I have not yet tested factory a single time. The miserable state in which 11.1 beta 1 (beta, not even factory!) was this time actually just reinforced that feeling. OpenOffice was completely unusable, crashed every time (bug #429069). Which is just a _huge_ waste of testing time, because probably dozens of people wast^wspent their time researching this already known issue (just like me). Just replace the binaries with xmessage "OpenOffice is currently broken. We're working on it." or just don't include stuff that is known to be broken in a release intended for public testing. Happy Holidays nordi -- Spam protection: All mail to me that does not contain the string "suse" goes to /dev/null. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 25 December 2008 07:57:15 am nordi wrote:
Eric Springer wrote:
What we need, is to put a lot more effort into the user-friendliness of factory. It should be easier to install, easier to upgrade to. Easier to report bugs. It shouldn't be in inconsistent states so often and we should be trying to keep it as stable as possible.
Amen!
When I read the factory list, I sometimes have the impression that the devs dump everything into factory as soon as it barely compiles. This may be nice for the devs, because they do need a place to dump their code, but it is absolutely horrible for testers. Which is also the reason why I have not yet tested factory a single time.
The miserable state in which 11.1 beta 1 (beta, not even factory!) was this time actually just reinforced that feeling. OpenOffice was completely unusable, crashed every time (bug #429069). Which is just a _huge_ waste of testing time, because probably dozens of people wast^wspent their time researching this already known issue (just like me). Just replace the binaries with
xmessage "OpenOffice is currently broken. We're working on it."
or just don't include stuff that is known to be broken in a release intended for public testing.
The Factory is by definition place where only guarantee is that code was compiled and packaged. It is not for everyone, and it will never be. The problem are development releases that are broken. If you want early testers, say from half of development cycle, some types of bugs should not exist. Base system has to start and bring up GUI. At that stage only problem can be that GUI runs on driver used to install system, not 3D, and application problems, like OpenOffice. If want to test openSUSE few links must be part of your bookmarks: http://en.opensuse.org/Bugs:Most_Annoying_Bugs and http://en.opensuse.org/Submitting_Bug_Reports which gives bunch of links that can be used to search for bugs, and report them. For instance in: http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.1_dev you will find OpenOffice related bugs.
Happy Holidays nordi
To you too nordi. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thu, 2008-12-25 at 14:57 +0100, nordi wrote:
Eric Springer wrote:
What we need, is to put a lot more effort into the user-friendliness of factory. It should be easier to install, easier to upgrade to. Easier to report bugs. It shouldn't be in inconsistent states so often and we should be trying to keep it as stable as possible.
Amen!
When I read the factory list, I sometimes have the impression that the devs dump everything into factory as soon as it barely compiles. This may be nice for the devs, because they do need a place to dump their code, but it is absolutely horrible for testers. Which is also the reason why I have not yet tested factory a single time.
Developers do not submit broken code on purpose. What needs to be taken into account is that there's some 3800 packages in Factory that all have to work together. The only way to "ensure" that it's not broken, is to submit one package, fully test everything, then sync it out to mirrors. Submit the next package, full testing, sync etc. It's just not feasible. When alpha/beta etc are cut for testing, there is some QA before they get released, but again, it's not possible to test everything. The proper way to test Factory is to have a virtual machine and/or a spare machine. Cheers, Magnus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
nordi escribió: Just replace the binaries with
xmessage "OpenOffice is currently broken. We're working on it."
What is happening in this thread ? suggestions are getting more and more ridiculous everyday.. how you will ever figure that openOffice is broken if you dont include the binaries ? -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
2009/1/2 Cristian Rodríguez
nordi escribió: Just replace the binaries with
xmessage "OpenOffice is currently broken. We're working on it."
What is happening in this thread ? suggestions are getting more and more ridiculous everyday.. how you will ever figure that openOffice is broken if you dont include the binaries ?
Obviously because when the version released found is "broken", an
interim message was suggested to avoid duplicate reporting and testing
effort.
If you'ld quoted him less selectively the meaning was clear :
2008/12/25 nordi
Eric Springer wrote:
What we need, is to put a lot more effort into the user-friendliness of factory. It should be easier to install, easier to upgrade to. Easier to report bugs. It shouldn't be in inconsistent states so often and we should be trying to keep it as stable as possible.
Amen!
When I read the factory list, I sometimes have the impression that the devs dump everything into factory as soon as it barely compiles. This may be nice for the devs, because they do need a place to dump their code, but it is absolutely horrible for testers. Which is also the reason why I have not yet tested factory a single time.
The miserable state in which 11.1 beta 1 (beta, not even factory!) was this time actually just reinforced that feeling. OpenOffice was completely unusable, crashed every time (bug #429069). Which is just a _huge_ waste of testing time, because probably dozens of people wast^wspent their time researching this already known issue (just like me). Just replace the binaries with
xmessage "OpenOffice is currently broken. We're working on it."
or just don't include stuff that is known to be broken in a release intended for public testing. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 16:35 -0600, Rajko M. wrote:
Smolt project is the beginning.
Using it is the thing, and getting feedback out to ppl who might help, if they knew that testing their PCI card would make a real difference.
Tell them to use command line tool "smoltSendProfile -d" instead of GUI and wait until administrator password appear. Make note of password and URL where profile is located. That password allows you to change some fields in report, when you visit smolt page, and GUI currently doesn't provide it.
That command is not installed by default. It is not even included in default repos. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklTADAACgkQtTMYHG2NR9XlogCfXPNfw8mwk9IuOlG1GRrGO0cr l2YAn21J3Xv8AW5LxjY1VnXnrBoERlIh =C/gx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 24 December 2008 09:38:23 pm Carlos E. R. wrote:
On Wednesday, 2008-12-24 at 16:35 -0600, Rajko M. wrote:
Smolt project is the beginning.
Using it is the thing, and getting feedback out to ppl who might help, if they knew that testing their PCI card would make a real difference.
Tell them to use command line tool "smoltSendProfile -d" instead of GUI and wait until administrator password appear. Make note of password and URL where profile is located. That password allows you to change some fields in report, and GUI currently doesn't provide it.
That command is not installed by default. It is not even included in default repos.
The smoltGUI should be installed, as it pops up on first update, but it has a problem that it doesn't provide password, so you can't change status on web page. smoltGUI smoltSendProfile smoltDeleteProfile -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rajko M. a écrit :
The smoltGUI should be installed, as it pops up on first update, but it has a problem that it doesn't provide password, so you can't change status on web page.
smoltGUI smoltSendProfile smoltDeleteProfile
I have it installed (don't remember how), but it's really not finished: at install time it comes with nearly no comment and I never found a way to give my point. I find it in the system/monitor kde menu, but it fails silently, as it does in a terminal, probably because it needs to be used as root. in konsole, root, A can launch the GUI, but it's so slow it look crashed. I could send my profile but not do anything else. do we have to fill a wiki page (smolt wiki)? or open a bugzilla? jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
jdd a écrit :
or open a bugzilla?
Done: Bug 462494 Submitted I have seen several open bugs on a very similar subject, but with different error messages, so the new open bug jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 25 December 2008 02:19:12 am jdd wrote:
jdd a écrit :
or open a bugzilla?
Done: Bug 462494 Submitted I have seen several open bugs on a very similar subject, but with different error messages, so the new open bug
It is known problem. The feature to give comments is not implemented, even existing feature in smoltSendProfile to show your admin password is not implemented in GUI. For now smolt is partially useful, if you filter results. For instance all openSUSE Beta, RC and Fedora rawhide are probably duplicates of final version. I know that I have 2 entries, and first one is stuck there for good. I have no password to delete it. They still have a lot of work ahead. For instance how to uniquely identify machine. UUID stored in /etc/smolt is not the way. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rajko M. a écrit :
It is known problem.
there are lots of problems, none probably not so difficult to fix :-)
For now smolt is partially useful, if you filter results.
IMHO it should be a cross distrib essential project jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 25 December 2008 05:19:56 am jdd wrote:
Rajko M. a écrit :
It is known problem.
there are lots of problems, none probably not so difficult to fix :-)
For now smolt is partially useful, if you filter results.
IMHO it should be a cross distrib essential project
It is meant as such: http://en.opensuse.org/Hardware/Smolt -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rajko M. a écrit :
It is meant as such: http://en.opensuse.org/Hardware/Smolt
yes but it seems to have been done quite silently when it should be the first effort. for example it make me notice my intel wlan card don't work on 11.1 (work perfectly on 11.0) :-() I'm ready to help a lot in this direction jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 22:14 -0600, Rajko M. wrote: El 2008-12-24 a las 22:14 -0600, Rajko M. escribió:
Date: Wed, 24 Dec 2008 22:14:30 -0600 From: Rajko M.
Reply-To: OS-prjct To: opensuse-project@opensuse.org Subject: Re: [opensuse-project] Development release: How to make it better, On Wednesday 24 December 2008 09:38:23 pm Carlos E. R. wrote:
On Wednesday, 2008-12-24 at 16:35 -0600, Rajko M. wrote:
Smolt project is the beginning.
Using it is the thing, and getting feedback out to ppl who might help, if they knew that testing their PCI card would make a real difference.
Tell them to use command line tool "smoltSendProfile -d" instead of GUI and wait until administrator password appear. Make note of password and URL where profile is located. That password allows you to change some fields in report, and GUI currently doesn't provide it.
That command is not installed by default. It is not even included in default repos.
The smoltGUI should be installed, as it pops up on first update, but it has a problem that it doesn't provide password, so you can't change status on web page.
smoltGUI smoltSendProfile smoltDeleteProfile
NOT_nimrodel:/etc # rpm -q smolt package smolt is not installed NOT_nimrodel:/etc # webpin -F smoltSendProfile ... performing request on http://api.opensuse-community.org/searchservice/Search/Simple/SUSE_Factory/s... 1 results (1 packages) found for "smoltSendProfile" in SUSE_Factory * smolt: Hardware Profiler - 1.1.1.1 [BS::home:/digitaltomm] >> /usr/bin/smoltSendProfile NOT_nimrodel:/etc # zypper se smolt Loading repository data... Reading installed packages... S | Name | Summary | Type - --+-------+--------------------------------------+----------- | smolt | Hardware Profiler | package | smolt | Hardware Profiler | srcpackage | smolt | smolt: Report Hardware Configuration | patch NOT_nimrodel:/etc # zypper in smolt ... NOT_nimrodel:/etc # smolt[tab][tab] smolt smoltDeleteProfile smoltGui smoltSendProfile NOT_nimrodel:/etc # man smolt No manual entry for smolt It is not installed by default, as it was not installed on my system; webpin did not find it. Curiously, zypper did. No manual. No description. I still do not know what it is for. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklThV4ACgkQtTMYHG2NR9VxcwCggKhx5Od+egP5y6yyBnQe35CA nEEAn3fuq0me8C9cNrNdHcFCFCqX5yEq =bh1F -----END PGP SIGNATURE-----
Tell them to use command line tool "smoltSendProfile -d" instead of GUI and wait until administrator password appear. Make note of password and URL where profile is located. That password allows you to change some fields in report, and GUI currently doesn't provide it.
this needs to be more visible, as it gives the solution smoltSendProfile -d jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 14:33 -0600, Rajko M. wrote:
Smolt project is the beginning.
Many people don't know what is that. I don't, not really. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklS/6kACgkQtTMYHG2NR9Ud2wCeI0VEkLUIo68cyfWzr60ZhBRd SagAnRGQOIXR8SUstzxmgRlzbdYaj9Ii =3upb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wednesday 24 December 2008 09:36:03 pm Carlos E. R. wrote:
On Wednesday, 2008-12-24 at 14:33 -0600, Rajko M. wrote:
Smolt project is the beginning.
Many people don't know what is that. I don't, not really.
Wiki: http://smolts.org/smolt-wiki/Main_Page -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2008-12-24 at 22:07 -0600, Rajko M. wrote:
Many people don't know what is that. I don't, not really.
I'd prefer a link on openSUSE, with the openSUSE position on that. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklThy0ACgkQtTMYHG2NR9XRDwCfYW7gApkB4kLzSQjWn4KWJ9XC cGkAoIwy2AwBsaDEaXfzRzxL9sjrOvxI =IHnZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Thursday 25 December 2008 07:14:20 am Carlos E. R. wrote:
On Wednesday, 2008-12-24 at 22:07 -0600, Rajko M. wrote:
Many people don't know what is that. I don't, not really.
I'd prefer a link on openSUSE, with the openSUSE position on that.
There is not much on that page, but it tells you essence: http://en.opensuse.org/Hardware/Smolt -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
What if? The system was, "11 boxed" (SLE11rc1) and openSUSE 12.0 where the same ISO (with branding and repo changes), I'm suggesting three layers of release; dev, tester , "Joe Plumber"\SLE. For all Novell Linux "Nightly" repo would be for internal development - aka unstable "Factory" could be the community "devs" repo and provide 12.0.X, 12.1.X, etc. released quarterly and the only place to include new kernel and desktop changes but never in X.3.X A "tester", could install with the 12 ISO which had "factory-update" as its repo, then 12.1 would be an update\add-on\upgrade, the same for 12.2, etc. preferably still on 9 month cycle and released as a delta iso (smaller bandwidth) Using a "Delta" or cumulative type release format could take most of the work out of bug-fixing the "boxed" release. Joe, doesn't have to think much , he goes straight for "11 boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us. I think we can all agree that the initial install is what the community(aka "joe" and some testers)most dislike, I am told this is mostly do to kernel and major desktop changes. By scheduling these things early in our release development and with the "boxed" being built from a known kernel and desktop, this issue should disappear. Yes? When applications fail during release it's usually because there wasn't enough testing. Yes? I believe it's causing to many issues to add or wait to add a new kernel or desktop release just because it happens to be close to our next release. These need to done in the early (i.e.12.0.x-12.1.x)releases. The goal for boxed is for "Joe" who simply wants to replace Windows with ease.( a growing group of people according to Apples sales numbers). He doesn't care about a stale Gnome,KDE or openOffice if it works. He does care that if his HD dies he can reinstall everything including peripheral applications provided for, but not included in, the distro. By Defining a "dev" level, we invite people who literally develop openSUSE and components specific to openSUSE to contribute to sub-releases, which lets them test small changes on a faster pace. By defining a layer as "tester", we invite those who want to be part of the development and expect issues. Sysadmins and Application Engineers looking to make a specific application work better. By defining a "Boxed" version, we invite more of the general public to use openSUSE with confidence. By making these definitions clear, we take away the reviewers ability to complain about our missteps if he is reviewing "tester" or "dev" releases. Changing the release cycle and the release itself to a more reliable and consistent product would look like this: 12.0 -security fixes until 12.1 there is no need to support the testing layer any longer than the next release. 12.0.X - no more than 3 months and no less then 1.5 months from 12.0 - Repo only - no patches provided. (Quarterly releases) 12.1 - no more then 9 months from 12.0 - Repo and "Add-On"\Patch CD\Delta ISO - same support as 12.0 12.2 - "" 18 months"" 12.3 - ""24 months"" 12 "boxed" \ openSUSE 13- no more then 27 months from 12.0 - ISO and retail box - subscription updates and installation support for no less than 24 months. Realistically not a big change, but the change to a structured cumulative development cycle with early kernel and desktop updates as well as 3 months dedicated to "boxing" would go a long way politically. -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
What if? The system was, "11 boxed" (SLE11rc1) and openSUSE 12.0 where the same ISO (with branding and repo changes), I'm suggesting three layers of release; dev, tester , "Joe Plumber"\SLE. For all Novell Linux "Nightly" repo would be for internal development - aka unstable "Factory" could be the community "devs" repo and provide 12.0.X, 12.1.X, etc. released quarterly and the only place to include new kernel and desktop changes but never in X.3.X A "tester", could install with the 12 ISO which had "factory-update" as its repo, then 12.1 would be an update\add-on\upgrade, the same for 12.2, etc. preferably still on 9 month cycle and released as a delta iso (smaller bandwidth) Using a "Delta" or cumulative type release format could take most of the work out of bug-fixing the "boxed" release. Joe, doesn't have to think much , he goes straight for "11 boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us. I think we can all agree that the initial install is what the community(aka "joe" and some testers)most dislike, I am told this is mostly do to kernel and major desktop changes. By scheduling these things early in our release development and with the "boxed" being built from a known kernel and desktop, this issue should disappear. Yes? When applications fail during release it's usually because there wasn't enough testing. Yes? I believe it's causing to many issues to add or wait to add a new kernel or desktop release just because it happens to be close to our next release. These need to done in the early (i.e.12.0.x-12.1.x)releases. The goal for boxed is for "Joe" who simply wants to replace Windows with ease.( a growing group of people according to Apples sales numbers). He doesn't care about a stale Gnome,KDE or openOffice if it works. He does care that if his HD dies he can reinstall everything including peripheral applications provided for, but not included in, the distro. By Defining a "dev" level, we invite people who literally develop openSUSE and components specific to openSUSE to contribute to sub-releases, which lets them test small changes on a faster pace. By defining a layer as "tester", we invite those who want to be part of the development and expect issues. Sysadmins and Application Engineers looking to make a specific application work better. By defining a "Boxed" version, we invite more of the general public to use openSUSE with confidence. By making these definitions clear, we take away the reviewers ability to complain about our missteps if he is reviewing "tester" or "dev" releases. Changing the release cycle and the release itself to a more reliable and consistent product would look like this: 12.0 -security fixes until 12.1 there is no need to support the testing layer any longer than the next release. 12.0.X - no more than 3 months and no less then 1.5 months from 12.0 - Repo only - no patches provided. (Quarterly releases) 12.1 - no more then 9 months from 12.0 - Repo and "Add-On"\Patch CD\Delta ISO - same support as 12.0 12.2 - "" 18 months"" 12.3 - ""24 months"" 12 "boxed" \ openSUSE 13- no more then 27 months from 12.0 - ISO and retail box - subscription updates and installation support for no less than 24 months. Realistically not a big change, but the change to a structured cumulative development cycle with early kernel and desktop updates as well as 3 months dedicated to "boxing" would go a long way politically. -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Monday 05 January 2009 04:50:49 pm James Tremblay aka SLEducator wrote:
I think we can all agree that the initial install is what the community(aka "joe" and some testers)most dislike, I am told this is mostly do to kernel and major desktop changes.
It is easy to dislike, if you run in problems and there is no experienced Linux user around, then all you can do is to quit and forget. Example: Yesterday I got "install fest" at friends home. All I got to do is to install openSUSE on one older Compaq desktop, as a showcase. Older Compaq crashed kernel right after start with 11.0 and 11.1. I would be in trouble if he hadn't Knoppix that I have forgotten some time ago, and Knoppix worked. So after downloading newest one and fiddling with its instalation, old Compaq is now running Debian Linux. His laptop that wasn't even in consideration for installation, I used to see how DVD would boot, and it was just opposite story. Since all seemed fine, owner decided that he will give it a try, and lucky for openSUSE, Linux and me all worked fine. Even dreaded wireless worked at once, while in Windows he has some more work to do. Discussion about support, development etc, should happen after we decide to have something that runs almost everywhere. There is no point to split hair over development as long as we don't have something that installs on almost any piece of hardware, like Knoppix. I can talk about improvements in the newest version, but that makes sense to computer owner after installation. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/6 Rajko M.
Discussion about support, development etc, should happen after we decide to have something that runs almost everywhere. There is no point to split hair over development as long as we don't have something that installs on almost any piece of hardware, like Knoppix.
Whilst I'm sure knoppix has it's problems on recent hardware, surely noone can claim knoppix had more resources. Though I do remember SuSE had Live CD's long time before knoppix made such a splash, because it made such a good job of auto-configuring on a wide range of kit. Some of the install difficulties, may be due to choices made to get newer code a wider user base. There may be a conflict of interest between long term, and short term community interests. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 06 January 2009 09:45:59 am Rob OpenSuSE wrote:
2009/1/6 Rajko M.
: Discussion about support, development etc, should happen after we decide to have something that runs almost everywhere. There is no point to split hair over development as long as we don't have something that installs on almost any piece of hardware, like Knoppix.
Whilst I'm sure knoppix has it's problems on recent hardware, surely noone can claim knoppix had more resources. Though I do remember SuSE had Live CD's long time before knoppix made such a splash, because it made such a good job of auto-configuring on a wide range of kit.
Some of the install difficulties, may be due to choices made to get newer code a wider user base. There may be a conflict of interest between long term, and short term community interests.
Well, Knoppix has booted on any hardware that I tried. Did everything worked? Not always, but it showed something that one can use. Was graphic fast? Almost never, but when I have GUI I have time to talk. Not much, but I if have nothing to present, then I'm toast. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/5 James Tremblay aka SLEducator
What if? The system was, "11 boxed" (SLE11rc1) and openSUSE 12.0 where the same ISO (with branding and repo changes), I'm suggesting three layers of release; dev, tester , "Joe Plumber"\SLE. For all Novell Linux
Having the same software with 2 different major versions, and then majorly updated core software with the same major version is a recipe for confusion, in my opinion. If openSUSE has to be encumbered with 'fixed' releases, which you need to install, or upgrade 'offline', then I'd far rather having consistent meaningful version numbering, and simply make the boxed sets, and SLE first rc version based on the end product of the stabilisation cycle, not the first attempt. Installs are disliked for a number of reasons : - Loss of configuration and settings - Large number of changes all at once - Danger of data loss through mistakes (using wrong partitions etc) - Uncertain outcome - May be large effort tracking down workrounds for problems - Possible difficulty afterwards, booting another OS (due to boot loader confusion) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/5 James Tremblay aka SLEducator
: What if? The system was, "11 boxed" (SLE11rc1) and openSUSE 12.0 where the same ISO (with branding and repo changes), I'm suggesting three layers of release; dev, tester , "Joe Plumber"\SLE. For all Novell Linux
Having the same software with 2 different major versions, and then majorly updated core software with the same major version is a recipe for confusion, in my opinion.
The Idea is that boxed is officially supported where 12.0 is stable short term version to support bringing in new testers and the community onto the first 12 series branding and versioning. It's small steps, like you keep talking about. 12.0 would only be current for 1.5 to 3 months.
If openSUSE has to be encumbered with 'fixed' releases, which you need to install, or upgrade 'offline', then I'd far rather having consistent meaningful version numbering, and simply make the boxed sets, and SLE first rc version based on the end product of the stabilisation cycle, not the first attempt.
Installs are disliked for a number of reasons :
- Loss of configuration and settings - Large number of changes all at once - Danger of data loss through mistakes (using wrong partitions etc) - Uncertain outcome - May be large effort tracking down workrounds for problems - Possible difficulty afterwards, booting another OS (due to boot loader confusion)
-- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Hi! On Wednesday 24 December 2008 16:26:43 Rajko M. wrote:
Problems in development release that scare 99% of todays users: 1) boot configuration setup is black box, there is no list of supported (to that moment tested) boot configurations. Actually there is no public specification what should go in this list: partitions, file system, permanent storage, (anything else)
Here is an attempt to cover this (but a lot of work is still left, e.g. most of the architectures): http://en.opensuse.org/Bootloader/Scenarios Stano -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2008/12/24 Carlos E. R.
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
Yes I agree. Noone came up with a real reason why the Net release and Box set release had to be simultaneous. The only point would be, why buy/order something you already downloaded? Hence thinking through ideas of a box set with an updated version, that was then the current stable version from Dec-Nov following year. With 6 month cycle, the less buggy version, would only have about 2 months before the Hoop La! for the next version starts. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Wed, 2008-12-24 at 01:04 +0100, Carlos E. R. wrote:
Possibly.
I think it would be better to delay the box and add the first month or two of patches. They usually are a lot patches, and some of the bugs discovered and solved in the first month or two after release are important.
Well, then you've got a number of other issues...
How do we make it known that the boxed edition with all the "fixes" are
available? Right now we take advantage of the launch period for the
normal release. If we just launch a normal release without any mention
of a boxed edition, then wouldn't we have to do another launch period
for the boxed edition, a month afterwards? Which more than likely won't
be as covered. And if we do mention the boxed edition, how do we do that
while not cannibalizing our downloads (as tempting as I'm sure it would
be to download a product which says "we'll have the fixes for all the
problems with this thing in a month", I'm not sure that's the best way
to create a splash with our product releases).
Plus, we need to instead address the root of this problem: why does
openSUSE release with issues anyway? If we need to talk about testing
and release methods, let's talk about them (in a new thread).
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
2008/12/24 Kevin Dupuy
On Wed, 2008-12-24 at 01:04 +0100, Carlos E. R. wrote:
How do we make it known that the boxed edition with all the "fixes" are available? Right now we take advantage of the launch period for the normal release. If we just launch a normal release without any mention of a boxed edition, then wouldn't we have to do another launch period for the boxed edition, a month afterwards?
Just make a net short term "interim" release 4 weeks earlier, which would effectively be a large scale RC, with updates working to the final release. 4 weeks so kernel driver problems have a chance to be sorted, with driver updates for the final ISO's. Ship RC version of GNOME with it, as an option to the stable version used before. Save the fuss for the big one, and trot out the numbers on the number of test installations, collected and how long it'll be supported for. If the released is timed correctly it'll have the latest GNOME & KDE. You don't lose surprise factor as all the alpha and beta versions are pulically available anyone now. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Kevin Dupuy escribió:
why does openSUSE release with issues anyway?
ohh dear.. there will always be issues, if you expect a software product without issues you are living in a different planet. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Fri, 2009-01-02 at 01:25 -0300, Cristian Rodríguez wrote:
Kevin Dupuy escribió:
why does openSUSE release with issues anyway?
ohh dear.. there will always be issues, if you expect a software product without issues you are living in a different planet.
Of course I don't expect that, and I did phrase that comment
misleadingly. What I mean is why are we releasing with known bugs that
are apparently pretty visible to users on the desktop, as some have
reported.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
Does this delay also effect the shipping of the "freebie" boxed sets and shirts for some? Dean Hilkewich -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Fri, 2009-01-02 at 17:15 -0600, Kevin Dupuy wrote:
On Fri, 2009-01-02 at 01:25 -0300, Cristian Rodríguez wrote:
Kevin Dupuy escribió:
why does openSUSE release with issues anyway?
ohh dear.. there will always be issues, if you expect a software product without issues you are living in a different planet.
Of course I don't expect that, and I did phrase that comment misleadingly. What I mean is why are we releasing with known bugs that are apparently pretty visible to users on the desktop, as some have reported. -- Kevin "Yeaux" Dupuy - openSUSE Member Public Mail:
Merry Christmas & Happy Holidays from the Yeaux!
There's three answers to that. 1) Testing, 2) Testing, 3) Testing. The problems we face are not enough testing and too close to end of cycle when more people start testing. And the other thing about "bugs", is that sometimes it has to be in combination with how you use the machine. I'm finding a relatively smooth experience on my 11.1 box with a few annoying bugs, others are experiencing crashes. Why? Different usage of their machines. It's impossible to come up with every possible scenario for testing. So... more Testing, Testing, Testing as early on as possible. The extended period for 11.2 might yield better results for us because it gives us all more time to test. -- Bryen Yunashko openSUSE Board Member -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sat, Jan 3, 2009 at 10:23 AM, Bryen
There's three answers to that. 1) Testing, 2) Testing, 3) Testing.
I daresay, any issue that isn't found during the current testing stage is going to be rare enough to be insignificant (in contrast with the thousands of known ones). And that's even taking into account our current hellish testing: 1) Hard to get/upgrade to 2) Constantly broken 3) So many known problems make finding (or getting to) the unknown ones extremely difficult 4) Updating is massive waste of internet bandwidth / time ...and probably more. So let's stop acting like testing is the cause or solution of our problems. Regards, Eric. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
I daresay, any issue that isn't found during the current testing stage is going to be rare enough to be insignificant (in contrast with the thousands of known ones). Or it is simply hidden behind so much other stuff as you wrote yourself. Or related to a feature that is not completed in time to be tested
Eric Springer wrote: properly. Suse-specific translations come to mind, they are always finished _very_ late in the process so that it is almost impossible to report bugs against missing/incomplete/wrong translations early enough for them to be fixed. Because finding a bug does not mean it gets fixed early enough for GM. My KDM login screen for example is partly in English. Missing translations for KDM are neither a rare nor an insignificant issue. But who reports a few untranslated words when there are many crash-bugs to be reported? Especially since many beta-testers speak English well enough to not even notice. (Note: That one may be a bad example since it already got reported, see bug #447066. But the point remains valid, e.g. for the boot menu or the installer which are the first things that a new user sees of openSuse.)
Regards, Eric. Btw, you are not working properly, see bug #441560. ;-)
Regards nordi -- Spam protection: All mail to me that does not contain the string "suse" goes to /dev/null. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sat, Jan 3, 2009 at 8:46 PM, nordi
Or it is simply hidden behind so much other stuff as you wrote yourself. Or related to a feature that is not completed in time to be tested properly. Suse-specific translations come to mind, they are always finished _very_ late in the process so that it is almost impossible to report bugs against missing/incomplete/wrong translations early enough for them to be fixed. Because finding a bug does not mean it gets fixed early enough for GM.
My KDM login screen for example is partly in English. Missing translations for KDM are neither a rare nor an insignificant issue. But who reports a few untranslated words when there are many crash-bugs to be reported? Especially since many beta-testers speak English well enough to not even notice.
You're absolutely right, and you picked a great example too. And that is the real purpose of testing -- not the typical "Confirming broken application is not working for me either" stuff. Once the package developers/maintainers believe that it's ready -- then put it in factory. I realize this gives packages a shorter testing time, but: people are more inclined to report/notice things when it's an anomaly not the norm. And there will easily be x2 or x3 the amount of testers ;D Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control. I don't even bother filing bug reports to software these days, unless it's project that takes it seriously and doesn't have a billion confirmed and known bugs. Take opensuse, the last bug I filed (#413806) was in August, one that stops all gtk ocaml programs from compiling. And even though the problem (comment #9) is a simple dependency issue, I'm not holding my breath for it to be fixed anytime soon.
Btw, you are not working properly, see bug #441560. ;-)
Haha. Made me laugh. Nice. :) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday 03 January 2009 07:37:21 am Eric Springer wrote:
On Sat, Jan 3, 2009 at 8:46 PM, nordi
wrote: Or it is simply hidden behind so much other stuff as you wrote yourself. Or related to a feature that is not completed in time to be tested properly. Suse-specific translations come to mind, they are always finished _very_ late in the process so that it is almost impossible to report bugs against missing/incomplete/wrong translations early enough for them to be fixed. Because finding a bug does not mean it gets fixed early enough for GM.
My KDM login screen for example is partly in English. Missing translations for KDM are neither a rare nor an insignificant issue. But who reports a few untranslated words when there are many crash-bugs to be reported? Especially since many beta-testers speak English well enough to not even notice.
You're absolutely right, and you picked a great example too. And that is the real purpose of testing -- not the typical "Confirming broken application is not working for me either" stuff. Once the package developers/maintainers believe that it's ready -- then put it in factory.
They do just that. If they have no problem, they put it out. Though, if you are not sure where bug comes from, software itself, or underlaying libraries, then you will publish software anyway, with hope that new round will reveal something.
I realize this gives packages a shorter testing time, but: people are more inclined to report/notice things when it's an anomaly not the norm. And there will easily be x2 or x3 the amount of testers ;D
Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control.
It is, as it is. When everything will be put under control it will be the same as with Microsoft, or any other place with central control. That communication should be more efficient, is fact, but how would you connect thousands of nodes to make sure that if openSUSE, or Ubuntu, or anyone else has bug in its bugzilla, that will be forwarded to project bug tracking system? The open source environment is huge, much bigger than any existing company, with many disparate bug tracking systems in place. How to connect them?
I don't even bother filing bug reports to software these days, unless it's project that takes it seriously and doesn't have a billion confirmed and known bugs.
That is another problem. No one has unlimited resources, and if you miss developers, then you don't fix the bugs.
Take opensuse, the last bug I filed (#413806) was in August, one that stops all gtk ocaml programs from compiling. And even though the problem (comment #9) is a simple dependency issue, I'm not holding my breath for it to be fixed anytime soon.
Btw, you are not working properly, see bug #441560. ;-)
Haha. Made me laugh. Nice. :)
-- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control.
It is, as it is. When everything will be put under control it will be the same as with Microsoft, or any other place with central control.
That communication should be more efficient, is fact, but how would you connect thousands of nodes to make sure that if openSUSE, or Ubuntu, or anyone else has bug in its bugzilla, that will be forwarded to project bug tracking system? The open source environment is huge, much bigger than any existing company, with many disparate bug tracking systems in place. How to connect them?
What you do not see is also that we report bugs upstream, or we work upstream and fix the bugs there. So in the end it is unified again.
I don't even bother filing bug reports to software these days, unless it's project that takes it seriously and doesn't have a billion confirmed and known bugs.
If we do not know about the bugs, we cannot fix them. That the speed depends on the assignee occasionaly, yeah, thats a bit sad. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday 03 January 2009 03:15:21 pm Marcus Meissner wrote:
That communication should be more efficient, is fact, but how would you connect thousands of nodes to make sure that if openSUSE, or Ubuntu, or anyone else has bug in its bugzilla, that will be forwarded to project bug tracking system? The open source environment is huge, much bigger than any existing company, with many disparate bug tracking systems in place. How to connect them?
What you do not see is also that we report bugs upstream, or we work upstream and fix the bugs there. So in the end it is unified again.
I know that. It is anyway a lot of manual work that way. For instance working with somebody upstream, you have to be a proxy if local reporter doesn't want to create one more login in his portfolio. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/3 Marcus Meissner
Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control.
What you do not see is also that we report bugs upstream, or we work upstream and fix the bugs there. So in the end it is unified again.
This is actually a reason to use openSUSE or Fedora community distro, rather than some other choices. Making that effort more visible in Bugzilla might help, where a Bug has a report in upstream tracker, with some kind of workround in openSUSE release(s). -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Le mardi 06 janvier 2009, à 13:31 +0000, Rob OpenSuSE a écrit :
2009/1/3 Marcus Meissner
: Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control.
What you do not see is also that we report bugs upstream, or we work upstream and fix the bugs there. So in the end it is unified again.
This is actually a reason to use openSUSE or Fedora community distro, rather than some other choices.
Making that effort more visible in Bugzilla might help, where a Bug has a report in upstream tracker, with some kind of workround in openSUSE release(s).
That's actually the current policy to put a link to the upstream bug tracker (in the URL field, and also in a comment), I believe. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/6 Vincent Untz
Le mardi 06 janvier 2009, à 13:31 +0000, Rob OpenSuSE a écrit :
2009/1/3 Marcus Meissner
: Anyway, the whole bug reporting is completely disenchanting. The system is far too inefficient, too distributed (across all the different distros) and when it's not monitored aggressively it spirals out of control.
What you do not see is also that we report bugs upstream, or we work upstream and fix the bugs there. So in the end it is unified again.
This is actually a reason to use openSUSE or Fedora community distro, rather than some other choices.
Making that effort more visible in Bugzilla might help, where a Bug has a report in upstream tracker, with some kind of workround in openSUSE release(s).
That's actually the current policy to put a link to the upstream bug tracker (in the URL field, and also in a comment), I believe.
I've seen them in comments in some bugs, but not in others; on occasion I've put in an URL for the kernel bugzilla myself. The problem is, it's not visible enough, and perhaps inconsistently done. Also I guess, if you don't shout about upstream cooperation in openSUSE news, then a lot of folk won't notice. Looking at a whole load of inaction in a certain distro's "Launchpad", was a motivation with settling on openSUSE despite a pretty rocky experience initially with 10.3. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
Though, if you are not sure where bug comes from, software itself, or underlaying libraries, then you will publish software anyway, with hope that new round will reveal something.
And that is where the problem lies. These problems are strictly for developers, pushing it to testing is a complete waste of resources and good will. It needs to sit in some sort of work-in-progress repository or be masked in a way. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
Though, if you are not sure where bug comes from, software itself, or underlaying libraries, then you will publish software anyway, with hope that new round will reveal something.
And that is where the problem lies. These problems are strictly for developers, pushing it to testing is a complete waste of resources and good will. It needs to sit in some sort of work-in-progress repository or be masked in a way.
When you use word tester you mean average computer user able to report problem, but not to help much. The other side of the sectrum is guy that is software developer. He is not necessarily familiar with software in question, but when required he can use debugging tools. Situations where something doesn't work are common when you try to synchronize few thousands software titles. Some configurations will work, some will fail. I use openSUSE becasue they still have very small number of problems, comparing to others. [1] For instance, OpenOffice is for me no-no in KDE4 desktop. Reason is nvidia driver for legacy chipsets (FX 5200). What happen is when OOo window has focus, and mouse pointer is anywhere on the desktop outside the OOo window, it will wreck havoc. When OOo window has no focus all comes back to normal. If one would be very strict OOo will not go out until that is fixed. Many users have graphic that is based on legacy GPUs, so bug affects a lot of people. Nvidia interest is to fix first bugs in drivers for current hardware, so legacy is after that. You can't let all the people wait until bug that affects only KDE4 users with legacy Nvidia graphic, is solved. [1] Fedora 10 installation quits on partitioning, without giving me a chance to point finger where it should be installed. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/4 Rajko M.
On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
For instance, OpenOffice is for me no-no in KDE4 desktop. Reason is nvidia driver for legacy chipsets (FX 5200). What happen is when OOo window has focus, and mouse pointer is anywhere on the desktop outside the OOo window, it will wreck havoc. When OOo window has no focus all comes back to normal.
If one would be very strict OOo will not go out until that is fixed. Many users have graphic that is based on legacy GPUs, so bug affects a lot of people. Nvidia interest is to fix first bugs in drivers for current hardware, so legacy is after that. You can't let all the people wait until bug that affects only KDE4 users with legacy Nvidia graphic, is solved.
Won't using the open source 2D 'nv' driver avoid that issue? Bugs with documented workrounds are less serious. Using a legacy Nvidia driver, means a tainted unsupported kernel, and no updates from Nvidia. If it works it's good fortune, if it doesn't you are left with the pieces; which is why we should support opensource friendly hardware companies. Why should OOo be delayed because of problems on unsupported configurations? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 06 January 2009 07:25:44 am Rob OpenSuSE wrote:
2009/1/4 Rajko M.
: On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
For instance, OpenOffice is for me no-no in KDE4 desktop. Reason is nvidia driver for legacy chipsets (FX 5200). What happen is when OOo window has focus, and mouse pointer is anywhere on the desktop outside the OOo window, it will wreck havoc. When OOo window has no focus all comes back to normal.
If one would be very strict OOo will not go out until that is fixed. Many users have graphic that is based on legacy GPUs, so bug affects a lot of people. Nvidia interest is to fix first bugs in drivers for current hardware, so legacy is after that. You can't let all the people wait until bug that affects only KDE4 users with legacy Nvidia graphic, is solved.
Won't using the open source 2D 'nv' driver avoid that issue? Bugs with documented workrounds are less serious.
If it would be simply press the button, switch to nv and run OpenOffice, that is no problem. The only easy to handle solution is not to use KDE4, until Nvidia guys can solve the problem. I know it is solved, it worked fine with newer adapter that is now toast. The backport is what I'm waiting for, and it will come, but it is not high priority.
Using a legacy Nvidia driver, means a tainted unsupported kernel, and no updates from Nvidia. If it works it's good fortune, if it doesn't you are left with the pieces; which is why we should support opensource friendly hardware companies.
If only opensource drivers would provide all functions that I need, I would be more than happy to use them, but they don't. Apropos 'tainted': I'm not sure that people advocating pure opensource can see all consequences. Small vendors with limited intellectual property assets can't opensource much without hurting themselves. Nvidia is relative small fish in the hardware market, if they disappear, that will mean lesser competition, and that doesn't work for consumers.
Why should OOo be delayed because of problems on unsupported configurations?
It was conditional. If one would be strict then some serious bugs will delay release, although openSUSE has nothing to do with them. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/7 Rajko M.
On Tuesday 06 January 2009 07:25:44 am Rob OpenSuSE wrote:
2009/1/4 Rajko M.
: On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
For instance, OpenOffice is for me no-no in KDE4 desktop. Reason is nvidia driver for legacy chipsets (FX 5200). What happen is when OOo window has focus, and mouse pointer is anywhere on the desktop outside the OOo window, it will wreck havoc. When OOo window has no focus all comes back to normal.
If one would be very strict OOo will not go out until that is fixed. Many users have graphic that is based on legacy GPUs, so bug affects a lot of people. Nvidia interest is to fix first bugs in drivers for current hardware, so legacy is after that. You can't let all the people wait until bug that affects only KDE4 users with legacy Nvidia graphic, is solved.
Won't using the open source 2D 'nv' driver avoid that issue? Bugs with documented workrounds are less serious.
If it would be simply press the button, switch to nv and run OpenOffice, that is no problem. The only easy to handle solution is not to use KDE4, until Nvidia guys can solve the problem
If you want to run KDE4 and OOo, and you've been able to track the problem down to a specific one in the Nvidia binary driver, then you are perfectly capable of changing a line of text from "nvidia" to "nv".
Using a legacy Nvidia driver, means a tainted unsupported kernel, and no updates from Nvidia. If it works it's good fortune, if it doesn't you are left with the pieces; which is why we should support opensource friendly hardware companies.
If only opensource drivers would provide all functions that I need, I would be more than happy to use them, but they don't.
Apropos 'tainted': I'm not sure that people advocating pure opensource can see all consequences. Small vendors with limited intellectual property assets can't opensource much without hurting themselves. Nvidia is relative small fish in the hardware market, if they disappear, that will mean lesser competition, and that doesn't work for consumers.
Your problem is caused because you bought Nvidia who have always had a closed policy, and now they don't support their old hardware properly. I don't believe you need 3D to run OOo, nor KDE4, you just like desktop effects or something. As Nvidia don't support, nor update drivers for legacy cards, and there's no source available, you will not get a fix in the example you have shown. When buying hardware, it's important to choose companies that are supporting, openSOURCE developments, by being cooperative. Then there's a far better chance that years on, your card will still be useful, years down the line. You're using openSOURCE, disk drivers, virtual memory system, scheduler, C compiler, libraries; there's no fundamental reason that the graphics drivers can't be as good. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE a écrit :
When buying hardware, it's important to choose companies that are supporting
as of video cards, you have little choice, if any in your money possibility I have headaches with 11.1 (need to revert to 11.0 to be able to print!!) - and this one was installed with the proprietary nvidia driver without really asking (did I add "nvidia" as community repository? may be, but I was never asked to choose AFAIK)
the graphics drivers can't be as good.
they are not... jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/7 jdd
Rob OpenSuSE a écrit :
When buying hardware, it's important to choose companies that are supporting
as of video cards, you have little choice, if any in your money possibility
Oh yes you do! Though newer cards need the closed binary driver at present. AMD/ATI are releasing necessary documentation and there's work going on by Novell under NDA on FOSS drivers. I have some old Matrox cards, which still work with 3D because they were always FOSS, if I find bugs the system is still supported. Unless we as a community consider FOSS support when making hardware purchase decisions, the situation will not change for the better. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE a écrit :
Unless we as a community consider FOSS support when making hardware purchase decisions, the situation will not change for the better.
do you have a laptop? jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/4 Rajko M.
On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
Situations where something doesn't work are common when you try to synchronize few thousands software titles. Some configurations will work, some will fail.
This is true, but now how to home in on the problem source, so a solution is found efficiently? Do you? a) Update and change absolutely everything, and release probably as one huge pile of broken stuff, which then needs a lot of sorting through? b) Phased updates, some parts release stable as others change, with only minimal required bug fixes going in to the rest of the system? c) Many small steps, rolling back 'bad' changes, with one release rolling on and evolving into the next? Some method of moving forwards, and rolling back changes; appears to me the best shot at growing tester base, and maintaining sufficient quality for the code to run on real hardware, not virtualised. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
On Tuesday 06 January 2009 07:40:13 am Rob OpenSuSE wrote:
2009/1/4 Rajko M.
: On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
Situations where something doesn't work are common when you try to synchronize few thousands software titles. Some configurations will work, some will fail.
This is true, but now how to home in on the problem source, so a solution is found efficiently?
Do you?
a) Update and change absolutely everything, and release probably as one huge pile of broken stuff, which then needs a lot of sorting through?
If you update kernel, libc, ( and probably more) or just change gcc options than whether you want or not, you have huge pile of broken stuff.
b) Phased updates, some parts release stable as others change, with only minimal required bug fixes going in to the rest of the system?
Phased updates are possible on software above base, but if you keep base stable, many packages can't be updated. If you don't have support in kernel for certain hardware, then your application will be stable and disfunctionall. I'm pretty sure that crashing leaves bad impression, but missing bugfixes and functionality is not good too.
c) Many small steps, rolling back 'bad' changes, with one release rolling on and evolving into the next?
Rolling back is in general wanted, but devil is in details.
Some method of moving forwards, and rolling back changes; appears to me the best shot at growing tester base, and maintaining sufficient quality for the code to run on real hardware, not virtualised.
In general there must be plan B, to go with A, or bust, is not good. While it forces people to test, new guys that will attempt installation to see how openSUSE works, will be scared away. It doesn't really matter how good is openSUSE when it is installed, if it crashes in first few steps in any boot option including Failsafe. I guess that we have to work a bit on scenario where the newest kernel crashes. What then? Debugging is fine idea, but having working alternative from the boot medium is better to bring masses to openSUSE, which bring more people willing to test. After successfull installation I was able to talk about improvements, but without it, there is no word that will save a day. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/7 Rajko M.
On Tuesday 06 January 2009 07:40:13 am Rob OpenSuSE wrote:
2009/1/4 Rajko M.
: On Saturday 03 January 2009 05:34:31 pm Eric Springer wrote:
On Sun, Jan 4, 2009 at 7:06 AM, Rajko M. wrote:
Situations where something doesn't work are common when you try to synchronize few thousands software titles. Some configurations will work, some will fail.
This is true, but now how to home in on the problem source, so a solution is found efficiently?
Do you?
a) Update and change absolutely everything, and release probably as one huge pile of broken stuff, which then needs a lot of sorting through?
If you update kernel, libc, ( and probably more) or just change gcc options than whether you want or not, you have huge pile of broken stuff.
Should that happen, then you know the probable cause, don't you? If you've updated applications at same time, then you're looking for a problem in far more code. Actually, generally updating the kernel, doesn't break a lot of stuff. gcc updates might be difficult or not, similarly glibc. I've got a SuSE 8.2 installation that can run on a 2.6 kernel for example. Those effects are actually arguments to move 1 step at a time, if you find that updating glibc, or recompiling with gcc leads to a huge pile of brokenness, then you don't implement that change widely, until the issues are understood and fixes are available.
b) Phased updates, some parts release stable as others change, with only minimal required bug fixes going in to the rest of the system?
Phased updates are possible on software above base, but if you keep base stable, many packages can't be updated.
If you don't have support in kernel for certain hardware, then your application will be stable and disfunctionall. I'm pretty sure that crashing leaves bad impression, but missing bugfixes and functionality is not good too.
"stable" doesn't mean frozen. In the even an application requires an update to the core system, say a patch to glibc, or a bug fix to another library, perhaps even gcc, then you should be able to do that. Some intelligence and impact assessment about such changes is required. Actually new software is generally developed for a while, and does not require the latest systems to run on; because that would cut down the end user base. Missing bug fixes, in a test release is not a huge issue; when you've explained that the aim is to test out other parts of the system. If it's a very important critical bug, then you don't keep the end users waiting, but effectively do a 'phased' update via a patch, and just change a minimal part of the system to sort out the bug. So do that, rather than worry about known bugs that are also present in the current stable versions, that end users are using.
c) Many small steps, rolling back 'bad' changes, with one release rolling on and evolving into the next?
Rolling back is in general wanted, but devil is in details.
Some method of moving forwards, and rolling back changes; appears to me the best shot at growing tester base, and maintaining sufficient quality for the code to run on real hardware, not virtualised.
In general there must be plan B, to go with A, or bust, is not good.
While it forces people to test, new guys that will attempt installation to see how openSUSE works, will be scared away. It doesn't really matter how good is openSUSE when it is installed, if it crashes in first few steps in any boot option including Failsafe.
I guess that we have to work a bit on scenario where the newest kernel crashes. What then? Debugging is fine idea, but having working alternative from the boot medium is better to bring masses to openSUSE, which bring more people willing to test.
Crashes, I've not seen; hangs whilst booting when udev starts up. Problems with screen resolutions and graphics drivers, or being unable to find the right disk or installation media. By the time, that kind of user is trying to install openSUSE they should have a kernel that's been run and tested widely; they ought to have experimented with Live CDs. They are not useful testers to a development release, their bug reports and skills to provide further information won't be high enough, nor will their motivation to see through an issue to a fix. Software is far more modular and more robust, if it's well written; it's just not true that installing a new version of GNOME with a certain version of gcc, is going to break perl scripts say, because the perl interpreter will be interfered with. The software packages are independant and rpm's job is partly to ensure there aren't conflicts, and keep perl & GNOME seperate. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2009-01-03 at 11:46 +0100, nordi wrote:
properly. Suse-specific translations come to mind, they are always finished _very_ late in the process so that it is almost impossible to report bugs against missing/incomplete/wrong translations early enough for them to be fixed. Because finding a bug does not mean it gets fixed early enough for GM.
Translation has to be late, almost the last thing to do. If the translators do it early, and the dev changes a single comma in a string, the display reverts to English (for that entire string), and the translation has to be remade. It is a lot of work, and if it get worse the sooner you do it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklgBH8ACgkQtTMYHG2NR9UomgCcCrO5Oe+fGxQA1COi8/FejrvE 9gEAn2CKgLS+bcM2RY/n5mwopVbvw1U8 =wUEG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/3 Eric Springer
On Sat, Jan 3, 2009 at 10:23 AM, Bryen
wrote: There's three answers to that. 1) Testing, 2) Testing, 3) Testing.
I daresay, any issue that isn't found during the current testing stage is going to be rare enough to be insignificant (in contrast with the thousands of known ones).
Unfortunately some make bug report, then don't respond with information required to investigate the problem. Whilst sometimes, the problem may be easily reproducible by Novell staff, other times it is not, but reliant on having certain hardware combinations. This leads to the situation where, bugs go unfixed from release to release, and also don't get upstreams attention. So actually, there is a shortage of the right kind of persistent well motivated "testing" which is needed by developers to fix. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Rob OpenSuSE a écrit :
So actually, there is a shortage of the right kind of persistent well motivated "testing" which is needed by developers to fix.
Rob, you said many interesting things, I answer here for simplicity. Not only I'm testing less than before, but I'm nearly leaving openSUSE, at least if the process don't change. 11.1 don't work on my wireless config (intel, of course bug known - usually intel is free?), and I have to boot 11.0 to have Internet and mail when moving, this is a blocker for me... we should absolutely have an ordered debugging process: kernel modules at the very first, then X, then GUI, application come later. And we shouldn't leave any non corrected bug in basic system. If devs can't find the bug, ask for help here "we need badly to solve #XXX bug, please help". I certainly will do my best in such situations. knowing what kde or gnome version we have is plain ridiculous if we can't have a working computer... jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-01-02 at 18:23 -0600, Bryen wrote:
There's three answers to that. 1) Testing, 2) Testing, 3) Testing.
The problems we face are not enough testing and too close to end of cycle when more people start testing. And the other thing about "bugs", is that sometimes it has to be in combination with how you use the machine. I'm finding a relatively smooth experience on my 11.1 box with a few annoying bugs, others are experiencing crashes. Why? Different usage of their machines. It's impossible to come up with every possible scenario for testing.
So... more Testing, Testing, Testing as early on as possible. The extended period for 11.2 might yield better results for us because it gives us all more time to test.
No. It crashes. I can't test anymore. End of history, no more testing. What we need is solving issues, and crashes/locks/lost data go first. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklfOzIACgkQtTMYHG2NR9W/jQCdFoPpKQPIL4MuKO2UKEUI6tst vj4AoI/qRiWSyqKU380jUfv8ACupwqYJ =UMhS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
2009/1/2 Cristian Rodríguez
Carlos E. R. escribió:
I think it would be better to delay the box and add the first month or two of patches.
Im sorry, but that makes abosolutely no sense to me, look only like a massive waste of the already reduced resources we have.
What positive suggestion would you make to improve the boxset release
quality, presuming you agree that the current model of a whole load of
alpha, beta and rc releases, where release label are "not predictive
of quality" and "there are too few alpha & beta testers", with many
joining at rc stage (too late)?
Scanning buglist, forum and email list, will show up a whole slew of
issues, which need fixes asap, for a large number of previous users of
openSUSE.
2009/1/3 Bryen
On Fri, 2009-01-02 at 17:15 -0600, Kevin Dupuy wrote:
On Fri, 2009-01-02 at 01:25 -0300, Cristian Rodríguez wrote:
Of course I don't expect that, and I did phrase that comment misleadingly. What I mean is why are we releasing with known bugs that are apparently pretty visible to users on the desktop, as some have reported.
There's three answers to that. 1) Testing, 2) Testing, 3) Testing.
The problems we face are not enough testing and too close to end of cycle when more people start testing. And the other thing about "bugs", is that sometimes it has to be in combination with how you use the machine. I'm finding a relatively smooth experience on my 11.1 box
So... more Testing, Testing, Testing as early on as possible. The extended period for 11.2 might yield better results for us because it gives us all more time to test. -- Bryen Yunashko openSUSE Board Member
At last, someone with an official position who seems to see that there is a problem; which is absolutely clear, if you spent time answering 11.1 problems on forum or in opensuse mail list around the release. When issue are denied and made light of, particularly from @suse.de or @novell.com email addresses; there is going to be damage to community relations. 10.3 had a longer release cycle, on the 3 systems I had, it was at least as problematic, and some network drivers were intimittently broken, which caused lots of confusing symptoms and misleading bug reports. So many issues, that "fatigue" set in, and thoughts of installing an alpha, or beta release; with presumed even lower quality were quietly shelved. Without some change to the proposed release plan, many alpha's & beta's, couple of rc's, with 1 big main release; I would expect to see exactly the same problems all over again. Having installation iso's which don't boot, have an opportunity cost to openSUSE's user base, and eventually to Novell's SLE because of the weaker community. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
Carlos E. R. escribió:
I think it would be better to delay the box and add the first month or two of patches.
Im sorry, but that makes abosolutely no sense to me, look only like a massive waste of the already reduced resources we have. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Carlos E. R. escribió:
I think it would be better to delay the box and add the first month or two of patches.
Im sorry, but that makes abosolutely no sense to me, look only like a massive waste of the already reduced resources we have.
But it does for some of us - just look at the answers I got >:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklerhwACgkQtTMYHG2NR9VXJwCcDey8UpkWfybEjLCifspfiDsp Nw0An2u/BDf/M1hQvk+kbwNhqWPDyIjm =lkE8 -----END PGP SIGNATURE-----
On Wed, Dec 24, 2008 at 2:16 AM, N B Day
If it isn't profitable or convenient to have a boxed release simultaneous with the general release, then why not do a box mid cycle or even late in the cycle incorporating all the updates and even a dvd or two with some of the main repositories?
Absolutely. To most people 2 or 3 months old, is pretty damn new. And during that time, there's going to be a lot of bugs fixed that the user would've inevitably ran into (or be swamped with updates .. which is a nightmare on a slow/dialup/pay-per-usage connection). And also, a lot of things need time to settle, guides/tutorial updated and software packaged. For instance, right now I'm unable to get the proprietary ATI drivers working in 11.1 -- but in a week or two, I'm sure it'll be well reported (and probably have it's own repository on ati.com) And some of the bugs, might even stop the user installing -- which leaves a terrible impression. The very first time I tried Ubuntu, my mouse completely didn't work. It wasn't a show stopper for me (I managed to update without use of the mouse) but it left a bad taste in my mouth, and I never went near it again, for at least a year. While it's fun to stay on the cutting edge, it's not what your typical end user needs/wants. (With the exception of some rare software or device support). Especially if we're only talking a few month delay. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
participants (31)
-
Andreas Jaeger
-
Benji Weber
-
Boyd Lynn Gerber
-
Bryen
-
Carlos E. R.
-
Carlos E. R.
-
Christian Boltz
-
Clayton
-
Cristian Rodríguez
-
Dean Hilkewich
-
Dominique Leuenberger
-
Druid
-
Eric Springer
-
Graham Lauder
-
James Tremblay aka SLEducator
-
jdd
-
Joe 'Zonker' Brockmeier
-
Kevin Dupuy
-
Magnus Boman
-
Marcus Meissner
-
Michael Loeffler
-
N B Day
-
nordi
-
Philipp Thomas
-
Rajko M.
-
Richard (MQ)
-
Rob OpenSuSE
-
Stanislav Visnovsky
-
Stephan Binner
-
Stephan Kulow
-
Vincent Untz