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
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)
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
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
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
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
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
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
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
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
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
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,
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
13 matches
Mail list logo
