Larry Finger wrote:

...

work on E17 is still in progress but I believe that E17 is very well usable for everyday use already. Please, tell me your opinion here.

I use LXDE on a couple of underpowered laptops. I tried E17 about 3 months ago, and I was underwhelmed! Has it improved that much recently? At the moment, if support for LXDE were to be dropped, I would likely choose another light-weight desktop, but not E17.

I'd almost, 2nd the above in so much that the LXDE is the one that is most likely to come up with low resource usage.. and w/o alot of bells and whistles -- it's a bit above a raw Xterm and has good configurability and flexibility -- simple but it had a polish to it. As a desktop it comes up notably faster than Gnome or KDE which are slow to start. This is more noticeable over a remote connection (even if the connection is on a local LAN). The only thing that is close has been XFCE.... I'll most often use their terminal emulators to login for work. Starting up a gnome or kde term takes forever when it's the only thing you are starting. E17 -- I would like to see it more polished. Work on it seems to be going very slow and it doesn't seem as polished and 'done' as LXDE. Not exactly the answer you were looking for -- but am wondering -- what type of compression does the DVD use? Has it switched to xz or would it be too slow? Are there binaries for install on E17 to try in factory? or where? Trying out the current work might stimulate more people to care one way or the other. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-05-14 19:22, Linda Walsh wrote:

Tomas Cech wrote:

...

Candidates for remove based on sense of aliveness?

...

There is one obvious choice - xxx doesn't seem to be much alive.

One reason something may not seem alive is that the needs of its users are being met -- which isn't the same as it not being used.

If the needs are met, the mailing lists would be practically (but that could also mean that the users have already left). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, In this special case, why not Xfce? It's already in our rescue system. And a rather stupid question: Why not just add another DVD? Allow me to list the DEs we have in OBS: * GNOME family: GNOME, MATE, Cinnamon, LXDE. * KDE family: KDE, KlyDE, Razor-qt. * Standalone family: Xfce, E17, awesome, i3wm, Unity. The ones we have in DVD: GNOME, KDE, Xfce, LXDE. I know some of them can only be used by developers for now, but anyway they'll grow and want to be in. If the condition one can be in is that another one has to be kicked out, the competition will be really hot. And anyway we'll run into a situation that one DVD is not enough because some of them can't be compared at all. If there're GNOME haters, certainly there'll be KDE haters. Debian made DVD 1-3, Ubuntu has derivatives, Fedora has spins. That's common situation in the industry. We can't say "oh we do have E17, but you have to install GNOME first and then uninstall it", if our "lightweight" means a heavy "download", I think users will choose by foot. And once a DE is in, certainly it'll gain enough users to prevent it from being kicked out. It's not a package, we are actually making the decision to kill someone out. So if we still want to keep the promise that no one will be left behind and there's no second-class citizen in openSUSE, we have to increase our capability in the long run. It may be more DVDs, special derivatives like openSUSE science, or Add-on CDs like those for languages. Greetings Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, May 15, 2013 at 9:56 PM, Guido Berhoerster wrote:

* Marguerite Su [2013-05-15 15:19]:

...

In this special case, why not Xfce?

It is laready on the DVD, it's just somewhat hidden in the Installer below "Others".

Hi, Guido, Yes, I know that. I mean: In this special case (E17 vs. LXDE in DVD), why not make it "E17 vs the Xfce in DVD"? because Xfce is already landing in our rescue system (a standalone DVD), while at the same time it's still in main DVD. It's redundant (forgive me I don't know how our rescue system works, I suppose it can get the full Xfce experience as that one in main DVD), so removing Xfce from main DVD won't hurt, because users can just download the rescue DVD, while it's even smaller. If in the short run we have to give E17 space (because although we have many DEs working, E17 is the only one made this proposal at the moment), I think this might be a better choice. Greetings Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marguerite Su wrote:

because Xfce is already landing in our rescue system (a standalone DVD), while at the same time it's still in main DVD. It's redundant (forgive me I don't know how our rescue system works, I

Hey, if you really wanted to save space and make openings for new packages... how about getting rid of KDE on the 'demo-disk'... and keep it in the main distro as one of the large kitchen-sink options. I'd think it was likely the largest (KDE/Gnome) and gnome is newer if that's the direction you wanna go -- though if size is important take off the biggest one from the DVD and add tons more smaller stuff...? Just throwing off ideas... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, May 15, 2013 09:18:41 PM Marguerite Su wrote:

Hi,

[...]

Why not just add another DVD?

This is a good idea, but has some drawbacks that we need to address. In openSUSE team we are trying really hard to improve the quality of our distribution. We had make some decisions in that regard, and we see that a good first step is to increase se coverage of the testing: we need to test the maximun number of different configurations for every medium, architecture, file system or boot loader (grub2, shim with UEFI, Secure Boot, ...). This is a combinatorial problem that we can see how fast grows making some numbers: suppose that we want to test only the installation process, and we have: * 5 medium (DVD, PromoDVD, KDE, GNOME, NET and Rescue) * 2 arch (x86 and x86_64) * 4 file systems (ext4, btrfs, LVM, LVM-encript) * 3 boot loaders (grub2, SHIM with UEFI, SHIM with Secure Boot) * 2 installation process (from scratch, updating and old system) The number of combinations that we need to cover is 240, and we need to do this for every stable build that comes from Factory, with more attention before milestones, betas or RCs. If we add a new medium, this number will add 48 more different scenarios where we need to test, and this is only in the installation part, where the desktop has less impact. We are addressing this problem now. We are updating openQA [1] to make those test automatically, and this is a lot of work. In fact, with the new openQA we are currently testing a very small subset of these 240 combinations. I am sure that when we increased the test coverage of the actual set of mediums, add a new medium to test will be a very easy work. [1] http://openqa.opensuse.org/

Greetings

Marguerite

Alberto Planas. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, May 16, 2013 02:55:54 AM Marguerite Su wrote:

On Thu, May 16, 2013 at 12:37 AM, Alberto Planas Dominguez

wrote:

...

The number of combinations that we need to cover is 240, and we need to do this for every stable build that comes from Factory, with more attention before milestones, betas or RCs.

If we add a new medium, this number will add 48 more different scenarios where we need to test, and this is only in the installation part, where the desktop has less impact.

Hi, Alberto,

I understand your concern and really appreciate your work to make our distro unbreakable.

But this growing trend will certainly drive us mad someday.

I can agree with that, but the future can be quite the oposite: the core distribution can be smaller but with higher quality / more tested components. In either way this decision is in the community hands, and my work is to help in whatever is the future of openSUSE as a distribution.

I don't know if our OpenQA can do all the testing, but I think anyway visual machines can't replace human-beings in the near future. So you'll be always lacking of capable hands.

You are right here again. VM has limits, we need to be careful that with this kind of tests we are not searching VM bugs, instead of bugs in the distribution. Also, automatic test has his own limits too. But if there is a percentage of the work that can be automatized with certain guarantee, I think that is a good idea to work on this.

As testers can't grow as fast as maintainers, why not make maintainers themselves do the testing by policy instead of ethic?

If you want to implement some basic QA in the process, you need some grade of reproducibility and tracking: you need to be sure what tests was made, by whom and the result of the test. There are tools for that, like testopia [1]. But in my opinion they are more for a real QA department, also is a slow tool with a very boring workflow. Can we impose such a thing to the maintainer? Is a lot of work, that need to be done in every integration process, and not only when a new version of the package is made. Another different thing is that the maintainer (or the community) provides a small perl script that use the openQA API to test the basic functionallity of the package, and there is an automatic process that launch this test when a new integration is made in Factory,

eg: some DEs are "officially tested by tester team", some DEs of small user database are "maintainer guaranteed". We just test base-system and GNOME/KDE.

This work can't be avoided. For 12.3 there was a weekend hackathon were contributors and maintaners like Dominique or Robert (and a lot more people) spend a full weekend testing and fixing bugs: there is not automatic test that can replace such a thing. But if some of the manual test can be expresed as a perl script (like testing the network, testing grub2, the integration between dbus and the DE, etc..), you can reproduce those test for every release, and be sure that we do not have a regression in one of the previously fixed bug.

And actually that's just the fact right now...lightweight DEs always have few maintainers, if they don't even guarante its working state, I certainly won't use it. Actually those DEs under development in OBS are all "maintainer guaranteed" fow now, they've already started getting users but have to wait for OpenQA to test and make them official.

Actually they do not need to wait for openQA to create a DE. But if we create a new official DVD for this DE, I think that we need to provide the same tests that for the other mainstream DE like KDE or GNOME. But this is only my opinion here. Also, the main problems is not in the DE, but in the integration points with other components, like NetworkManager, systemd ...

So why not, in the mid term, give them an entrance to second DVD by making a policy like "if you want it in, show me 100 people's test results", give them an "official unstable" entrance? It's kinda like creating a DVD on SuSEstudio yourself, but get backup from and promoted by openSUSE because you've proved you're usable although still need further professional testing.

If we had >100 tests for every milestone, beta and rc, with every arch, DE, FS, ... the automatic test tool can be completely avoided. But the problem is, again, in the integration part: a change in one component can break something in KDE, E17, or GNOME, and you need routinely tests to detect this.

I think that's what KlyDE do for now, I see Jos, Will and AJ, so I know it's of course usable even it's now in SuSEstudio. All we need is to add an entry on s.o.o and tell users it hasn't been officially tested yet.

It's kinda like "fix them then give out" vs "give them something to play first then fix them". I think users may prefer the last way, we just need some way to pick ourselves out of the responsibility. We can just tell them "okay I'm about to test it, but I got my hands full so it's on schedule. you're encouraged to fix and find workarounds".

I agree that this is the perfect approach for the development process. If you want to integrate a new DE, this is the way to go. My only concern is in the next step: put this DE as an official openSUSE medium, not as a package or as a installation option in YaST. This is the case that I think that we need to integrate those tests, because now we are distributing this DE.

At the same time, we can still improve our OpenQA's capacity in the long term. They do not conflict with each other.

Exactly, I do not see any conflict during the development / integration stage. [1] Testopia http://www.mozilla.org/projects/testopia/

Greetings

Marguerite

Thanks, Alberto Planas. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 15/05/13 09:02, Yamaban escribió:

Word of warning: Until you PROVE that E17 runs as fast and lean as LXDE on OLD (pentium1, 512mb) hardware, such a statement will get you scrores of enemies.

That is non-sense, I strongly object that we spend any sleep or human resources attempting to cater to the "pentium 1 , 512 mb" use-case. A phone probably has more computing power than that these days. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 16 May 2013 10:16, Linda Walsh wrote:

Cristian Rodríguez wrote:

...

El 15/05/13 09:02, Yamaban escribió:

...

Word of warning: Until you PROVE that E17 runs as fast and lean as LXDE on OLD (pentium1, 512mb) hardware, such a statement will get you scrores of enemies.

That is non-sense, I strongly object that we spend any sleep or human resources attempting to cater to the "pentium 1 , 512 mb" use-case. A phone probably has more computing power than that these days.

---

You don't understand the implications of that statement -- IT is not that it can run well on a [sic?] pentium 1? (rats ass) ...etc, but that it will run in a fraction of the resources as any other ..

If you have a heavily loaded machine or a server and you want lightweight pieces that are just a notable bit better than xterm, this fits the bill.

Another use case -- remote access where lightweight communications (not eyecandy as E17 has more of), can really make or break usability. I wouldn't be adverse to seeing E17 -- but I was part serious when I said let it compete and take the place of one of the big desktops -- ONLY on the 'demo' CD -- you'd get alot more bang for your buck if you eliminated one of those, but eliminating the low-resource/fastest one you will be changing people's perceptions of OpenSuse as not being "as able" to support the low end.

A common themed death knell among computer manufacturers was the retreat to the high end where they could get away with higher margins and more waste. I don't see that it would be that different in the open-linux environment...

I'll add to this: what runs more than "acceptable" on such small x86 hardware, has a more than decent chance run well on ARMv7, which, with respect to low-end tablets, low- to mid-end smartphones, and "le gasp" homeservers / mirco-computers (pogoplug, rasberry-pi, beagleboard, etc.). A prognosis: within max 5 years ARM (at least ARMv8 aka arm64) will be a first class member for linux distros. Now, do You want openSUSE to be one of the first to offer a full (incl. GUI [X11 / Wayland]), or one of the last, if at all. Not everybody has the money, room, or time to invest in ARM hw just for play right now, but such a "limited" Virtual PC is possible for most devs. - Yamaban.

Yamaban wrote:

A prognosis: within max 5 years ARM (at least ARMv8 aka arm64) will be a first class member for linux distros.

Now, do You want openSUSE to be one of the first to offer a full (incl.

GUI [X11 / Wayland]), or one of the last, if at all.

Per Jos'es announcement, opensuse 12.3 considers 32-bit arm a full-fledged member of the supported family. 64-bit arm is experimental. We have a arm based cluster now in obs so the builds are native. Apparently each manufacturer of MBs does it a little different so opensuse 12.3 has numerous media downloads to choose from, based on the type of MB you have. And as far as I know, opensuse is the first to release a full linux distro for arm. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 16, 2013 at 09:01:34PM +0200, toganm@opensuse.org wrote:

...

...

...

...

...

"GF" == Greg Freemyer writes:

GF> And as far as I know, opensuse is the first to release a full GF> linux distro for arm.

I might be wrong but I guess Debian was the first

I think so. I'm afraid that we were the last (after the drop). Debian, Gentoo, Ubuntu, Arch, all them have support. S_W

On Fri, 17 May 2013 09:07:47 +0200 Tomas Cech wrote:

...

- PROVE your claims of usability, esp. in low resource env.

How can I prove that?

One way is using Samsung data, if you can find them. Hardware that is used, software that is installed. The other would be to create setup with certain functionality and compare that to other options that provide the same set of features. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org