incoming update policy

[zerozero]

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;

[GeneC]

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;

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.

[nunol]

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

[grizzler]

- 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?

It would certainly make sense to me.

[darknetmatrix]

imo a weekly update would be great if it is possible

[samriggs]

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

[zerozero]

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

[samriggs]

cool

[nunol]

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.

[amina]

That's funny, some got "updateitis" (by craig10x) from using LMDE, I think the other half of us got absolutely addicted

[samriggs]

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.

Weird things happen on full moons, ask any hospital, can see it now with some breakages and some computers being torn to shreds
Sorry couldn't help myself with that one.

[Helmsdeeper]

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.

[Gerd50]

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

[acithium]

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

[zerozero]

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.

[samriggs]

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

[acithium]

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.

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?

[clem]

this request is as easy to write as blind in the implications behind it, so please Clem, go easy on me

OK

- for what i understand incoming has an one month (roughly) update rate, the same as latest, only before?

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.

- incoming role is basically to test regressions, breakages, issues so the latest update can be as safe as possible?

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.

- 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?

Yes. It depends on the content. Right now it's all about MESA and Gnome 3. These

- 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;

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.

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

[kmb42vt]

That's funny, some got "updateitis" (by craig10x) from using LMDE, I think the other half of us got absolutely addicted

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.

[zerozero]

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