Developer Opening: Package Maintainer

apeiro · 2005-06-02 17:23:31

Hey guys.

It's time to get a couple more maintainers on the dev team. Eric Johnson (farphel) is leaving, so we'll need some people to pick up his packages. There are also quite a few orphan packages that need some love.

http://www.archlinux.org/jobs/maintainer.html

If you're interested and you've got the goods, lemme know. Preference will be given to long-standing community members and people that have proven they can get things done.

Thanks!

i3839 · 2005-06-02 19:04:45

I've no idea how things go behind the curtains, but from my point of view it looks like there's some strange invisible gap between package maintainers and TUs. Why not just merge the two groups together? They both just make packages which can be trusted, but they've different names.

Of course this doesn't increase the total number of supported packages, but it may be a good way to get more package maintainers in the long run.

Any reason why orphaned packages can't be (automatically) pushed to AUR? Or is having it once in an offical repo enough reason to keep around the outdated package instead of letting people handle it themselves if they want?

As I see it the offical packages can be trusted to work and trusted to be safe. The later is much easier to assure than the first, as reading and auditing the pkgbuilds is enough, while for the first extensive testing is needed. What about letting some trusted people audit the packages in AUR, and if deemed safe they are marked as such in some way? If the binary package isn't build automatically from the PKGBUILD then the auditing people probably should also upload their version. Then it is also more certain that such pkgbuilds is not only safe, but also builds.

All packages which passed "phase 1" are added automatically to an AUR repo, so that people can easily use and keep such packages up to date. Then the quality control is in users' hands, while the safety of packages is assured. Main goal is of course to have as much usable packages as possible while keeping the maintenance cost for the Arch team low. It also makes it more rewarding for users to submit packages to AUR, as they can be used more easily by other users.

bardo · 2005-06-04 13:09:14

i3839 wrote:

I've no idea how things go behind the curtains, but from my point of view it looks like there's some strange invisible gap between package maintainers and TUs. Why not just merge the two groups together? They both just make packages which can be trusted, but they've different names.

Well, I don't completely agree with you. I could make packages as a TUR without any problem (I already maintain a bunch of packages in the AUR), but I surely don't have all the skills requested to become a dev maintainer, or at least not at the requested level.

While I'm sure some TUs should be official devs, maybe there's somebody like me who surely can make, maintain and keep packages up to date, but wouldn't be "enough", even if they'd love to be... don't know if I'm clear

Just my 2 cents

i3839 · 2005-06-04 14:02:50

I don't know if you're a TU or not, but one of the many requirements to become a TU seems to be that you can be trusted to make good and working packages. Simply adding some working packages to AUR isn't enough. The whole point is that a Trusted User can be trusted to provide quality packages. Anything else, like TUs not having the required skills of a "real" package maintainer, means that TUs can't be really trusted, making the title sort of empty.

Perhaps not all TUs should be made official package maintainers, but those that want it and have enough time should be able to become one very easily. Then the only difference is that a TU has not enough time and manages less than 30 packages.

I'm not a TU, nor a dev, just a watching bystander who doesn't understand and tries to give advice.

BTW, is there anywhere a public archive of arch-dev?

Dusty · 2005-06-04 15:10:02

i3839: I do know what goes on behind the curtain, and I firmly support the separation of the two communities. The difference is not so much in the quality of the packages, but in the control of other works. Basically, TUs maintain packages independently of the developers. Package Maintainers are developers, meaning they have a lot more input into the direction and control of the entire distro as a whole. Though a TU may be trusted to make good packages, I may not trust them to direct AL's future the way I trust Judd, Jason, Damir, and the rest of the crew.

Dusty

i3839 · 2005-06-04 16:09:04

Thanks for clearing that up Dusty. So the TUs have their community repo and the Arch devs have base/extra/etc, making both communities happy.

I'm toying with the idea of starting an AUR auditing project. It would consist of a group of people who audit packages in AUR and a repo of the trusted packages of AUR which aren't in community (currently only about 100 of the 700 packages are in community). The idea is to let people themselves manage their own packages, and to provide almost all AUR packages to users through an AUR repo instead of only a random subset. I'll wait a bit to see how fast the community repo grows before making any decisions.

Dusty · 2005-06-04 16:48:05

I think it would be better just to add more TUs than to have another repository of "trusted" packages... although the idea of not having any one person responsible for a specific package may have merit.

I'm thinking of writing a script that automatically downloads and builds pkgbuilds from unsupported. The catch is you have to be smart enough to check that the PKGBUILD is decent quality before installing it... basically, it would just automate the download and build package process after you've manually verified the package contents online.

Dusty

i3839 · 2005-06-04 17:59:24

Mere mortals can't just add and maintain some packages in AUR which are accessible through a repo for other users. Only when the maintainership is taken away by some TU then the package is availabe. The goal should be to let the users do as much work as possible, not to take it away from them.

As only checking if a pkgbuild is safe and builds is much less work than making sure a package really works and keeping it up to date, I thought it would be good to concentrate only on the minimal safety guarantee needed before you can install packages from strangers without worrying about nastiness.

Adding TUs is the brute-force way, not really scalable at first glance, considering how long it takes before even dibble becomes one. The TU thing resembles too much a community with al its politics and whatnot instead of a system that provides as much packages as possible in a convenient way to users. AUR comes close, but there is no AUR repo, so you can't easily keep packages from AUR up to date as far as I know. Though an AUR repo may be too crude, the community repo seems too official. So something in between seems like a good gap filler.

But if after a while the most popular packages from AUR are in community and everyone thinks that's good enough then I won't bother of course.

Dusty · 2005-06-04 18:42:56

hmm, good points all of them. I guess you're right to just wait and see if the current solution will work or not...

Dusty

bardo · 2005-06-04 18:52:17

i3839: I'm not a TU, but Dusty said it right. I modestly think that my packages are good, I've been using linux for some years now, I can do bash/sed scripting, and as you can see my PKGBUILDs are not always the "trivial-three-command" ones. I think I could be a TU, even though I don't know if I could keep the commitment and get the work done.

I surely couldn't be an Arch dev, because as the name says you should act on the whole distro, which is just not the simple packages, there's a lot of work to be done, and you have to be sure of what the people working with you can, or cannot, do.

About the AUR question, I noticed how underrated is the voting question, and I think that this is the problem with it. Maybe there should be a function to mark a package as "bad build" with possibility to comment about it, so we could add the help of the community to spot which PKGBUILDs are dangerous. Just as we say "I need this package" with a vote, we should be able to say "I like/dislike its build", and we'd make clear what the real aim of every function.
I think most people do not use the AUR because they don't feel good enough with all those things written by other people and rarely verified.

Once people starts using the AUR, and judging the builds, then we will able to say there's no need for other repos, TUs or anything else.

Tell me what you think

Dusty · 2005-06-04 19:01:24

bardo wrote:

About the AUR question, I noticed how underrated is the voting question, and I think that this is the problem with it. Maybe there should be a function to mark a package as "bad build" with possibility to comment about it, so we could add the help of the community to spot which PKGBUILDs are dangerous.

This is a great idea. There's already a commenting mechanism in AUR, but a flag to warn other users that it is dangerous is a good idea. I'll post it to the bug tracker.

http://bugs.archlinux.org/index.php?do=details&id=2797

Dusty

i3839 · 2005-06-04 19:29:04

If "package maintainer" wouldn't imply "Arch dev" but simply what it says then the problem is sort of gone. Assuming that packages follow Arch guidelines and don't have a big influence like e.g. the rc scripts and init. But enough about this.

Voting for quality of packages is good, but it won't really help a lot because it isn't organized. The exact purpose of the current vote system is already vague, let alone the confusion of the new one. It also doesn't help to verify that the binary package is alright (build with the given pkgbuild), nor does it help getting an AUR repo with safe packages. But if done right it could work I suppose, though the chance that AUR is polluted with comments about the security aspect of a package instead of about the package itself is high. I expect communication between the auditors more suited for a dedicated mailinglist.

We'll always need different repo's, as one repo can't fulfil all functionality. More or less what there's now and could be:

1) official repo's: can be trusted and expected high quality.

2) TUR/community: same as official, but made by other people.

3) AUR: high chance of being safe, but no quality guarantees other than that it builds and installs.

4) bare binaries from the AUR site: use at your own risk.

EDIT:
I fixed the url in your post Dusty, if you don't mind. Also, this voting system is good to have independend of the active auditing thing, and should go both ways: you should be able to vote that a package is alright, but one vote that it isn't should invalidate the whole package, so to speak, until the matter is resolved. Now only what's missing is that all packages with a certain goodness score are automatically build and added to an AUR repo which people can use (say 5 positive votes and none negative). Also if a new version is uploaded then the whole process needs to start again; perhaps if only the versions changed it could be automated so that it isn't needed. In most other cases it should.

pjmattal · 2005-06-10 11:28:41

Dusty wrote:

bardo wrote:
About the AUR question, I noticed how underrated is the voting question, and I think that this is the problem with it. Maybe there should be a function to mark a package as "bad build" with possibility to comment about it, so we could add the help of the community to spot which PKGBUILDs are dangerous.
This is a great idea. There's already a commenting mechanism in AUR, but a flag to warn other users that it is dangerous is a good idea. I'll post it to the bug tracker.
http://bugs.archlinux.org/index.php?do=details&id=2797
Dusty

This is a very good idea. It could work like the out of date flag, where it's toggle-able. Then a user can log in and see what's going on.

There is currently the ability for a package to be deleted from the AUR, but it's not exactly working properly. That will be fixed in the next major rollout release. TUs and devs will be able to remove packages from unsupported arbitrarily.

Best,
Paul

Arch Linux

#1 2005-06-02 17:23:31

Developer Opening: Package Maintainer

#2 2005-06-02 19:04:45

Re: Developer Opening: Package Maintainer

#3 2005-06-04 13:09:14

Re: Developer Opening: Package Maintainer

#4 2005-06-04 14:02:50

Re: Developer Opening: Package Maintainer

#5 2005-06-04 15:10:02

Re: Developer Opening: Package Maintainer

#6 2005-06-04 16:09:04

Re: Developer Opening: Package Maintainer

#7 2005-06-04 16:48:05

Re: Developer Opening: Package Maintainer

#8 2005-06-04 17:59:24

Re: Developer Opening: Package Maintainer

#9 2005-06-04 18:42:56

Re: Developer Opening: Package Maintainer

#10 2005-06-04 18:52:17

Re: Developer Opening: Package Maintainer

#11 2005-06-04 19:01:24

Re: Developer Opening: Package Maintainer

#12 2005-06-04 19:29:04

Re: Developer Opening: Package Maintainer

#13 2005-06-10 11:28:41

Re: Developer Opening: Package Maintainer

Board footer