View of non maintained packages
Hello, Is it possible to have a view of all the non maintained ports ? -- Benoit
Am 13.01.2008 um 22:09 schrieb Benoit Caccinolo:
Hello,
Is it possible to have a view of all the non maintained ports ?
try: port echo maintainer:nomaintainer reg's Rolf
-- Benoit _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
-- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932
On Jan 13, 2008 10:17 PM, Rolf Würdemann <rowue@digitalis.org> wrote:
Am 13.01.2008 um 22:09 schrieb Benoit Caccinolo:
Hello,
Is it possible to have a view of all the non maintained ports ?
try:
port echo maintainer:nomaintainer
Thank you !
port echo maintainer:nomaintainer | wc -l 2292
Gosh, there is a lot of packages not maintained ! It could be interesting to launch a call for maintainers on the blog ? Benoit
Am 13.01.2008 um 22:25 schrieb Benoit Caccinolo:
On Jan 13, 2008 10:17 PM, Rolf Würdemann <rowue@digitalis.org> wrote:
Am 13.01.2008 um 22:09 schrieb Benoit Caccinolo:
Hello,
Is it possible to have a view of all the non maintained ports ?
try:
port echo maintainer:nomaintainer
Thank you !
port echo maintainer:nomaintainer | wc -l 2292
Gosh, there is a lot of packages not maintained !
It could be interesting to launch a call for maintainers on the blog ?
Hmmm - I'm a maintainer of three ports - and waiting since one to three weeks for commitments ... If this happens to new maintainers - think they will not be maintainers for very long
Benoit
Reg's Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932
Hi Rolf, On Jan 13, 2008, at 1:31 PM, Rolf Würdemann wrote:
Gosh, there is a lot of packages not maintained !
It could be interesting to launch a call for maintainers on the blog ?
Hmmm - I'm a maintainer of three ports - and waiting since one to three weeks for commitments ...
If this happens to new maintainers - think they will not be maintainers for very long
I would encourage you, and anybody else who is a maintainer and who would like to be able to do their own commits, to simply apply for committer status. We are not particularly selective about giving out commit bits, as long as the individual has shown that they can maintain ports in a trustworthy fashion. http://trac.macports.org/projects/macports/wiki/NewCommittersGuide James
Am 13.01.2008 um 23:28 schrieb James Berry:
Hi Rolf,
Hi James,
On Jan 13, 2008, at 1:31 PM, Rolf Würdemann wrote:
Gosh, there is a lot of packages not maintained !
It could be interesting to launch a call for maintainers on the blog ?
Hmmm - I'm a maintainer of three ports - and waiting since one to three weeks for commitments ...
If this happens to new maintainers - think they will not be maintainers for very long
I would encourage you, and anybody else who is a maintainer and who would like to be able to do their own commits, to simply apply for committer status. We are not particularly selective about giving out commit bits, as long as the individual has shown that they can maintain ports in a trustworthy fashion.
O.K. - I've thought about it today - and wrote the mail a few minutes ago ;) But it seems that we need more committers before asking on the website - if we get mainatiners for a quarter of the ports there will be much work (if my case with the one to three weeks was not a single case) ;)
http://trac.macports.org/projects/macports/wiki/NewCommittersGuide
James
reg's Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932
Rolf Würdemann wrote:
But it seems that we need more committers before asking on the website - if we get mainatiners for a quarter of the ports there will be much work (if my case with the one to three weeks was not a single case) ;)
Maybe we should have someone who is responsible for committing updates for particular port categories. I think the problem at the moment is that a port update is committed if someone looked into Trac to see any pending updates... So this is rather random when a port update is committed. Rainer
Am 14.01.2008 um 00:21 schrieb Rainer Müller:
Rolf Würdemann wrote:
But it seems that we need more committers before asking on the website - if we get mainatiners for a quarter of the ports there will be much work (if my case with the one to three weeks was not a single case) ;)
Maybe we should have someone who is responsible for committing updates for particular port categories. I think the problem at the moment is that a port update is committed if someone looked into Trac to see any pending updates... So this is rather random when a port update is committed.
Maybe an commit-group would be an idea ;) (something like the support- group at our office ;)
Rainer
Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932
On Jan 13, 2008, at 17:37, Rolf Würdemann wrote:
Am 14.01.2008 um 00:21 schrieb Rainer Müller:
Rolf Würdemann wrote:
But it seems that we need more committers before asking on the website - if we get mainatiners for a quarter of the ports there will be much work (if my case with the one to three weeks was not a single case) ;)
Maybe we should have someone who is responsible for committing updates for particular port categories. I think the problem at the moment is that a port update is committed if someone looked into Trac to see any pending updates... So this is rather random when a port update is committed.
Maybe an commit-group would be an idea ;) (something like the support-group at our office ;)
Do you mean a group of people who do nothing but commit things that others submit? If we have people who are interested in performing that function, then sure. But we don't want everything that's submitted into Trac just blindly committed into Subversion. We need the committer to be aware of the changes that are being made, to police the changes in a way. Don't commit patches that do multiple things; break it into separate patches or ask the contributor to do so. Don't commit patches that make whitespace changes to the entire portfile in addition to functional changes. Don't commit patches that obviously revert a previous revision without the contributor explaining why. Don't commit patches that use inadvisable practices without first discussing these with the contributor. And so forth. In order to know these things, it helps if such a committer is also an accomplished port maintainer/author. I think what we need are committers who are interested in each category of software. I occasionally look through the unassigned tickets and either try to handle them (new ports, or patches for unmaintained ports) or assign them to their ports' maintainers. But some tickets I don't deal with, like most tickets for Python modules or most Gnome tickets, because I don't use or sufficiently understand Python and Gnome. We need committers who are interested in and proficient in Python and Gnome (and maybe some other categories) who will deal with those tickets.
On 14.01.2008, at 08:57, Ryan Schmidt wrote:
On Jan 13, 2008, at 17:37, Rolf Würdemann wrote:
Am 14.01.2008 um 00:21 schrieb Rainer Müller:
Rolf Würdemann wrote:
But it seems that we need more committers before asking on the website - if we get mainatiners for a quarter of the ports there will be much work (if my case with the one to three weeks was not a single case) ;)
Maybe we should have someone who is responsible for committing updates for particular port categories. I think the problem at the moment is that a port update is committed if someone looked into Trac to see any pending updates... So this is rather random when a port update is committed.
Do you mean a group of people who do nothing but commit things that others submit? If we have people who are interested in performing that function, then sure.
But we don't want everything that's submitted into Trac just blindly committed into Subversion. We need the committer to be aware of the changes that are being made, to police the changes in a way. Don't commit patches that do multiple things; break it into separate patches or ask the contributor to do so. Don't commit patches that make whitespace changes to the entire portfile in addition to functional changes. Don't commit patches that obviously revert a previous revision without the contributor explaining why. Don't commit patches that use inadvisable practices without first discussing these with the contributor. And so forth. In order to know these things, it helps if such a committer is also an accomplished port maintainer/author.
I think what we need are committers who are interested in each category of software. I occasionally look through the unassigned tickets and either try to handle them (new ports, or patches for unmaintained ports) or assign them to their ports' maintainers. But some tickets I don't deal with, like most tickets for Python modules or most Gnome tickets, because I don't use or sufficiently understand Python and Gnome. We need committers who are interested in and proficient in Python and Gnome (and maybe some other categories) who will deal with those tickets.
I think this is the way to go. What do we need? First, we need people to volunteer for group-committers on all groups! Of course individuals can decide themselves whether they cannot perform this task at all or perform it on one or multiple port groups. As Ryan said: he can do it on some (practically does it on several) but not on others... Second, we need to "announce" these port-group committers, i.e., on the MacPorts Wiki. Preferably the committers of a single group are placed on a <group>-commit-pending@ mailing list... Third, some means to assign a committed patch to one or, if appropriate, multiple port groups. Optimally, this would be automatic based on the Portfile. Then the <group>-commit-pending@ is automatically emailed. Obviously, a poor mans version would to request the ticket creator to add the correct <group>-commit-pending@ to the cc: field (good enough for a test of the whole system). Fourth, the people behind <group>-commit-pending@ need the time to look at these tickets on a (nearly) daily basis... From my perspective this is te hardest point! Fifth: we need more volunteers! a) more maintainers b) more people with commit-rights c) group-committers ... Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D Sex, drugs and rock-n-roll
Am 14.01.2008 um 08:57 schrieb Ryan Schmidt:
On Jan 13, 2008, at 17:37, Rolf Würdemann wrote:
Am 14.01.2008 um 00:21 schrieb Rainer Müller:
Rolf Würdemann wrote:
[Need of more committers] [Port Categories]
Maybe an commit-group would be an idea ;) (something like the support-group at our office ;)
Do you mean a group of people who do nothing but commit things that others submit? If we have people who are interested in performing that function, then sure.
Not but nothing (o.k. that's different to support parts at office) - but beeing responsible ;) but I think your approach below is the better one ;)
But we don't want everything that's submitted into Trac just blindly committed into Subversion. We need the committer to be aware of the changes that are being made, to police the changes in a way. Don't commit patches that do multiple things; break it into separate patches or ask the contributor to do so. Don't commit patches that make whitespace changes to the entire portfile in addition to functional changes. Don't commit patches that obviously revert a previous revision without the contributor explaining why. Don't commit patches that use inadvisable practices without first discussing these with the contributor. And so forth. In order to know these things, it helps if such a committer is also an accomplished port maintainer/author.
Definitive. (And perhaps we should state this better in the documentation - otherwise one guy can set up an update for bugfix or new version, read the documentation, tidy up, submit and get the message "hey! you better break this in a few steps ;) (I've just made an update to gwyddion and tidy the portfile in one step ;)
I think what we need are committers who are interested in each category of software. I occasionally look through the unassigned tickets and either try to handle them (new ports, or patches for unmaintained ports) or assign them to their ports' maintainers. But some tickets I don't deal with, like most tickets for Python modules or most Gnome tickets, because I don't use or sufficiently understand Python and Gnome. We need committers who are interested in and proficient in Python and Gnome (and maybe some other categories) who will deal with those tickets.
*g* - o.k. - thats the better approach (having people which where insterested in each category of software and feel responsible ;) But a problem will be a bug fix that's in the ticket (and the fixing one (maintainer or other person) have no possibillity to change the status - than we have to look throught all tickets complete or the fixing one must open a new ticket (which is perhaps stated in the documentation ;) reg's Rolf -- Security is an illusion - Datasecurity twice Rolf Würdemann - private: rowue@digitalis.org - office: rowue@crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue@digitalis.org 2F66A061 89BCA1A0 AD654827 6FD037FF 53C3E932
On Jan 14, 2008, at 03:23, Rolf Würdemann wrote:
I think what we need are committers who are interested in each category of software. I occasionally look through the unassigned tickets and either try to handle them (new ports, or patches for unmaintained ports) or assign them to their ports' maintainers. But some tickets I don't deal with, like most tickets for Python modules or most Gnome tickets, because I don't use or sufficiently understand Python and Gnome. We need committers who are interested in and proficient in Python and Gnome (and maybe some other categories) who will deal with those tickets.
*g* - o.k. - thats the better approach (having people which where insterested in each category of software and feel responsible ;)
But a problem will be a bug fix that's in the ticket (and the fixing one (maintainer or other person) have no possibillity to change the status - than we have to look throught all tickets complete or the fixing one must open a new ticket (which is perhaps stated in the documentation ;)
I didn't quite understand your last paragraph?
participants (6)
-
Benoit Caccinolo
-
James Berry
-
Jochen Küpper
-
Rainer Müller
-
Rolf Würdemann
-
Ryan Schmidt