Dnia 2012-06-01, o godz. 12:11:06 Alex Belanger napisał(a):

Such tracking is usually done within the MAKEPKG file, e.g. [1]. It is indeed better practice but not mandatory. As long as we can contact the current maintainer, why the need of previous maintainer?

Second it doesn't really matter who owns the package. We all contribute to Arch together and benefits from everyone's work as a whole. I understand your willingness to own your baby, but we're a community. As long as I know the package is well maintained, it doesn't make a big difference wether it's him or you. You can always contact the person and deal something with them if it can help you sleep better.

I think you misunderstood me. It's not about taking packages back if they are maintained. It's about giving orphaned packages back to the previous maintainer if they are still orphaned and he has logged in again and pushed some new packages to AUR or started maintaining some other packages.

Lastly, you can already pick any package orphaned and give it some love. AUR doesn't have (and I don't think it will ever have) any kind of automated system for that. That's why we are here, also it helps keep an eye on what's going on and take the good decisions.

Please keep in mind I don't have the truth, I'm nowhere near TU rank here.

It's about having those orphaned packages maintained and giving them that love that you mentioned by last maintainer. I also don't have the truth but IMO many of those ppl like me (I hope I'm not the only one here who's back to Arch) will gladly continue to maintain old packages but there are times where you just don't remember you've ever had that or some other package under your care.

I'm just speaking common sense.

I'm really glad I can confront this idea with others and get some valuable response. Second paragraph is also my response to Oon-Ee Ng. Thanks!

Alex. [1] http://aur.archlinux.org/packages/ac/ace/PKGBUILD

-- Regards Marcin 'sirmacik' Karpezo http://sirmacik.net

Heiko Baums wrote:

Am Fri, 1 Jun 2012 20:20:14 +0200 schrieb Marcin 'sirmacik' Karpezo :

...

I think you misunderstood me. It's not about taking packages back if they are maintained. It's about giving orphaned packages back to the previous maintainer if they are still orphaned and he has logged in again and pushed some new packages to AUR or started maintaining some other packages.

What do you think a maintainer has orphaned a package or a package was orphaned by a TU? Maybe the maintainer isn't interested in maintaining it anymore? So why would you give those packages automatically back to those previous maintainers who are not interested in them? They most likely would feel annoyed by that and will orphan them again.

If you are interested in maintaining an orphaned package, feel free to adopt and maintain it yourself.

Sorry, but really pointless idea.

Um, I don't think you understood his idea, but at least it didn't stop you from replying with your usual abrasive tone. Simplified version: User Foo maintains x packages in AUR Foo decides to leave Arch for another distro Foo orphans his packages because he does not expect to be able to maintain them Foo later realizes how much better Arch is and returns to Arch as a prodigal son Foo is now ready to resume maintenance of his old packages *if necessary* Foo sees that y packages have been adopted and Foo is happy Foo would like to easily re-adopt the (x-y) packages that are still orphans He's just asking for a way to simplify finding the old packages *that are still orphans*. Now that the request is clear, I will say that I don't think this should be done on the AUR itself. As already mentioned, there are not many users who drop everything in the AUR and then come back (even if "they always come back"). Such a user could just write a script that: a) compiles a list of currently maintained AUR packages b) re-adopts them if they are orphans The list generation and orphan detection could both be done with python3-aur, but that cannot (yet?) log in and perform user operations.

On Fri, 1 Jun 2012 23:59:44 +0200 Cédric Girard wrote:

On Fri, Jun 1, 2012 at 10:42 PM, Xyne wrote:

...

Now that the request is clear, I will say that I don't think this should be done on the AUR itself. As already mentioned, there are not many users who drop everything in the AUR and then come back (even if "they always come back").

I don't think you should only focus on that particular use case. There may be other problems that could be solved by a more generic approach.

What I'm thinking about is having a "last maintainer" field that would be displayed and searchable for orphans packages. It would not only allow to easily find all packages that were belonging to a specific user but would also give an easy way to reach the last maintainer of an orphan package to get extra informations before adopting it.

This is just a random thought and may be pointless... What is your opinion on this?

It is possible to search by the "Submitter" so it's easily possible to search for packages that were originally created by oneself and take them if they are orphans by now. So this part of packages is covered in any case, coming back or simply having time to maintain packages in AUR again. Adding another search field for the last maintainer is in my opinion a waste of resources. Someone uses an orphaned, there's an upstream release, so the package is taken, updated and again orphaned as the time for real maintenance is missing. Someone else who has the time for this can take the package easily. That is a behaviour I've seen a lot of times with orphan packages. For the original idea of this thread this field is not quite useful in case someone did this with a package one maintained before the time lacked or one switched distributions, so the package won't show up. The more general case that one wants contact to the previous maintainer of the package is usually covered by the list of previous Contributors / Maintainers in a PKGBUILD - except one does not want to show up there in this case you already have the package and don't need to search for it. Of course the package would show up if nobody touched it, but comparing the database resources and the real use I still think this is more a waste of resources than actually useful. Currently there are 37159 packages in the AUR, 9774 of them are orphans that means 27385 packages currently have a maintainer who - in my opinion - do not really need this. -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

2012/6/2 Heiko Baums

...

I already understood this. This doesn't change anything. Still no reason for an automation. In those very rare cases I guess the previous maintainer still knows which packages he had maintained, and wants to continue maintaining. So he already can easily search for and adopt those packages.

...

Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR.

And what about asking to you? Or a field option on the sittings, like to receive a digest or to receive any mail separately, you could choose if you want your #Contributor flag to be removed or not

Am Sat, 2 Jun 2012 01:23:30 +0200 schrieb Cédric Girard :

On Sat, Jun 2, 2012 at 1:04 AM, Heiko Baums wrote:

...

Btw., I read at least one comment in the AUR in which the old maintainer asked to be removed from the #Contributor flag in the PKGBUILD. So I think that not everybody would be happy with such a previous maintainer field in the AUR.

Seems strange. Only real reason I can see for not wanting to appear as previous maintainer would be if the PKGBUILD has deviated too much from previous maintainer vision (and probably in a bad way). But it means the PKGBUILD has a new maintainer which is a different case.

Unfortunately I can't remember which package it was, but I remember that the previous maintainer hasn't given a reason for his request. A reason I could also think of are (new) privacy concerns for whatever reason. Heiko

Am Sat, 02 Jun 2012 01:23:46 +0200 schrieb Christian Stadegaart :

You were not sharing an opinion, you were sharing facts, right? I advise you to be careful with the words you choose.

Why? Answer my questions, and you will see that it's true. In the most cases you will come to the same conclusion than me. What do you think, why a maintainer has orphaned a package or a package was orphaned by a TU? Maybe the maintainer isn't interested in maintaining it anymore? The reason why someone orphans a package himself is in most cases that he is not interested in this package anymore. This can have several reasons. The most common reasons are: - He switches the distro from Arch to another one. - He doesn't use this package anymore and don't want to maintain it anymore. - He doesn't have time enough to maintaining the package. - There are major issues with the source package, and he doesn't want to spend too much time in patching the package. And many more. In most cases it's pretty unlikely that the previous maintainer wants to get the package back. And in the first case (switching the distro back to Arch Linux), I'm pretty sure that the maintainer still knows which packages he has maintained or he just looks for outdated, and orphaned packages he wants to use, like he was a new user. The reason why a package is orphaned by a TU is: - The package is outdated, the maintainer doesn't update it, and doesn't respond to the out-of-date flag, comments and e-mails within two weeks. You also can be pretty sure that the previous maintainer doesn't want the package back. So why would you give those packages automatically back to those previous maintainers who are not interested in them anymore? If I would orphan a package - and I already did this with a few - I would be pretty annoyed if an AUR automatism would see that those packages are orphaned, and assign them to me again, because there have been reasons why I have orphaned the package before. So, no reason for an automatism.

Your facts are based on *your* view and interpretation on the whole and prevent this subject to be discussed any further by stating it's a pointless idea just because the facts (read: the information you found and interpreted as facts) are saying so.

Not really an interpretation. See above.

I think Marcin's idea is not that bad. I wouldn't suggest it to be the way he writes, but some automation might be welcome. I don't have enough knowledge to come with another idea though.

What I think what you mean - and this is indeed an interpretation -, is writing a helper (a search function) for finding packages someone has maintained before, and adding a function (a button or the like) to adopt those packages again. Well, I don't have anything against this. I'm not sure if this is necessary, because, like I said before, I guess that everybody knows which packages he has maintained previously. But why not? For people who maintained about 100 packages this can be helpful. But this has not much to do with an automation, this is rather a search function and a helper. Heiko

Hugo Osvaldo Barrera wrote:

I think a list of "packages I've contributed to" (similar to "my packages", but also includes packages you've orphaned) in AUR would solve this, and be helpful for other stuff.

If a user leaves Arch for some reason, and comes back, IF he's intereseted in re-adopted his orphaned packages, he'll just see that list, and adopt them.

Currently, it's pretty hard to know what packages you've contributed to in the past, and it is something nice to have.

That poses two problems already raised in this thread: 1) privacy issues: not everyone will want to be permanently associated with packages 2) backend complexity: each package would have to store a list of contributors in the database 1 would not actually be a list of contributors, only a list of current and former maintainers, as those who contribute via comments will not be tracked in this way. It thus defeats the goal of giving credit, but it would still work to track previous maintainers. I lean towards the privacy argument on this and would prefer that we don't track every maintainer, but I don't see it as a big deal. I also think that tracking the last maintainer would be much more useful than the submitter. Currently someone could easily adopt orphaned packakges, insert malicious code and then orphan them again. A last-maintainer field would enable use to determine who did that and deal with it. Now, switching submitter for last maintainer might be easy enough to do on the backend.

Sorry for top-posting and such a long response time, but I had pretty rough time and I needed few hours of sleep to get operational again. [; Thanks for this awesome feedback. I'm really impressed and thankful for what the original idea turned out to be here. Such list of packages "I've maintained/contributed to" will completely be a good solution for a problem described by me and others mentioned here. I also don't remember all the packages I've maintained and if I hadn't had old backup on my github I'd ave no way to remember. If it's not too big trouble to implement it, I'd love to see such list in AUR. Thanks guys! Marcin W dniu 02.06.2012 17:21, Hugo Osvaldo Barrera pisze:

On 2012-06-02 11:55, Xyne wrote:

...

Hugo Osvaldo Barrera wrote:

...

I think a list of "packages I've contributed to" (similar to "my packages", but also includes packages you've orphaned) in AUR would solve this, and be helpful for other stuff.

If a user leaves Arch for some reason, and comes back, IF he's intereseted in re-adopted his orphaned packages, he'll just see that list, and adopt them.

Currently, it's pretty hard to know what packages you've contributed to in the past, and it is something nice to have.

That poses two problems already raised in this thread:

1) privacy issues: not everyone will want to be permanently associated with packages

That's why I said "package *I*'ve contributed to"; each user can only see him own contributions.

...

2) backend complexity: each package would have to store a list of contributors in the database

It's not really that complex. You'd need a new table ("former-maintainer"?) for mapping users<->packages.

...

1 would not actually be a list of contributors, only a list of current and former maintainers, as those who contribute via comments will not be tracked in this way. It thus defeats the goal of giving credit, but it would still work to track previous maintainers.

Yes, the list would actually be "packages I've maintained".

...

I lean towards the privacy argument on this and would prefer that we don't track every maintainer, but I don't see it as a big deal.

I also think that tracking the last maintainer would be much more useful than the submitter. Currently someone could easily adopt orphaned packakges, insert malicious code and then orphan them again. A last-maintainer field would enable use to determine who did that and deal with it.

Yes, that's exactly the point. I've maintained packages in the past, and I'm curious as to what happened to them. Since I actually adopted them (not submited), I've no way of easily listing them.

...

Now, switching submitter for last maintainer might be easy enough to do on the backend.

Yes, it makes much more sense; the last maintainer is way more relevant than the submitter. Complete rewrites are not uncommon, and the submiter is irrelevant in those cases.