vote on the bleepin packaging/incoming debate

Dusty · 2004-05-02 17:06:41

In this post: http://bbs.archlinux.org/viewtopic.php?p=25032#25032 rasat and I have described a simple method that could alleviate some of the problems with the incoming stuff immediately. I vote that we implement this as a first step while further discussion continues.

Basically, this is my plan, though it might need some changes:

* ditch incoming in ftp
* post all new packages to New Packages forum. Author or mod should add a "do you think this package should be added to the official repositories" poll.
* If the yes count becomes high enough, add the package to extra (go through TUR, staging, testing, however the devs decide this should be done)
* allow the devs to slowly prune some not-often-used packages from extra on their own time.

can we start with something like this and then move onto other questions, like whether TURs are necessary, or how many repos there should be? We're trying to solve too many probs at once.

Dusty

Zephirias · 2004-05-02 17:08:48

I just re-posted my idea in the other Topic, let people look that over, and we'll get some input on that, as it could work.

EDIT: I did vote Yes, however.

Mr Green · 2004-05-02 17:17:32

I vote Yes...

Mr Green

jak · 2004-05-02 17:42:28

Dusty wrote:

can we start with something like this and then move onto other questions, like whether TURs are necessary, or how many repos there should be? We're trying to solve too many probs at once

Sorry I voted no, but for my own reasons, not because it's a bad plan. I think the other questions are more compelling, like how many repos:

One repo, current, with no more than 300 packages. Ditch everything else. Don't bring a new package into current until the demand is overwhelming. And if the limit of 300 is reached, then bringing in a new popular package requires ejecting a less popular one. Of course the number 300 is one I just picked off the top of my head. Maybe some other number makes more sense.

That's the best way to avoid package madness and unmaintained cruft. Just my opinion.

rasat · 2004-05-02 21:42:07

Dusty wrote:

I vote that we implement this as a first step while further discussion continues.

This says everything.

I voted yes not because being part of the plan but the "New Package" forum is a good place where to start. Users are already familar with and can get an idea about the new incoming system.

contrasutra · 2004-05-02 21:45:29

I vote we stop discussing this.

We've all voiced our ideas, now it's up to the developers to decide. This isn't going to happen overnight. I hope and know the developers will spend a long time discussing this internally.

They might even decide things shouldn't change, but this isn't going to be a popluarity contest.

rasat · 2004-05-03 05:52:41

contrasutra wrote:

I vote we stop discussing this.
We've all voiced our ideas, now it's up to the developers to decide.

What Contrasutra is saying is correct. But how he does it, being himself the cause of this poll, is not fair.

In topic "Suggestions for INCOMING", I think most users understood the incoming issue was given to the developers to make a decision and we (users) wait for the solution, when I suggested Xentac and Contrasutra.
http://bbs.archlinux.org/viewtopic.php?t=4112

What Contrasutra did, he created a new topic suggesting a vote system, which is an excellent idea. Moreover it was a topic related to the incoming communication what we didn't go in detail in the previous topic, so this didn't conflict what had been decided.
http://bbs.archlinux.org/viewtopic.php?t=4300

A doubt took place when Contrasutra made it clear he wanted to remove the whole incoming system, even Xentac was surprised about it.... meaning the discussion will go on infinitely. Not only this, he made it to look, the way how he replied to posts, as if the topic is his personal agenda. Naturally this went to a poll..... same would have had happened if anyone had "forcefully" insisted as if his/her idea(s) is the only solution.

PS.
No ill feelings.... just trying to clarify what took place.

beniro · 2004-05-03 14:51:19

In our own way, we're all Arch Linux developers, each of us as much as we want to be. I voted yes.

The results are so far in favor, but it IS still up to the core developers.

LB06 · 2004-05-03 15:29:32

I voted yes, but I don't think we should get rid of the TU's. They're doing an excellent job. Who else will be maintaining those packages when they are gone?

I would find it a very good idea to make testing pacman enabled and let all packages that have come through the votes (and ALL new or upgraded packages) remain for at least a week in testing. After this week, they will be moved to current/extra/unstable. Only security or bug-related updates should be merged into the official tree asap. The TUR's packages will not need to go through voting or testing.

With this system people who want bleeding edge, can just add testing to pacman.conf and people who do not want to risk breaking anything can just leave testing and get the upgrades only a week later, while the risk of breaking anything has been reduced by 90%.

beniro · 2004-05-03 15:45:51

LB06 wrote:

I would find it a very good idea to make testing pacman enabled and let all packages that have come through the votes (and ALL new or upgraded packages) remain for at least a week in testing. After this week, they will be moved to current/extra/unstable. Only security or bug-related updates should be merged into the official tree asap. The TUR's packages will not need to go through voting or testing.

That was my original idea exactly.

LB06 · 2004-05-03 17:59:56

LB06 wrote:

I voted yes, but I don't think we should get rid of the TU's. They're doing an excellent job. Who else will be maintaining those packages when they are gone?
I would find it a very good idea to make testing pacman enabled and let all packages that have come through the votes (and ALL new or upgraded packages) remain for at least a week in testing. After this week, they will be moved to current/extra/unstable. Only security or bug-related updates should be merged into the official tree asap. The TUR's packages will not need to go through voting or testing.
With this system people who want bleeding edge, can just add testing to pacman.conf and people who do not want to risk breaking anything can just leave testing and get the upgrades only a week later, while the risk of breaking anything has been reduced by 90%.

To clarify things, I had something in mind like this:

shen · 2004-05-03 20:22:04

I agree removing incoming is a good idea. I like the idea of voting on packages to be placed in the official arch repos. I do however think that there might be some packages that may not be overly popular but still used by enough users to be maintained elsewhere. Maybe via the TUR concept or another method. I would hate to see some packages get totally blown off when there is still a small user base who uses them. Other then that I think the concept dusty posted is solid and valid.

Basically I think those not-so-often-used packages should still have some sort of a home for those users who do use them. Even if it is just to keep the PKGBUILDS and needed files like patches,.installs and such in ABS so the users can compile them for themselvese if they need them. Bottom line just don't toss the files out of ABS for the packages that get removed from the repos.

I haven't read any of the other posts just basing my thoughts on this particular thread/poll. Anyways I vote yes for what Dusty posted as a starting point is a good start even if it is not a complete solution.

Zephirias · 2004-05-03 21:41:29

We just need to work on one thing at a time...though it seems as though there are a few people that don't like this idea, as of this post, the count is 15-10...we can't have that many people disagreeing, otherwise it could cause problems in the future. We just need to all get together and come up with one way to get all of this to work out. In the meantime, we should just try to come up with more ideas...

rasat · 2004-05-04 12:28:13

Zephirias wrote:

...we can't have that many people disagreeing, otherwise it could cause problems in the future.

Its a valid point, so I checked around enquiring if we should go ahead.

<b>Conclusion:</b> (1) the "New Package" forum has to be cleanup regardless what will be decided among devs.... the forum will be there in one way or other, (2) curious to know if practical, and (3) try it as a test.

When taking in account of the high number of disagreeing users, I plan to do the following:

1. Clean the "New Package" forum: remove non-related topics, chat, etc.
2. Keep topics as per packages currently in incoming and TUR.
3. Add poll ("do you want to remove this package") in all topics with a pkg in incoming but not those moved to TUR.

This looks like a lot of work but 1 and 2 has to be done. No. 3 should not be a problem when using AIR. Purpose here is to clean the incoming.

When this is done we will change the poll question.

<b>Help:</b>
(1) Users who know what incoming packages are of no use. Please add in the temporary Wiki list. Also if any pkg is already in another repo.
http://wiki.archlinux.org/index.php/Rem … ngPackages

(2) Add missing PKGBUILDs in the forum.

punkrockguy318 · 2004-05-06 01:58:08

I have some suggestions and expansions to what's already stated in this post and others.

First, the new incoming package system should be organized, rather then a mosh. Different categories (games, libs, net, ect) would be a great idea. Other users should be able to expand upon, tweak, and fix the PKGBUILDs in this respitory. This would be the first step to a better system.

After this step is implemented, my hope is that a new respitory will arise, and will do away with staging and TURs. This "Unofficial" respitory will consist of packages from the new incoming database system that have been voted functional and complete. Once enough people vote that the package works properly, the package will go to unoffical.
This unofficial respitory would make a nice bridge between the new incoming system and the official respitories, or if a package is unwanted in the offical respitories, it can be a permenent home.

From the unoffical respitory, there are two ways a package can get into the official respitory.
1) If the devs feel it's necesary
2) If a large amount of votes of users feel it's neccessary.

And lastly, an old respitory would be created for packages that are outdated, and barely used. Devs can put things in this respitory when it's not needed in the official ones anymore. A team of user's can maintain this respitory.

My other post is here for more information.
http://bbs.archlinux.org/viewtopic.php? … c&start=60
Those are my two cents. What do you guy think? I know things won't work overnight, we need to take it one step at a time, but do you think that may work?

sarah31 · 2004-05-06 04:15:55

voting is stupid.... it is not a good way to manage a package system.

rasat · 2004-05-06 05:41:19

sarah31 wrote:

.... it is not a good way to manage a package system.

I understand your point, but how then manage... select packages for official, TUR and remove?

What's the measurement of selection when 20-30 new contributions are made every month? Its suggested to have "good quality & popular" packages in official and "less quality but useful" packages in TUR. Devs select the official and Users the TUR packages. Before the selection, test packages will be made.

A poll system sounds reasonable.

Instead of asking as poll: "Do you think this package should be added to the official repositories?" we ask for a rate: "Rate this package quality and usefulness from 1 to 5".

EDIT:
New Package forum is cleaned (topics removed or moved to User Contributions). Few poll samples. New subject headers in process.
http://bbs.archlinux.org/viewforum.php?f=25

punkrockguy318 · 2004-05-06 11:25:24

rasat wrote:

sarah31 wrote:
.... it is not a good way to manage a package system.
I understand your point, but how then manage... select packages for official, TUR and remove?
What's the measurement of selection when 20-30 new contributions are made every month? Its suggested to have "good quality & popular" packages in official and "less quality but useful" packages in TUR. Devs select the official and Users the TUR packages. Before the selection, test packages will be made.
A poll system sounds reasonable.
Instead of asking as poll: "Do you think this package should be added to the official repositories?" we ask for a rate: "Rate this package quality and usefulness from 1 to 5".
EDIT:
New Package forum is cleaned (topics removed or moved to User Contributions). Few poll samples. New subject headers in process.
http://bbs.archlinux.org/viewforum.php?f=25

Or... instead of users voting, only the devs could vote. This would be more secure, and the devs know what they're doing. If a user wants a package, he can maintain it himself in a TUR. Then if/when the new incoming works, we can move on for a better tur system (unofficial?).

dp · 2004-05-06 11:34:25

one question - what would happen, if a lot of people vote for a library to be not usefull? you cannot exclude a lib from the repos, only because it is itself not that useful (bud as dependence very usefull)

only one aspect that i think is to also think about

rasat · 2004-05-06 15:08:55

dp wrote:

one question - what would happen, if a lot of people vote for a library to be not usefull?

A package can't run if a dependecy is missing, so poll doesn't matter. Best will be to not poll library packages or other pkgs what go without a say. The contributors can decide. Morover, in the forum many topics also include dependency packages.

punkrockguy318 wrote:

Or... instead of users voting, only the devs could vote.

The idea of vote was to help devs / pkg testers to select.

sarah31 · 2004-05-07 03:21:30

the problems with voting are:

what criteria do you use to decide what a winning set of votes?

for example programming languages such as ruby are not less useful than perl or python to some. alot of users may not have any interest at all in programming languages at all so a pole to vote for a programming language could have very few votes.

where do you elicit opinions from?

while the web forum may have 1400+ users one cannot say they all use the mail list as well. what about users that don't use or frequent either? voting on the mail list would clutter it with spam.

and so forth...

i could probably think of more but these two questions are just points. like the arch stats program voting is not an accurate cross section of the user base.

there is no real best way of deciding what gets included in the repos. but i really do think that considering how crux handles their repos should be considered. (it is basically a user managed system) by no means is it a positively secure system but it allows the developer(s) of the core system to focus just on the core system.

in the case of arch the developers could just focus on current and some sort of user managed system could be developed. perhaps it could just be made of PKGBUILDs that the users could then download and build the package themselves.

i dunno. it was just a thought. but voting could certainly cause more grief than it would cure.

Dusty · 2004-05-07 05:36:29

It's late at night or I'd have the sense to stay out of this... blockhead Dusty...
I agree that voting isn't really the best way, I can't imagine people going out of their way to vote against a package. I think there should be a way for people to express interest in a package though, a "I want this" option, rather than a "Do you want this" yes/no question. The threshold for including the package would then mostly just be number of votes over a certain period of time.

If packages aren't useful to a lot of people, then they can be relegated to either TUR or an unofficial PKGBUILD somewhere...

Dusty

rasat · 2004-05-07 07:12:48

I changed the poll into an information system. This system gives a value to a posted package instead of discriminating between yes, no or remove. The contributor (author of the topic) can edit the options.

This is default options (any other suggestion... keep in mind its one vote/tick per user).

Package information
1. Ready for TUR
2. Tested by a user
3. Doesn't work

The aim of the forum is to give information about the package... PKGBUILD, download ftp_link, to know when a package is moved to another repo and freshmeat.net information (currently by AIR), feedback, etc.

punkrockguy318 · 2004-05-07 10:25:52

rasat wrote:

I changed the poll into an information system. This system gives a value to a posted package instead of discriminating between yes, no or remove. The contributor (author of the topic) can edit the options.
This is default options (any other suggestion... keep in mind its one vote/tick per user).
Package information
1. Ready for TUR
2. Tested by a user
3. Doesn't work
The aim of the forum is to give information about the package... PKGBUILD, download ftp_link, to know when a package is moved to another repo and freshmeat.net information (currently by AIR), feedback, etc.

Yes, yes yes! This is what I was getting at in my earlier posts

wdemoss · 2004-05-07 13:51:59

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.

My other idea has to do with packages making it into the arch repositories. I also think incoming is a bad idea, because it provides a built package. Packages in incoming probably are looked over by a dev, then rebuilt using the package build. There really isn't any good thing about taking built packages from untrusted users.

So instead of incoming, I've heard some sort of forum or system be set up to provide package builds. I think this is a good idea. Then if someone wants to maintain an official Arch version of that package, whether it be the submitter of the package build or not, can volunteer. If the devs trust that person, then they become the official maintainer. If that person decides to orphan that package, then the package is removed from the offical repository, until someone else decides to volunteer to maintain it.

This way, there are no orphaned packages in the system. Also, if a package is wanted by someone to be offically maintained by someone bad enough, then they will volunteer. I think this will remove the cruft out of the package management system. I also think this model scales well with more packages, because it only supports that packages that the community are willing to maintain.

Sorry if I'm kicking a dead horse.
-wd

Arch Linux

#1 2004-05-02 17:06:41

vote on the bleepin packaging/incoming debate

#2 2004-05-02 17:08:48

Re: vote on the bleepin packaging/incoming debate

#3 2004-05-02 17:17:32

Re: vote on the bleepin packaging/incoming debate

#4 2004-05-02 17:42:28

Re: vote on the bleepin packaging/incoming debate

#5 2004-05-02 21:42:07

Re: vote on the bleepin packaging/incoming debate

#6 2004-05-02 21:45:29

Re: vote on the bleepin packaging/incoming debate

#7 2004-05-03 05:52:41

Re: vote on the bleepin packaging/incoming debate

#8 2004-05-03 14:51:19

Re: vote on the bleepin packaging/incoming debate

#9 2004-05-03 15:29:32

Re: vote on the bleepin packaging/incoming debate

#10 2004-05-03 15:45:51

Re: vote on the bleepin packaging/incoming debate

#11 2004-05-03 17:59:56

Re: vote on the bleepin packaging/incoming debate

#12 2004-05-03 20:22:04

Re: vote on the bleepin packaging/incoming debate

#13 2004-05-03 21:41:29

Re: vote on the bleepin packaging/incoming debate

#14 2004-05-04 12:28:13

Re: vote on the bleepin packaging/incoming debate

#15 2004-05-06 01:58:08

Re: vote on the bleepin packaging/incoming debate

#16 2004-05-06 04:15:55

Re: vote on the bleepin packaging/incoming debate

#17 2004-05-06 05:41:19

Re: vote on the bleepin packaging/incoming debate

#18 2004-05-06 11:25:24

Re: vote on the bleepin packaging/incoming debate

#19 2004-05-06 11:34:25

Re: vote on the bleepin packaging/incoming debate

#20 2004-05-06 15:08:55

Re: vote on the bleepin packaging/incoming debate

#21 2004-05-07 03:21:30

Re: vote on the bleepin packaging/incoming debate

#22 2004-05-07 05:36:29

Re: vote on the bleepin packaging/incoming debate

#23 2004-05-07 07:12:48

Re: vote on the bleepin packaging/incoming debate

#24 2004-05-07 10:25:52

Re: vote on the bleepin packaging/incoming debate

#25 2004-05-07 13:51:59

Re: vote on the bleepin packaging/incoming debate

Board footer