+1 To what Chip had to say on this thread. My use of ownership was wrong
and I actually meant "interest". I have also started on the
producingoss.com as suggested by Rohit, looks like a good way to
understand the working of a voluntary community.
So now that I am positive on the community feedback
> -Original Message-
> From: Joe Brockmeier [mailto:j...@zonker.net]
> Sent: Thursday, April 11, 2013 7:34 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
> On Thu, Apr 11, 2013, at 09:28 AM, Noah S
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Thursday, April 11, 2013 7:40 AM
> To:
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
> On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek
On 11 April 2013 20:09, Chip Childers wrote:
> On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
>> Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
>> Also community members should volunteer
Abhi - not to gang up on you and I'm glad to see you share your
opinions, concerns about release management and such.
I see the problem you might be facing though. I think it would be
better to have your internal JIRA mirror the ASF JIRA. That way you
can triage as you please corporate style ;) in
On Thu, Apr 11, 2013 at 8:09 PM, Chip Childers wrote:
> On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
> > Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
> > Also community members shoul
+1
On 11 April 2013 15:39, Chip Childers wrote:
> On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
> > Yes, I think we need to space our releases further apart.
>
> That's a different discussion, which you are free to raise if you'd like.
>
> > Also community members should v
On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
> Yes, I think we need to space our releases further apart.
That's a different discussion, which you are free to raise if you'd like.
> Also community members should volunteer to own some part so that in above
> circumstances a
On Thu, Apr 11, 2013, at 09:28 AM, Noah Slater wrote:
> To me, it seems like what you're describing are components. You assign or
> sort the ticket into a component. Then I guess, people who are interested
> can watch that component for new issues. I am not sure if there's a way
> to
> "watch" a co
To me, it seems like what you're describing are components. You assign or
sort the ticket into a component. Then I guess, people who are interested
can watch that component for new issues. I am not sure if there's a way to
"watch" a component in JIRA so that you get email notifications for it. I
to
On the Jira notification my suggestion will be to have a goto list of
people for various domains of expertise. Anyone can register for these
domains. When a bug is filed, the filer selects one of the domains he
thinks that is right for getting the bug to be resolved. This alerts the
people who ha
On 11 April 2013 15:11, Joe Brockmeier wrote:
>
> I'm against a policy of never assigning tickets, but it shouldn't be the
> norm for one set of folks to triage tickets and assign them to another
> set of folks.
Me too.
We should establish:
a) A rule that we avoid ticket assignment by defau
On Thu, Apr 11, 2013, at 05:22 AM, Abhinandan Prateek wrote:
> >Never would be too lenient. Maybe assign it after 7-8 days since they
> >don't need immediate attention.
>
> 7-8 days is a huge time lost. I was suggesting that this to be 3 days.
> Let other community members chime in too.
Are we as
I believe it is possible to "mention" someone in a JIRA ticket in such a
way that they get notified. Might this be an effective way of CCing someone
into the conversation, without prescribing who should fix it? Might there
be some room for exploration here?
On Thursday, 11 April 2013, Abhinandan
Yes, I think we need to space our releases further apart.
I had big trouble when master was unstable for a while and specially on VMware
it was difficult to deploy and test features. Yes for each issue I could have
shouted on mail list I saw people doing that but the fact is that instability
was
Of course releases are important.
But if our current cadence is putting too much pressure on the community,
one option might be to do our releases further apart from each other. Or,
we get strict about the principal of time based releases: i.e. if your
feature is not ready for the freeze, then it
I think it will be good if we also find out a process so that the release
cycle is not affected by unclaimed bugs sitting out there. Here I am
assuming the releases are important.
I guess the discussion has turned into keeping things free without
offering solutions to problems that that system wil
+1
On Apr 11, 2013, at 7:22 AM, Noah Slater wrote:
> On 11 April 2013 11:22, Abhinandan Prateek
> wrote:
>
>>
>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
>> other community members chime in too.
>
>
> I should have replied to this in my previous missive. Bu
On 11/04/13 4:23 PM, "prasanna" wrote:
>On 11 April 2013 15:52, Abhinandan Prateek
> wrote:
>>
I will start with an example: A critical bug (CLOUDSTACK-1941) that is
blocking a release (4.1) is not picked up by any community member for 5
days !
The reason being that it is a
On 11 April 2013 11:22, Abhinandan Prateek wrote:
>
> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
> other community members chime in too.
I should have replied to this in my previous missive. But I want to
reenforce how unhealthy I believe this practice is. 7-8 day
On 11 April 2013 04:08, Abhinandan Prateek wrote:
>
> Now is it wrong to ask the community members who have expertise on UI to
> fix it, in a bid to help Chip get the release out ?
>
It is certainly not wrong to co-ordinate with people in an effort to ship a
release. (I would point out, however,
On 11 April 2013 15:52, Abhinandan Prateek
wrote:
>
>>>
>>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>>>blocking a release (4.1) is not picked up by any community member for 5
>>>days !
>>>The reason being that it is a UI issue but not that clear from the desc,
>>>the
>>
>>I will start with an example: A critical bug (CLOUDSTACK-1941) that is
>>blocking a release (4.1) is not picked up by any community member for 5
>>days !
>>The reason being that it is a UI issue but not that clear from the desc,
>>the nature of the bug is known after someone spends time on it
+1 with slight modifications :)
On 11/04/13 8:39 AM, "Abhinandan Prateek"
wrote:
>
>
>On 10/04/13 8:57 PM, "Joe Brockmeier" wrote:
>
>>On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
>>> I think if you were wrongly assigned bug that you did not want to work
>>>on
>>> just spit it i
+1 to Abhi's suggestion.
> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Thursday, April 11, 2013 8:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
On 10/04/13 8:57 PM, "Joe Brockmeier" wrote:
>On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
>> I think if you were wrongly assigned bug that you did not want to work
>>on
>> just spit it in the mailing list and you will not be guilty of cookie
>> licking.
>>
>> Given the huge nu
On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote:
> I think if you were wrongly assigned bug that you did not want to work on
> just spit it in the mailing list and you will not be guilty of cookie
> licking.
>
> Given the huge number bugs lets focus on how to reduce that pile instead
>
I think if you were wrongly assigned bug that you did not want to work on just
spit it in the mailing list and you will not be guilty of cookie licking.
Given the huge number bugs lets focus on how to reduce that pile instead of
raking up non issues.
On 10-Apr-2013, at 12:41 PM, "Rohit Yadav"
On Wed, Apr 10, 2013 at 12:40 PM, Rohit Yadav wrote:
> Hi Abhi,
>
> First of all I totally agree with you on having at least our release
> manager the triaging blockers.
>
> Secondly, we need to understand the issue Noah is trying to raise. The
> issue assignment way now is surely an anti-pattern
Hi Abhi,
First of all I totally agree with you on having at least our release
manager the triaging blockers.
Secondly, we need to understand the issue Noah is trying to raise. The
issue assignment way now is surely an anti-pattern. Let's not deviate from
the real issue Noah started with this thre
On Tue, Apr 09, 2013 at 11:44:37PM +0530, Rohit Yadav wrote:
> On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam wrote:
>
> > On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > > [Animesh>] Folks I wanted to get your opinion on auto-assignment
> > > based on the component m
I see that the term "cookie-licking" is being used frequently in the email
thread.
We are talking about roughly 200 cookies. 55 of which nobody is willing to
touch.
150 of them are already assigned that means that these are either being
licked or being eaten.
As per the above definition if a rel
We have to leave some of this flexibility in the hands of the release
manager.
I agree the community should have a first go at the unassigned tickets,
while some tickets are picked up quickly others are around for a while.
As a release manager it is the responsibility bestowed in that person that
Got it. Thanks! :)
On 9 April 2013 19:29, Rohit Yadav wrote:
> On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater wrote:
>
> > When you say it's understandable that people being paid to work on
> > CloudStack full time engage in cookie licking, do you mean to say you
> think
> > it is acceptable?
>
On Tue, Apr 9, 2013 at 11:51 PM, Noah Slater wrote:
> When you say it's understandable that people being paid to work on
> CloudStack full time engage in cookie licking, do you mean to say you think
> it is acceptable?
Hell NO, understandable == I understand how people work in the companies
who
When you say it's understandable that people being paid to work on
CloudStack full time engage in cookie licking, do you mean to say you think
it is acceptable? Or do you believe we should be working to prevent it?
On 9 April 2013 19:14, Rohit Yadav wrote:
> On Tue, Apr 9, 2013 at 11:56 AM, Pra
On Tue, Apr 9, 2013 at 11:56 AM, Prasanna Santhanam wrote:
> On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> > [Animesh>] Folks I wanted to get your opinion on auto-assignment
> > based on the component maintainers list. We can also create shared
> > issues filters based on
On 09/04/13 11:57 AM, "Prasanna Santhanam" wrote:
>On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
>> [Animesh>] Folks I wanted to get your opinion on auto-assignment
>> based on the component maintainers list. We can also create shared
>> issues filters based on components.
On Mon, Apr 08, 2013 at 01:32:58PM -0700, Animesh Chaturvedi wrote:
> [Animesh>] Folks I wanted to get your opinion on auto-assignment
> based on the component maintainers list. We can also create shared
> issues filters based on components. Folks can subscribe to the
> filters of interest and rece
ack.apache.org
> > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
> >
> >
> >
> > On 4/8/13 1:32 PM, "Animesh Chaturvedi"
> > wrote:
> >
> > >
> > >>
> > >> I also wanted to find out how do
> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Monday, April 08, 2013 2:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
>
>
> On 4/8/13 1:32 P
On 4/8/13 1:32 PM, "Animesh Chaturvedi"
wrote:
>
>>
>> I also wanted to find out how do other projects get through resolving
>>blocker
>> bugs sooner?
>>
>> [1]
>>
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainer
>> s+Per+Component
>>
>[Animesh>] Folks I wanted to
> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Tuesday, April 02, 2013 3:46 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
>
>
>
> > -Origin
> I understand the reasoning - but for a newcomer looking to get involved, I
> think 'assigning' a bug - whether by default, or otherwise can be construed as
> excluding newcomers and no room for them to get involved, so I think it
> warrants caution at a minimum.
>
> Our 'if not 'in progress' any
On Tue, Apr 2, 2013 at 6:53 PM, Alex Huang wrote:
> So let me start off with I agree in principle with what Noah is talking about
> here. Cookie licking is an anti-pattern that we should reject as a
> community. However, I disagree the solution or even what is perceived as
> cookie licking.
>
ssigned
to. Just whether the bug is open or not.
--Alex
> -Original Message-
> From: Noah Slater [mailto:nsla...@apache.org]
> Sent: Tuesday, April 2, 2013 12:21 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Don't assign tickets to people when triaging
&
> -Original Message-
> From: Will Chan [mailto:will.c...@citrix.com]
> Sent: Tuesday, April 02, 2013 2:22 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Don't assign tickets to people when triaging
>
> I think the purpose of this discussio
org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
>
> On Apr 2, 2013, at 3:21 PM, Noah Slater wrote:
>
> > Dear community,
> >
> > Right now, we have people who are regularly going through JIRA and
> > triaging tickets. This i
On Apr 2, 2013, at 3:21 PM, Noah Slater wrote:
> Dear community,
>
> Right now, we have people who are regularly going through JIRA and triaging
> tickets. This is totally fantastic, and a very valuable activity for the
> project. (So thank you!) But I also notice that specific individuals are
Dear community,
Right now, we have people who are regularly going through JIRA and triaging
tickets. This is totally fantastic, and a very valuable activity for the
project. (So thank you!) But I also notice that specific individuals are
being assigned to the tickets in the process.
This is a for
50 matches
Mail list logo
