[arch-dev-public] Let's use the Maintainer tag
Hey devs, I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again. On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too. That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs. And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people. Pierre -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs.
And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people.
I'm all for it; it would make the web interface more robust. I don't think the issue with packages being orphaned will come up again, but having that data accurate in each PKGBUILD and .pkg.tar.gz file would make the entire world a much better place. (Especially greenland) Dusty
On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
I see a few problems/issues here. 1) Maintainer is a shell script comment. This means it is completely ignored by makepkg, and I will NOT manually parse the file for this one piece of information, it is just not worth it. 2) Your name will end up in packages you never built. Anyone building a package from ABS and customizing it doesn't delete the maintainer tag, and then people will come to you with questions about pidgin-awesome or something and you will have no idea what they are talking about. 3) All of this pertains only to organizational issues. Personal users of makepkg have no real use for this.
That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs.
And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people.
I'm all for it; it would make the web interface more robust. I don't think the issue with packages being orphaned will come up again, but having that data accurate in each PKGBUILD and .pkg.tar.gz file would make the entire world a much better place. (Especially greenland)
I see the problem we are trying to solve, but I'm not convinced this is the best way to do it. I wish I had an idea to propose though... -Dan
For the record, there is already maintainer information stored in the .db.tar.gz -- I don't know where it comes from but I noticed it there when I was debugging the last issue. Another option is automatically setting the maintainer flag to whoever updates the package. There could be an override to the command or hook that does this so that people can update other people's packages when necessary. Dusty 2008/9/20 Dan McGee <dpmcgee@gmail.com>:
On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
I see a few problems/issues here. 1) Maintainer is a shell script comment. This means it is completely ignored by makepkg, and I will NOT manually parse the file for this one piece of information, it is just not worth it. 2) Your name will end up in packages you never built. Anyone building a package from ABS and customizing it doesn't delete the maintainer tag, and then people will come to you with questions about pidgin-awesome or something and you will have no idea what they are talking about. 3) All of this pertains only to organizational issues. Personal users of makepkg have no real use for this.
That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs.
And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people.
I'm all for it; it would make the web interface more robust. I don't think the issue with packages being orphaned will come up again, but having that data accurate in each PKGBUILD and .pkg.tar.gz file would make the entire world a much better place. (Especially greenland)
I see the problem we are trying to solve, but I'm not convinced this is the best way to do it. I wish I had an idea to propose though...
-Dan
On Sat, 20 Sep 2008, Dusty Phillips wrote:
For the record, there is already maintainer information stored in the .db.tar.gz -- I don't know where it comes from but I noticed it there when I was debugging the last issue.
What you saw was probably the packager info which is not the same as the maintainer.
Another option is automatically setting the maintainer flag to whoever updates the package. There could be an override to the command or hook that does this so that people can update other people's packages when necessary.
That seems messy. Especially for things as x86_64 builds and testing rebuilds.
Dusty
2008/9/20 Dan McGee <dpmcgee@gmail.com>:
On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
I see a few problems/issues here. 1) Maintainer is a shell script comment. This means it is completely ignored by makepkg, and I will NOT manually parse the file for this one piece of information, it is just not worth it. 2) Your name will end up in packages you never built. Anyone building a package from ABS and customizing it doesn't delete the maintainer tag, and then people will come to you with questions about pidgin-awesome or something and you will have no idea what they are talking about. 3) All of this pertains only to organizational issues. Personal users of makepkg have no real use for this.
That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs.
And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people.
I'm all for it; it would make the web interface more robust. I don't think the issue with packages being orphaned will come up again, but having that data accurate in each PKGBUILD and .pkg.tar.gz file would make the entire world a much better place. (Especially greenland)
I see the problem we are trying to solve, but I'm not convinced this is the best way to do it. I wish I had an idea to propose though...
-Dan
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Sat, Sep 20, 2008 at 6:23 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki@gmail.com> wrote:
2008/9/20 Pierre Schmitz <pierre@archlinux.de>:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
I see a few problems/issues here. 1) Maintainer is a shell script comment. This means it is completely ignored by makepkg, and I will NOT manually parse the file for this one piece of information, it is just not worth it. 2) Your name will end up in packages you never built. Anyone building a package from ABS and customizing it doesn't delete the maintainer tag, and then people will come to you with questions about pidgin-awesome or something and you will have no idea what they are talking about. 3) All of this pertains only to organizational issues. Personal users of makepkg have no real use for this.
As Eric pointed out, Pierre is talking about the maintainer of the PKGBUILD, not the builder of the package. Additionally, if parsing shell scripts is the issue here, why not add some new metainfo: maintainer="Aaron Griffin <aaronmgriffin@gmail.com>" Seems ok to me. We could even start doing it right now, as makepkg will just ignore it for now
On Sun, Sep 21, 2008 at 10:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Additionally, if parsing shell scripts is the issue here, why not add some new metainfo: maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"
Seems ok to me. We could even start doing it right now, as makepkg will just ignore it for now
Side note. Just to future-proof this, we'd probably want an array, for the case of multiple maintainers
Aaron Griffin wrote:
On Sun, Sep 21, 2008 at 10:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Additionally, if parsing shell scripts is the issue here, why not add some new metainfo: maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"
Seems ok to me. We could even start doing it right now, as makepkg will just ignore it for now
Side note. Just to future-proof this, we'd probably want an array, for the case of multiple maintainers
+2 - P
2008/9/22 Aaron Griffin <aaronmgriffin@gmail.com>:
As Eric pointed out, Pierre is talking about the maintainer of the PKGBUILD, not the builder of the package.
Additionally, if parsing shell scripts is the issue here, why not add some new metainfo: maintainer="Aaron Griffin <aaronmgriffin@gmail.com>"
I think a new metainfo is a nice idea but it'd be cool if the devs could additionally be allocated a unique ID that can be cross-reffed to a dbase to avoid having to update the email manually/avoid having an out of date email in an old file. The first thing that springs to mind as an ID is the list of names on http://www.archlinux.org/developers/ e.g. maintainer=(AaronG DanM) I'm thinking these could be nicely parsed out in/by the web interface and linked up to hopefully up to date contact details. A few caveats instantly spring to mind, such as this is only really implementable for official pkgs and devs, but it can also provide nice meta info for AUR pkgs.
Seems ok to me. We could even start doing it right now, as makepkg will just ignore it for now
Am Montag 22 September 2008 17:12:08 schrieb Phil Dillon-Thiselton:
I think a new metainfo is a nice idea but it'd be cool if the devs could additionally be allocated a unique ID that can be cross-reffed to a dbase to avoid having to update the email manually/avoid having an out of date email in an old file.
We all have an adress like <username>@archlinux.org. So I would prefere this solution. That would also be consistent to the packager data. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On Mon, 22 Sep 2008, Pierre Schmitz wrote:
Am Montag 22 September 2008 17:12:08 schrieb Phil Dillon-Thiselton:
I think a new metainfo is a nice idea but it'd be cool if the devs could additionally be allocated a unique ID that can be cross-reffed to a dbase to avoid having to update the email manually/avoid having an out of date email in an old file.
We all have an adress like <username>@archlinux.org. So I would prefere this solution. That would also be consistent to the packager data. I eg. obfuscate this one because /me hates spam. It's so easily accessable for email harvester.
my 2c. I do like the idea in genral though, to have amaintainer tag. With a growing number of developers and probably packages we might end up having architecture bound maintainers and this must be reflected in the maintainer tag. All my 64bit packages are build by Andy and Eric, because I dun have a 64bit machine. I'm still officailly the maintainer but for blender it's mainly Andy wrestling with it. -Tobias
Pierre Schmitz wrote:
Hey devs,
I think our current method of organizing maintainership of packages is not optimal. One problem is that we loose those meta information from time to time (we have 2667 orphaned packages atm). Also the webinterface for adopting packages is not the best solution I could think of. You have to adopt every single arch and if you put a package into testing you'll have to adopt it again.
On the other side we have the Maintainer tag within our PKGBUILDs since a long time, but we don't make use of it. My idea would be parsing those tags (multipile maintainers should be possible) with makepkg and put those information in every package. In addition to this repo-add should store this data in the db-files, too.
That would make things a lot easier, more robust (we have all data stored in svn) and consistent. This would also decrease the complexity of the webfrontend a lot; it allready reads data from the sync-dbs.
And last but not least support could be added to pacman to display the mainter(s). ATM it only shows the packager which confuses some people.
I like the idea but I think it would be better to just have something parse the SVN repo. Currently makepkg does not see the Maintainer entry as it is a comment. So to have this information get into packages, we would need to either change how we set the maintainer field in PKGBUILDs or some other hack. Having the maintainer based on the current field in SVN trunk would also allow for orphaning (just remove field) and adoption without having to rebuild the package. Allan
participants (9)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Dusty Phillips
-
Eric Belanger
-
Paul Mattal
-
Phil Dillon-Thiselton
-
Pierre Schmitz
-
Tobias Kieslich