incoming update policy
Forum rules
LMDE 2 has reached end of support as of 1-1-2019
LMDE 2 has reached end of support as of 1-1-2019
incoming update policy
this request is as easy to write as blind in the implications behind it, so please Clem, go easy on me
- for what i understand incoming has an one month (roughly) update rate, the same as latest, only before?
- incoming role is basically to test regressions, breakages, issues so the latest update can be as safe as possible?
- wouldn't make more sense (to achieve this goal) to have a more frequent update rate (say weekly), so the issues could be tested and the fixes and/or workaround prepared to the next latest pack?
- this eventually would mean update a broken incoming once in a while, fine i say, the people in incoming made a conscientious choice, for the others there's now, thanks to your amazing work, latest, and anyway we just came from wild testing, so can't be worst
- what is the point of incoming then in this scenario i propose? easier for you to pint-point issues and regressions (the same as before) but with more time to find solutions
- this would mean a lot more work (yeahh i know) and this is the issue;
- for what i understand incoming has an one month (roughly) update rate, the same as latest, only before?
- incoming role is basically to test regressions, breakages, issues so the latest update can be as safe as possible?
- wouldn't make more sense (to achieve this goal) to have a more frequent update rate (say weekly), so the issues could be tested and the fixes and/or workaround prepared to the next latest pack?
- this eventually would mean update a broken incoming once in a while, fine i say, the people in incoming made a conscientious choice, for the others there's now, thanks to your amazing work, latest, and anyway we just came from wild testing, so can't be worst
- what is the point of incoming then in this scenario i propose? easier for you to pint-point issues and regressions (the same as before) but with more time to find solutions
- this would mean a lot more work (yeahh i know) and this is the issue;
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
Re: incoming update policy
Yes. I was thinking that just once a month was too long a period for the "incoming" repos, myself, once a WEEK would be better, but would like to hear opposing views. If its a matter of too much work on the maintainers part, I surely understand.zerozero wrote:this request is as easy to write as blind in the implications behind it, so please Clem, go easy on me
- for what i understand incoming has an one month (roughly) update rate, the same as latest, only before?
- incoming role is basically to test regressions, breakages, issues so the latest update can be as safe as possible?
- wouldn't make more sense (to achieve this goal) to have a more frequent update rate (say weekly), so the issues could be tested and the fixes and/or workaround prepared to the next latest pack?
- this eventually would mean update a broken incoming once in a while, fine i say, the people in incoming made a conscientious choice, for the others there's now, thanks to your amazing work, latest, and anyway we just came from wild testing, so can't be worst
- what is the point of incoming then in this scenario i propose? easier for you to pint-point issues and regressions (the same as before) but with more time to find solutions
- this would mean a lot more work (yeahh i know) and this is the issue;
Re: incoming update policy
Are we going to have a Patch Tuesday every week or are you going to choose another day?
http://en.wikipedia.org/wiki/Patch_Tuesday
http://en.wikipedia.org/wiki/Patch_Tuesday
Re: incoming update policy
It would certainly make sense to me.zerozero wrote:- wouldn't make more sense (to achieve this goal) to have a more frequent update rate (say weekly), so the issues could be tested and the fixes and/or workaround prepared to the next latest pack?
- darknetmatrix
- Level 3
- Posts: 156
- Joined: Fri Dec 19, 2008 9:10 pm
- Contact:
Re: incoming update policy
imo a weekly update would be great if it is possible
Re: incoming update policy
Sounds good to me, I was doing it pretty much daily or every few days before anyhow, the only thing is the people behind the scenes working on it, is it too much for them as they do have a lot on their plate right now with all the versions of mint going on?
I would rather see them get rid of the ubuntu based ones and switch everything over to this instead eventually, but that's just me.
Plus once a month updating is great I will admit that for the other four systems I update for but as far as finding breakages and fixing them it would take more testers to do it on different systems.
The only thing is will putting out updates with breakages deter people away from lmde?
Maybe have a monthly final updatepackage for those who don't want to test and a weekly one for the testers.
I don't know if that is even possible except to warn people in the mu to only update on this date for non testers or have a preference choice in the mu to be a tester or not that way the testers get the weekly and the nontesters get the monthly that way it gets a lot more testing and keeps the nontesters happy.
Might have increased the work load by double doing it this way though I don't know.
Sam
I would rather see them get rid of the ubuntu based ones and switch everything over to this instead eventually, but that's just me.
Plus once a month updating is great I will admit that for the other four systems I update for but as far as finding breakages and fixing them it would take more testers to do it on different systems.
The only thing is will putting out updates with breakages deter people away from lmde?
Maybe have a monthly final updatepackage for those who don't want to test and a weekly one for the testers.
I don't know if that is even possible except to warn people in the mu to only update on this date for non testers or have a preference choice in the mu to be a tester or not that way the testers get the weekly and the nontesters get the monthly that way it gets a lot more testing and keeps the nontesters happy.
Might have increased the work load by double doing it this way though I don't know.
Sam
Re: incoming update policy
nuno, why not tuesday
sam, this idea would only apply to incoming, so the issues and fears you are talking about, breakages that could scar users away from LMDE, wouldn't be an issue, because those have now a safer option -latest
sam, this idea would only apply to incoming, so the issues and fears you are talking about, breakages that could scar users away from LMDE, wouldn't be an issue, because those have now a safer option -latest
Re: incoming update policy
Tuesday is ok but it's on Friday night or during the weekend that users have more free time to have fun with the updates.
If Clem goes for the monthly updates I think the lunar month is better, it's shorter and we could update every full moon.
If Clem goes for the monthly updates I think the lunar month is better, it's shorter and we could update every full moon.
Re: incoming update policy
That's funny, some got "updateitis" (by craig10x) from using LMDE, I think the other half of us got absolutely addicted
Re: incoming update policy
Weird things happen on full moons, ask any hospital, can see it now with some breakages and some computers being torn to shredsnunol wrote:Tuesday is ok but it's on Friday night or during the weekend that users have more free time to have fun with the updates.
If Clem goes for the monthly updates I think the lunar month is better, it's shorter and we could update every full moon.
Sorry couldn't help myself with that one.
Re: incoming update policy
Weekly or bi-weekly updates seem appropriate under most circumstances, depending on the breakages. I wouldn't set a time in stone as some regressions need more time.
Re: incoming update policy
At first i thought well, incoming update repo i can use like i did with testing repo. But not, updates only once a month
That's not good for me. I have a damn slow coppercable connection (max dl speed 47 kb/s)
Update monthly for me means, it will take a lot of time to dl all the packages. As a copper worm i think, i'll further use the
terminal method. Then it's all the same whether it's tuesday, sun or moon shining and i'm able to prefer rainy days
That's not good for me. I have a damn slow coppercable connection (max dl speed 47 kb/s)
Update monthly for me means, it will take a lot of time to dl all the packages. As a copper worm i think, i'll further use the
terminal method. Then it's all the same whether it's tuesday, sun or moon shining and i'm able to prefer rainy days
Re: incoming update policy
My vote is for patch Tuesday. On another note, I think that kernel updates should be spaced apart a bit. This way if there is some breakage (kernel wise), we don't have mass panic (or in my case, just panic) over something not working due to the kernel. With more time between kernel updates, we could wait and see if they are patched down the road.
-Acithi
-Acithi
Re: incoming update policy
there's something else that should be pointed out: updating incoming in a monthly basis means a lot of pkgs each time, and it's more complex to debug breakages/regressions, making the next latest update pack trouble free a harder task.
Re: incoming update policy
I agree zero when you point it out that way, always easier to fix a few then many, I just did a complete reinstall of lmde (went crazy deleting things and adding things to try stuff out and borked a few things Lucky I backed up everyhitng first, but it took me all day to fix things. The software manager just stalled, had to get rid of the latest python-image 1.7.3 or whatever it was and force install 1.7.2 to get it working again, at first it took two installs and the apt-get -f then another install then finally the grub upgrade, had fun doing all this almost forgot what it was like since things been running too smoothly for awhile, probably borked my system on purpose subconsciously
Anyhow a good house cleaning is always good.
It does take quite a bit more to install it from the ISO now then it did before when I first did it months ago.
I was also wondering do you know when full blown gtk3 and gnome 3 is coming down the pipelines?
Sam
Anyhow a good house cleaning is always good.
It does take quite a bit more to install it from the ISO now then it did before when I first did it months ago.
I was also wondering do you know when full blown gtk3 and gnome 3 is coming down the pipelines?
Sam
Re: incoming update policy
Wow. I didn't really think of it like that. So do you think the bet way would be to stay pointed at the debian testing repo, and fix those issues and release the packs once a month to tackle the bugs one at a time?zerozero wrote:there's something else that should be pointed out: updating incoming in a monthly basis means a lot of pkgs each time, and it's more complex to debug breakages/regressions, making the next latest update pack trouble free a harder task.
Re: incoming update policy
OKzerozero wrote:this request is as easy to write as blind in the implications behind it, so please Clem, go easy on me
Not really... the one month thing is there as a rough guideline to make sure we don't leave things too long without attending to them. What drives for change isn't the calendar itself but the content of the update pack, the problems experienced by users and the fixes and breakages that occur upstream. For instance, right now, the MESA fix is triggering update pack 2 to come into Incoming. It's nothing to do with how long we've been looking at update-pack 1.- for what i understand incoming has an one month (roughly) update rate, the same as latest, only before?
Not exactly. It's for latest to be as "documented" as possible. If we're happy with the update pack in incoming, we document its regressions and we release it to latest. If we're not happy with it, we skip it and it doesn't make its way to latest. So all in all, at some stage in the future, latest will be "exactly" like update-pack 2 in incoming or update-pack 3 in incoming... but whichever update pack it has, that update-pack would have been in incoming beforehand and so we would know and have documented its related problems.- incoming role is basically to test regressions, breakages, issues so the latest update can be as safe as possible?
Yes. It depends on the content. Right now it's all about MESA and Gnome 3. These- wouldn't make more sense (to achieve this goal) to have a more frequent update rate (say weekly), so the issues could be tested and the fixes and/or workaround prepared to the next latest pack?
One last thing... as soon as we're happy with update-pack 2 in incoming it goes to latest. There's no "1 month" time period in between these two repositories. In quiet times we'd try to update incoming once a month, and have latest follow a couple of days later. In troubled times (like now) we try to get an update-pack ready as soon as something is fixed.- this eventually would mean update a broken incoming once in a while, fine i say, the people in incoming made a conscientious choice, for the others there's now, thanks to your amazing work, latest, and anyway we just came from wild testing, so can't be worst
- what is the point of incoming then in this scenario i propose? easier for you to pint-point issues and regressions (the same as before) but with more time to find solutions
- this would mean a lot more work (yeahh i know) and this is the issue;
The challenge for update-pack 2 is to bring a fix with MESA with as little Gnome 3 regressions as possible. As you can imagine, this means releasing as early as possible after MESA is fixed
Re: incoming update policy
I've started a "Testers Anonymous" group for the more senior LMDE testers who may be suffering from massive withdrawals when "Update pack 2" came in from "incoming" with no breakages. Some I hear are nearly catatonic.amina wrote:That's funny, some got "updateitis" (by craig10x) from using LMDE, I think the other half of us got absolutely addicted
"Humph. Choice, it is the quintessential Linux delusion, simultaneously the source of it's greatest strength, and it's greatest weakness." (All apologies to The Architect)
Re: incoming update policy
Clem,
As always, very clear.
Thank you very much for the time taken to answer and, may i say, clarify this questions. As someone said this is brand new
As always, very clear.
Thank you very much for the time taken to answer and, may i say, clarify this questions. As someone said this is brand new