[aur-general] Should TU put in [community] packages they use?

older
[aur-general] qt-4 and qt3 will...

bardo

18 Jan 2008 18 Jan '08

1:50 p.m.

This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question. There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base? Corrado

Show replies by date

Ronald van Haren

18 Jan 18 Jan

2:01 p.m.

On Jan 18, 2008 2:50 PM, bardo wrote:

...

This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

Corrado

In my opinion you should leave these packages in unsupported. Sure it it great for the small userbase the package may have to get updates via community, but at one point you, or any other TU may leave, giving the rest of the TUs not much options than to put these packages in unsupported (I can imagine it are quite a number of packages for all TUs together). Now the small userbase which did use this package is assuming automatic updates because 'it is in community', which is not the case anymore, leaving the package in unsupported for a long time without being adopted/updated by someone (and the users using an outdated community build). For more popular packages this would obviously not be the case because there will probably always be someone noticing that a new version is released, and when the user wants to flag it out of date he notices it is orphaned and adopts it.

Darwin Bautista

2:03 p.m.

IMHO, TUs should prioritize packages with sufficiently high votes (and are eligible, of course). I've seen quite a lot of "unpopular" (software that I haven't even heard of before and probably never/seldom used) packages in community lately when there are in fact a lot of other, more popular, packages that needs a TU's love. (I'm not a TU but I also use [community] that's why I wanted my voice to be heard.) On Jan 18, 2008 9:50 PM, bardo wrote:

...

This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

-- Darwin M. Bautista BS Electronics and Communications Engineering University of the Philippines Diliman http://www.darwin.uk.to University of the Philippines Linux Users' Group http://www.uplug.org

Grigorios Bouzakis

2:25 p.m.

On Fri, Jan 18, 2008 at 02:50:31PM +0100, bardo wrote:

...

This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

Corrado

As i had also stated in my previous illiterate mail (sorry for that), IMHO yes, TU's should upload to community only packages that have high demand by users. This is also the case now for developers about uploading packages in extra too. I think i am one of the few people who dont use community anymore and that fact is one of the main reasons. The community repo has gone very big, with many high demand packages staying in unsupported, while many of the packages in community have low usage, are old projects with almost no updates for years and build in a couple of secs. Even though the later isnt a reason for them to not be in community. If TU's want to upload to community packages they use before adding them to unsupported they should instead consider creating a custom local repo just like everyone else. You guys arent TU's to only help yourself but mostly help other community members and the distro itself. Greg

Alessio Bolognino

2:43 p.m.

On Fri 2008-01-18 16:25 , Grigorios Bouzakis wrote:

...

On Fri, Jan 18, 2008 at 02:50:31PM +0100, bardo wrote:

...
[...]

As i had also stated in my previous illiterate mail (sorry for that), IMHO yes, TU's should upload to community only packages that have high demand by users. This is also the case now for developers about uploading packages in extra too. I think i am one of the few people who dont use community anymore and that fact is one of the main reasons. The community repo has gone very big, with many high demand packages staying in unsupported, while many of the packages in community have low usage, are old projects with almost no updates for years and build in a couple of secs.

One of the worst thing a TU can do is to move a high demanded package that he doesn't use in [community]. This way he can't test it properly, and no, just trying if it runs one time, before committing it in the repo is not "proper testing".

...

Even though the later isnt a reason for them to not be in community. If TU's want to upload to community packages they use before adding them to unsupported they should instead consider creating a custom local repo just like everyone else.

Just use common sense, IMVHO there is no problem if a TU moves 5 packages he uses on every machine in [community]. It *is* a problem if he moves 300 packages.

...

[...]

Cheers, -- Alessio Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB

Grigorios Bouzakis

4:01 p.m.

On Fri, Jan 18, 2008 at 03:43:28PM +0100, Alessio Bolognino wrote:

...

On Fri 2008-01-18 16:25 , Grigorios Bouzakis wrote:

...
On Fri, Jan 18, 2008 at 02:50:31PM +0100, bardo wrote:

...
[...]

As i had also stated in my previous illiterate mail (sorry for that), IMHO yes, TU's should upload to community only packages that have high demand by users. This is also the case now for developers about uploading packages in extra too. I think i am one of the few people who dont use community anymore and that fact is one of the main reasons. The community repo has gone very big, with many high demand packages staying in unsupported, while many of the packages in community have low usage, are old projects with almost no updates for years and build in a couple of secs.

One of the worst thing a TU can do is to move a high demanded package that he doesn't use in [community]. This way he can't test it properly, and no, just trying if it runs one time, before committing it in the repo is not "proper testing".

Well, they should ask testing from the users of the application then. I clearly remember developers doing that numerous of times with many packages. Personaly, i consider developers to be the same as TU's when it comes to building packages for the repos. I am certain there are packages in extra their maintainer doesnt use. Yet they continue building them for having them available for the users. One example that can be seen in most TU application is the user stating the packages he maintains in unsupported and gonna move to community. Why should a TU move some/all of his maintained packages from unsupported and not instead grab others that have many more votes than his or take care of some already in the repo, orphans or from a TU with many maintained packages? I have to admit that many TU's follow the amount of votes principle and at the same time keep low used packages in unsupported too but others just maintain only what they want to maintain. At least a certain amount of moderation is needed on what goes to the repos. Greg

Aaron Schaefer

8:08 p.m.

On Jan 18, 2008 8:50 AM, bardo wrote:

...

This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

Corrado

This is my take...I don't see any down side to including the packages in community. I suppose you could say that bandwidth on the mirrors would be one, but that's about it. People are arguing that the AUR should be run like to official repositories where the devs ask the other devs if it's okay to add packages to extra/core, but their reasoning for the recent cleanup and rules regarding that aspect are because those two repos define Arch Linux as a distribution. That's not really the case with community. Even if only a few people are voting for the packages, like Corrado said, the TU is doing the work anyway, so why not let everyone benefit from it since downloading/installing from the community repo is a lot easier for everyone than building from a PKGBUILD, especially if you're not familiar with building from source. Plus votes might not be an accurate portrayal of usage, if you consider that many times dependencies of a popular package might not have nearly as many votes as the package that requires them, but I'd still put them in the same repo for convenience. Yes, the TUs should be helping to move popular packages in to community as well, but ideally it would be a package that they are interested in using themselves so they actually will be able to test and use it themselves rather than just knowing that it built without errors. I think Allesio made that point very well. Aaron "ElasticDog" Schaefer --

Darwin Bautista

19 Jan 19 Jan

10:55 a.m.

On Jan 19, 2008 4:08 AM, Aaron Schaefer wrote:

...

On Jan 18, 2008 8:50 AM, bardo wrote:

...
This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

Corrado

This is my take...I don't see any down side to including the packages in community. I suppose you could say that bandwidth on the mirrors would be one, but that's about it. People are arguing that the AUR should be run like to official repositories where the devs ask the other devs if it's okay to add packages to extra/core, but their reasoning for the recent cleanup and rules regarding that aspect are because those two repos define Arch Linux as a distribution. That's not really the case with community.

Even if only a few people are voting for the packages, like Corrado said, the TU is doing the work anyway, so why not let everyone benefit from it since downloading/installing from the community repo is a lot easier for everyone than building from a PKGBUILD, especially if you're not familiar with building from source. Plus votes might not be an accurate portrayal of usage, if you consider that many times dependencies of a popular package might not have nearly as many votes as the package that requires them, but I'd still put them in the same repo for convenience.

Yes, the TUs should be helping to move popular packages in to community as well, but ideally it would be a package that they are interested in using themselves so they actually will be able to test and use it themselves rather than just knowing that it built without errors. I think Allesio made that point very well.

...

From the guidelines in the wiki, I can only conclude that TUs have the duty to adopt and maintain popular packages (nothing is said about 'personal' packages though). Of course, I might be wrong if the guidelines in the wiki are already outdated or are no longer applicable/used. Lastly, the last line, "The voting mechanism in the AUR allows a TU to quickly gauge which packages users want." suggests

But the AUR Trusted User Guidelines says otherwise. Ideally, "... He/she maintains popular packages, ..." "A TU may adopt any package at any time. But because the TU's time is limited, he should try to only adopt popular packages. The voting mechanism in the AUR allows a TU to quickly gauge which packages users want." that TUs should also consider what the users want (maybe that's the reason why the repo was named 'community'). -- Darwin M. Bautista BS Electronics and Communications Engineering University of the Philippines Diliman http://www.darwin.uk.to University of the Philippines Linux Users' Group http://www.uplug.org

bardo

12:23 p.m.

2008/1/19, Darwin Bautista :

...

But the AUR Trusted User Guidelines says otherwise. Ideally, "... He/she maintains popular packages, ..."

I didn't notice this passage, good to know.

...

"A TU may adopt any package at any time. But because the TU's time is limited, he should try to only adopt popular packages. The voting mechanism in the AUR allows a TU to quickly gauge which packages users want."

This paragraph focuses on the free time of a TU, but I would maintain those packages anyway, so the time I need to maintain them doesn't account in my free time. Anyway, the point about a TU resigning and leaving his "unpopular" packages behind is strong too. As you see I am really undecided =) C.

w9ya＠qrparci.net

7:18 p.m.

...

On Jan 19, 2008 4:08 AM, Aaron Schaefer wrote:

...
On Jan 18, 2008 8:50 AM, bardo wrote:

...
This came to my mind reading the discussion about Sergej, but after some thinking I couldn't make up a clear opinion about it, so this thread just brings up the question.

There's a few packages I maintain in unsupported that almost nobody voted, so I never moved them to [community]. But what if I use them in my daily activities? I'm interested in having an up-to-date package, so I'd maintain, build and test it anyway... should I share it with its (small) user base?

Corrado

This is my take...I don't see any down side to including the packages in community. I suppose you could say that bandwidth on the mirrors would be one, but that's about it. People are arguing that the AUR should be run like to official repositories where the devs ask the other devs if it's okay to add packages to extra/core, but their reasoning for the recent cleanup and rules regarding that aspect are because those two repos define Arch Linux as a distribution. That's not really the case with community.

Even if only a few people are voting for the packages, like Corrado said, the TU is doing the work anyway, so why not let everyone benefit from it since downloading/installing from the community repo is a lot easier for everyone than building from a PKGBUILD, especially if you're not familiar with building from source. Plus votes might not be an accurate portrayal of usage, if you consider that many times dependencies of a popular package might not have nearly as many votes as the package that requires them, but I'd still put them in the same repo for convenience.

Yes, the TUs should be helping to move popular packages in to community as well, but ideally it would be a package that they are interested in using themselves so they actually will be able to test and use it themselves rather than just knowing that it built without errors. I think Allesio made that point very well.

But the AUR Trusted User Guidelines says otherwise. Ideally, "... He/she maintains popular packages, ..."

"A TU may adopt any package at any time. But because the TU's time is limited, he should try to only adopt popular packages. The voting mechanism in the AUR allows a TU to quickly gauge which packages users want."

...
From the guidelines in the wiki, I can only conclude that TUs have the duty to adopt and maintain popular packages (nothing is said about 'personal' packages though). Of course, I might be wrong if the guidelines in the wiki are already outdated or are no longer applicable/used. Lastly, the last line, "The voting mechanism in the AUR allows a TU to quickly gauge which packages users want." suggests that TUs should also consider what the users want (maybe that's the reason why the repo was named 'community').

-- Darwin M. Bautista

Hey Darwin and the gang; Well, the "guidelines" are just that, as they are NOT rules, and part of a wiki document that may change at any time. And please ALSO remember that the paragraph starts with "A TU may adopt any package at any time.", which *IS* the basis for a TU's decision. i.e. The decision rest solely with the TU as it always has. So, if you understand that the wiki is a suggestion, and presents *A* method to consider, then you understand fully that the TU makes his or her decision and then is judged on his or her Quality and NOT quantity or any other specific item (including the voting field). And since it is a simple process to become a TU, then those amongst us that would like to base their repo contributions on the AUR voting field may do so, as they can merely write a few PKGBUILDs and submit them for consideration when they ask to become a TU. IF you seek admission as a TU you will find that you have to merely ask. And the more TUs then the more fun we will all have and if YOU want to put highly voted items from the AUR into the repo, you certainly can. Very best regards; Bob Finch

5939

Age (days ago)

5940

Last active (days ago)

List overview

Download

9 comments

7 participants

participants (7)

Aaron Schaefer
Alessio Bolognino
bardo
Darwin Bautista
Grigorios Bouzakis
Ronald van Haren
w9ya＠qrparci.net