Request: "Staging" for all packages

contrasutra · 2004-02-04 23:09:02

I only have one problem with ArchLinux, and that is that there is no "stable" track. Basically, the developer can update a package and it goes live without any sort of testing.

Although there is lots of testing done to get a package from incoming to the official repositories, any updated version of a package already in the repositories isn't tested before going live. The solution to this would be a "Staging" for ALL packages, not just ones from incoming.

If any package in the official repos has to be updated, the package goes into Staging (which would act as the staging does now, "unofficial/testing, but available from pacman") for a day or maybe two. At that time, anyone who likes to live on the edge can test it, and submit any bug reports.

If all goes well, it can then be merged into the official repositories. This would help solve the problem of downloading a broken package, and would also help if the actual program developer releases a quick update to fix some major problem, as they usually come a day later. Too often, I've had to download 2 or 3 releases of a package because the packager got something wrong the first time.

Also, I do understand that the major packages (mozilla, gcc) are tested, but more care should go into the "little" packages that could break something major. This solution would not require much extra work either. The "-s1" versioning in staging would also help staging and the normal repos work well together.

I know this isnt a replacement for a true "stable" track with strict testing requirements, but its half way there.

sarah31 · 2004-02-05 00:04:26

you are opening a can of worms here. this has been discussed quite a bit by the developers. i don't know if you'll see anything like you suggest.

personally i do no think all packages need to go through a staging. libraries either work or don't and you will know long before even submitting a package to staging.

then there is the issue with when is it okay to move a package out of staging? what criteria do you use? some packages either way will NOT be tested at all.

alot of people will not use staging. the idea of unstable software is scary to many/most and staging implies unstable.

personally i don't know a good solution. indeed something should be done though.

Xentac · 2004-02-05 00:49:55

It has been talked about and we've come to a conclusion on it. Testing will happen eventually; probably when I push for it more .

We will use a similar revision (-1t1) scheme for testing; that's where I got the idea for staging from.

Even if the testing repo is just used by developers, it's an easier medium for us to pass package changes back and forth. You can look forward to it in the future.

contrasutra · 2004-02-05 02:17:54

Eventually? :cry:

Well, I guess I can wait, but i dont know why it hasnt been implemented yet, its not too hard.

Then again, a "stable" branch would be cooler.

*contrasutra is waiting patiently*

Xentac · 2004-02-05 02:20:59

It's not hard for you to think about. It's a lot harder for us package maintainers though. We have to keep track of many many more things. To make sure the transition goes well, and there are no problems with the new system, we have to think a lot. Forgive us if we like to do things right.

sarah31 · 2004-02-05 05:00:35

might i suggest you get several more motivated packagers?

Moo-Crumpus · 2004-02-05 07:59:58

I would really like to do some packaging. Unfortunately, my job and family leaves little time to spent in learning it.

I would be glad if there was a kind of packaging tutorial in easy steps. Yes, I know there is a bit of stuff, and yes, I can fetch several package settings out of my abs. But puzzleing parts together is not the fastest way if you have only randomly and little spare time for it.

Xentac · 2004-02-05 08:10:45

We're working on the more packagers thing right now. But even then, I don't know how much more packagers can help with, other than more packages. Just because you have more people thinking about a problem, doesn't mean the problem will be solved any sooner.

I'll tell you, if this was my day job, things would happen a lot faster (that was to all the people with corporate funding).

sarah31 · 2004-02-05 12:53:04

well more will allow for a proper 'testing/staging' repo. however, partime devs are plentiful already on arch, arch needs more people that can work on it in a more full time capacity.

it is getting very obvious that the days of being able to treat it as a part time project are rapidly coming to an end.

contrasutra · 2004-02-08 01:15:41

I know you dont want to "mess things up" with a bad implementation of staging, but I am now forced to download ALL of gnome again, because of some little packaging mistake.

I spent the last 6 hours downloading it, and I now have to do that again, on dialup.

Yeah, I know this isn't constructive, but it's things like this that show how important a staging is. Some sort of package testing is needed before going into the official repos, or you will cause MANY people MANY problems.

Frankly, I would put this at the top of the list of things that need to be fixed. And yes, I understand the devs are busy.

apeiro · 2004-02-08 01:21:25

contrasutra wrote:

I know you dont want to "mess things up" with a bad implementation of staging, but I am now forced to download ALL of gnome again, because of some little packaging mistake.

It's not a packaging mistake, it's a configuration change/improvement that trickled down from libglade in current. The fact that Blaasvis has upgraded gnome the day before is sheer coincidence.

Staging is one of the developers' current active discussions, and will be looked at in detail after 0.6's release.

One step at a time.

Xentac · 2004-02-08 01:32:47

I'd prefer to refer to this testing repo as "testing" and continue calling the Trusted User Repository named staging "staging", just so they don't get confused.

contrasutra · 2004-02-08 02:06:47

apeiro wrote:

It's not a packaging mistake, it's a configuration change/improvement that trickled down from libglade in current. The fact that Blaasvis has upgraded gnome the day before is sheer coincidence.

Well, maybe it wasn't a mistake, but if you are going to update big packages (GNOME, KDE, kernel, etc), you should make sure something's not going to happen within the next 2-3 days that will force you to rebuild everything.

Xentac: Yeah, "testing" is more descriptive.

I think the problem is in some of the secrecy. Xentac encouraged us not to talk about this so much. Sure, lots may be happening with the development, but we really don't know about it. For example, we don't know when 0.6 will be released, or even what critera are needed for the release.

For this, I think a weekly newsletter would be great. It could give us all the gory details about what when on, not holding anything back.

Once again, I don't want to sound ingrateful. I'm sticking with Arch, as nothing comes close.

Xentac · 2004-02-08 03:02:53

I will say that I like some of the secrecy we have. Not because I feel like I'm more privileged than anyone else (phew, side stepped that one well), but because we talk about a lot of stuff that might get people rattled or that they'd be really bored about.

I've thought about a newsletter before. Even if it was just one about all the things happening in the community, I think it'd be helpful. That way people could see common problems and stuff.

Having a newsletter about what went on in the dev side is a good idea as well. I'd like to be involved with that... but I keep wanting to be involved in everything.

How's this sound? If someone steps forward to make a weekly newsletter of the forum and ml (and tur-users?), I will submit what's gone on in dev land every week. That way I don't have to manage the thing and someone can bug me to give them stuff

sarah31 · 2004-02-08 08:42:25

contrasutra wrote:

Well, maybe it wasn't a mistake, but if you are going to update big packages (GNOME, KDE, kernel, etc), you should make sure something's not going to happen within the next 2-3 days that will force you to rebuild everything.

um are you serious? there are very few software developers that provide advanced information to distro developers. case in point no one working on freetype bothered to inform the community of the pending changes between 2.1.5 and 2.1.7 and you know what the end result of that was. ehll those guys did not even advertise anywher other than on freshmeat the 2.1.7 was out.

i know that the maintainers of large package groups try their very best to stay ontop of thing and release when they are sure it is safe to. but sometimes it just does not work out.

as for the devs being secretive. that is their right to do so if they put everything to the community for approval consideration everything they desired to do would be argued. i think a general road map of things they are working on (such as testing) is a good idea but i don't think that anything more detailed is necessary.

even then road maps are a problem because everyone in the community will have what they see as different priorities. yours is testing, anther persons i proxy support, etc. some are more recent others are long standing so how do you place them on the map?

then the question is how badly will you bug the developers to stick to their road map? will you pester them to work on testing while their exams are going on?

what you are asking is not as simple as clicking a few buttons because we all know that you would likely be the first one to bitch if testing was not perfect right off the bat. then there would be all the bitching to get things through it quickly.

and so forth...

sorry ben i am not trying to insult you but just trying to implore you for a little patience. not to mention try and make you not press so hard the few developer that arch has. right now arch is quickly becoming more than a part itme distro and you have to allow the developers to make that transition.

Xentac · 2004-02-08 09:19:13

Now that freetype was brought up I'll mention a little irony that I found. Somewhere in 1.x they made a mention in the changelog (and mailing list) about the usage of includes (specifically the thing we ran into) and that support for the old method might not be guaranteed in later 1.x versions.

It looks like they stuck it out for as long as they could and finally took the steps in 2.x.

Arch Linux

#1 2004-02-04 23:09:02

Request: "Staging" for all packages

#2 2004-02-05 00:04:26

Re: Request: "Staging" for all packages

#3 2004-02-05 00:49:55

Re: Request: "Staging" for all packages

#4 2004-02-05 02:17:54

Re: Request: "Staging" for all packages

#5 2004-02-05 02:20:59

Re: Request: "Staging" for all packages

#6 2004-02-05 05:00:35

Re: Request: "Staging" for all packages

#7 2004-02-05 07:59:58

Re: Request: "Staging" for all packages

#8 2004-02-05 08:10:45

Re: Request: "Staging" for all packages

#9 2004-02-05 12:53:04

Re: Request: "Staging" for all packages

#10 2004-02-08 01:15:41

Re: Request: "Staging" for all packages

#11 2004-02-08 01:21:25

Re: Request: "Staging" for all packages

#12 2004-02-08 01:32:47

Re: Request: "Staging" for all packages

#13 2004-02-08 02:06:47

Re: Request: "Staging" for all packages

#14 2004-02-08 03:02:53

Re: Request: "Staging" for all packages

#15 2004-02-08 08:42:25

Re: Request: "Staging" for all packages

#16 2004-02-08 09:19:13

Re: Request: "Staging" for all packages

Board footer