Direction

[Kaleb]

Soooo....

We've been having discussions in IRC about stuff, and... it seems like there's a pretty strong consensus that we really don't like the recent set of Cooker breakages (for me, rpm distepoch, sound, apache, and one other thing... can't remember). For me, I can't seriously expect my end users to hold on to a system if RPM is going to break. Not only that, but I'm sick of Cooker developers screwing around with my work system-- this is the second time in about 2 months they've broken my sound. So here are the potential scenarios for change. What sounds best to people?

Scenario: Stick with Cooker
Advantages: Stay up to date, closer to a rolling release model, always able to see what's coming down the pipe soon.

Drawbacks: Instability, breakage, and all the stigma that comes with it.

Scenario: Stick with Cooker, implement some kind of filter.
We could implement a filter in Smart which could temporarily block upgrades or could only allow upgrades the UL team has approved.

Scenario: Move to Stable series
Advantages: Stability, no worrying about hitting a moving target.
Drawbacks: Applications may be older, may lack features. Transitioning from one stable series (2011) to the next (2012) may cause breakage. So breakage may simply be delayed and not avoided. I personally strongly prefer some kind of rolling release. I just don't like breakage.

Scenario: Go back to using MDV cooker SVN, but manage our own binaries.
Advantages: We can stay behind MDV a week or so and avoid a lot of the breakage, while still staying pretty well up to date. We can still contribute upstream to MDV. I personally like packaging, and I have a quad-core that isn't doing anything most of the time.
Drawbacks: I don't know if we have the manpower for this. A lot could simply be automated, but setting up the system to have it be automated could be time-consuming.

Scenario: Use something else for a base (Yoper, for example).
Advantages: Unknown; case by case basis

Drawbacks: Unknown; case by case basis

Scenario: Make our own base.
Advantages: Complete control. We can effect complete stability overall and be bleeding edge in a few non-critical areas.
Drawbacks: Manpower, again.

I personally don't know what anybody else is thinking, but I am going to take this downtime while things are broken and I'm going to try out Linux From Scratch. I'm not *planning* on going anywhere. I'm just doing it as an educational opportunity and to learn as much as I can about Linux so I can do as much as possible.

I am actually somewhat leaning toward striking out on our own. When I was away from Unity, I started work on a packaging system. It's looking a little tempting again.

What do you think?

[Chris Evans]

---

From: Kaleb <djj...@gmail.com>
To: ul-developers <ul-dev...@googlegroups.com>
Sent: Friday, March 23, 2012 11:44 PM
Subject: [ul-developers] Direction

I think I like having repos that are already managed by a distro larger than unity. But if this is how things are going to be - always broken and never knowing when the next upgrade will break it again - then the hell with that. Why can't unity do like alot of other distros out there and base on stable, or at least relatively stable and backport from testing? Could it be possible to have both a stable release and a testing release? IF I have to choose one or the other, I want my system to work please. That is not happening the way it is now at all. I mean I can always go to rpm.pbone and download something more up to date to install if I want to risk breaking my system. But at least that remains my choice to risk it. I was so happy to be running with TinyMe and Unity again, and it lasted about a week before things started breaking left and right. That sucked worse than running PCLOS again for the last year. Again if I have to choose I'll take a stable base and just update one by one my rpm's to newer versions. At least that way I'll know what the hell I broke and have a good chance of fixing it myself.

[freedomrun]

I am glad that you wrote this as it is better said than my poor english
spelling ever would.

1st we need to solve problems not run away from them as even that is
not much easier than solving

- it looks that you`re not aware what we have gone through to get here
where we are right now, on cooker and that means development so now
we have great chance to contribute to the linux community not just
depend on it

we need all your coding skills, bug reports, thoughts, ideas, energy
and available time as if you`re doing remasters you are closer to know
what I mean. You can better see what is missing or what could work
better or what worked and don`t work anymore. If you don`t know or
cannot find how to fix things fast bug reporting will bring you faster
problem fixing.

Anyway I am not going to repeat what we all should already know so I`m
gonna be short and my suggestion is:

- stay on cooker
- report all bugs you know or discover on the Unity Linux issue tracker
which is for bug reports and feature requests. (devnet we need it up)
or here in ML
- keep a copy of stable kernels, udev and rpm5 related packages in our
own repo to use it like buffer for keeping us on the surface of
cooker`s sea of development process. This could buy us some time.

As we have that chance I say we should go for it.

- we need a meeting to agree on this anyway

I hope I did wrote this in pretty much understandible english.
Best regards

[OnlyHuman]

Maybe most of KDulcimer's and other unity users concerns could be met
by what freedomrun has said,
users need reliability, other wise who would use unity.
If people hear good things about unity then hopefully more users will
be attracted.
I would also say, having again a unity-desktop iso would be handy for
less experienced users,
that is if unity wish to have a broad base of users.
Also more compatibility with pc's and graphics cards, would be helpful
as some people have on irc and the forum reported
getting just a black screen after grub boot splash.(intel graphics on
an i3 was one),. thought some other distro's booted fine apparently.

[Douglas Wilson]

I am an observer here and I have observed the best Scenario was the last one, but there were not enough hands helping out so I have observed where unity is now. I observe from an end user perspective and I seen a lot of breakage.

Maybe if there was a lot of help unity could have it's own base. I like the scenario too of holding back packages or updates at first like Mint does.

 Doug

--
Use Linux

[Raphaël Jadot]

Maybe before choosing a scenario, we should wait what will Mandriva
become :)

[Kaleb]

2012/3/24 Raphaël Jadot <ashle...@hodo.fr>

Maybe before choosing a scenario, we should wait what will Mandriva
 become :)

I have been sitting around, playing the waiting game, and loosing all my end users for the past 3 years now. Enough waiting has been done. It's time for action.

[Raphaël Jadot]

The fact is that, even though not annouced officially, Mandriva SA the
company will create an independant foundation that will be be in charge
of the distribution. So it will be a fully community driven distro. I've
been pushing a lot so that Unity would be an major leader in this new
structure, and JM Croset, the Mandriva COO told me that this is now the
moment for contacting him.

I don't know what will be the future of Mandriva (the distro) and what
will be its name, but if UL leave the ship now, it just won't be able to
keep the user/contrib base of Mandriva that will leave for Mageia or
Ubuntu or something else.

It's a good moment (maybe the only one) for creating a good organization
around RPM5

If there are breakage problem, please talk about that with Per Oyvind
and Jeff Johnson that are very kind people, and will understand all
problems.

And please, Derrick or Matthew or anyone contact JM Croset
jmcr...@mandriva.com

Raphaël

[Raphaël Jadot]

I forgot, please no official announce before mandriva does it, this
will happen very soon

[Matthew Dawkins]

2012/3/24 Raphaël Jadot <ashle...@hodo.fr>

Sorry, I'm on travel and kinda only read bits and pieces, but I think I understand the POV and the frustration.

I've talked to devnet about this in the past.
My plan was to do two types of releases.

First primarily based on cooker and help keep development rolling.

Second, based on Mandriva releases. This I think is what many of you remasterers are looking for. It will supply a stable platform and minimal upgrades of the most popular pkgs.

The problem going forward from UL repos to Mdv repos was this, there was too much work to upstream to cooker and then also turn around and backport to 2011. The problem wasn't just porting mklivecd and some of our tools to cooker, but also conditioning much of cooker to a Unity style too.

Does this help ease concerns?

[Chris Evans]

It does help to know. I want to use Unity everyday like I used to do. Can't do that if everyday I boot my machine to find another thing broken. I mean I'll gladly dual boot so that I can have my stable install when I need it and still be of some small help to Unity testing and the like. But for the majority of us end users I think the main reason we use linux in the first place is we are all control freaks at heart. Having my system broken and not knowing how to fix it irks me to no end ;)

---

From: Matthew Dawkins <matt...@gmail.com>
To: ul-dev...@googlegroups.com
Sent: Saturday, March 24, 2012 11:30 PM
Subject: Re: [ul-developers] Direction

[Thomas Fröhlich]

now i read this and understand the problematic, my suggestion is,
1. change to  our self base, just this be very importent to continue with the speed of rpm-evolution;
2. basepkg just should be toolchain up to kernel and depencies like dkms-?? and x.. task's for printing, X, etc... but not for DE's
3. not a DE-environment, that better the remasters make it self for e.g. xfce or gnome ......
4. so not all pkgs must keep on the dev-build-servers,
5. the remasters can setup and keep repos of DE-depended pkg self

so not a crashing while building DE by use a lib- or whatever with depencies they would not have into a blank xfce -- just as example
Regards

2012/3/26 Chris Evans <z3r0_...@yahoo.com>