Date: Sat, 24 May 2014 21:48:34 +0200 From: Michelle Sullivan <michelle@sorbs.net> To: Kurt Jaeger <lists@opsec.eu> Cc: Matthew Rezny <matthew@reztek.cz>, freebsd-ports@freebsd.org Subject: Re: FreeBSD ports which are currently scheduled for deletion Message-ID: <5380F792.2040301@sorbs.net> In-Reply-To: <20140524180557.GF2341@home.opsec.eu> References: <2318877.ATaMhzlr5B@desktop.reztek> <1521997.Va510XRLDQ@desktop.reztek> <534AD94A.2030105@marino.st> <2827292.qM76QHi0yk@workstation.reztek> <20140524180557.GF2341@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Before I say anything - tonight is a bottle of wine and a night off... ;-) >> Also, I've done the steps of fix, stage, and claim maintership. The issue is >> "honestly be the maintainer". How can I honestly call myself the maintainer >> when I can't actually do anything to the port myself. >> > > If you want to change things directly in the ports tree, you have to > become a ports committer. For this, some committer or two need to > be your mentors (I'm still being mentored, so...). All (most?) committers > are very busy, that's the general problem. > Safe, but also a bottle neck (at the moment). > >> Sure, there's always disagreements, but part of keeping a functioning >> community depends on minimizing disagreement. I'm not saying >> staging should be dropped, but making it a requirement for commit >> just deters other bugs from getting fixed. "Ooh, I could fix this, >> but then I have to stage it too... meh, fuck it." >> > > That's seldom the real problem. Finding time to fix anything is > the problem, mostly. > Sorry going to pipe in define "fixing" ... just getting something to compile or fixing a whole slew of ports that are dependent on others... because the first shouldn't be an issue in *most* cases - there are special cases, but it's usually a quick look at the code, working out which header has changed etc.. (and most are Googleable).. In the latter .. if there are dependent and parent packages that create a whole slew of issues.. then there is a problem in general. >> that were not handled, or were handled all the way up to the last step and >> then forgotten. i.e. ports/188784 >> > > @work. Building in poudriere right now. > > >>> you already have the figures (~4700 ports), but here's a dynamic list: >>> http://people.freebsd.org/~bapt/notstaged.txt >>> > > It's already down to 3446 right now. > They just need converting to a staged environment? If so if you'd like to take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=189880 and tell me if I did it right and tell me how I can choose something that no-one is working on I'll crack on with some of them. > >> I had kept distance from getting involved in the ports side because it always >> looked like a cesspool. After long enough avoiding it, I made the mistake of >> stepping in. Knee deep in this shitmess, I have a choice to make. >> > > I agree that there was a lot of change in the ports tree recently. > But: There is a reason for this: The ports tree has to be cleaner > so that it can provide better automatic processes to the users. > It's not easy, but it's getting there. > However, breaking s**t whilst cleaning up is also a good way to alienate people .. breaking all builds on hosts pre 9.1 for example was not the best of things to do... fortunately for me - my build server is only running as far back as 9.0.. though I have production servers back to 6.1...!! (and I have trouble migrating/updating them because they 6/7 -> 9.2 may/maynot work, but more than that I can't test against any of the new packages because I can't build .. so I can't tell if I upgrade the OS whether I will even have a useful/working system as I can't build test packages with the new versions on the old OS before upgrading... I know they have been EOLd (in some cases for years) but people are still running them, and in some cases the job of upgrading takes months of work per server... it shouldn't but it does... and to get 'oh that version of the OS has been EoL since 3 weeks ago' .. well that can generate frustration which weighs people away from helping (if you can't help me, why should I help you?) > Please add civility and patches/PRs to the process, this would help > us tremendously. A long rant is sometimes helpful, but if it gets > too angry, it alienates others. > +1 >> I can keep >> throwing patches at PRs and hope somebody might just commit them, >> or I can say screw it all and just fork the ports tree in a public repo. >> > > Provide PRs, send me a Cc: and I can have a look at them. > > I'm happy to help when I have time (today I could have probably got through 10 'easy' ones).. however having never done it before and no actual feedback of what I have done as I have now updated 2 (one new one, one add a patch to an existing one) .. I don't know if I'd even get it right... that said my poudriere VMs and jenkins are not complaining about what I have done (I patch auto-manually (scripted) after each portsnap) Michelle -- Michelle Sullivan http://www.mhix.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5380F792.2040301>