Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Fri, Mar 27, 2015 at 09:45:25PM +0100, Pacho Ramos wrote: El mié, 25-03-2015 a las 21:25 +, Robin H. Johnson escribió: [...] - timeout: this is how long you we suggest you wait for the maintainer/team to comment on your change. Format should be a short duration specifier per ISO8601 I'd like to default it to 1 week: 'P1W'. [...] I would establish a maximum here to prevent people from avoiding any changes by others setting, for example, the value to 1 year and, once the issue is completely ignored, blaming on not following the metadata.xml rules :| Ok, what's a reasonable max that doesn't block progress? P6M? -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
El vie, 27-03-2015 a las 21:03 +, Robin H. Johnson escribió: On Fri, Mar 27, 2015 at 09:45:25PM +0100, Pacho Ramos wrote: El mié, 25-03-2015 a las 21:25 +, Robin H. Johnson escribió: [...] - timeout: this is how long you we suggest you wait for the maintainer/team to comment on your change. Format should be a short duration specifier per ISO8601 I'd like to default it to 1 week: 'P1W'. [...] I would establish a maximum here to prevent people from avoiding any changes by others setting, for example, the value to 1 year and, once the issue is completely ignored, blaming on not following the metadata.xml rules :| Ok, what's a reasonable max that doesn't block progress? P6M? I would prefer 1M (well... if the developer is not able to even comment in bug reports in 1 month, maybe he should have at least a devaway message explaining how to deal with his/her packages if he is not able to reply so soon) :/ Anyway, that is my personal opinion of course, maybe other would prefer 3M or similar :|
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Fri, 27 Mar 2015 22:14:04 +0100 Pacho Ramos pa...@gentoo.org wrote: I would prefer 1M (well... if the developer is not able to even comment in bug reports in 1 month, maybe he should have at least a devaway message explaining how to deal with his/her packages if he is not able to reply so soon) :/ Anyway, that is my personal opinion of course, maybe other would prefer 3M or similar :| Why not have a forums poll? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
El mié, 25-03-2015 a las 21:25 +, Robin H. Johnson escribió: [...] - timeout: this is how long you we suggest you wait for the maintainer/team to comment on your change. Format should be a short duration specifier per ISO8601 I'd like to default it to 1 week: 'P1W'. [...] I would establish a maximum here to prevent people from avoiding any changes by others setting, for example, the value to 1 year and, once the issue is completely ignored, blaming on not following the metadata.xml rules :|
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 23.03.2015 18:22, Tim Harder wrote: With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. +1 (to any other non-herd marker in metadata.xml to achieve the same effect, too) Sebastian
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Tue, Mar 24, 2015 at 08:41:52AM +0100, Alexis Ballier wrote: On Mon, 23 Mar 2015 13:22:25 -0400 Tim Harder radher...@gentoo.org wrote: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? sounds like nmu is what you want: https://archives.gentoo.org/gentoo-dev/message/604102ed1392afd3bfe35bfb33da8796 Here's a quick stab at a nmu element for metadata.xml; based on vapier's comments. I'm not set on the name of 'nmu', something like 'change-policy' might be a cleaner choice. nmu element, which has machine-readable attributes: - who: - ANYONE - anybody can touch (implicit default) - REQUIRES_TEAM - you must be a team member of a team listed - REQUIRES_MAINTAINER - you must be an explicitly listed maintainer specific herds or devs can be explicitly listed if you want to direct people to ask somebody about your packages (but that person should probably be listed as a maintainer then). - timeout: this is how long you we suggest you wait for the maintainer/team to comment on your change. Format should be a short duration specifier per ISO8601 I'd like to default it to 1 week: 'P1W'. - scope: How big of changes are ok? - NONE - (included for completeness) - STABLE - you can mark it stable after the normal 30 days - VERBUMP-MINOR - strictly a minor version bump, no other changes - TRIVIAL - simple, strict bugfixes (implicit default) - VERBUMP-MAJOR - a major version bump - MAJOR - rewrites, large functionality changes nmu element may also have human-readable content, to help clarify your intent if you think you cannot make it sufficiently clear with the machine attributes. Under this proposal, I'll be tagging most of my packages with: nmu who='ANYONE' timeout='P0' scope='TRIVIAL' / Fragile things might be tagged with: nmu who='REQUIRES_MAINTAINER' timeout='P2Y' / It should be valid to have multiple elements; something fragile to patches (eg qmail), but ok for bumping minor versions, because upstream is very good about API breakage: nmu who='ANYONE' timeout='P2W' scope='VERBUMP-MINOR,!STABLE' / nmu who='REQUIRE_TEAM' timeout='P1W' scope='VERBUMP-MAJOR' / nmu who='REQUIRE_MAINTAINER' timeout='P0' scope='MAJOR' / Overall, I suggest that these two elements become the implicit default: nmu who='ANYONE' timeout='P1W' scope='TRIVIAL' / nmu who='REQUIRE_TEAM' timeout='P1W' scope='MAJOR' / -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/03/15 01:22 PM, Tim Harder wrote:
Hey all,
Having been around for a few years I've inherited or added quite a
few pkgs to the tree that I wouldn't mind other people
fixing/bumping/etc that don't fall into any current herds.
With that in mind, I think it would be an interesting experiment if
we had a collaborative herd (probably named collab) that signals
the status that anyone is generally free to fix, bump, or do sane
things to the pkgs with the caveat that you fix what you break.
Anyone else interested in such a setup?
Tim
The idea sounds great to me, and is something I've been
armchair-lobbying for over the past couple of years as well.
Implementation-wise, I share others' views that using the herd tag
probably isn't a good idea. Where I ran into a wall, however, was
exactly what the metadata tag(s) should be. I ended up just keeping a
list of devs' that i've talked to over the years that are fine with
me/others touching their packages.
It would be very helpful IMO to have this per-package in metadata, one
way or another. Given all of the possible specifics we could do here,
what are people's thoughts on a two-tag approach -- 1,
nmu{yes,no}/nmu , for a quick means to see if the primary
maintainer is OK with non-maintainer updates; 2,
maintainer-notes.../maintainer-notes , for general instructions
regarding package maintenance.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlURa9sACgkQ2ugaI38ACPCtOwD/ca0Y+wiVVCbl1trBmPRWL4TG
JXpjYoQyl0GE2jdU7jMA/3v43v56GF/7WXwNF6CtezuIIACFXsnadRhmv1v6majp
=cS5M
-END PGP SIGNATURE-
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Mon, 23 Mar 2015 13:22:25 -0400 Tim Harder radher...@gentoo.org wrote: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? sounds like nmu is what you want: https://archives.gentoo.org/gentoo-dev/message/604102ed1392afd3bfe35bfb33da8796
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
Dnia 2015-03-23, o godz. 13:22:25 Tim Harder radher...@gentoo.org napisał(a): Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? Don't abuse herds when you can easily add new data to metadata.xml. In fact, you can store much more useful information there rather than some dumb on/off switch. That said, we would use some 'best practices' page on the wiki. Say, I don't mind others bumping my packages as long as they compare configure.ac Makefile.am between revisions. -- Best regards, Michał Górny pgpsZY7eGXuOW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Mon, 23 Mar 2015 22:53:45 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Mon, 23 Mar 2015 14:49:44 -0400 Tim Harder wrote: On 2015-03-23 13:48, Panagiotis Christopoulos wrote: You want to have a herd for that or something in metadata.xml that would raise a flag that the package can be freely touched/maintained by anyone? I'd rather have a herd so people can easily scan via euscan or similar to see the entire array of pkgs falling into the space. Abusing another metadata field doesn't give the same visibility or would require changes from tools. For example, bugs assigned to the herd or with it in CC could be fixed by anyone without having to ask for permission. How would that be handled easily when using an extra metadata field? I agree that something along these lines would be really useful. Possibly it might be a good idea to have some sort of extra information in the metadata if you want to specify some restrictions on this. Something like feel free to bump/fix bugs etc but please don't bump to prerelease versions.
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Mon, 23 Mar 2015 14:49:44 -0400 Tim Harder wrote: On 2015-03-23 13:48, Panagiotis Christopoulos wrote: You want to have a herd for that or something in metadata.xml that would raise a flag that the package can be freely touched/maintained by anyone? I'd rather have a herd so people can easily scan via euscan or similar to see the entire array of pkgs falling into the space. Abusing another metadata field doesn't give the same visibility or would require changes from tools. For example, bugs assigned to the herd or with it in CC could be fixed by anyone without having to ask for permission. How would that be handled easily when using an extra metadata field? Assume that half of the tree joined this idea. Mail traffic on this herd will be insane. I'm in favour of a special tag idea, equery tool may be updated to show it on `equery meta $pkgname` calls. Best regards, Andrew Savchenko pgpr_65K89ad7.pgp Description: PGP signature
[gentoo-dev] collab herd for cooperative pkg maintenance
Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? Tim signature.asc Description: PGP signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 13:22 Mon 23 Mar , Tim Harder wrote: Hey all, Hi, ... With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? You want to have a herd for that or something in metadata.xml that would raise a flag that the package can be freely touched/maintained by anyone? -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project )
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 2015-03-23 13:48, Panagiotis Christopoulos wrote: You want to have a herd for that or something in metadata.xml that would raise a flag that the package can be freely touched/maintained by anyone? I'd rather have a herd so people can easily scan via euscan or similar to see the entire array of pkgs falling into the space. Abusing another metadata field doesn't give the same visibility or would require changes from tools. For example, bugs assigned to the herd or with it in CC could be fixed by anyone without having to ask for permission. How would that be handled easily when using an extra metadata field? Tim signature.asc Description: PGP signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 03/23/2015 01:22 PM, Tim Harder wrote: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? It's not semantically correct, but it might be the easiest way to actually get this working with a minimum of changes. I guess what you really want is for the package to be maintainer-needed, but for you to be CCed on bugs? That would require metadata.xml and probably tool changes though. However we wind up doing it, most of my packages would fall into this category so I support the idea.
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On Monday, March 23, 2015 01:22:25 PM Tim Harder wrote: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? Tim I could see this fitting in to the proxy-maintainer herd if they would consider a change in their current purpose. Their current statement is [1]: Proxy maintainers is a group of developers maintaining abandoned packages on behalf of Gentoo users. Changing this to something like: Proxy maintainers are a group of developers maintaining packages on behalf of Gentoo users and fellow developers. This would of course require additional changes in protocol for the herd. As it stands now they focus solely on user interaction with developers. Expanding this to developer owned packages would meet your intent of allowing fellow developers to assist with your packages. Metadata would also reflect your ownership of the package and add proxy-maintainers to herd. Thoughts? [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers -- Cheers, Aaron Bauman (b-man) Gentoo Linux Developer signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
El lun, 23-03-2015 a las 13:22 -0400, Tim Harder escribió: Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named collab) that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? Tim Personally I think a tag in metadata to show that a package can be touched by others freely would be much more useful than having a big herd with a mix of packages that are not even related. If people usually don't have time to fix the tons of packages that lacks a maintainer (and, then, they could also fix them without asking for permission), I doubt that new herd would get much real help :(
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 2015-03-23 18:54, Pacho Ramos wrote: Personally I think a tag in metadata to show that a package can be touched by others freely would be much more useful than having a big herd with a mix of packages that are not even related. Sure, I'd just like to expose this status in a better manner for the set of official and unofficial tools out there than having to grep the tree or similar. I'm fine with a metadata flag if people can agree on what that is as I'm unsure if the previous discussion on that topic went anywhere. If people usually don't have time to fix the tons of packages that lacks a maintainer (and, then, they could also fix them without asking for permission), I doubt that new herd would get much real help :( This isn't about unmaintained pkgs or asking for help. It's more an experiment in non-territorial package maintenance. Tim signature.asc Description: PGP signature
