Time from submission to availability in "unofficial&quo

ipqw · 2003-11-10 22:50:41

How long time does it typically go from a submission on ftp and announce here, to a package is in the unofficial collection?

(I'm thinking on the two I made: bcrypt and xfig)

Cheers, KS.

sarah31 · 2003-11-10 23:17:33

there is no set period. right now it takes a long time because there is no one actively working on testing incoming packages at the moment.

contrasutra · 2003-11-11 01:31:58

I've had packages in there for months and months.

And they can't possibly be bad packages.

ipqw · 2003-11-11 02:01:41

Okay It was just if nobody uses the contributed packages, then there is no point in uploading them ... but anyway, those of us that read this forum knows ;-)

Best, Kristian.

sarah31 · 2003-11-11 02:16:56

well if that is your choice then they definitely will never get to the repos.

some of the other developers have plans of working on incoming now that most if not all packages in the repos have benen fixed up.

ipqw · 2003-11-11 02:32:38

Don't worry - that is not "my choice"! It was not an "angry" post previous - I just wanted to know how status were. I fully understand that everyone working on Arch - and other Linux distros aswell, do not have time for it all!

I am getting to like Arch - and don't mind spending a few more minutes on makeing the pacman packages for the software I would install anyway. It is a good thing others can benefit from ones work. Else we/linux would not be were we are today

Cheers!
KS.

rasat · 2003-11-11 04:08:39

ipqw wrote:

Okay It was just if nobody uses the contributed packages, then there is no point in uploading them ...

For me, and I think also for some other users, incoming packages have helped to have particular softwares for AL. The difficulties what is appearing, with large number of incoming packages, to know what are available especially to know the description of each packages and what they do. Needs a website same as official and unofficial.

The Software database, what I created, got stranded when not having time to feed the data. But now seeing the shortcome of incoming, I will enter the data of incoming. Later create a permission for users building packages, to feed the info of incoming to the database.
http://bbs.archlinux.org/viewtopic.php?t=1251

If the users feel to have an Arch Linux heading (instead of AMLUG), I will ask AL if I can make the data entry and viewing incoming page with AL header... with a note these are NOT official packages of AL.

PS
I will work on it end of this month once I am back in Singapore.... Mauritius and Kenya no ADSL connection.

sarah31 · 2003-11-11 05:17:18

while i understand wanting to know what each package is in incoming does/is it is an awful lot of work for little in return.

how will the database handle when packages are removed from incoming? i believe three were moved to unofficial tonight. are you going to get each user to manually enter the pkg description in your db? would it not be easier to have scripts that descend into the tarball then the PKGBUILD and extract the info?

there are piles of other questions i have and i feel that each one would just create more work.

rasat · 2003-11-11 11:59:03

sarah31 wrote:

... to know what each package is in incoming does/is it is an awful lot of work for little in return.
how will the database handle when packages are removed from incoming?

I have not yet thought in depth, but certainly there will be lot of work entering 375 packages. Hopfully the authors of incoming will help in the work.

The return of the work will be the start of the Software database because all data is entered in one database (MySQL) regardless if then incoming, official or other type. To change a package from incoming to unofficial only the type of package field info is changed.

To find what each packages does, Valery V. Kachurov's software database project will help in this regard. I have been in contact with him. He is currently entering his website info into one MySQL database with the help of few members from Polish Linux community.
http://linuxshop.ru/linuxbegin/win-lin- … able.shtml

sarah31 · 2003-11-11 17:01:02

the "authors of incoming" are those that contribute to it not those developers who test packages from it.

....just so you know

like i say automatic tranfer/production of data is the only way you won't go nuts.

once a package goes to the repos it is pointless having a database because we have one. if descriptions are bad or one cannot figure out how to search it then...well to be harsh it isn't our fault.

rasat · 2003-11-11 23:52:50

sarah31 wrote:

if descriptions are bad or one cannot figure out how to search it then..

As long as the type of application (wordprocessor, editor, finance, etc.) is correct should not be a problem... if not .... search ALL

I will keep all the points in mind what have been mentioned, so let see where it will lead.

sarah31 · 2003-11-12 06:00:25

of course i am not trying to discourage you just want to make sure that the time you may put in is worth the effort.

rasat · 2003-11-13 09:24:01

Sitting in the plane for 7 hours from Singapore to Mauritius, an idea arise what may help the test package developers to decide what packages to test as priority (among current 375 packages and also for future).

The Software database has a popularity rate category evaluated by the author. This may not be accurate depending on author's knowledge of usage and honesty but still gives some direction. But if the database compares the incoming packages with users' installed packeges recorded in ArchStat database (once its ready), this would give an additional info of popularity among Archers. What would be the minimum % of usage is upto the test developers.

sarah31 · 2003-11-13 16:23:02

priority is oldest to youngest. not use. i believe that is how it is being handled now. i don't think it is fair to people who submitted packages months ago to get supplanted by the new hot incoming package.

i am not a huge fan of using stats to decide what packages go where and when. stats can be very misleading. if others handle it different that is fine but i really do not like using stats in this manner.

deepfreeze · 2003-11-13 20:06:04

On the topic of outdated packages in /incoming (based on another thread about Opera and having an outdated package in /incoming)...

If packages are to be evaluated oldest to youngest (that is, the ones uploaded first are evaluated first), would it be the best to allow an "outdated" package to be evaluated and added to the repository and then flag it out-of-date so it can be updated to the newest version?

The other alternative, deleting the old package and uploading the newer package, would delay the implementation of the package by effectively moving it to the back of the line. Perhaps it would be the most effective that, until a package is added to a repository, provided that it doesn't have major bugs that are fixed by an upgrade, that any newer versions are kept out of incoming. People can post upgrade info and new PKGBUILDs in the forums, but leave the old package in place in order to get it implemented in a quicker fashion...

sarah31 · 2003-11-13 21:18:59

yes it would make way more sense to inform people that a new version of a package in incoming is ouit and let them upgrade rather than adding yet another copy to incoming. un less there are patches i don't really see the need to upload the new version. it would ineed make those who work on incoming's job alot easier.

i don't know about those working on incoming now but when i was doing it i ALWAYS checked to make sure that i had the most recent stable(,working,) version. this prevented someone whining about the version being old right away.

good points deepfreeze.

rasat · 2003-11-15 09:34:57

sarah31 wrote:

priority is oldest to youngest. not use. i believe that is how it is being handled now. i don't think it is fair to people who submitted packages months ago to get supplanted by the new hot incoming package.

Oldest to youngest is the system I also have understood and its good and fair when handling 20 or 30 packages. Incomming is now holding 375 packaes with no test developers, which has resulted this topic. I also don't expect anyone wanting to go through / test the packages... its a full time job.

The handling "policy" has to be reconsidered. I personnaly feel its an "unhealthy" policy for AL commiting itself to make all workable incomming packages into unofficial thereby doing the same mistake as what SuSE and Debian did. I don't want to see Arch becoming another "package monster" distro with thousands of softwares knowing 50% have no much value except for one or two users. For common users its very confusing.

Here I am not trying to discourage incomming developers but to remove the expectation of getting into unofficial what on bottom line is not necessary as long as users know the packages exists in incomming and can download whenever is needed. Also the author of the package maintains the upgrade.

I suggest AL selects the incomming packages according to usage thereby maintaining good / popular packages in unoffical and official. But at the same time is aware what are in incomming and removes oudated / defective packages. The testing /evaluation ground can be this forum.

How to select? Example (my incomming):
Kbear --- > unofficial (already)
Win4lin03 --- > keep in incomming until there is a demand.
Rpm ---> should never be added to unofficial.
hwd ---- > unofficial.

From a users point of view, why not make incomming as unofficial (as the word imply), unofficial as official (tested and approved), and official as "core" package (or other suitable name). The name "Incomming" binds AL to take responsibilties but as unofficial there is no committment.

deepfreeze · 2003-11-15 13:33:31

I really have to respectfully disagree here. I think it's irrelevant if only a handful of people find a particular package useful or necessary...the fact that they need it and use Arch points to the fact that it should be included in the distro, espcially with the thought that later users might also need or want the same package. Restricting similar packages in an attempt to not confuse the user isn't, imho, what OSS and the Linux Community are about. Choice is A Good Thing (TM) and just because my choice of package is only used by 3% of users while your choice of package is used by 97% does not make my choice any less valid or any less worthy of being included in repositories.

If there are 375 packages sitting in /incoming as opposed to 20 or 30, then the way to remedy this really is to get more volunteers and people willing to test packages rather than changing the policy that has seemed to serve AL so well up until this point. With a 2 week old baby in my house now, my time has been severly limited, but I would love to test packages and I'm sure there are others that feel similarly. As it is right now, incoming is being used as it's own unofficial repository, but that really is not how it was ever intended and I don't think it's something that will serve the AL Community well by continuing.

Really, this is about fixing the "problem" (too many packages in /incoming...getting more testers) and not the "symptom" (perception that packages in /incoming are not worthwhile or needed to be included)

sarah31 · 2003-11-15 17:02:06

what one user considers unnecessary another may not. to decide by statistics is rediculous when there are no stats which tell me conclusively which packages are truly "useless". there are package both in incoming, unofficial, and official that have not been upgraded in a long time so they may have no activity on them at all. are these useless?

personally i don't think there is a "problem" with incoming anyway. so there are 375 packages in it...so what? it is not like the packages in there cannot be used. users may not have the ability to install package from it directly but they are there. if a user took the time to contribute a package we deserve to put it in the repos (if it is a working build/package) if it proves later to not be used all that much or becomes obsolete then it will be removed.

i would rather acknowledge a users contribution then ignore it.

terrapin · 2003-11-15 17:12:05

maybe we could incorporate some kind of abs system for incoming packages. This would give users the ability to contribute PKGBUILDS and those interested in those applications a way of building them. I know that the "new package" post is suppose to contain the PKGBUILD information but this isn't always done. I also think it would be more efficient to store all of these PKGBUILDs in one place instead of having to search the forums. Then based on the popularity of the application a arch package could be made.

Anyways just a thought.

sarah31 · 2003-11-15 17:51:45

well there are PKGBUILDs in each tarball in incoming.....they are only posted here for those people who are highspeed disabled (or something).

and yet again i say it is not wise, right now, to base any decisions on incoming based on popularity. there are no definitive stats nor will there be something added two months ago may zero activity one added today may have lots. as well i am sure there are a good deal of arch users that have little or no knowledge of incoming at all.

it is just not right to exclude apps in incoming based on popularity.

red_over_blue · 2003-11-15 18:44:22

As I have recently started adding packages (only a couple so far) from incoming to the unofficial repository, I thought I would write a quick summary on how I am personally handling this situation.

There are a number of factors influencing the way I have decided to handle incoming packages. These include, but are not limited to, the following:

1. Maintainers: Arch has recently recruited a number of new maintainers, myself being one of them. The priority for these new maintainers was to adopt the orphaned packages already contained in the Arch repositiories. Before this, there simply weren't enough maintainers for the number of packages already available to Archer's in the repositories. That being said, as maintainers move packages from incoming to unofficial (for example), they spread themselves even thinner and have less time on average to commit to each package.

2. Time Spent in Incoming: Packages in incoming can easily be listed by date uploaded. Some amount of weight should be given to when a package has been contributed.

3. Package: The actual package itself, like it or not, must carry weight in determining its positition on my priority list for inclusion into the Arch repositories. To paraphrase some of sarah31's comments, I don't believe anyone wants Arch to become a distro with hundreds of packages that one or two individuals used once or twice and only made it into the repositories because they were the oldest in incoming. However, I don't think the Maintainer's personal opinion of the package should carry any weight in determining its position.

So, with those factors, this is the way I am going to go about selecting packages from incoming:

1. List all packages by date

2. Starting with the oldest, pick packages that I think would be most beneficial to Archers in general.

This may not be what "everyone" would like, but I think it is what most would like. Also, if a package is so specific that only a few members are using it, then likely one of them was the individual that uploaded it to incoming in the first place. Let's not forget that just because it is in incoming and not in unofficial does not prohibit its installation from incoming in any way.

Well, thanks for reading this, I just thought I would share my views and I hope everyone understands that there are only so many hours in the day, so we much choose how we spend those hours carefully.[/list]

terrapin · 2003-11-15 18:46:45

errr...I don't think I explained my idea very good in my previous post.

I believe a PKGBUILD management system would be easier to manage over time then the current user contribution system (incoming). Users could post their PKGBUILDs to an abs like system. Everyone would be able to contribute any package they wanted and anyone would be able to build that package. ALL packages would be available to everyone with no popularity basis. Then based on popularity (demand) these PKGBUILDs could be made into arch packages and then moved into one of the repositories.

The process would work like this.
I create a PKGBUILD for some application (Opera)
I then submit that PKGBUILD to the PKGBUILD management system
I post the application to new packages forum
who ever is interested in the package builds the package using the PKGBUILD
if the package is popular the maintainer will create an arch package and add it a repositiory.

Advantages I see over the current incoming system.
* Users are able to update old PKGBUILDs to current versions
* packages no longer sit in "incoming" for months with no activity
*reduced number of packages in incoming
* less popular applications are still available to anyone who wants them with out adding to the size current repositiories
* ability to categorize PKGBUILDs into different clases like "network" or "multimedia"
* PKGBUILDs are smaller then full packages this saves both hard drive space and bandwidth

My idea is biased towards PKGBUILDs as the main distribution method for new packages instead of the actual packages. While the PKGBUILD is currently available by extracting it from the incomin tarball this might be considered inconvient to people (I personally find it inconvient).

I only suggest this as another way of looking at the incoming problem. I understand that package maintainers have limited time to volunteer and I am just trying brainstorm a way to relieve some of the burden of the current system from the developers/mainters to the users.

sarah31 · 2003-11-16 01:56:17

the problem is that if you abs-ize incoming then you pass the perception on that arch linux endorses these PKGBUILDs and are then responsible for any problems they have or damage they cause.

having only the PKGBUILDs is not a bad idea but having an abs for them is not. when i did work on incoming i found the filelist important too, especially when there was a problem with the build.

but like i told ROB it is up to those who manage incoming to do what they like i wash my hands of it now. if it is abs-ized thouugh i don't want it as a default option in my abs script i have never used anything in abs except some of the stuff i contributed a way back when.

for those people though that did comment that they don't want arch to become like debian or something with respect to the number of packages i don't think even adding 375+ packages will do that remember debian has well over 10000 packages arch has one tenth that.

as for adding based on what one thinks will benefit the whole arch commuinty........good luck. everyone's tastes are different. you will never ever please everyone in one fell swoop. but when the users who contributed what they think would be good for arch linux to have several months ago don't see their packages ever go in the repos then don't be surprised when those people start getting cranky.

there are probably several packages in incoming and the repos that fit well within the boundaries of "not benfitting the arch commnity". basically anything outside of base is optional and therefore not necessarily benfitting anyone.

see the circularity of the argument? now when i realized it was basically a losing position for me thats when i decided that it best i leave the judging of usefullness to the larger community and upload according to date. in the end i though that showing the users that their effort and opinions of what THEY think is important to be in arch was more imortant than me choosing what to upload based on some guessing game. sometimes the least used app is one of the best.

dp · 2003-11-16 03:09:14

sarah31 wrote:

[...] sometimes the least used app is one of the best.

... and often not that popular apps are horribly difficult to install (source based); here comes the big advantage of arch ... only once someone writes a build() and then you can (if this package is in one of the repos) install it on a machine by simply running "pacman -S $pkgname"

here my suggestion on testing "incoming" and abs-PKGBUILD:
-----------------------------------------------------
what about having a repository called "testing" that includes all packages from incoming; and the users themselves can include this repo to pacman.conf and test packages made by others ... and in the forum they can communicate about their experiences --- once they decide that it works as it should, they can just flag this package "working" ... and if a maintainer then sees this flag (word in the forum), (s)he can decide then to put it in (un)official/stable or not /// of course system-critical apps should be tested again by the maintainers, but if maintainers/experts have a look in the discussion, they also can get a lot of infos from the testers (and dont need to do everything themselves)
----------------------------------------------------
why "testing" :
from the users point of view:
say you want to install app XYZ on your arch:
1) you search in the repos for XYZ
-> if you find it: great/easiest way: just pacman it to your sys
2) you search in the incoming
-> if you find it: download the file, uncompress in the local-repos you should have set, "gensync" and then pacman
3) you search in the forum
-> and discuss with others why this is not able to compile with libs we have on arch (partimage) ... and finally someone creates a pkg and posts it in incoming (goto 2) )
4) you search the internet, make you own PKGBUILD and try building a pkg (longest way) -> forum -> incoming ->pacman

with testing, you benefit from:
-> having a lot of people testing things (on their own risk, that's clear)
-> having packages from "incoming" "fast to install" (it's done by one command)

what do you think?

Arch Linux

#1 2003-11-10 22:50:41

Time from submission to availability in "unofficial&quo

#2 2003-11-10 23:17:33

Re: Time from submission to availability in "unofficial&quo

#3 2003-11-11 01:31:58

Re: Time from submission to availability in "unofficial&quo

#4 2003-11-11 02:01:41

Re: Time from submission to availability in "unofficial&quo

#5 2003-11-11 02:16:56

Re: Time from submission to availability in "unofficial&quo

#6 2003-11-11 02:32:38

Re: Time from submission to availability in "unofficial&quo

#7 2003-11-11 04:08:39

Re: Time from submission to availability in "unofficial&quo

#8 2003-11-11 05:17:18

Re: Time from submission to availability in "unofficial&quo

#9 2003-11-11 11:59:03

Re: Time from submission to availability in "unofficial&quo

#10 2003-11-11 17:01:02

Re: Time from submission to availability in "unofficial&quo

#11 2003-11-11 23:52:50

Re: Time from submission to availability in "unofficial&quo

#12 2003-11-12 06:00:25

Re: Time from submission to availability in "unofficial&quo

#13 2003-11-13 09:24:01

Re: Time from submission to availability in "unofficial&quo

#14 2003-11-13 16:23:02

Re: Time from submission to availability in "unofficial&quo

#15 2003-11-13 20:06:04

Re: Time from submission to availability in "unofficial&quo

#16 2003-11-13 21:18:59

Re: Time from submission to availability in "unofficial&quo

#17 2003-11-15 09:34:57

Re: Time from submission to availability in "unofficial&quo

#18 2003-11-15 13:33:31

Re: Time from submission to availability in "unofficial&quo

#19 2003-11-15 17:02:06

Re: Time from submission to availability in "unofficial&quo

#20 2003-11-15 17:12:05

Re: Time from submission to availability in "unofficial&quo

#21 2003-11-15 17:51:45

Re: Time from submission to availability in "unofficial&quo

#22 2003-11-15 18:44:22

Re: Time from submission to availability in "unofficial&quo

#23 2003-11-15 18:46:45

Re: Time from submission to availability in "unofficial&quo

#24 2003-11-16 01:56:17

Re: Time from submission to availability in "unofficial&quo

#25 2003-11-16 03:09:14

Re: Time from submission to availability in "unofficial&quo

Board footer