On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote:
> * It makes zero sense to manually manage ChangeLogs in git[1]
> - Irritating conflicts while merging branches or remote master
> + Similar argument for having only distfile manifests; but I digress...
> - Duplication of effort and info
On 04/04/10 22:48, Roy Bamford wrote:
> Open bugs per package and mean age of bugs per package come to mind.
> Such per package metrics can be aggregated per herd, per project, the
> whole of Gentoo or whatever.
>
> A reducing mean age of bugs and open bugs shows we are moving in the
> right dir
Le 03/04/2010 11:50, Petteri Räty a écrit :
> I don't think later is valid resolution. If there's a valid bug it just
> means it's never looked at again. If the bug is not valid then a
> different resolution should be used. So what do you think about
> disabling later? I would like to avoid things
On 2010-04-06 04:12, Ben de Groot wrote:
> After the mostly positive feedback on the recent wiki discussion, we
> have now gone ahead, formed a preliminary team consisting of both
> users and developers, and put up a project page [1]. All constructive
> feedback on this new project is welcome.
Thi
On 04/05/10 13:12, Ben de Groot wrote:
After the mostly positive feedback on the recent wiki discussion, we
have now gone ahead, formed a preliminary team consisting of both
users and developers, and put up a project page [1]. All constructive
feedback on this new project is welcome.
We'd also l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05-04-2010 18:26, Zeerak Mustafa Waseem wrote:
> On Mon, Apr 05, 2010 at 04:07:01PM +, Jon Portnoy wrote:
> There should be a process of weeding out developers that bitch and/or whine,
> but if most of the teams are understaffed then there has
One of the few remaining problems to be solved for the migration to
git for our gentoo-x86/ and gentoo/ trees (besides other
projects/overlays) is the problem of how to handle ChangeLogs.
Gist:
* It makes zero sense to manually manage ChangeLogs in git[1]
- Irritating conflicts while m
# Michael Sterrett (05 Apr 2010)
# Needs dev-python/numeric which is going away.
# No release since 2006
# Masked for removal on 20100505
games-strategy/castle-combat
On Mon, Apr 5, 2010 at 11:24 PM, Denis Dupeyron wrote:
> On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan wrote:
>
>> I see no reason whatsoever to keep it open.
>
> How about this one: preventing users from filing dupes.
>
We already advise our users to check RESO bugs before filing bugs; and
t
> Date: Mon, 5 Apr 2010 23:37:31 +0200
> From: zeera...@gmail.com
> To: gentoo-dev@lists.gentoo.org
> Subject: Re: [gentoo-dev] [RFC] Gentoo Wiki Project
>
> On Mon, Apr 05, 2010 at 10:15:21PM +0300, Markos Chandras wrote:
> > On Monday 05 April 2010 21:12:49 Ben de Groot wrote:
> > > After the m
On Mon, Apr 05, 2010 at 10:15:21PM +0300, Markos Chandras wrote:
> On Monday 05 April 2010 21:12:49 Ben de Groot wrote:
> > After the mostly positive feedback on the recent wiki discussion, we
> > have now gone ahead, formed a preliminary team consisting of both
> > users and developers, and put up
On Monday 05 April 2010 21:12:49 Ben de Groot wrote:
> After the mostly positive feedback on the recent wiki discussion, we
> have now gone ahead, formed a preliminary team consisting of both
> users and developers, and put up a project page [1]. All constructive
> feedback on this new project is w
On Mon, 5 Apr 2010 20:12:49 +0200, Ben de Groot
wrote:
> After the mostly positive feedback on the recent wiki discussion, we
> have now gone ahead, formed a preliminary team consisting of both
> users and developers, and put up a project page [1]. All constructive
> feedback on this new project
On Mon, Apr 5, 2010 at 12:51 PM, Nathan Zachary
wrote:
> [...] but it
> would be much more enlightening to me to work on creating ebuilds while
> working one-on-one with a mentor.
The whole purpose of the training period between the ebuild quiz and
the end quiz (see [1]) is exactly this. If your
On 05/04/10 13:12, Ben de Groot wrote:
> After the mostly positive feedback on the recent wiki discussion, we
> have now gone ahead, formed a preliminary team consisting of both
> users and developers, and put up a project page [1]. All constructive
> feedback on this new project is welcome.
>
> We
On 05/04/10 11:07, Jon Portnoy wrote:
> On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
>
>> Just replying randomly.
>>
>> On 05.04.2010 04:33, Tobias Heinlein wrote:
>>
>>> I think this is a good starting point to get rid of the "some important
>>> questions are too hard to ans
On Mon, Apr 5, 2010 at 11:57 AM, Jon Portnoy wrote:
> Which is all well and good -- the "you wrote some ebuilds so here's
> your commit privs and @gentoo.org" approach to recruitment worked great
> when Gentoo had a few dozen developers.
>
> Today QA is a bit more important, and development is oft
After the mostly positive feedback on the recent wiki discussion, we
have now gone ahead, formed a preliminary team consisting of both
users and developers, and put up a project page [1]. All constructive
feedback on this new project is welcome.
We'd also like to invite any users and developers, w
On Mon, Apr 05, 2010 at 03:27:34PM +0200, Tiziano MMMller wrote:
> > Via that, the resolver can see that a rebuild is necessary and plan a
> > rebuild of all consumers (whether NEEDED based or revdep). Note
> > preserve-lib would be rather useful here- specifically holding onto
> > the intermed
On Sat, Apr 3, 2010 at 9:25 AM, Jorge Manuel B. S. Vicetto
wrote:
> I disagree. Resolved LATER is useful to some maintainers that want to
> fix that bug, but don't have time or don't find the issue to be a
> priority at the moment. By marking it LATER they're acknowledging the
> bug exists and nee
On Mon, Apr 05, 2010 at 05:50:49PM +0100, George Prowse wrote:
> That assumes the system is working perfectly and the whole fact that
> we are having this discussion would go against that.
>
> From what i've read in the community, lots of people would have no
> problems helping out maintaining pac
On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan wrote:
> I see no reason whatsoever to keep it open.
How about this one: preventing users from filing dupes.
> If we
> start doing that, we'll end up with tons of extra bugs on our hands.
What's the big deal? You know you'll be adding/bumping th
On 04/05/2010 09:26 PM, Zeerak Mustafa Waseem wrote:
>
> The first option could be somewhat simple, we already have overlays
> so those could simply be used. The second option (which would be the
> best IMO) is a fair bit harder. The first thing that needs to be done
> is find out why people don'
On Mon, Apr 5, 2010 at 9:33 AM, Richard Freeman wrote:
> What I was getting at is trying to identify what aspects of the whole
> recruitment process added the most value and which added the least, and
> adjusting accordingly. I think that assessing attitude and maturity, and
> providing the tools
On 05/04/2010 17:07, Jon Portnoy wrote:
On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
Just replying randomly.
On 05.04.2010 04:33, Tobias Heinlein wrote:
I think this is a good starting point to get rid of the "some important
questions are too hard to answer" dilemma that can be
On Mon, Apr 05, 2010 at 04:07:01PM +, Jon Portnoy wrote:
> On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
> > Just replying randomly.
> >
> > On 05.04.2010 04:33, Tobias Heinlein wrote:
> > > I think this is a good starting point to get rid of the "some important
> > > questions a
On Mon, Apr 05, 2010 at 08:50:49AM +0300, Eray Aslan wrote:
> Just replying randomly.
>
> On 05.04.2010 04:33, Tobias Heinlein wrote:
> > I think this is a good starting point to get rid of the "some important
> > questions are too hard to answer" dilemma that can be implemented
> > relatively fas
On 04/04/2010 02:09 PM, Denis Dupeyron wrote:
All ideas regarding improving recruitment are welcome, thanks. However
if, during your review, you were not given the impression that your
maturity and other social skills were being assessed then you were
being blissfully naive. :o)
That actually
Am Montag, den 05.04.2010, 08:16 +0200 schrieb Maciej Mrozowski:
> On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote:
>
> >> Besides I
> >> can already imagine PMS-related discussion regarding "make the PMs check
> for rdeps per default before unmerging things" - thx but no thx.
> > This
On 04/05/2010 03:48 AM, Ciaran McCreesh wrote:
On Mon, 05 Apr 2010 03:33:52 +0200
Tobias Heinlein wrote:
3) Questions that aren't that important at all and would just be "nice
to know".
[snip]
Examples for these:
5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
insi
Am Sonntag, den 04.04.2010, 23:44 -0700 schrieb Brian Harring:
> On Mon, Apr 05, 2010 at 08:16:42AM +0200, Maciej Mrozowski wrote:
> > Unconditionally removing libraries (instead of preserving them) and making
> > their reverse runtime dependencies reinstalled is unacceptable because
> > "emerge"
mån 2010-04-05 klockan 03:54 +0300 skrev Mart Raudsepp:
> The problem is really the RESOLVED connotation and the hiding that goes
> along with that on searches, etc.
>
> The LATER status itself can be useful when used properly (more as
> "ASSIGNED LATER"). In the lack of that some bigger teams mig
On 04/05/2010 05:36 AM, Alistair Bush wrote:
>> On 4/3/10 3:40 PM, Ben de Groot wrote:
>>> Are there any other ideas on how to improve our recruitment process?
>>
>> The idea appeared before, but I think it's worth noting.
>>
>> Either merge the ebuild and end quizzes, or make the split actually
>>
On Mon, Apr 05, 2010 at 08:48:08AM +0100, Ciaran McCreesh wrote:
> On Mon, 05 Apr 2010 03:33:52 +0200
> Tobias Heinlein wrote:
> > 3) Questions that aren't that important at all and would just be "nice
> > to know".
> > [snip]
> > Examples for these:
> >
> > 5. What is wrong with using $(somecomm
On Mon, 05 Apr 2010 03:33:52 +0200
Tobias Heinlein wrote:
> 3) Questions that aren't that important at all and would just be "nice
> to know".
> [snip]
> Examples for these:
>
> 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
> inside SRC_URI, DEPEND, etc?
> [Devm
35 matches
Mail list logo
