Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
I have strong opinions against this, at least for ports with an active maintainer. I really see these deprecation campaigns as treading on somebody's toes. I really like linimon's periodic emails FreeBSD ports that you maintain which are currently marked broken, which I see as a reminder that there are ports of mine that require action, but going further than that and deprecate a port that I maintain without even informing me in an official way is not what I consider collaboration. Even more so because I don't see any advantage in moving a port from BROKEN to DEPRECATED state. If a user has a working version of the port installed, he will stick to that, otherwise, installation will be frown upon anyway. I and bapt have already exchanged opinions on this subject more than once, and I would now like to see what other people (other maintainers in particular) think about it. Can we please stop this? On 2012-Apr-09, 23:51, Baptiste Daroussin wrote: bapt2012-04-09 23:51:44 UTC FreeBSD ports repository Modified files: games/8kingdoms Makefile misc/airoflash Makefile graphics/autopano-sift Makefile x11/avant-window-navigator-xfce4 Makefile lang/boo Makefile x11/cl-clx-sbcl Makefile palm/coldsyncMakefile print/cups-magicolor Makefile deskutils/doodle Makefile games/flightgear-atlas Makefile games/freeorion Makefile net-p2p/gnunet Makefile audio/gstreamer-plugins-flite Makefile x11-themes/gtk-qt-engine Makefile science/hdf Makefile databases/hypertable Makefile www/kazehakase Makefile x11-themes/kde-icons-amaranth Makefile x11-themes/kde-icons-amaranth-althaea Makefile x11-themes/kde-icons-krystaline Makefile x11-themes/kde-icons-realistic Makefile misc/kde3-i18n-hsb Makefile misc/kde3-i18n-mtMakefile misc/kde3-i18n-nso Makefile editors/komodo-edit Makefile graphics/linux-ac3d Makefile sysutils/linux-megamgr Makefile mail/lmtpd Makefile graphics/long-exposure-tools Makefile multimedia/moonlight Makefile devel/nana Makefile databases/ocaml-pgocaml Makefile math/octave-develMakefile multimedia/p5-Video-Info Makefile security/pantera Makefile databases/pear-MDB2_Driver_ibase Makefile net/perldap Makefile math/petsc Makefile math/petsc-mpich Makefile databases/pg_filedump Makefile net-im/pino Makefile chinese/cxterm Makefile net-p2p/py-bittorrent Makefile net-p2p/py-bittorrent-core Makefile games/rigsofrods Makefile databases/ruby-kyotocabinet Makefile devel/rubygem-vmcMakefile cad/salome-gui Makefile math/scilab-toolbox-sivp Makefile games/secretmaryochronicles Makefile games/sfbol Makefile graphics/solang Makefile net/spnetkit Makefile databases/sqlrelay Makefile devel/subcommander2 Makefile sysutils/thunar-volman-plugin Makefile games/wesnoth-devel Makefile x11/x3270Makefile games/xchadance Makefile x11-drivers/xf86-video-rdc Makefile deskutils/xfce4-volstatus-icon Makefile multimedia/xfmedia-remote-plugin Makefile x11-toolkits/xforms-i18n Makefile Log: Mark as deprecated and set expiration to 2012-05-10 for ports that are mark as broken for more than 6 month Revision ChangesPath 1.3 +3 -0 ports/audio/gstreamer-plugins-flite/Makefile 1.6 +3 -0 ports/cad/salome-gui/Makefile 1.35 +3 -0 ports/chinese/cxterm/Makefile 1.8 +3 -0 ports/databases/hypertable/Makefile 1.6 +3 -0 ports/databases/ocaml-pgocaml/Makefile 1.7 +3 -0 ports/databases/pear-MDB2_Driver_ibase/Makefile 1.6 +3 -0 ports/databases/pg_filedump/Makefile 1.14 +3 -0 ports/databases/ruby-kyotocabinet/Makefile 1.70 +3 -0 ports/databases/sqlrelay/Makefile 1.23 +3 -0 ports/deskutils/doodle/Makefile 1.4 +3 -0 ports/deskutils/xfce4-volstatus-icon/Makefile 1.13 +3 -0 ports/devel/nana/Makefile 1.5 +3 -0 ports/devel/rubygem-vmc/Makefile 1.26 +3 -0 ports/devel/subcommander2/Makefile 1.18 +3 -0 ports/editors/komodo-edit/Makefile 1.12 +3 -0 ports/games/8kingdoms/Makefile 1.32 +3 -0 ports/games/flightgear-atlas/Makefile 1.31 +3 -0 ports/games/freeorion/Makefile 1.16 +3 -0 ports/games/rigsofrods/Makefile 1.25 +3 -0 ports/games/secretmaryochronicles/Makefile 1.15 +3 -0 ports/games/sfbol/Makefile 1.101 +3 -0 ports/games/wesnoth-devel/Makefile 1.20 +3 -0
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
I have strong opinions against this, at least for ports with an active maintainer. I really see these deprecation campaigns as treading on somebody's toes. I really like linimon's periodic emails FreeBSD ports that you maintain which are currently marked broken, which I see as a reminder that there are ports of mine that require action, but going further than that and deprecate a port that I maintain without even informing me in an official way is not what I consider collaboration. Even more so because I don't see any advantage in moving a port from BROKEN to DEPRECATED state. If a user has a working version of the port installed, he will stick to that, otherwise, installation will be frown upon anyway. I and bapt have already exchanged opinions on this subject more than once, and I would now like to see what other people (other maintainers in particular) think about it. Can we please stop this? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp As you inquire people's opinion, I would say that I find this way of proceeding a bit pushy and I consider it a good example of closed communication as I find it: - non-caring: such a commit is a detached and impersonal way to give the information to a maintainer that has not unbroken his port for a long time - dogmatic: it looks like an unwillingness to accept the maintainer's point of view or at least to hear about his work on maintaining the port - superior: deprecating without prior communication with the maintainer stresses differences in status between portmgr/committer and maintainers Hence I am not surprised when you say you feel someone is treading on your toes, and more generally I fear this does not do any good to maintainer's motivation and commitment to the project. On the other hand I also believe those deprecation actions are necessary and I thank bapt for his work on this. To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been marked as broken for a period of at least six months. As a maintainer of one of those ports, feel free to remove the deprecate status if you need more time to fix the breakage and do not hesitate to contact portmgr@ if you need additional information on this policy. I hope this brings something to the discussion. -- Frederic Culot cu...@freebsd.org pgpx1R7qscdc8.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 06:56, Mark Linimon wrote: On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. That's exactly my point: maintainers are very likely to know the situation by the time these deprecation campaigns set off, and committing to their ports without prior approval is in contrast with our policy. I still do not see the necessity to deprecate maintained ports, even though a port might be maintained as broken for a long period of time. The maintainer might be waiting for something to happen either upstream or in our infrastructure, which could release the port from brokenness. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpWY2RVMXgYc.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Mark Linimon lini...@lonesome.com On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. I strongly agree with the bapt's action to set some ports that are often broken to deprecated or even some of them that are broken for a long time to deprecated. There is nothing more frustrating than try to install a port an it doesn't fetch or doesn't build. Also to avoid some problems with fetch, we can use public distfile or even mirror the tarball/zipball(or whatever it is) in a fashion way. And in my opinion a bunch of new emails with some warnings could be useful just in the beggining, after while those ports maybe will have still problem to be fetch. Maybe something that might work would be something quite similar like the QAT provided by itetcu a long time ago, send some message to the developers@ list and wait for someone to fix that. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 02:21:42PM +0200, Pietro Cerutti wrote: The maintainer might be waiting for something to happen either upstream or in our infrastructure, which could release the port from brokenness. Putting a comment about that in the Makefile might go a long way to minimizing frustration all around. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 09:32:47AM -0300, Marcelo Araujo wrote: There is nothing more frustrating than try to install a port and it doesn't fetch or doesn't build. That's been my main point of worry all along (more personally than as portmgr), and why I think the deprecation campaigns do more good than harm. Obviously some folks do not agree :-/ We'll have to agree to disagree on that point. I'll also note that not every port that gets deprecated actually gets removed. In English we have this saying the carrot and the stick. I'd certainly rather use the carrot than the stick, but sometimes the stick (setting DEPRECATED) is effective. Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 09:32, Marcelo Araujo wrote: 2012/4/10 Mark Linimon lini...@lonesome.com On Tue, Apr 10, 2012 at 01:45:38PM +0200, Frederic Culot wrote: To conciliate such a necessary action without hurting the feelings of those maintainers who despite their work could not update the state of their port in a timely manner, maybe it would be good to be more verbose in the log of such commits. Inspired by linimon's emails, something like the following could be added: I do get some responses from maintainers to those emails, and (except in the cases where the email gets stuck in my mbox) I honor their requests for an extension. OTOH in general I get personal replies and not replies to the list, so people aren't seeing that interaction in public. From my standpoint, by the time something has been broken for 6 months, the maintainer will have already gotten multiple emails from portsmon. So, I'm going to have to say I'm a little frustrated if I need to send another round of mail even on top of that. I strongly agree with the bapt's action to set some ports that are often broken to deprecated or even some of them that are broken for a long time to deprecated. There is nothing more frustrating than try to install a port an it doesn't fetch or doesn't build. I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpbmPvdVo2NB.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 14:44, Pietro Cerutti wrote: I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In theory, it tickles administrators to look for alternatives if they depend on the port or fork a working copy of the port in their local infrastructure and provides a deadline for this to action to be completed. BROKEN is supposed to be a temporary state, leading to a fix. DEPRECATED is a temporary state leading to removal. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. This is awkward. We're not supposed to spend our time rolling back unwanted commits. We're supposed to make sure that a commit made to someone else's port is wanted in the first place. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Well, as I see it, marking a port as DEPRECATED is kind of a final decision. I.e., I'll start to look at alternatives and forget about it. If you mark a port as DEPRECATED and 12 hours later I back off your chance with a comment I'm working on it, a really unconsistent and confused message will pass. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgpW8cZ2RQyFm.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 09:04, Jerry wrote: On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. For the record, the port in question was fetchable / buildable / runnable. For some reason, some python class sometimes doesn't get byte-compiled, resulting in packaging (PLIST) errors. -- Pietro Cerutti The FreeBSD Project g...@freebsd.org PGP Public Key: http://gahr.ch/pgp pgppnRkZc7urK.pgp Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
2012/4/10 Pietro Cerutti g...@freebsd.org On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. That is a very good point, if someone send a PR, nobody need to make it DEPRECATED, but unfortunately, sometimes it doesn’t happens. And as I can see, almost all ports that switch from BROKEN to DEPRECATED, is because no one send a PR. In case that has any issue related with the ports framework that make the ports be broken, he can ping any developer to give him more time to fix or even rollback the DEPRECATED commit with a proper message on the commit's log. This is awkward. We're not supposed to spend our time rolling back unwanted commits. We're supposed to make sure that a commit made to someone else's port is wanted in the first place. I agree with you, maybe there is another better way. It also will let us know, what's happen with that port and maybe someone else could give a hand to help the maintainer to fix it. Well, as I see it, marking a port as DEPRECATED is kind of a final decision. I.e., I'll start to look at alternatives and forget about it. If you mark a port as DEPRECATED and 12 hours later I back off your chance with a comment I'm working on it, a really unconsistent and confused message will pass. Here depends! Usually when I need a port that is set as DEPRECATED, first I take a look why it is set like this, and then, I start to looking for an alternative in case I can’t fix that port or it is really obsolete because the software is dead for some reason. Best Regards, -- Marcelo Araujo ara...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 16:47, Pietro Cerutti wrote: On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. Not to discredit your work in any way, but 6 months of being BROKEN can be classified as maintainer timeout in the general case. Also given the error you're seeing it sounds like a very specific case that shouldn't affect the generally solid deprecation policy that is in effect - the bulk of the deprecation cases are upstream abandonware with an equally absent maintainer. I check the list of deprecated ports regularly when I feel nostalgic for blink, java-based rollover menus and News from the previous millennium. On a more constructive note - why don't you mention the specific port? Maybe some of us on the list can help you figure out why some files sometimes don't get byte compiled or provide you with a work-around solution (dynamically generated plist comes to mind). -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 10 April 2012 14:56, Pietro Cerutti g...@freebsd.org wrote: On 2012-Apr-10, 09:04, Jerry wrote: On Tue, 10 Apr 2012 07:40:09 -0500 Mark Linimon articulated: Finally, I agree that FreeBSD can't guarantee any given ports will work, but I think we owe the users the effort to make sure if a port is included, it's at least not completely useless. To guarantee that the port will work is certainly beyond the scope of the ports system; however, to guarantee that it is fetch-able and build-able is an implied action by the simple fact that it is included in the ports structure. If, after a reasonable amount of time, a solution for a port's inability to properly build or if the port is just plain not able to be fetched, then it should be removed from the port system. There is no upside to keeping ports that will not build, or cannot be fetched. For the record, the port in question was fetchable / buildable / runnable. For some reason, some python class sometimes doesn't get byte-compiled, resulting in packaging (PLIST) errors. BUILD_ENV= PYTHONDONTWRITEBYTECODE=yes usually helps. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 2012-Apr-10, 17:17, Mel Flynn wrote:
On 4/10/2012 16:47, Pietro Cerutti wrote:
On 2012-Apr-10, 11:20, Marcelo Araujo wrote:
2012/4/10 Pietro Cerutti g...@freebsd.org
I might agree on that. But how is a DEPRECATED port better than a BROKEN
one in this regard?
In my point of view, no make sense have a bunch of ports that actually
doesn't works or because there is a fetch problem or even it is set as
BROKEN. Who never was upset when need and find a port but it is BROKEN for
some reason, In my view, have a port BROKEN or haven't it, is the same. Of
course, I mean when a port is BROKEN for all plataforms as well as for all
FreeBSD version.
I agree on that.
I believe set it as DEPRECATED is a good way to make the maintainer take
attention to fix it soon as possible, due he has put effort to insert this
software on the ports tree in the past.
What about submitting a PR, as we usually do for anything else? If it's
ok to wait 15 days (maintainer timeout) to commit an update to a port
that brings in important features, it is even more so to wait to
deprecate one.
Not to discredit your work in any way, but 6 months of being BROKEN can
be classified as maintainer timeout in the general case.
That's your opinion, and while I agree on the general idea that six
months is a lot, I would like actions / behavior to be based on policies
previously agreed upon and documented.
15 days -- implicit approval (maintainer timeout) is documented
6 months -- implicit deprecation of broken ports is not
On a more constructive note - why don't you mention the specific port?
Maybe some of us on the list can help you figure out why some files
sometimes don't get byte compiled or provide you with a work-around
solution (dynamically generated plist comes to mind).
The port is editors/komodo-edit. sbz@ gave me a hint about forcing
byte-compilation of all the python classes using
post-install:
@${PYTHON_CMD} -O -m compileall -q ${DATADIR} || true
@${PYTHON_CMD} -m compileall -q ${DATADIR} || true
but I never got to commit that. I'm testing it right now and unbreak the
port very soon. Thank you!
--
Pietro Cerutti
The FreeBSD Project
g...@freebsd.org
PGP Public Key:
http://gahr.ch/pgp
pgp8vdcN6uHEQ.pgp
Description: PGP signature
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On Tue, Apr 10, 2012 at 04:47:41PM +0200, Pietro Cerutti wrote: On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. That is a good option, next time I'll do that for maintained ports that are mark as BROKEN. I didn't intend to be disrespectful on other's work, I'm sorry if that is the fealing some could get, next time, I'll be more careful about this and send the deprecation stuff as PR. regards, Bapt pgpm1695GMUu0.pgp Description: PGP signature
