[arch-dev-public] Moving packages into community
Hi, Most of the time, when a TU is working on adding a new package to community, he could: - Send a message on aur-general@al.org - Write some lines in the AUR package comments - Open a BR for inclusion - Push his new package to community. This let him time to carefully: - Test his modification - Start his communication with upstream - Warn the former AUR maintainers - Request some feedback. So, fellow TU, could you verify, before moving a package from AUR to community, that it is not already in *and* not already in process of being included. I added some lines about that in our Guidelines[1]. Cheers, [1] https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 02/11/2014 02:37 AM, Sébastien Luttringer wrote:
- Send a message on aur-general@al.org - Write some lines in the AUR package comments
I usually write a message directly to package maintainer, asking if he see any problems deterring the package from inclusion. I really don't see why I should forward/CC it to aur-general, especially when requirements listed on the wiki are met.
- Open a BR for inclusion Unnecessary procedure bringing only noise to the bugtracker and overcomplicating simple task.
- Test his modification I guess this is what most TUs do anyway before they push packages to repositories.
- Start his communication with upstream Makes sense only if software is problematic or upstream provides own PKGBUILD.
- Request some feedback. You can subscribe to arch-commits and forward your feedback to arch-dev-public or request it directly here.
So, fellow TU, could you verify, before moving a package from AUR to community, that it is not already in *and* not already in process of being included. Address your issues to TU who modified your package. I can only speak for myself, but it's clear to me that I'm late to the party if PKGBUILD is already in svn.
-- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 11/02/2014 14:39, Bartłomiej Piotrowski wrote:
On 02/11/2014 02:37 AM, Sébastien Luttringer wrote:
- Send a message on aur-general@al.org - Write some lines in the AUR package comments - Open a BR for inclusion - Push his new package to community
This is a short list of well known places where you can find hints that someone is already working on moving your package. I did *not* suggest that you should do one of the previous examples. I'm not telling you to open a BR before moving a package. I'm too lazy. But if you move a package, it's a good idea to check if there is bug report opened (or closed) about it. Like a feature request[1].
- Test his modification - Start his communication with upstream - Request some feedback.
All these bullets was to justify, that sometimes, you need more time than usual before pushing the binary package. That why we should check the previous places before inclusion.
Address your issues to TU who modified your package. Be sure that was the first thing I have done.
However that's not the first time I see this happening during the inclusion process, that motivated me to share this point on the list and add this "obvious" recommendation in our guidelines. Cheers, [1] https://bugs.archlinux.org/task/38698 -- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A
On 12 February 2014 03:57, Sébastien Luttringer <seblu@seblu.net> wrote:
On 11/02/2014 14:39, Bartłomiej Piotrowski wrote:
On 02/11/2014 02:37 AM, Sébastien Luttringer wrote:
- Send a message on aur-general@al.org - Write some lines in the AUR package comments - Open a BR for inclusion - Push his new package to community
This is a short list of well known places where you can find hints that someone is already working on moving your package. I did *not* suggest that you should do one of the previous examples.
I'm not telling you to open a BR before moving a package. I'm too lazy. But if you move a package, it's a good idea to check if there is bug report opened (or closed) about it. Like a feature request[1].
- Test his modification - Start his communication with upstream - Request some feedback.
All these bullets was to justify, that sometimes, you need more time than usual before pushing the binary package. That why we should check the previous places before inclusion.
Address your issues to TU who modified your package. Be sure that was the first thing I have done.
However that's not the first time I see this happening during the inclusion process, that motivated me to share this point on the list and add this "obvious" recommendation in our guidelines.
Agree on all points, and have updated the wiki edit to make the suggestions clearer: https://wiki.archlinux.org/index.php?title=AUR_Trusted_User_Guidelines&diff=296958&oldid=296802 -- GPG/PGP ID: C0711BF1
participants (3)
-
Bartłomiej Piotrowski
-
Ray Rashif
-
Sébastien Luttringer