On 2018/12/04 13:28, Edward Lopez-Acosta wrote: > Daniel, > > Not sure how much you looked into this besides the 30 sec noted, but nothing > requires py-pygfm in the ports tree for py2 or py3. The python markdown > module has had a lot of improvements since 2015 (current version in the ports > tree) including cleaning up of dead code, improved testing, and improved > docs. All of which are important to the OpenBSD project per the FAQ. > > If gfm doesn't want to keep up with this then I propose it gets dropped since > it then conflicts with the OpenBSD project notes above and it isn't required > by anything.
That does not match up with your earlier comment about py-pygfm "already up to date so I see no issue". > Looking at py-cheetah as well, which as noted is 8 years old in the tree, > most of it's dependant projects are dead from what I can tell. Should this > also be kept? I didn't bother to chase down deps of deps because that seems > like a waste of time given this information. gnuradio and sabnzbd depend on py-cheetah, these are still developed. workrave isn't actively developed any more afaik, but still works. Not sure about the others. > On December 4, 2018 3:26:19 AM UTC, Daniel Jakots <danj+o...@chown.me> wrote: > >On Mon, 3 Dec 2018 18:43:23 -0600, Edward Lopez-Acosta > ><elopezaco...@gmail.com> wrote: > > > >> textproc/py-pygfm is also dependant on this but already up to date so > >> I see no issue. > > > >Really? How much have you looked? > > > >It took me less than 30 seconds to find one. I did > >cd /usr/ports/textproc/py-pygfm/ > >make show=HOMEPAGE > >*click on the link* > >*click on "Homepage" to get on the github repository* > >*look at last commit* > >"Pin Markdown<3.0 to fix issue" > > > > > >From the issue listed in the commit "Markdown 3.0.0 being a major > >release, most internal code have changed, making dependent code > >(including py-gfm) broken." > > > >So other consumers should be checked carefully. The other one is www/pelican so that wants checking too. Looks to me that at this point updating py-markdown to the newest 2.6.x release would be a more appropriate course of action for now. (That still wants checking with dep's too, of course!). > >We don't ask you to be careful with consumers just to make the update > >process complicated or anything. It is actually *needed*. Right. This is work that has to be done. Providing an update diff is often the easiest part of an update. Thinking about and testing how it interacts with the rest of the tree is often the bigger part. I can't say about other developers but when I have limited time (which is most of the time) I am typically prioritising 1) submissions from people who have a track record of good testing and not needing much in the way of changes to be made, and 2) submissions from people who are new/learning and are taking feedback on board. Submissions where we know or suspect that only limited testing has been done typically come way down the list unless they're for some port of particular interest.
