[arch-dev-public] Let's use the Maintainer tag

[Eric Belanger]

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 at gmail.com>:
>> On Sat, Sep 20, 2008 at 5:24 PM, Dusty Phillips <buchuki at gmail.com> wrote:
>>> 2008/9/20 Pierre Schmitz <pierre at 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.