[gentoo-user] Re: The end of "Herds"
Alec Ten Harmsel alectenharmsel.com> writes: > There is a large discussion on the Spark mailing list right now about > having groups of maintainers for different areas: > http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html This is an excellent link and model for a "hi profile" software. It is a very open and accountable model for code development, reviewing patches, including patches and in general code maintenance and bug fixes. > I'm not sure how relevant that is, but it's interesting. It is relevant to very large and important codes. I do believe that most of the gentoo ebuilds (packages) will not be afforded this level and number of devs. As the gentoo distro grows, it is a model for the devs and the council to keep in mind for those critically important packages... James
[gentoo-user] Re: The end of "Herds"
Alec Ten Harmsel alectenharmsel.com> writes: > > I think the concept of "Projects" will persist, but herds have > > to become active and request to become "Projects" as defined > > on the gentoo wiki or they will be erased. Like many others, > > I have been burned in the past with trying to get directly involved > > with Gentoo (been here since 2004). That's all water under the bridge. > > So I am "tip_toeing" behind the scenes willing to be a grunt > > and clean up some of the java mess, participate in clustering and > > contribute to the science project. We'll see just how long it lasts > > before I get "bitch_slapped" like my previous attempts > There is a large discussion on the Spark mailing list right now about > having groups of maintainers for different areas: > > http://apache-spark-developers-list.1001551.n3.nabble.com/VOTE-Designating-maintainers-for-some-Spark-components-td9115.html > > I'm not sure how relevant that is, but it's interesting. > > My own viewpoint is that there should be no individual maintainers; > packages should be assigned on a herd level, and the herds can > self-regulate and know who has expertise with each package. Just my two > cents; best to not have a single point of failure. The spark post is relevant to the discussion. But spark is one (large) code_set and we have thosands of different codes at Gentoo as a distro. So some of our softwares, such as Python, are like spark and there are multiple maintainers, like spark. We also have many smaller softwares (ebuilds) that need someone (anyone?) to step forward and maintain that singular package. Routine on Gentoo dev, there are packages up for grabs that need a maintainer. Spark is in the luxury postion of having many, very talented coders all working on one (large) piece of software. Beside, I think the the "projects" will provide that group effort that you admire in the current gentoo herds and the spark community for very important codes (like gcc, python, perl etc). But there will also be many useful softwares that we should keep around that just need a single maintainer. How it shakes out as to what the devs will allow for those sorts of packages, like "elvis" for example of a package that is not in anyone's critical path, but are cool to keep around. We, gentoo, have a wide variety of codes to maintain, and we'll need everyone from the very talented coders to capable_users to maintain these ebuilds, as our distro grows. We're going to have dozens if not hundreds of codes (ebuilds) just to fluff out the clustering codes necessary for a robust set of ebuilds for gentoo_clustering, imho. We need more devs and responsible users to help maintain and grow the base of ebuilds, imho. But I do agree, spark is going to need a very talented maintainer.. with quite a bit of java and gentoo expertise? Beside I think the decision, from what I've read, to terminate herds is pretty much a "done deal". Think of projects and maintainers and others, as you formulate gentoo's path forward. James
Re: [gentoo-user] The end of "Herds"
On 11/04/2014 03:13 PM, James wrote: > Hello, > > > If you follog gentoo-dev you can see Rich's summary > interpretation (which I do agree with) posted at the > bottom of this thread. > > > Recently I was asked to help clean up some of the Java > bugs. OK, as a non-maintainer I agreed. I went through > over 100 java bugs, mostly pre 2010, as to make a dent > in the backlog of ~500 java bugs that would probably > be the easiest to clean up. Sure enough, there were > only a few that were still relevant (Hm) > > > So I proposed, to one of the Java Herd members we blast out > a few emails notifying everyone that if folks did not > "reaffrim" these (very old) java bugs, they would be mass-closed. > If you look at those (old bugs) most would agree with my > assessment. However, I listed a few as blatant examples > that needed to be closed. It seems there is no "closer" for > java bugs. Nobody around with the authority (will?) to close > any old Java bugs. The herd is descimated, on furlog or just > burnt out and non-responsive. So all of my work and > effort was for nothing. Over the years, I have made > at least 3 attemps to use java on gentoo; all resulted in > using other linix distros. For me, java is a reality > that cannot be wished away. What I have learn in the last few > months is that Java on Gentoo is alive and properous; folks with > Java ebuilds just do not bother with getting them into Gentoo > because of the morass of apathy the gentoo java hers has become. > > So now is the time for folks to read and post to gentoo-dev on > thread: :" Deprecating and killing the concept of herds" if > you have any issues with herds being removed from Gentoo. > Ideas on how to best organize bug_cleaning is also welcome. > I think there will be an uptake in proxy-maintainers, if the > gentoo-dev club is sincere about treating these proxy maintainers > with respect and mutual professionalism. > > I think the concept of "Projects" will persist, but herds have > to become active and request to become "Projects" as defined > on the gentoo wiki or they will be erased. Like many others, > I have been burned in the past with trying to get directly involved > with Gentoo (been here since 2004). That's all water under the bridge. > So I am "tip_toeing" behind the scenes willing to be a grunt > and clean up some of the java mess, participate in clustering and > contribute to the science project. We'll see just how long it lasts > before I get "bitch_slapped" like my previous attempts > > > That's why I named by current /usr/local/portage "jackslap". > We shall see what happens. > > > I see the enabling of user patches directly into ebuilds in the tree > (EAPI 6) and the cleansing of the irresponsible amongst the herds > with exclusive control over bugs as a very positive sign that the gentoo > dev community is one again dedicated to making Gentoo an excellent platform. > Whatever your experiences have been, I hope you read, post > and give direct participation in Gentoo your deepest consideration. > > > James > > > > My (rich) proposal: > > For the steady state: > > 1. For the maintainer tag in metadata, have a type attribute that can > be developer, project, or proxy. > > 2. Add a contacts tag in metadata that takes an email. > > 3. Package without maintainers (individuals or projects - regardless > of presence of aliases) get assigned to maintainer-needed and get > treecleaned as usual. > > I'm also fine with normalizing this and just switching to a contact > tag that can have a type of developer, project, proxy, or contact. > That is a bigger change. However, it would probably simplify > scripting and be a bit cleaner for the long-term. > > > For the transition to the steady state: > > a. We generate a list of all current herds and email their aliases to > see if they want to be converted to a non-maintainer alias, or be > disbanded entirely. One reply to the email is enough to keep the > alias around, no replies means retirement. > > b. Anybody in Gentoo can start a project already by following GLEP 39. > It is encouraged for these projects to take over existing aliases > where they feel it is appropriate. There is no need for all aliases > to have a project - just ones that want some kind of structure (ie > this is strictly voluntary). When this is done the project will > remove the herd from metadata and add the project alias as a > maintainer with the agreed-upon tagging. > > c. We generate a list of all current packages that do not have a > maintainer (either one or more individuals or projects (NOT herds)). > That gets posted so that individuals can claim them. I suggest not > doing the usual treecleaning email since there could be a LOT of them. > Or we could do it herd-by-herd over time to ease the load. > > d. We remove all herds from the existing packages. Where aliases were > kept in (a) above they are converted to aliases with appropriate > tagging. If no maintainer
Re: [gentoo-user] [OT] Browser support for IPv6 Link-Local: oh, the shame...
On Thu, Nov 6, 2014 at 12:38 PM, Grant Edwards wrote: > > IPv6 link-local addresses are _way_ cool for dealing with embedded > devices that have network interfaces. You can actually set them up > and use them without having to faff about with dualing DHCP servers, > temporarily adding an IP address/route to your laptop/desktop, using > proprietary Windows-only widget-management utilities, configuring the > thing via serial console, USB port, hardware switches/jumpers, etc. > They also don't change every time your dynamic prefix changes to the internet. I realize that 99% of people using IPv6 today at home have static IPs with tunnel brokers, but if it ever gets rolled out mainstrem it is likely to involve dynamic prefixes, which means anytime your ISP changes your outside IP every device in your house will change its internet-routable IP. Today you don't see that since everybody uses NAT. Link-local is really the solution to this if you don't want to use NAT in the IPv6 world (which is clearly the greater evil, and even then you're using link local anyway). -- Rich
[gentoo-user] [OT] Browser support for IPv6 Link-Local: oh, the shame...
I just found out that Firefox recently _removed_ support for IPv6 link-local addresses. It was a very useful feature -- at least to me -- but it wasn't required by law, so they removed it. Yes, that's _actually_ what the devs said in the thread I found. AFAICT, chrome has never supported it. Links doesn't. w3m doesn't. Internet Explorer does. Oh, the shame... You'd think with a nice geeky feature like that, it would be the other way around: supported by firefox/chrome/links/w3m but not by IE. Of course the _way_ that Microsoft supports it using some meaningless numerical index as the zone identifier is rather half-arsed compared to the interface names you use on Linux, but at least it _works_ in IE. [For those of you keeping score, curl does support IPv6 link-local addresses, so it's not a shutout.] Now that RFC6874 is standards-track, I assume Firefox devs will be forced (against their will, apparently) to put that feature back in. Hopefully Chrome, w3m, links, et alia will follow suite. IPv6 link-local addresses are _way_ cool for dealing with embedded devices that have network interfaces. You can actually set them up and use them without having to faff about with dualing DHCP servers, temporarily adding an IP address/route to your laptop/desktop, using proprietary Windows-only widget-management utilities, configuring the thing via serial console, USB port, hardware switches/jumpers, etc. -- Grant Edwards grant.b.edwardsYow! at gmail.com
[gentoo-user] Regarding my final year thesis
I an Applied Maths student, currently in my final year. In my last 6 months i need to do a thesis something related to Mathematics as i am a Maths student. I have been using gentoo for quite a long time so was thinking to do something related to gentoo. Give me suggestion of what can be done. Anything related to modeling, simulation or Discreet Mathematics would be a better choice.
Re: [gentoo-user] Nagios testers wanted
On Tuesday, November 04, 2014 10:15:13 AM Michael Orlitzky wrote: > We're collecting more and more Nagios bugs every day, and we've been > stuck on the 3.x series for a while even though upstream has moved to 4.x. We are? I'm currently using the stable version myself and it does seem to work. The web-interface isn't the most useful, but the emails do get send. > The main problem as far as I can see is that nagios-plugins is a big > mess, and it's hard for any one person to test. (We use it at work, but > there's no ipv6 there, or ldap, or snmp, or game servers...) I use LDAP, no IPv6 yet. But I don't have a check on the LDAP yet. (If that dies, I get plenty of other failures anyway) > I've rewritten the nagios, nagios-core, and nagios-plugins ebuilds, and > will eventually ask permission to commit them to ~arch. That will rip > the band-aid off, so to speak, after which I can work on addressing the > existing bugs. But before I do, I'd like to have a few people test it > and tell me it works. > > So if anyone is using nagios, please give these a try. > > net-analyzer/nagios and net-analyzer/nagios-core: > > https://bugs.gentoo.org/show_bug.cgi?id=485756 > > nagios-plugins: > > https://bugs.gentoo.org/show_bug.cgi?id=522946 I'd love to, but am a bit constrained with time. Nagios is, for me, not mission-critical. If you do push them to the tree, I will check them as they come in. Any bugs I find, I will report along, if possible, as much info as possible. (Preferably also patches) > If you see any problems, just comment on the bug or email me or > whatever. I am actually using these ebuilds, so they won't delete your > system32 or anything. If there are bugs they're likely in one of the > parts I don't use. I'm also pretty sure that most of the open bugs on > b.g.o still apply, but this version at least shouldn't be any worse than > the one in the tree. If it were me, feel free to push them to the tree. -- Joost
Re: [gentoo-user] using python 2.7
On Thu, 06 Nov 2014 16:11:49 +1100, wraeth wrote: > > > For future reference, make sure nothing depends on whatever version > > > of python you want to remove before you remove it. If you don't, > > > it could get very interesting in a really bad way. > > > > The simplest way to do that, with any package you want to remove, is > > to use > > > > emerge --depclean --ask -v cat/pkg > > > > instead of > > > > emerge --unmerge --ask cat/pkg > > > > With depclean, dependencies are checked and the package will only be > > removed if nothing depends on it. Adding the -v shows you what > > depends on it. > > It should also be noted that running --depclean on a specific package > *ONLY* removes that package. After depcleaning a specific package, you > should run --depclean again to remove any dependencies of that removed > package: > > emerge --depclean --ask -v cat/pkg > emerge --depclean --ask > > The alternative (at least for packages not in a selected set) is to > > emerge --deselect cat/pkg > emerge --depclean --ask > > This will, oddly enough, deselect the package from being wanted or > "selected", allowing it to be depcleaned, along with its own > dependencies, if no other packages depend on it. Good point. The advantage of depcleaning a particular package is that if something does depend on it, emerge will tell you what, and you may decide to remove or change flags on the dependant package. With deselect, if the initial package is still wanted, the subsequent depclean will do nothing silently. Horses for courses really, -- Neil Bothwick Therapy is expensive, popping bubble wrap is cheap! You choose. pgpMx7LDwjrB8.pgp Description: OpenPGP digital signature
