About unofficial/unstable repositories...

orelien · 2003-01-27 16:05:02

I've quoted this from an answer of our so much devoted Sarah31

zsnes will be upoaded (as all new packages will be) in the near future to unstable before being moved to unofficial. unstable will tell the user that the package is largely untested outside of the committer's box and that i *may* contain bugs. After a spell in unstable or a commiter deems it stable enough it will be moved to unofficial. Some packages such as cvs or development versions of application will stay in unstable until the developers deem it stable enough for a release version and at that point it will be moved to unofficial. An example of the latter is phoenix or mysql4 both are either development versions or cvs and have not met with official release versions by the applcaiton developers.

To my understanding, mysql4 is unstable because it is a developpement release. It does not depend on the quality of the package.

I think an 'unstable' repository containing both untested and unstabled packages mixed together could lead to confusion.
To my understanding, unstable means 'from a development release'.

I think it would be better to have an 'untested' repository aiming at hosting contributed packages from incoming. 'untested' would mean that the package was contributed and that it could be broken (missing dependencies, paths layout not in line with Arch specifications, ...).

After a while in the untested repository (enough to say that the package was corretly be done: pkg info ok, paths ok, dependencies ok, ...), it could be moved to unofficial... or to unstable!!!

Let's explain. Why not spilt unofficial in 2 new repositories: unofficial (for stable applications) and unstable (for unstable/cvs/developpement applications)?

OK, I think I wrote enough for today... Let's have a break

sarah31 · 2003-01-27 18:18:33

well i am not to keen on another repository as i think three is too many myself. this debated by the developers and it was decided that unstable would be for new, cvs and developer packages. With only the new packages being moved out as they were more tested and cvs woould NEVER be moved. Development as it was declared stable.

Basically this follows the Debian format. Unstable comes with the warning that the packages are largely untested or sourced from development branches.

however, if apeiro deems your suggestions as worthy of another tree i will go along.

apeiro · 2003-01-27 19:35:54

orelien wrote:

I think an 'unstable' repository containing both untested and unstabled packages mixed together could lead to confusion.
To my understanding, unstable means 'from a development release'.

I have to agree here. Using the unstable repo for untested packages will mean a lot more packages moving from unstable to unofficial as they are approved by packagers. I would rather 'untested' packages were tested before they were put in any repository.

sarah31 · 2003-01-27 19:56:59

well i never put stuff that is not tested locally in the trees however my box's configuration is not like someone else's and i have only one other box with one other configuration to test on. If it works on both then i consider it tested on my part. As i have found though packages that tested fine on my box later had unwanted configurations that limited their use to only a certain few people that had alsa installed. As well packages that had worked fine for me from the unofficial tree that were uploaded by the previous maintainer did not work for others (sdl_foo).

what i am trying to say is the i consider any new package as largely untested and therefore unstable until more people with various different computer setups have tried them out. that is why i mentioned the beta testers and suggested and unstable repository in the first place so that users of the unofficial tree would know that when they installed something from unofficial the chances that it would work on their system were very good. unofficial, afterall, is supposed to be the repository for packages that arfch caries outside of the main repository which i assume is meant to be kept to a minimum for various philosophical and practical reasons.

by untested i mean that it works for me and/or jk and for the person who submitted it but who knows beyond that. THAT is not extensive testing imho and therefore with the uncertainy that there may be undetected bugs for other users the package is unstable. is that the wrong way to be thinking?

jk · 2003-01-27 20:33:46

I agree with Sarah here. If a package works for me, that doesn't mean it'll work for others.

apeiro · 2003-01-27 23:00:14

Right, I agree with her too, but that's not the point of dispute. I don't want to keep a bunch of 'untested' packages in an 'unstable' repository. They don't mean the same thing.

The choice is basically whether we want another repository or not. I'd rather not have to open a fourth at this time, but you guys have a say in this too. We could just leave untested packages in /incoming (where they often begin their lifespan anyway) or move them to an /untested directory after an arch packager has verified the package. Users can download them from there until the packages move to a real repository.

My reasoning is that I'd like to avoid creating/managing another cvs module and pacman database for a package group that contains most packages only temporarily. The majority of packages in an untested category will likely move to another repository after they have attained 'tested' status. Until a package finds its home, I'd rather not commit it to one of our cvs modules.

Thoughts?

dunbar · 2003-01-28 12:19:59

Hypothetically speaking: Newbie thinks this is confusing; ducks anything not declaring itself as being a totally production grade release. Newbie suffers a poor Linux experience, because 90% of Linux packages are never at production grade. Newbie discards Linux and returns to the lying and thieving evilOS.

U$D0.02: disclaimer explaining tree intentions: untested vs unstable vs official.

Untested: only one person thinks this package is as functional as the original code permits it to be; only one person tested the package and felt that no errors were seen to be introduced by the build process; insufficient testing has taken place. The next likely repositories for this package include being discarded or placed in stable; after testing, placed in stable is because the source code is deemed stable.

Unstable: authoratative entities (either multiple individuals or the author) feel that the source code will always lead to an unstable package, build errors are not considered in this category as a goal, there are to be no build errors of any kind in any package. The next likely repositories are any of the repositories, since instability may be induced by dependancy issues.

Official: Archlinux has built these packages and over the existing life of this exact package, there has been no causes observed for deeming the package as either unstable or untested. If the package is stable and tested, it must already exists as an Arch package, since stability and testing both depend on environment in which it is tested.

Just food for thought, edit at will.

Arch Linux

#1 2003-01-27 16:05:02

About unofficial/unstable repositories...

#2 2003-01-27 18:18:33

Re: About unofficial/unstable repositories...

#3 2003-01-27 19:35:54

Re: About unofficial/unstable repositories...

#4 2003-01-27 19:56:59

Re: About unofficial/unstable repositories...

#5 2003-01-27 20:33:46

Re: About unofficial/unstable repositories...

#6 2003-01-27 23:00:14

Re: About unofficial/unstable repositories...

#7 2003-01-28 12:19:59

Re: About unofficial/unstable repositories...

Board footer