On Thu, 10 Mar 2011 20:25:10 +
"Kevin F. Quinn" wrote:
> I would guess these old untouched bugs aren't actually going to be
> touched, ever - a lot simply won't be relevant any more for one reason
> or another. All they're doing is cluttering up bugzilla.
I never understand this argument.
On Fri, 11 Mar 2011 04:52:19 +0100
Jeroen Roovers wrote:
> On Thu, 10 Mar 2011 21:06:54 +0100
> Amadeusz Żołnowski wrote:
>
> > > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED
> > > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED
> >
> > Who confirms the bug?
On Thu, 10 Mar 2011 21:06:54 +0100
Amadeusz Żołnowski wrote:
> > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED
> > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED
>
> Who confirms the bug? I would expect that CONFIRMED is set by the
> package maintainer and the
On 03/10/2011 02:25 PM, Kevin F. Quinn wrote:
Hi all,
I was nosing through bugzilla, and noticed:
* Number of open bugs is greater than 14,000
* Number of open bugs untouched for more than 2 years - well over 2000.
* Number of open bugs untouched between 1 and 2 years - well over 2000.
* Number
Kevin F. Quinn posted on Thu, 10 Mar 2011 20:25:10 + as excerpted:
> Hi all,
>
> I was nosing through bugzilla, and noticed:
>
> * Number of open bugs is greater than 14,000
> * open bugs untouched > 2 years - well over 2000.
> * open bugs untouched 1 - 2 years - well over 2000.
> * open bug
On Thursday, March 10, 2011 12:28:59 Patrick Börjesson wrote:
> On 2011-03-09 19:11, Mike Frysinger wrote:
> > +list. GLEPs are then reviewed at a Council meeting where it may be
> > approved +or rejected outright, or send it back to the author(s) for
> > revision. This
>
> Just a minor note; Th
On 3/10/11 9:33 PM, Mike Gilbert wrote:
> Chromium tarballs are actually around 140 MB. It would be interesting
> to see if we can trim that tarball down.
Oh yes, we can. I guess the biggest problem is testing, but we can
certainly remove more from the tarball.
If anyone's interested, it's src/to
On Thu, Mar 10, 2011 at 3:04 PM, James Cloos wrote:
>> "PH" == Paweł Hajdan, writes:
>
> PH> That's the chromium-bin, really. The difference is that chromium has
> PH> more deps and takes more time to compile than grub. Also, it has much
> PH> more frequent releases, and almost every stable r
Hi all,
I was nosing through bugzilla, and noticed:
* Number of open bugs is greater than 14,000
* Number of open bugs untouched for more than 2 years - well over 2000.
* Number of open bugs untouched between 1 and 2 years - well over 2000.
* Number of open bugs untouched between 6 months and 1 y
On 03/10/2011 02:35 AM, Mike Frysinger wrote:
i cant see much value anymore in even making this an option. just drop the
USE flag and always use LFS.
-mike
+1
Excerpts from Jeroen Roovers's message of Thu Mar 10 20:42:29 +0100 2011:
> For existing bugs, then, NEW bugs should be changed to UNCONFIRMED
> when they are assigned to bug-wranglers, and to CONFIRMED when they
> have already been assigned to their maintainers (irrespective of
> whether they are
> "PH" == Paweł Hajdan, writes:
PH> That's the chromium-bin, really. The difference is that chromium has
PH> more deps and takes more time to compile than grub. Also, it has much
PH> more frequent releases, and almost every stable release is a security
PH> update.
And every one of those chro
On Thu, 10 Mar 2011 11:04:19 -0500
Mike Gilbert wrote:
> If we were to switch to the new workflow, it probably would make sense
> to switch the default new bug status to UNCONFIRMED. I'm not sure how
> we would handle the existing bugs in NEW status.
I agree that new should now automatically be
On Thu, 10 Mar 2011 10:56:31 +0100
justin wrote:
> On 10/03/11 10:44, Diego Elio Pettenò wrote:
> > Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto:
> >>
> >> there are not many packages using it, but I will add this flag to
> >> another 10.
> >
> > Why?
>
> just because upstream
On 2011-03-09 19:11, Mike Frysinger wrote:
> +list. GLEPs are then reviewed at a Council meeting where it may be approved
> +or rejected outright, or send it back to the author(s) for revision. This
Just a minor note; The sentence is written from the perspective of the
GLEP, so the last part sho
On Thu, Mar 10, 2011 at 6:15 AM, Markos Chandras wrote:
> On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote:
>> On 3/7/11 11:13 AM, Brian Harring wrote:
>> > Re-read what he stated- it'll convert all existing NEW bugs to
>> > CONFIRMED upon migration. There's a fair number of bu
On Thu, Mar 10, 2011 at 8:52 AM, Anthony G. Basile wrote:
> Hi,
>
> I noticed that release 11.0 was annouced on distrowatch.com,
> sourcewell.berlios.de, and other places, but not on freshmeat.net. The
> last release announced there is 10.0 back in Oct 7, 2009. dabbot is
> listed, but he is on
Hi,
I noticed that release 11.0 was annouced on distrowatch.com,
sourcewell.berlios.de, and other places, but not on freshmeat.net. The
last release announced there is 10.0 back in Oct 7, 2009. dabbot is
listed, but he is on devaway until May. Is PR aware?
BTW, I think the liveCD is very pret
On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote:
> On 3/7/11 11:13 AM, Brian Harring wrote:
> > Re-read what he stated- it'll convert all existing NEW bugs to
> > CONFIRMED upon migration. There's a fair number of bugs that are in a
> > NEW state, decent number that have sat
On 3/5/11 11:05 AM, Duncan wrote:
> What about handling chromium-bin the same way amd64 handles grub-static?
> They create a standard binpkg of the normal grub ebuild (using
> standardized USE flags, of course), using that as the source tarball for
> the grub-static ebuild, which then simply eb
On 3/7/11 11:13 AM, Brian Harring wrote:
> Re-read what he stated- it'll convert all existing NEW bugs to
> CONFIRMED upon migration. There's a fair number of bugs that are in a
> NEW state, decent number that have sat for a long while too. Those
> bugs aren't 'confirmed'- just like with the n
On 3/7/11 1:05 PM, Hanno Böck wrote:
> Am Sun, 27 Feb 2011 15:44:13 +0100
> schrieb "Paweł Hajdan, Jr." :
>
>> As the package seems rather unmaintained, I'm going to wait for a
>> while and check in the ebuild if nobody is against that.
>>
>> Any feedback is welcome, please let me know what you th
Il giorno gio, 10/03/2011 alle 10.56 +0100, justin ha scritto:
>
>
> just because upstream has this configure flag. but it seems we agree
> on
> removing the flag completely, defaulting on largefile support and
> fixing
> what needs a fix.
> Correct?
Correct. Any configure with AC_SYS_LARGEFILE
On 10/03/11 10:44, Diego Elio Pettenò wrote:
> Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto:
>>
>> there are not many packages using it, but I will add this flag to
>> another 10.
>
> Why?
just because upstream has this configure flag. but it seems we agree on
removing the flag
Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto:
>
> there are not many packages using it, but I will add this flag to
> another 10.
Why?
Please remember that largefile doesn't just mean files bigger than 4GiB,
it enables more than just sizeof(off_t)==8, it is also required to
acc
On Thu, Mar 10, 2011 at 2:12 PM, justin wrote:
> euse -i largefile
[snip]
> [+ C ] largefile (dev-libs/eggdbus):
> Support for large files
>
For the record: eggdbus was merged into glib itself as gdbus, and
almost nothing needs it anymore. It'll be removed as soon as
libgnome-keyring-2.32.0 and
On Thursday, March 10, 2011 03:36:46 Amadeusz Żołnowski wrote:
> Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011:
> > there are not many packages using it, but I will add this flag to
> > another 10.
> > And I think, it is of a general, global meaning. Do you agree in
> > making it
Mike Frysinger wrote:
On Thursday, March 10, 2011 03:08:24 justin wrote:
there are not many packages using it, but I will add this flag to
another 10.
And I think, it is of a general, global meaning. Do you agree in making
it a global USE?
i cant see much value anymore in even making
On 10/03/11 09:36, Amadeusz Żołnowski wrote:
> Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011:
>> there are not many packages using it, but I will add this flag to
>> another 10.
>> And I think, it is of a general, global meaning. Do you agree in
>> making it a global USE?
>
> I'
Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011:
> there are not many packages using it, but I will add this flag to
> another 10.
> And I think, it is of a general, global meaning. Do you agree in
> making it a global USE?
I'm new here, but I think it would be good idea to list p
On Thursday, March 10, 2011 03:08:24 justin wrote:
> there are not many packages using it, but I will add this flag to
> another 10.
> And I think, it is of a general, global meaning. Do you agree in making
> it a global USE?
i cant see much value anymore in even making this an option. just drop
Hi,
there are not many packages using it, but I will add this flag to
another 10.
And I think, it is of a general, global meaning. Do you agree in making
it a global USE?
justin
signature.asc
Description: OpenPGP digital signature
32 matches
Mail list logo
