[gentoo-dev] Re: rfc: formally allow qa to suspend commit rights

On Sat, Jan 18, 2014 at 11:02:24PM -0600, William Hubbs wrote: > +* In case a particular developer persistently causes breakage, the QA lead > may request commit rights of that developer to be suspended by the Infra > team. Comrel should then proceed to evaluate the situation, by finding a > com

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

All, I put this on the wrong list, so please disregard this here and reply on -project instead; I forwarded this msg over there. Thanks, William signature.asc Description: Digital signature

[gentoo-dev] rfc: formally allow qa to suspend commit rights

All, I would like to bring back for discussion an old patch to glep 48 [1] which was suggested by Jorge [2]. That patch evolved into this one [3], and in the council meeting back then [4], parts of it made their way into glep 48, but the rest seemed to be forgotten. Attached you will find an upd

[gentoo-dev] Last rites: virtual/monodoc

# Dion Moult (19 Jan 2014) # Mask for removal in 30 days. Packages now depend on dev-lang/mono directly and # not on virtual/monodoc (bug #471180) virtual/monodoc

[gentoo-dev] Last rites: sys-apps/usleep

# Dion Moult (19 Jan 2014) # Mask for removal in 30 days. usleep is actually provided part of # app-admin/killproc (bug #467212) sys-apps/usleep

[gentoo-dev] Last rites: app-misc/flyte-download-manager

# Dion Moult (19 Jan 2014) # Mask for removal in 30 days. Flyte service discontinued so package is useless. # (bug #495138) app-misc/flyte-download-manager

[gentoo-dev] Re: Regarding long delays on GLSA generation

Dirkjan Ochtman posted on Sat, 18 Jan 2014 17:33:36 +0100 as excerpted: > On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos wrote: >> What I want to achieve is to try to get this problem solved, I don't >> think has any sense to have pending GLSA bugs waiting for ages (yes, >> ages), I see this for re

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 13:57 -0500, Chris Reffett escribió: [...] > We prefer that the maintainers do the drop in case there's some > dependency situation we're not aware of, but we will drop if > maintainers are unresponsive. > [...] > By all means, maintainer should be the one to call for the

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 19:35 +0100, Pacho Ramos escribió: [...] > They helped for sure :) and I appreciate them, I simply thought nothing > was being worked out as I explained in previous mail (I was still saying > long delays) -> seeing (not sure why I type so wrongly :S)

Re: [gentoo-dev] Regarding long delays on GLSA generation

On Jan 18, 2014 1:35 PM, Pacho Ramos wrote: > > El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: > [...] > > So you observed correctly there's still plenty of delays. There are > > three parts to an advisory that take time: > > - Drafting: Collecting information, linking references

[gentoo-dev] Re: overlays.gentoo.org restoration & post-mortem

Alex Legler posted on Sat, 18 Jan 2014 13:59:56 +0100 as excerpted: > Ironically, the only site that was already using the Tyrian theme (i.e. > the one with a top-right menu) was infra-status. > Now with overlays using the new theme too, I've updated the list. > > (NB: During the outage, I added

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió: [...] > So you observed correctly there's still plenty of delays. There are > three parts to an advisory that take time: > - Drafting: Collecting information, linking references, getting package > versions done right (slots are a huge pain

Re: [gentoo-dev] Regarding long delays on GLSA generation

On 18.01.2014 18:38, Pacho Ramos wrote: > […] > > Then, how are you finally going to fix this? Thank you for finally showing interest in anything we do. Here is how we are 'finally' going to fix this. > Only for knowing, I still > was seeing some delays and, then, I though situation was not impr

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 18:26 +0100, Alex Legler escribió: > On 18.01.2014 17:30, Pacho Ramos wrote: > > […] > > > > What I want to achieve is to try to get this problem solved, I don't > > think has any sense to have pending GLSA bugs waiting for ages (yes, > > ages), I see this for really a lot

Re: [gentoo-dev] Regarding long delays on GLSA generation

On 18.01.2014 17:30, Pacho Ramos wrote: > […] > > What I want to achieve is to try to get this problem solved, I don't > think has any sense to have pending GLSA bugs waiting for ages (yes, > ages), I see this for really a lot of packages, the pointed one was only > one example, but there are many

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 17:30 +0100, Pacho Ramos escribió: [..] > The issue is still present even if we don't talk about it and keep > simply ignoring all bug reports assigned to security and accumulating > for years. [Bah, the touchpad] I was referring the, until know, I was simply ignoring tha

Re: [gentoo-dev] Regarding long delays on GLSA generation

On Sat, Jan 18, 2014 at 5:30 PM, Pacho Ramos wrote: > What I want to achieve is to try to get this problem solved, I don't > think has any sense to have pending GLSA bugs waiting for ages (yes, > ages), I see this for really a lot of packages, the pointed one was only > one example, but there are

Re: [gentoo-dev] Regarding long delays on GLSA generation

El sáb, 18-01-2014 a las 17:02 +0100, Alex Legler escribió: > On 18.01.2014 16:34, Pacho Ramos wrote: > > Was looking to existing gedit bug reports and I found: > > https://bugs.gentoo.org/show_bug.cgi?id=257004 > > > > That is only one more example of a really old bug report still opened > > and

Re: [gentoo-dev] Regarding long delays on GLSA generation

Oops, didn't send to @-dev. On Jan 18, 2014 10:58 AM, creff...@gentoo.org wrote: > > Short version since I'm on my phone: we're working on reducing the number of > fields, can't really auto generate, current blocker is getting two additional > devs (beyond the author) to sign off on the GLSA. We

Re: [gentoo-dev] Regarding long delays on GLSA generation

On 18.01.2014 16:34, Pacho Ramos wrote: > Was looking to existing gedit bug reports and I found: > https://bugs.gentoo.org/show_bug.cgi?id=257004 > > That is only one more example of a really old bug report still opened > and waiting for a GLSA. Was wondering what really causes this long > delays,

[gentoo-dev] Regarding long delays on GLSA generation

Was looking to existing gedit bug reports and I found: https://bugs.gentoo.org/show_bug.cgi?id=257004 That is only one more example of a really old bug report still opened and waiting for a GLSA. Was wondering what really causes this long delays, can't GLSA be done automatically? Would a GLSA even

Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem

On Sat, 18 Jan 2014 05:02:56 + "Robin H. Johnson" wrote: > FYI: The following repos appeared to be empty: > ... > dev/tomwij.git > ... Not empty, has app-office/taskjuggler and dev-java/jetty-*; did a check against my local clone, and `git ls-tree --full-tree -r HEAD | sha1sum` reports the s

Re: [gentoo-dev] Re: overlays.gentoo.org restoration & post-mortem

On 18/01/14 05:57 AM, Martin Vaeth wrote: > Robin H. Johnson wrote: >> >> FYI: The following repos contained dangling commits/tags/blobs >> [...] you are encouraged to push again [...] >> user/mv.git (+blobs) > > I cannot imagine that the suggested "git push" removed orphaned blobs: > AFAIK it is

Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem

On 01/18/2014 12:59 PM, Alex Legler wrote: > On 18.01.2014 06:23, Kent Fredric wrote: >> >> On 18 January 2014 18:02, Robin H. Johnson > > wrote: >> >> - More people need to use the infra-status page to learn about the state >> of Gentoo services. >> >> >> >> A

Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem

On 18.01.2014 06:23, Kent Fredric wrote: > > On 18 January 2014 18:02, Robin H. Johnson > wrote: > > - More people need to use the infra-status page to learn about the state > of Gentoo services. > > > > A service middle layer like fastly or cloudflare whi

[gentoo-dev] arch="any" (Re: rfc: revisiting our stabilization policy)

On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote: > On Fri, 17 Jan 2014 18:28:41 + > Ciaran McCreesh wrote: > > > On Fri, 17 Jan 2014 17:47:58 +0100 > > Tom Wijsman wrote: > > > Maybe we can let the package managers only perceive it as keyworded > > > or stable if all of its depen

[gentoo-dev] Re: overlays.gentoo.org restoration & post-mortem

Robin H. Johnson wrote: > > FYI: The following repos contained dangling commits/tags/blobs > [...] you are encouraged to push again [...] > user/mv.git (+blobs) I cannot imagine that the suggested "git push" removed orphaned blobs: AFAIK it is not possible to execute commands like "git prune", "g

Re: [gentoo-dev] overlays.gentoo.org restoration & post-mortem

On 18/01/2014 09:49, Alec Warner wrote: > On Fri, Jan 17, 2014 at 11:10 PM, Alan McKinnon > wrote: > > On 18/01/2014 09:04, Patrick Lauer wrote: > >> which could link to the > >> > infra page would be good here perhaps, so when an outage > occurred

Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas

Dnia 2014-01-18, o godz. 02:28:52 "Thomas D." napisał(a): > Hi, > > Michał Górny wrote: > > Now, does anyone have an old portage-YYZZ.tar.{bz2,xz} snapshot? I > > need the official one from our mirrors, preferably 3-4 months old. > >

Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas

Dnia 2014-01-18, o godz. 10:08:13 hero...@gentoo.org napisał(a): > Michał Górny writes: > > > However, it may be actually beneficial to provide other durations, like > > weekly deltas. In my tests, the daily updates for this week summed up > > to almost 50M while the weekly was barely 20M. > >