About packages release method

Comete · 2004-03-06 11:49:36

Hi all,

First, excuse me for my poor english but i'm french I'm an Archer since last summer and i've created and put some packages (MtoolsFM, pam_ldap, nss_ldap...) in "incoming" since many month for some, like other archers did. At this time, you (maintainers) asked us (users) to help Arch to support as many packages as possible. That's what we did with a great pleasure ! . But now, i wonder if our help is so usefull because i think that "incoming" is no longer (or just a bit) looked by maintainers or TURs. I don't know if other users have got the same problem with their contributions (and that's what i want to know too) but my packages are still i "incoming" waiting for someone to test and include them. Each time i've put a package in it, i've posted a thread on this forum to announce it.

So my questions are :
Do you still need us to contribute ? or is this work just for TURs now ?
Don't you think it's time to reorganize the release method or to define exactly and officially, with a "HOW TO" for example, what is the job of each in the Arch Community ?
I think i'm not the only one who need precision on this problem...

And just a suggestion, could it be possible to add a list of orphaned packages in the News Letter ?

Thanks a lot for your job and your attention !

Comete

sarah31 · 2004-03-06 16:26:52

thanks you for posting this. i for one always said that there should be no discrimination when testing packages except if it is something you just don't understand (like for me i am not very technically or network inclined). i went on to say that if some users contributions kept being ignored there would be blow back. arch has need of users contributions most definitely but it needs a better contribution handling policy more.

thanks again for raising the issue comete (and thanks for your contributions)

Comete · 2004-03-07 23:15:36

This is what i wrote to Judd:

On Sun, Mar 07, 2004 at 04:35:44PM +0100, Comete wrote:
Hello Judd !
Could you read and consider this please ?
http://bbs.archlinux.org/viewtopic.php?t=3037
thanks a lot
Comete.

and this is what he replies:

Judd Vinet wrote:
What part are you wanting me to consider? Would you like to propose a different package release method?
I'm not really a part of the team that handles /incoming stuff, that's been left up to the Extra maintainers and the TUs. The way Jason explained TUs to me, was that they would pick up packages from incoming as they saw fit, and add them to their respective TUR. When the package was deemed stable and worth of existence in Extra repository, they would move it to Staging, whereby it would be examined and adopted by an Arch maintainer.
Is this is the "package release method" that you're talking about?
- J

And finally, this is what i suggested him:

What i suggest is that TURs should have a look at "incoming" REGULARLY and not to take packages in order of "importance" or "popularity" but by DATE of post. So many contributors could see (one day) their packages integrated in Arch.
thank you
Comete

Xentac · 2004-03-07 23:22:47

This is what they should be doing. I'd said there was a little leeway, but they should be getting packages based on the creation date.

Right now the TUR system is down for maintenance, so they can't do anything, but I will bring it up again when they can.

dp · 2004-03-07 23:32:37

the TUR-system is at reconstruction at the moment

... TU's take pkgs from incoming at a
->> regularly <<--
basis, but this is slow process --- so maybe it seems not to be regularly

there is need for more TU's ... make you a name as good pkg-builder and contact the TU's over the mailing list with your example pkgs that they know you as a good builder ... that's how you become TU and then you can take all pkgs from incoming on regularity you like (every minute one? )

about priorities ... hmm ... by ->> date <<- is a "often used method", indeed :-)

... but we are humans and popularity is also some way important (and not all people know what pkgs are intended to do what ... you must have a idea what a software is for that you can test it, right?)

(i have 9 pkgs in incoming ... some of them for really long ... but no time to have again a look at them)

(we are not speaking about a certain pkg?)

Comete · 2004-03-08 06:54:56

so do you think there's no solution ? i don't think so...

A lot of contributors post a thread on the "New Packages" Forum when they have put a new one in "incoming" (that's what i did too).
So TUs just have to look at this Forum section to know "what package do what"... Maybe every contributor should act like that to inform you ? What about writing a CONTRIBUTOR/TRUSTED USER GUIDE on the Wiki to precise how to procede ? ... a kind of recipe with rules that each one (contributor and TU) should respect to make packages to be tested by TUs in a shorter time than now (some packages in "incoming" are from the last summer...).

Comete.

sarah31 · 2004-03-08 16:18:12

one of the things i tried to impress upon whatever devs were working on incoming was that an effort should be made to tackle the oldest contributions first and not what they saw fit to include from the oldest.

one of the things that frustrated me before i left the dev team and frustrates me even now is seeing just how old some of the contributions are in incoming and how some people's work was completely ignored, but each time a new developer comes on their favorite applications and even ones they did not contribute to incoming show up before stuff that USERS contributed long ago.

don't get me wrong i would never say don't add something to the package repos (except maybe alien or rpm) but consider other contributions before your favorites. just because you never use <insert package name here> does not mean that somebody else might not. it is like using archstats to determine what should be upgraded first and what should not. i know freom the stats that the application rip is not widely used but that does not mean that NOBODY uses it and it does not mean that to those people it is any less important than say grip or ripperx.

i think comete is saying that there are no outward signs that the "policies" for adding packages stated in this thread are being followed. maybe if year old contributions were disappearing from incoming or turs or whatever he would not have even posted.

comete did not intend this post to say that devs were not doing their jobs but he was just trying to point out that some users are and will continue to feel that way unless they see their work show up sooner in the repos (if it is indeed a good build).

incoming has been a mess for a long time despite efforts of many to reverse it and i think comete was just trying to kickstart more attention to this.

Comete · 2004-03-08 17:31:29

Thank you sarah31 ! I couldn't say it better !

drivingmsjuki · 2004-03-09 23:54:12

Sorry to be late to the discussion, but has anyone floated the idea of having folders in /incoming so that the packages can be grouped roughly as they would in the regular repositories?

/incoming/games
/incoming/office
/incoming/multimedia
.. etc.

A lot of the times it's not immediately obvious to someone what package XYZ is without searching on Google. I wouldn't even know what cinelerra was for if I hadn't already spent boatloads of time trying to make it run right on RH9, which was a complete distaster.

Does it sound to anyone as if it would be helpful to have /incoming split into categories like that?

sarah31 · 2004-03-09 23:58:09

well i think the whole idea was to have very few packages in there at all as the TURs were ideally supposed to be taking them out as they come in testing them then supplying them in their repo then moving to staging and so forth.

drivingmsjuki · 2004-03-10 01:05:49

Maybe we need more TU's? If so, I vote for you

i3839 · 2004-03-10 01:39:43

Well, it seems logical to me that TUR makers are either to be trusted, so it's relative hard to become a TUR, or that it's rather easy to become a TUR and it more or less replaces incomming, because people should put their package in their TUR instead of in incomming. In the first case such people could be as well package maintainers instead of TUR maintainers, as the criteria aren't that differently, in the second case it seems to mean that there are too many incomming packages, so they must be buffered somewhere. Perhaps I overlooked something rather important, but why aren't the current TURs just package maintainers? The current way of incomming -> TUR -> staging -> official seems a bit long and inefficient.

sarah31 · 2004-03-10 05:04:16

some TURs asked to be package maintainers and were not accepted some TURs do not want to be package maintainers and so forth.

regardless of whether or not a TUR or somebody else is hired as a package maintainer it still seems that the handling of incoming still suffers either because their new package maintaining duties draw their attention or they simply just add from incoming what they like and what they had sitting on their box that they feel arch needs.

personally once incoming was was incoming faster than i could handle i felt overloaded and lost interest. i am sure that is the same for everyone. TURs were to act as a buffer and make it easier for everyone to test out packages from incoming with a simple pacman -S instead of the more manual process for stright incoming handling.

in theory TURs should have worked better.

fianally, when i had left the dev team they only needed one more package maintainer and in that time they have replaced two and added one or two without substantial growth in the package repos (with respect to having need of more maintainers). there is the possiblity of having too many devs.

they just need to scare some of their devs out of hiding as a few of them seem to be rather elusive.

Arch Linux

#1 2004-03-06 11:49:36

About packages release method

#2 2004-03-06 16:26:52

Re: About packages release method

#3 2004-03-07 23:15:36

Re: About packages release method

#4 2004-03-07 23:22:47

Re: About packages release method

#5 2004-03-07 23:32:37

Re: About packages release method

#6 2004-03-08 06:54:56

Re: About packages release method

#7 2004-03-08 16:18:12

Re: About packages release method

#8 2004-03-08 17:31:29

Re: About packages release method

#9 2004-03-09 23:54:12

Re: About packages release method

#10 2004-03-09 23:58:09

Re: About packages release method

#11 2004-03-10 01:05:49

Re: About packages release method

#12 2004-03-10 01:39:43

Re: About packages release method

#13 2004-03-10 05:04:16

Re: About packages release method

Board footer