"Arch Indirect Support"

georgia_tech_swagger · 2008-08-12 18:10:38

I have experienced the breakage lately with numerous community projects as Arch has pushed out updates. Pacman's upgrade was discussed on the dev list for some time, but it was only in testing for a few days. Its upgrade hosed yaourt and shaman. Yaourt was quickly fixed, but shaman is only just now getting fixed. When KDE 4.1 was pushed out it broke anything KDE related if you used KDEmod for 36 hours until the KDEmod team had a chance to push out new builds.

So ... Arch has a number of verifiably badass community projects. Excellent.
These get broken with alarming frequency during routine updates. Frowny face.

So -- perhaps we could create something along the lines of "Arch Indirect Support". Packages likely to break major community related projects (such as KDEmod, shaman, etc) are required to be held in testing for x number of days to allow those projects to catch up. The only alternative to this is much more strict dependency versioning with packages in Arch. And the devs I spoke to didn't like this, because it creates more work on their end, and then they get bugs filed when upgrading fails due to deps.

What does everybody think about this? Unreasonable? Better idea? Want to flame me because "zomfg ur like uh complete N00BER"?

kensai · 2008-08-12 18:29:28

The community projects runs around Arch, we don't run around the community projects.

It is true we do appreciate and some of us use these community projects, but wee can't let them be the factor between our development, and how we do things. The users knows that certain upgrade might break certain things, but in due time it will get fixed. You can always abstain from upgrading certain package because you know it will break this and that community project, until the said project upgrades itself.

georgia_tech_swagger · 2008-08-12 18:31:55

But that requires forehand knowledge that upgrading x will break y. It's impractical to check the forums for every package you upgrade isn't it?

Does it hurt the Arch devs or the Arch experience that much to just have a required time period for some things to be in testing?

Mr.Elendig · 2008-08-12 18:36:12

Well, when it comes to the late pacman/libalpm changes, most of them shoudn't have been a big suprice, since most of the changes have been in the git tree for a while. And as you said, it was also discussed on the dev list, so the shama/yaourt devs should have had the opertunity to update their code, and when 3.2.0 finaly hit testing, check that their update was good.

When it comes to kdemod, as far as I remember, there were just one 'breakage' for kdemod, when kde4.1 hit [extra], but at the same time there were repo changes etc in kdemod too that made updates imposible without user interference anyway. It could also have been avoided if the kdemod devs had asked the mantainer of the arch's kde pkg's what he planned to do for the release.

I feal that it's just as mutch a problem with communication between the mantainers of the community projects and the arch devs, as anything else. (not blaming either side)

Snowman · 2008-08-12 18:40:23

I think it's up to the people who work on community projects to keep track on what's going on with pacman and the Arch packages.

Users working on pacman frontends shoud be subscribed on the pacman-dev ML. All the patches are posted there. If they have a good knowledge of the pacman code, they can probably find what changes that can cause breakage. Plus any plans about future pacman release are posted there as well. The first mention about an upcoming pacman 3.2 was posted on June 6: http://archlinux.org/pipermail/pacman-d … 12070.html. That is more than 2 months before pacman 3.2 went in core. IMO, that is ample time to build a pacman-git package and see what needs to be fixed in the frontend.

Same thing for kdemod, discussions about an upcoming kde 4.1 started in the arch-dev public ML way before it even went in testing. Also, Pierre mentionnened that he were in contact with the kdemod people. So they were kept informed.

EDIT: Mr.Elendig was faster to post.

jdhore · 2008-08-12 18:45:49

I believe it's a problem on both ends. It's a problem with the community/3rd-party devs not having foresight (hehe) and spending 5 minutes looking at either the git repo or the pacman-dev mailing list or [testing]. Also, it took almost 7 days for the KDE4 merge in Extra to finish. the KDEMod devs couldn't have checked the RSS and fixed it before it became a problem?

This being said, i do also blame Arch a bit. The number of KDEMod and Shaman posts just on this forum alone are astounding enough to assume they're the 2 most popular Arch community projects. Being that they are, Arch should have some sort of "support team" (which i would volunteer for) where...When Pacman 3.2.0 is about to hit Extra/Testing, the support team emails the Shaman dev to let him know that it'll break shaman and to fix it. Same with KDEMod (though that probably won't be necessary till KDE 5.1).

georgia_tech_swagger · 2008-08-12 18:46:52

Regarding mailing lists ... I hate em. I avoid them if possible. I love forums. I even run a *massive* forum site. I think it's a generational thing. Most the people my age in the local LUG are the same way. And somewhere around 35+ everybody starts to hate forums and love mailing lists.

But kudos to Pierre for reaching out. Only took a minute ... and probably greatly shortened the breakage time with KDEmod 4.1.

But the main reason I focused on a time requirement in testing is it seemed (to me at least, but I'm no dev) to be a good compromise. It doesn't require projects to go out of their way to stay up to date ... it doesn't require devs to go out of their way to stay up to date. Simply have a testbed running [testing]. Sync it a few times a week to ensure (insert name of community project you work on here) still works. If it doesn't, you can fix the problem before it affects everybody.

Last edited by georgia_tech_swagger (2008-08-12 18:51:33)

Dusty · 2008-08-12 18:53:21

The current testing procedure is not based on 'time spent in testing' but verification in testing. Core packages must be tested and signed off by two developers before they go out. For non-core packages, it is up to the individual packager to request such signoffs if they think its a big issue.

In the past, things have spent weeks or even months in testing and there was still major breakage at the time it was released to core/extra, so if there is a problem, I don't think this solution would fix it.

Personally, I haven't had any major breakage on my system since the devfs-->udev upgrade, so I don't really see the problem.

Dusty

Mr.Elendig · 2008-08-12 18:54:52

jdhore wrote:

I believe it's a problem on both ends. It's a problem with the community/3rd-party devs not having foresight (hehe) and spending 5 minutes looking at either the git repo or the pacman-dev mailing list or [testing]. Also, it took almost 7 days for the KDE4 merge in Extra to finish. the KDEMod devs couldn't have checked the RSS and fixed it before it became a problem?
This being said, i do also blame Arch a bit. The number of KDEMod and Shaman posts just on this forum alone are astounding enough to assume they're the 2 most popular Arch community projects. Being that they are, Arch should have some sort of "support team" (which i would volunteer for) where...When Pacman 3.2.0 is about to hit Extra/Testing, the support team emails the Shaman dev to let him know that it'll break shaman and to fix it. Same with KDEMod (though that probably won't be necessary till KDE 5.1).

I think that aproach is a wrong one. It will be 'a warm place' to try to keep track of all projects that might break from any changes to the arch repos. Trying to keep track of the butterfly effect will requier an ever increasing amount of work, and in most cases you won't prevent enough problems for the manpower to be worth it. How will you know that some update in arch is going to break something in another project or not?

edit:

But the main reason I focused on a time requirement in testing is it seemed (to me at least, but I'm no dev) to be a good compromise. It doesn't require projects to go out of their way to stay up to date ... it doesn't require devs to go out of their way to stay up to date. Simply have a testbed running [testing]. Sync it a few times a week to ensure (insert name of community project you work on here) still works. If it doesn't, you can fix the problem before it affects everybody.

From my viewpoint, the only thing that would achive is to delay more or less important updates for x amount of time. (And create alot of threds with the title 'FOO CAME OUT 3 WEEKS AGO WHY ISN'T IT IN ARCH!?!?! ZOMG ARCH DEVS SUXCKS; ARCH ISN*T ROLLING; ARCH NIDS NEW LADERSHIP')

Last edited by Mr.Elendig (2008-08-12 19:05:05)

Lord Illidan · 2008-08-12 19:01:56

Wasn't the shaman dev on vacation? In that case, how could he fix his program while pacman was still in testing?

Personally, I think the cycle should go as it is now, but if a developer, say of yaourt or shaman finds that his program is not complying with the version under testing, he should make a forum post or comment about it on AUR, and perhaps ask the testing maintainers to withold it for a little while?

kensai · 2008-08-12 19:44:55

There is never a problem if they communicate with us, so far the Arch Devs have proven to be very understanding and communicative. As I said before, some of us use community projects and like them.

In my case I've had people emailing me directly about packages and other stuff. That is the best way to get things working smoothly between devs and users.

Last edited by kensai (2008-08-12 19:47:02)

drf · 2008-08-12 20:08:50

Guys, speaking for Shaman: it took me a single day to get it back working, well, let's say 3-4 hours. Yeah, there is still one known bug since I had to do things quick, but nothing so harmful, as it's only in visualization. So I was ready for the update, though I was simply away

I feel like quoting everything the devs said. Upgrading x breaks y because this is how software works. If you want to step forward you have to break something, and there's nothing wrong about this. The only reason you experienced downtimes in community projects is just because it's August and everyone has a pretty intense real life, and this month I'm off. Moreover, it was a lucky chance I got home for a day and I had the time to fix this.

Pacman 3.2 got in testing right the day after I left, so this is how things went, and I'm sure that if everything happened in September the problem wouldn't even have been there.

Cheers everyone

EDIT: Anyway, kudos to Allan that in the fixed Shaman package put dependencies on pacman>3.2 && pacman<3.3. I feel like this is the best way to avoid breakages and notify people.

Last edited by drf (2008-08-12 20:14:54)

shining · 2008-08-12 20:55:23

Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!

georgia_tech_swagger · 2008-08-12 20:59:33

drf wrote:

Moreover, it was a lucky chance I got home for a day and I had the time to fix this.

drf · 2008-08-13 08:37:33

shining wrote:

Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!

Ops... forgot that... This will never happen again.

/me goes back to the anti-atomic bunker and starts coding 24/7

Lord Illidan · 2008-08-13 09:03:58

drf wrote:

shining wrote:
Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!
Ops... forgot that... This will never happen again.
/me goes back to the anti-atomic bunker and starts coding 24/7

Evidently we need more whips around here!

funkyou · 2008-08-13 11:56:49

To speak for KDEmod: We are always aware of changes... And about Shaman: drf does a marvellous job with it and he is always aware and fixes stuff very fast...

Snowman wrote:

Same thing for kdemod, discussions about an upcoming kde 4.1 started in the arch-dev public ML way before it even went in testing. Also, Pierre mentionnened that he were in contact with the kdemod people. So they were kept informed.

Its also the other way around. We are working together since Pierre started packaging KDE4 and exchange our stuff and keep it in sync...

jdhore wrote:

This being said, i do also blame Arch a bit. The number of KDEMod and Shaman posts just on this forum alone are astounding ...

In my opinion, most of these post could have been avoided if people actually search and read a bit... There were even people asking for install/upgrade instructions, although these instructions were available at the known places (tm)...

tlaloc · 2008-08-13 12:09:58

shining wrote:

Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!

Indeed - I suggest that all of the devs get encarceled behind a - say, 5 metre-high wall of barb-wire (including the guys and girls from community projects). Electrically loaden barb-wire, of course. AND we need about a dozen of well-trained Dobermanns to patrol the outskirts.
But we could have community votes on whether someone gets released for holidays ...:D

Mr.Elendig · 2008-08-13 12:39:25

tlaloc wrote:

shining wrote:
Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!
Indeed - I suggest that all of the devs get encarceled behind a - say, 5 metre-high wall of barb-wire (including the guys and girls from community projects). Electrically loaden barb-wire, of course. AND we need about a dozen of well-trained Dobermanns to patrol the outskirts.
But we could have community votes on whether someone gets released for holidays ...:D

Barbed wire is to easy to cut trough, use constatine wire instead.

tlaloc · 2008-08-13 17:49:42

Not good enough in my eyes - we could use footshells to get the devs disciplined. You know, these tiny little bands around their ankle joints. I have a cheap source for Semtex, and maybe we could use GPS to locate them. So everytime that a dev steps away more than 10 metres from his work station, he will just be blown up. Who needs an idle dev, right?

drf · 2008-08-13 22:34:58

tlaloc wrote:

Indeed - I suggest that all of the devs get encarceled behind a - say, 5 metre-high wall of barb-wire (including the guys and girls from community projects). Electrically loaden barb-wire, of course. AND we need about a dozen of well-trained Dobermanns to patrol the outskirts.
But we could have community votes on whether someone gets released for holidays ...:D

Sounds good to me - as long as we're both guys & girls.

Megamixman · 2008-08-13 22:45:26

tlaloc wrote:

shining wrote:
Wait wait wait...
Now developers can take holidays and stop working for free for all Arch users?? NO WAY!
Indeed - I suggest that all of the devs get encarceled behind a - say, 5 metre-high wall of barb-wire (including the guys and girls from community projects). Electrically loaden barb-wire, of course. AND we need about a dozen of well-trained Dobermanns to patrol the outskirts.
But we could have community votes on whether someone gets released for holidays ...:D

That's called an Office Building. The only thing you're missing is the cubicle dividers. They are there to keep the minions from reproducing at uncontrollable rates.

Last edited by Megamixman (2008-08-13 22:46:29)

tlaloc · 2008-08-14 00:54:40

Sounds good to me - as long as we're both guys & girls.

It goes without saying that this plan is beyond of any form of sexual harrassment or discrimantion. So girls will get torn up by Dobermanns at an equal rate:)

wain · 2008-08-14 17:24:00

I speak for yaourt. Sometimes yaourt is broken after pacman upgrade (like pacman 2.9 to 3.0) or AUR upgrade. Usually, I can prevent or update yaourt quickly because I'm keeping informed with ML dev.
Real advantage to have some sort of "support team" is not for the emergency but for minor regression bugs or enhancement request.
Some task are just closed because "We dont support 3rd party tools". Community projects deserve more consideration.

georgia_tech_swagger · 2008-08-14 22:51:46

Some task are just closed because "We dont support 3rd party tools". Community projects deserve more consideration.

I'm not alone! I'm not alone! *sob*

Arch Linux

#1 2008-08-12 18:10:38

"Arch Indirect Support"

#2 2008-08-12 18:29:28

Re: "Arch Indirect Support"

#3 2008-08-12 18:31:55

Re: "Arch Indirect Support"

#4 2008-08-12 18:36:12

Re: "Arch Indirect Support"

#5 2008-08-12 18:40:23

Re: "Arch Indirect Support"

#6 2008-08-12 18:45:49

Re: "Arch Indirect Support"

#7 2008-08-12 18:46:52

Re: "Arch Indirect Support"

#8 2008-08-12 18:53:21

Re: "Arch Indirect Support"

#9 2008-08-12 18:54:52

Re: "Arch Indirect Support"

#10 2008-08-12 19:01:56

Re: "Arch Indirect Support"

#11 2008-08-12 19:44:55

Re: "Arch Indirect Support"

#12 2008-08-12 20:08:50

Re: "Arch Indirect Support"

#13 2008-08-12 20:55:23

Re: "Arch Indirect Support"

#14 2008-08-12 20:59:33

Re: "Arch Indirect Support"

#15 2008-08-13 08:37:33

Re: "Arch Indirect Support"

#16 2008-08-13 09:03:58

Re: "Arch Indirect Support"

#17 2008-08-13 11:56:49

Re: "Arch Indirect Support"

#18 2008-08-13 12:09:58

Re: "Arch Indirect Support"

#19 2008-08-13 12:39:25

Re: "Arch Indirect Support"

#20 2008-08-13 17:49:42

Re: "Arch Indirect Support"

#21 2008-08-13 22:34:58

Re: "Arch Indirect Support"

#22 2008-08-13 22:45:26

Re: "Arch Indirect Support"

#23 2008-08-14 00:54:40

Re: "Arch Indirect Support"

#24 2008-08-14 17:24:00

Re: "Arch Indirect Support"

#25 2008-08-14 22:51:46

Re: "Arch Indirect Support"

Board footer