UP communication complaints.

Important informations about SolydXK including releases notes, forum rules and other anouncements
User avatar
ChipButty
Posts: 21
Joined: 19 Jun 2013 23:52

Re: UP communication complaints.

Postby ChipButty » 08 Nov 2013 17:38

Montala wrote:Why not just adopt the "It will be released when it is ready" approach?
I would be perfectly happy with a "release when ready" approach too or maybe a general aim of getting it out within the first half of the month or so giving you a two week window instead of one day. For me presonally I don't mind if the UP's are late. I don't feel a burning need to get the latest ASAP every month and if I needed that kind of thing I'd move over to something like Arch and get real bleeding edge. One of SolydXK's primary purposes is stability and if stability requires extra time then so be it. I think a more general relase date approach might be better and of course will ease the pressure on the testers.

User avatar
dyfet
Posts: 55
Joined: 05 Apr 2013 11:41
Contact:

Re: UP communication complaints.

Postby dyfet » 08 Nov 2013 17:44

Indeed, one of a number of things I do like about the distro is the "relatively frequent" update packs, rather than either a pure (sid or arch style) rolling distro, or one that gets locked in place for long periods of time. But to me, "relatively frequent" can just as happily mean every 3 months, or simply "as needed", rather than on a fixed and monthly schedule...
fleabus wrote:
Schoelje wrote: ...Release on the 15th, even if we're done earlier.

By extending the period we can take off the pressure of testing (more time, so we don't need to hasten), and decrease the chance that we have to postpone the go-live.

So, what do you think?
ane champenois wrote:Less pressure, less need of communication, less risk of breakage, no more postponing: the way of simplicity. Ok for me :geek:
^^^ Agree with ane. Schoelje, you've got plenty enough to do, I would hope this would ease the "UP-pressure" somewhat.

-- Dave
Information in the computer age is the last genuine free market left on earth except those free markets where indigenous people are still surviving - Russell Means

User avatar
Arjen Balfoort
Site Admin
Posts: 9394
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP communication complaints.

Postby Arjen Balfoort » 08 Nov 2013 20:04

Companies, and organizations tend to plan any IT activity, including updates. Releasing the UP "when it's done" cannot be planned around current IT related projects, and will introduce a risk in the the organization's project planning.
You can plan your organizational IT projects, and make the necessary resources available more easily when you know when exactly you can expect the updates.


SolydXK needs you!
Development | Testing | Translations

Fargo
Posts: 896
Joined: 17 Sep 2013 14:40

Re: UP communication complaints.

Postby Fargo » 08 Nov 2013 20:37

My first question is why did we need the newest kernel compiled by Santa? Not that I don't appreciate his work and helping us out. The work Santa does is greatly appreciated. But what did this newer kernel give us that the kernel in Debian testing did not offer? Why are we going outside of Debian Testing for this? Putting aside for the moment the issue of the delayed UP. What is the benefit vs stability cost of kernels outside of Debian testing. What I am asking is, can compiling newer kernels outside of Debian Testing produce incompatibility/stability issues? If so, what is the benefit of newer kernels that we would give up stability for it? If there are no stability or compatibility concerns with a different kernel then I have no issue with newer kernels.

So with the kernel concerns aside, lets get back to the delay and UP schedule. I think a couple of reasonable solutions have been made.

1) Release the UP on the (10th?) or 15th of each month to give more time to complete the testing
2) Move to quarterly releases to give more time for testing.
3) Only use core packages directly available through Debian Testing. There is no need for more recent kernels or KDE etc than what Debian testing has. This will reduce the need for secondary testing.
4) #1(or #2) and #3 above - Use only Debian Testing along with a later release date.

Personally, whether it is for business or home, I prefer stability to bleeding edge. So I am happy to push back the release date to the 15th. And if adding newer kernels or any other packages may cause stability or compatibility concerns then leave them out. Lets stick to Testing and what has been approved through Debians quality control procedures. It seems to me that when distros start grabbing packages from SID or elsewhere to have the latest and greatest is when trouble starts to appear. As far as having the latest and greatest packages goes. If the package is available in Debian Testing, let us be happy with the version that is available in Debian Testing and only replace or update what Solyd testing has found to be an issue. Isn't that the point of basing on Testing and then doing further testing?

Obviously SolydXK Packages and outside packages like Firefox and others that are not available in the Debian Testing repos are the exception to the Debian Testing rule. But in general my opinion is to use Debian Testing packages only and to move the UP release date back to the 10th or 15th if more time is needed for testing. I do appreciate the consistency of knowing the UP will be released on the same date each month.

User avatar
Zill
Posts: 1850
Joined: 13 Aug 2013 14:28
Location: Lincolnshire, UK

Re: UP communication complaints.

Postby Zill » 08 Nov 2013 20:55

dyfet wrote:Indeed, one of a number of things I do like about the distro is the "relatively frequent" update packs, rather than either a pure (sid or arch style) rolling distro, or one that gets locked in place for long periods of time. But to me, "relatively frequent" can just as happily mean every 3 months, or simply "as needed", rather than on a fixed and monthly schedule...
+1

Regarding companies needing to know exactly when to schedule updates, I suggest that it is far more important that they receive good, fully tested, updates, rather than ones that have been pushed through prematurely to meet some (unnecessary) timeline.

A longer development cycle for UPs would help this by allowing more time for testing prior to formal release.

Similarly, to ensure stability, I agree with Fargo that Solyd should primarily use Testing packages as the baseline, with Sid packages rarely, if ever, used.

User avatar
fleabus
Posts: 1227
Joined: 16 Sep 2013 04:24
Location: Winchester, VA USA

Re: UP communication complaints.

Postby fleabus » 08 Nov 2013 21:23

Schoelje wrote:You can plan your organizational IT projects, and make the necessary resources available more easily when you know when exactly you can expect the updates.
Agree, Being able to plan for the UPs is good, and you _are_ targeting businesses here. However whether the UP occurs on the 6th or the 15th, it's still only ~30 days between UPs. The only way to ease the pressure is to increase that to ~45 days, or ~60 days, or whatever...

-- Dave

Fargo
Posts: 896
Joined: 17 Sep 2013 14:40

Re: UP communication complaints.

Postby Fargo » 08 Nov 2013 22:24

fleabus wrote:
Schoelje wrote:You can plan your organizational IT projects, and make the necessary resources available more easily when you know when exactly you can expect the updates.
Agree, Being able to plan for the UPs is good, and you _are_ targeting businesses here. However whether the UP occurs on the 6th or the 15th, it's still only ~30 days between UPs. The only way to ease the pressure is to increase that to ~45 days, or ~60 days, or whatever...

-- Dave
Its still only 30 days between ups for the end user. But since Schoelje is syncing with Debian testing on the 30th of the previous month it goes from 6 days of testing to 15 days of testing.

User avatar
fleabus
Posts: 1227
Joined: 16 Sep 2013 04:24
Location: Winchester, VA USA

Re: UP communication complaints.

Postby fleabus » 09 Nov 2013 00:01

Fargo wrote:...since Schoelje is syncing with Debian testing on the 30th of the previous month it goes from 6 days of testing to 15 days of testing.
:oops: I missed that, Thanks Fargo..

-- Dave

User avatar
zerozero
Posts: 5373
Joined: 10 Feb 2013 23:37
Location: West Midlands, England
Contact:

Re: UP communication complaints.

Postby zerozero » 09 Nov 2013 00:16

Schoelje wrote: I propose the following:
We start as we usually do:
  1. Last day of the month: synchronize Debian repository, and prepare the testing environment.
  2. Start testing when done synchronizing (usually the first day of the month).
  3. Start testing KDE when updated.
  4. Release on the 15th, even if we're done earlier.
By extending the period we can take off the pressure of testing (more time, so we don't need to hasten), and decrease the chance that we have to postpone the go-live.

Separating the software packages from the regular updates is more complicated to maintain. Often the regular updates cause changes in the software packages, and I'd like to minimize the update moments to a minimum in that I want to prevent package updates in between UP's.

So, what do you think?
in practical terms this is a maintenance nightmare:
  • a) a couple days before the sync with testing we are already focused in the upcoming UP;
    b) from day 1 to day 14 we **need** and **should** focus all the attention in the UP-testing (we all want a reliable and solid UP, right?)
    c) from day 15 onwards (let's give it a weeks time) we **need** to support UP-Production (with mirrors syncing late and users not updating in the first day it's not that much)
    d) we are on the 22th day of the month; have left roughly 8 until a new cycle starts
    e) and this in months that we are not planning new isos; because on those months some of those dates will have to overlap
basically we will live perpetually in testing/updating/testing.

====
what started as a topic to gather information about the best way to communicate the UP-process soon shown some of the perceived limitations of the process we have atm:
  • 1- the testing period is too short
    2- the UP rate is too high
probably we should focus in these.
bliss of ignorance

User avatar
fleabus
Posts: 1227
Joined: 16 Sep 2013 04:24
Location: Winchester, VA USA

Re: UP communication complaints.

Postby fleabus » 09 Nov 2013 00:36

zerozero wrote: ...in practical terms this is a maintenance nightmare...
...basically we will live perpetually in testing/updating/testing.
...some of the perceived limitations of the process we have atm:
  • 1- the testing period is too short
    2- the UP rate is too high
probably we should focus in these.
Yeah, that's what was on my mind in my post above, ~30 days? To do all that? :shock: Y'all are gonna wind up in the loony bin before too long... :lol: I don't know how you managed to handle it all even thus far. Things really take off and you get a lot more users, it'll only get worse... Seriously folks, all kidding aside, How about ~60 days? Before Schoelje and zz become burn-out casualties of the UP battle? :)

-- Dave

User avatar
ChipButty
Posts: 21
Joined: 19 Jun 2013 23:52

Re: UP communication complaints.

Postby ChipButty » 09 Nov 2013 02:13

Well there's the danger of becoming another LMDE isn't there? I do like the semi-rolling aspect of Solyd and if I'm not mistaken LMDE does their update packs every 6 months which I don't care for and would be sad to see Solyd end up like that. I like getting them every month but again if it's late it doesn't bother me.

User avatar
fleabus
Posts: 1227
Joined: 16 Sep 2013 04:24
Location: Winchester, VA USA

Re: UP communication complaints.

Postby fleabus » 09 Nov 2013 02:45

ChipButty wrote:...I do like the semi-rolling aspect of Solyd...
Yes, so do I, it's one of the many reasons I'm here. And yes, the idea of doing monthly UPs is so the updates don't stack up so high, but they are carrying quite a heavy load! ~45 or ~60 days between UPs might cut down on the pressure. I wish I knew more about the development stuff and could help in some way, but I'm a hardware maniac.

-- Dave

User avatar
ane champenois
Posts: 1539
Joined: 24 Feb 2013 08:17
Location: Grands lacs Forêt d'Orient, France

Re: UP communication complaints.

Postby ane champenois » 09 Nov 2013 07:07

Thanks ZZ for giving us elements that I miserabily forgot :oops:
zerozero wrote: what started as a topic to gather information about the best way to communicate the UP-process soon shown some of the perceived limitations of the process we have atm:
  • 1- the testing period is too short
    2- the UP rate is too high
probably we should focus in these.
For me you're right...at the moment: if we had a more numerous 'testing community' and 'dev squad', these problem could be forgotten. Please correct me if I'm wrong.
-----
What about a 6 weeks or a 2 months release :?:
They did not know it was impossible so they did it.

dyfi
Posts: 88
Joined: 15 Mar 2013 17:45

Re: UP communication complaints.

Postby dyfi » 09 Nov 2013 09:11

As an ordinary home user OS stability is more important for me (and probably many others) than knowing the exact date of UP. As previously mentioned in this topic, when the icon shows updates in your Panel one click and away you go. That really is very simple! If the developers and testers can make life easier for themselves by rearranging schedules - I'm all for it.

User avatar
Arjen Balfoort
Site Admin
Posts: 9394
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP communication complaints.

Postby Arjen Balfoort » 09 Nov 2013 10:34

I really like where this discussion is going.
Thinking about better scheduling, improving quality, and (not the least important) making it better maintainable for the testing team is very valuable for the continuity of SolydXK.

I've heard many good responses, and these are the ones that appealed most to me:
  • Decrease frequency of the UP's to quarterly periods (every 90 days).
    Quarterlies are periods that can be planned by organizations, it gives the testing team time to breath between UP's, it gives me time for development, marketing, and other stuff that's piling up...but for home users it might be too long.
  • Increase the testing period for obvious reasons.


SolydXK needs you!
Development | Testing | Translations

User avatar
fleabus
Posts: 1227
Joined: 16 Sep 2013 04:24
Location: Winchester, VA USA

Re: UP communication complaints.

Postby fleabus » 09 Nov 2013 11:39

Schoelje wrote:...better scheduling, improving quality, and (not the least important) making it better maintainable for the testing team...
  • Decrease frequency of the UP's to quarterly periods (every 90 days).
Makes Solyd even better at keeping the vision for which it was created: rock-solid dependable+modern, a system that business and home users can rely on.
Schoelje wrote:...but for home users it might be too long.
IMHO At the very least go to 60 days to give yourself, zz, and the testing folks breathing room.

-- Dave

User avatar
sjmur
Posts: 23
Joined: 06 Nov 2013 14:49
Location: Dublin, Ireland

Re: UP communication complaints.

Postby sjmur » 09 Nov 2013 13:51

If we go down the 90 day release route then will we see a new kernel every 90 days? A nice, stable one.
//Mozilla Rep, Web Developer, Open Source supporter, Community Manager, Irish//

User avatar
Montala
Posts: 6
Joined: 02 Nov 2013 18:12
Location: Herefordshire (U.K.)

Re: UP communication complaints.

Postby Montala » 09 Nov 2013 16:33

I am trying to look at this from both sides of the fence, as it were!

With my 'home user' hat on, I would naturally prefer to see a new release every 60 (rather than 90) days, which I think would also help to give SolydXK an advantage over other distros.

However, as has already been said, it does take time as well as experience and effort to ensure that what is ultimately released is a solid and reliable product. I guess that the developers and testers are not actually being paid for doing this, and neither are they able to spend the majority of their time working on it.

A lot of them are family men with possibly a wife or partner, and also children with whom they enjoy spending time... and then there is a house and garden to maintain, holidays to be taken etc, etc. If however I have made any wrong assumptions in this post, then I will apologise now!

It is obvious that there is a very dedicated team here, under the guidance, or 'umbrella' of Schoelje, and it is important, I feel, that unreasonable demands are not made on them.

Again, I apologise if, as a relatively new forum member, I am speaking out of turn here, but I have been round the block a few times already! ;)

User avatar
pnlarsson
Posts: 21
Joined: 30 Aug 2013 21:19
Location: Gothenburg

Re: UP communication complaints.

Postby pnlarsson » 09 Nov 2013 19:40

Schoelje wrote: I've heard many good responses, and these are the ones that appealed most to me:
  • Decrease frequency of the UP's to quarterly periods (every 90 days).
Having 90 days between would need some updates during that time - firefox / thunderbird comes to my mind.
I really like SolydXK for the updates (refuge from LMDE) and 90 days without any is a very long time - how about security releases?

Even a week ago I kind of expected firefox and thunderbird to be released before the UP (got tired of clicking away the upgrade notice from thunderbird).

Well this is my 2 öre, you are doing a great job! And you need to have time to live as well - we want this distro to be around for many years!

/niklas

User avatar
Arjen Balfoort
Site Admin
Posts: 9394
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP communication complaints.

Postby Arjen Balfoort » 09 Nov 2013 19:57

sjmur wrote:If we go down the 90 day release route then will we see a new kernel every 90 days? A nice, stable one.
Depends on what Debian if offering at that time.
I also don't remember Santa building any kernels, and when I run apt policy, all kernel packages come from the debian repository, not from packages/kdenext (which is used for Santa's packages).

Code: Select all

$ apt policy linux-image*
linux-image-3.10-3-rt-amd64-dbg:
  Installed: (none)
  Candidate: 3.10.11-1
  Version table:
     3.10.11-1 0
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages
linux-image-rt-amd64:
  Installed: (none)
  Candidate: 3.10+52
  Version table:
     3.10+52 0
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages
linux-image:
  Installed: (none)
  Candidate: (none)
  Version table:
linux-image-3.10-3-amd64-dbg:
  Installed: (none)
  Candidate: 3.10.11-1
  Version table:
     3.10.11-1 0
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages
linux-image-3.10-3-amd64:
  Installed: 3.10.11-1
  Candidate: 3.10.11-1
  Version table:
 *** 3.10.11-1 0
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages
        100 /var/lib/dpkg/status                                                                                     
linux-image-amd64:                                                                                                   
  Installed: 3.10+52                                                                                                 
  Candidate: 3.10+52                                                                                                 
  Version table:                                                                                                     
 *** 3.10+52 0                                                                                                       
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages                                        
        100 /var/lib/dpkg/status                                                                                     
linux-image-3.10-3-rt-amd64:                                                                                         
  Installed: (none)                                                                                                  
  Candidate: 3.10.11-1                                                                                               
  Version table:                                                                                                     
     3.10.11-1 0                                                                                                     
        500 http://debian.solydxk.com/production/ testing/main amd64 Packages                                        
linux-image-2.6-rt:                                                                                                  
  Installed: (none)                                                                                                  
  Candidate: (none)                                                                                                  
  Version table:


SolydXK needs you!
Development | Testing | Translations


Return to “News & Anouncements”

Who is online

Users browsing this forum: No registered users and 2 guests