vote on the bleepin packaging/incoming debate

LB06 · 2004-05-07 19:31:57

wdemoss wrote:

Ok, I know I'm coming into this discussion late. Mainly because I feel this is mostly a decision to be decided by the devs. But I have a few ideas related to the two threads raging over package management that I thought I would contribute.
My first idea involves testing and staging and requires some modifications to pacman. Instead of having a testing and staging repo, make it a level of confidence for each repository. So the layout of the repos would be something like this:
current
    stable
    testing
    staging
extra
    stable
    testing
    staging
unstable
    stable
    testing
    staging
then in pacman.conf you would specify the level of confidence in the repo name, for example [current level=testing]. If no level was specified, then stable would be used by default. Package resolution would be staging->testing->stable, so that a newer version of a package in testing would be chosen before stable if the level of confidence chosen was testing. When a package is deemed stable, it is just copied over from testing to stable, and the index is regenerated.
This way each class of packages has it's own stable/testing/staging path.
...
-wd

Imho this is a good idea. It's basically similar to mine, after all.

One flaw: Why does unstable have three 'confidence' levels? Unstable exists mostly out of bèta's and RC's. The only way those packages will become stable is by upgrading them to a non-beta/RC version, which makes unstable=>testing/stable even less than useful. I mean, as soon as an unstable package gets upgraded, it will move to current/extra.

wdemoss · 2004-05-08 01:01:26

LB06 wrote:

One flaw: Why does unstable have three 'confidence' levels? Unstable exists mostly out of bèta's and RC's. The only way those packages will become stable is by upgrading them to a non-beta/RC version, which makes unstable=>testing/stable even less than useful. I mean, as soon as an unstable package gets upgraded, it will move to current/extra.

It was my understanding that unstable was not a measure of the maintainer's confidence that the package will function correctly, but the projects assertion about its maturity. There are mostly "devel" or "beta" releases of packages in unstable that have corrosponding "official" releases in core or extra. If this is the case, then it is not redundant to have staging, testing, and stable for the unstable repository. Perhaps stable is not the best adjective, but it was the only one I can think to mean that the package maintainer is very confident that the installation of the package is accomplished correctly.
-wd

Zephirias · 2004-05-08 02:28:44

I still kinda' think that we should develop a program for Arch Developers that could easily create and update packages...it'd be a revolutionary idea if we could just update almost as soon as a package came out by just downloading and compiling the files via the program, then remotely upload them to the server.

wdemoss · 2004-05-08 02:40:35

Zephirias wrote:

I still kinda' think that we should develop a program for Arch Developers that could easily create and update packages...it'd be a revolutionary idea if we could just update almost as soon as a package came out by just downloading and compiling the files via the program, then remotely upload them to the server.

I think that is a good idea. I don't see any reason this couldn't be accomplished using rss feeds, or a daemon that monitors repositories checking for newer versions, very similar to how ketchup checks for kernel upgrades. This would be good for bug fix releases and minor updates.

Zephirias · 2004-05-08 02:47:33

wdemoss wrote:

Zephirias wrote:
I still kinda' think that we should develop a program for Arch Developers that could easily create and update packages...it'd be a revolutionary idea if we could just update almost as soon as a package came out by just downloading and compiling the files via the program, then remotely upload them to the server.
I think that is a good idea. I don't see any reason this couldn't be accomplished using rss feeds, or a daemon that monitors repositories checking for newer versions, very similar to how ketchup checks for kernel upgrades. This would be good for bug fix releases and minor updates.

Finally, someone who agrees with me.

sarah31 · 2004-05-08 04:08:59

Zephirias wrote:

I still kinda' think that we should develop a program for Arch Developers that could easily create and update packages...it'd be a revolutionary idea if we could just update almost as soon as a package came out by just downloading and compiling the files via the program, then remotely upload them to the server.

well i dunno about this. having something that is completely automatic is not really desirable. i could give you plenty of reasons why.

the problem is the whole management of the repos is insufficient and there are not enough developers. arch does not really have all that many packages but for what they do have is too many for the few developers.

making more repos is not the answer. desiging upgrade daemons is not the answer. and arguing about it is not the answer. it is simple the repos that exist are sufficient. the handling of incoming packages in not sufficient. the number of maintainers is insufficient.

all upgrades and new packages should go into testing and then once their assigned trial period is done then they move on. there should be a dedicated base of developers that receive and test incoming packages and then pass them upstream. that would be all they do. its really simple but somehow a mountain has been made out of a molehill

Dusty · 2004-05-08 04:23:25

That's settled then!

Zephirias · 2004-05-08 04:24:52

Bah, I lose again. :x

Oh well, I'm tired and going to bed. See you all tomorrow.

rasat · 2004-05-08 05:58:17

How the packages will go to the testing place (repo) in an uniformed format, Xentac made one test_pkg script automatically makes the tarball, which include PKGBUILD and related files.

test_pkg

options:
-submit Tar and upload the necessary build scripts to incoming
-list List the available packages from incoming
-get <package> Download the package from incoming
-build <package> Download and build the package from incoming

http://bbs.archlinux.org/viewtopic.php?p=24272#24272

Do we have now all the ingredients for the incoming?
1. Communication in New Package forum
2. All packages in testing repo
3. Upload and download with test_pkg script
4. Moderators to mod the repo and forum
6. Testing by dedicated users
7. From testing to official by devs

contrasutra · 2004-05-08 16:45:26

Umm, nothing has been decided yet. The devs are still discussing everything. I'm sure they'll announce it when they come to a decision.

Unless you plan on doing this without dev approval?

Zephirias · 2004-05-08 16:46:34

contrasutra wrote:

Umm, nothing has been decided yet. The devs are still discussing everything. I'm sure they'll announce it when they come to a decision.
Unless you plan on doing this without dev approval?

Yeah, it's rebel time!

rasat · 2004-05-08 18:54:32

contrasutra wrote:

I'm sure they'll announce it when they come to a decision.

I am hearing devs have difficulties to decide when there is no agreement among the users. This is understandable when this issue is more an users issue than devs. The whole package system has come to a stop when users wait for devs and devs for users.

Zephirias · 2004-05-08 19:07:38

rasat wrote:

contrasutra wrote:
I'm sure they'll announce it when they come to a decision.
I am hearing devs have difficulties to decide when there is no agreement among the users. This is understandable when this issue is more an users issue than devs. The whole package system has come to a stop when users wait for devs and devs for users.

I think it's just that we have no common base...we need to create a new Topic or go to the IRC Chat or something, and start from stratch. Pick one main goal, and work from that. This doesn't seem to be working.

punkrockguy318 · 2004-05-08 20:43:29

Zephirias wrote:

rasat wrote:
contrasutra wrote:
I'm sure they'll announce it when they come to a decision.
I am hearing devs have difficulties to decide when there is no agreement among the users. This is understandable when this issue is more an users issue than devs. The whole package system has come to a stop when users wait for devs and devs for users.
I think it's just that we have no common base...we need to create a new Topic or go to the IRC Chat or something, and start from stratch. Pick one main goal, and work from that. This doesn't seem to be working.

I agree, everyone is just stating there opinions and It's getting us nowhere. IRC would be nice

Zephirias · 2004-05-08 20:48:11

punkrockguy318 wrote:

Zephirias wrote:
rasat wrote:
I am hearing devs have difficulties to decide when there is no agreement among the users. This is understandable when this issue is more an users issue than devs. The whole package system has come to a stop when users wait for devs and devs for users.
I think it's just that we have no common base...we need to create a new Topic or go to the IRC Chat or something, and start from stratch. Pick one main goal, and work from that. This doesn't seem to be working.
I agree, everyone is just stating there opinions and It's getting us nowhere. IRC would be nice

Thanks...I'm probably (might) going to start another Topic on this, where we'll just work off of that, as this argument is getting too messy.

punkrockguy318 · 2004-05-08 21:03:03

There's already like four topics on this subject. Getting everyone together at a certain time on IRC would be the best bet.

Zephirias · 2004-05-08 21:12:23

Eh, I already made one, but at least it's fresh, and we can do it there (set the IRC time).

rasat · 2004-05-09 05:58:04

rasat wrote:

Do we have now all the ingredients for the incoming?
1. Communication in New Package forum
2. All packages in testing repo
3. Upload and download with test_pkg script
4. Moderators to mod the repo and forum
6. Testing by dedicated users
7. From testing to official by devs

To start discussing from scratch is not needed. The above points, when going through what have been said in different topics, points 2 to 7 are agreed to some extent by all (though point 6 is a question mark to get dedicated users to do the job).

Point 1 is the problem. There is no agreement how and where to communicate. Also who will make it? Its not solved by giving more theories. But to analyze what have been said and compare with the exiting incoming system, and then develop it.... one dynamic web site. Or someone already has the project in mind and ready to bring forward for feedback. Or find in Internet one ready made application or modify it for this purpose. This is the Linux way.... find existing or present newly made applications, modify them and then decide.

The usage of "New Package" forum was not agreed. If we still want to solve the communication, lets then make or come up with something new based what we have here seen and experienced.

PS.
To not confuse the users, I have removed the sample poll and AIR link from "New Pacakge" forum topics.

Zephirias · 2004-05-09 15:34:32

How about setting up an IRC Room just for that, or just make a new Forum for it? I mean, there really aren't that many options about it.

Dusty · 2004-05-09 18:40:50

Zephirias wrote:

How about setting up an IRC Room just for that, or just make a new Forum for it?

I think the devs can communicate via telepathy, if not they already have this forum or room for discussing it.

Zephirias · 2004-05-09 18:55:24

Dusty wrote:

Zephirias wrote:
How about setting up an IRC Room just for that, or just make a new Forum for it?
I think the devs can communicate via telepathy, if not they already have this forum or room for discussing it.

Alright, I'm not going to talk anymore, as it's not going anywhere.

Arch Linux

#26 2004-05-07 19:31:57

Re: vote on the bleepin packaging/incoming debate

#27 2004-05-08 01:01:26

Re: vote on the bleepin packaging/incoming debate

#28 2004-05-08 02:28:44

Re: vote on the bleepin packaging/incoming debate

#29 2004-05-08 02:40:35

Re: vote on the bleepin packaging/incoming debate

#30 2004-05-08 02:47:33

Re: vote on the bleepin packaging/incoming debate

#31 2004-05-08 04:08:59

Re: vote on the bleepin packaging/incoming debate

#32 2004-05-08 04:23:25

Re: vote on the bleepin packaging/incoming debate

#33 2004-05-08 04:24:52

Re: vote on the bleepin packaging/incoming debate

#34 2004-05-08 05:58:17

Re: vote on the bleepin packaging/incoming debate

#35 2004-05-08 16:45:26

Re: vote on the bleepin packaging/incoming debate

#36 2004-05-08 16:46:34

Re: vote on the bleepin packaging/incoming debate

#37 2004-05-08 18:54:32

Re: vote on the bleepin packaging/incoming debate

#38 2004-05-08 19:07:38

Re: vote on the bleepin packaging/incoming debate

#39 2004-05-08 20:43:29

Re: vote on the bleepin packaging/incoming debate

#40 2004-05-08 20:48:11

Re: vote on the bleepin packaging/incoming debate

#41 2004-05-08 21:03:03

Re: vote on the bleepin packaging/incoming debate

#42 2004-05-08 21:12:23

Re: vote on the bleepin packaging/incoming debate

#43 2004-05-09 05:58:04

Re: vote on the bleepin packaging/incoming debate

#44 2004-05-09 15:34:32

Re: vote on the bleepin packaging/incoming debate

#45 2004-05-09 18:40:50

Re: vote on the bleepin packaging/incoming debate

#46 2004-05-09 18:55:24

Re: vote on the bleepin packaging/incoming debate

Board footer