The herds have been deprecated by the Council and are being replaced by projects. For this reason, please decide on the fate of the herd stated in the summary and update [1] or state the request here. The common choices are: 1. Map the herd to an existing project (in this case all packages in the herd will be maintained by the project) -- let us know which project to use. 2. Create a new project for the herd -- create the wiki page, let us know the new mail alias name to be created, create the wiki page and let us know about it. 3. Decide to disband the herd -- just let us know (but keep it for now in herds.xml!), we'll replace it with individual maintainers when herds are removed. [1]:https://wiki.gentoo.org/wiki/Project:Metastructure/Herd_to_project_mapping
As per the recent Council decision[1], the final deadline for herd -> project migration is 24th January 2016. If no action is taken for this herd by that time, any packages that do not have another maintainer will be reassigned to maintainer-needed. Common options include: mapping the herd to a new project, mapping it to an existing project, reassigning the packages to the herd maintainers, and reassigning to maintainer-needed. Please let me know ASAP about your intentions for this herd and I'll be happy to take care of it. 1: https://projects.gentoo.org/council/meeting-logs/20160110-summary.txt
Packages and their other maintainers: app-emacs/ocaml-mode : emacs app-emacs/tuareg-mode : emacs app-eselect/eselect-unison : app-misc/ledit : app-misc/wyrd : app-text/htmlc : dev-lang/confluence : dev-lang/mlton : dev-lang/ocaml : dev-lang/polyml : dev-lang/smlnj : dev-ml/ANSITerminal : dev-ml/async : dev-ml/async_extra : dev-ml/async_kernel : dev-ml/async_rpc_kernel : dev-ml/async_unix : dev-ml/batteries : dev-ml/bignum : dev-ml/biniou : dev-ml/bin-prot : dev-ml/bolt : dev-ml/calendar : dev-ml/camlbz2 : dev-ml/camldbm : dev-ml/camlidl : dev-ml/camlimages : dev-ml/camlp4 : dev-ml/camlp5 : dev-ml/camlzip : dev-ml/camomile : dev-ml/cmdliner : dev-ml/comparelib : dev-ml/core : dev-ml/core_bench : dev-ml/core_extended : dev-ml/core_kernel : dev-ml/core_profiler : dev-ml/cppo : dev-ml/cryptokit : dev-ml/csv : dev-ml/cudf : dev-ml/custom_printf : dev-ml/deriving : dev-ml/deriving-ocsigen : dev-ml/dose3 : dev-ml/easy-format : dev-ml/eliom : dev-ml/enumerate : dev-ml/extlib : dev-ml/facile : kde dev-ml/faillib : dev-ml/fieldslib : dev-ml/findlib : dev-ml/gd4o : dev-ml/herelib : dev-ml/incremental : dev-ml/io-page : proxy-maintainers, tomboy64@sina.cn dev-ml/iTeML : dev-ml/js_of_ocaml : dev-ml/jsonm : dev-ml/kaputt : dev-ml/lablgl : dev-ml/lablgtk : dev-ml/labltk : dev-ml/lambda-term : dev-ml/lwt : proxy-maintainers, aballier@, pclairam@gmail.com dev-ml/macaque : dev-ml/menhir : dev-ml/mirage-profile : proxy-maintainers, tomboy64@sina.cn dev-ml/oasis : dev-ml/ocaml-autoconf : dev-ml/ocaml-base64 : dev-ml/ocaml-cstruct : proxy-maintainers, tomboy64@sina.cn dev-ml/ocaml-ctypes : dev-ml/ocamldap : dev-ml/ocaml-data-notation : proxy-maintainers, v.ivanov@ymail.com dev-ml/ocaml-dns : proxy-maintainers, tomboy64@sina.cn dev-ml/ocaml-doc : dev-ml/ocamldsort : dev-ml/ocaml-expat : dev-ml/ocaml-expect : proxy-maintainers, v.ivanov@ymail.com dev-ml/ocaml-fileutils : proxy-maintainers, v.ivanov@ymail.com dev-ml/ocaml-gettext : dev-ml/ocamlgraph : dev-ml/ocamlify : dev-ml/ocaml-ipaddr : dev-ml/ocaml-make : dev-ml/ocamlmod : dev-ml/ocaml-mysql : dev-ml/ocamlnet : dev-ml/ocamlpam : dev-ml/ocaml-pcap : proxy-maintainers, tomboy64@sina.cn dev-ml/ocaml-re : dev-ml/ocaml-safepass : dev-ml/ocamlsdl : dev-ml/ocaml-sha : dev-ml/ocaml-sqlite3 : dev-ml/ocaml-ssl : dev-ml/ocaml-text : dev-ml/ocaml-uri : proxy-maintainers, tomboy64@sina.cn dev-ml/ocamlweb : dev-ml/ocplib-endian : proxy-maintainers, tomboy64@sina.cn dev-ml/ocurl : dev-ml/odns : dev-ml/opam : dev-ml/optcomp : dev-ml/ounit : dev-ml/pa_bench : dev-ml/pa_ounit : dev-ml/parmap : dev-ml/pa_structural_sexp : dev-ml/pa_test : dev-ml/pcre-ocaml : dev-ml/pgocaml : dev-ml/pipebang : dev-ml/pomap : dev-ml/postgresql-ocaml : dev-ml/pxp : dev-ml/qcheck : proxy-maintainers, tomboy64@sina.cn dev-ml/re2 : dev-ml/react : dev-ml/reactiveData : dev-ml/res : dev-ml/sexplib : dev-ml/stringext : proxy-maintainers, tomboy64@sina.cn dev-ml/textutils : dev-ml/type-conv : dev-ml/typehashlib : dev-ml/typerep : dev-ml/typerep_extended : dev-ml/tyxml : dev-ml/ulex : dev-ml/utop : dev-ml/uutf : dev-ml/variantslib : dev-ml/xmlm : proxy-maintainers, v.ivanov@ymail.com dev-ml/xstr : dev-ml/yojson : dev-ml/zarith : dev-ml/zed : dev-scheme/schoca : scheme dev-tex/bibtex2html : tex dev-tex/hevea : tex dev-util/coccinelle : radhermit@ dev-util/omake : net-misc/hsc : net-misc/libres3 : proxy-maintainers, tomboy64@sina.cn net-misc/unison : sci-mathematics/coq : sci-mathematics www-servers/ocsigenserver :
make it a project and be done (In reply to Michael Palimaka (kensington) from comment #1) > As per the recent Council decision[1], the final deadline for herd -> > project migration is 24th January 2016. If no action is taken for this herd > by that time, any packages that do not have another maintainer will be > reassigned to maintainer-needed. on a side note, the natural default solution for "herd -> project migration", is to actually do that; "threatening" to mass re-assign hundreds of packages is not actually very friendly
(In reply to Alexis Ballier from comment #3) > make it a project and be done No problem, I'll take care of it. > (In reply to Michael Palimaka (kensington) from comment #1) > > As per the recent Council decision[1], the final deadline for herd -> > > project migration is 24th January 2016. If no action is taken for this herd > > by that time, any packages that do not have another maintainer will be > > reassigned to maintainer-needed. > > on a side note, the natural default solution for "herd -> project > migration", is to actually do that; "threatening" to mass re-assign hundreds > of packages is not actually very friendly It's not clear in every situation what to do with the herd. Some herds decided to create new projects, some to merge with existing projects, and some decided to each take the packages they care about, send the rest to maintainer-needed, and disband the herd. The reason for dropping herds that do not respond to maintainer-needed (as approved by the Council) is to avoid having packages that appear to be maintained but are not. This is a big problem in general, and this migration has been a good opportunity to try and improve that. I sincerely apologise if my message came off as threatening - it was intended only as a reminder. I want to make sure that only herds that are truly dead get dropped to maintainer-needed.
(In reply to Michael Palimaka (kensington) from comment #4) > (In reply to Alexis Ballier from comment #3) > > make it a project and be done > > No problem, I'll take care of it. Thanks > > (In reply to Michael Palimaka (kensington) from comment #1) > The reason for dropping herds that do not respond to maintainer-needed (as > approved by the Council) is to avoid having packages that appear to be > maintained but are not. This is a big problem in general, and this migration > has been a good opportunity to try and improve that. Well, the usual metric here is the # of members (and # of bugs piling up), for which, afaik, several herds have been disbanded in the past. > I sincerely apologise if my message came off as threatening - it was > intended only as a reminder. I want to make sure that only herds that are > truly dead get dropped to maintainer-needed. No need to apologize: I know you've been really helpful and willing to help on the subject. Thanks again for that. My comment was meant to emphasize that this didn't reflect the intentions I had understood.