geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: [jira] Resolved: (GERONIMO-1738) Plugin migration to Maven 2: geronimo-deployment-plugin
Date Thu, 20 Jul 2006 23:46:14 GMT
I agree that the normal practice is to close a defect once its been  
applied to all affected branches.  However, due to work being done in  
a single branch, I personally don't see a problem with closing out  
the subtasks to be able to get a much accurate indicator of m2  
status.  Are all of M2 tasks under one parent and fixed versions  
marked targeted to the single branch? If so, what is wrong with  
keeping the just the parent defect open until all of the m2 changes  
have been pushed to trunk?  Once the work in trunk begins, we can re- 
open and retarget them if necessary.

Jacek, I agree with what you said but we're in desperate need of  
scrubbing all of our open jiras, some of which have been open for  
years, so we're currently not exactly giving our users an accurate  
indicator on project status anyways.   So my feeling is, as long as  
these m2 defects are being worked in this branch go ahead and close  
them out.

-sachin

On Jul 20, 2006, at 4:19 PM, Jason Dillon wrote:

>>> We were finding it difficult to manage the subtasks with all of them
>>> being in the "open" state even when their patches had been applied.
>>
>> Did they? Where? How can the end users find the information? I don't
>> think it's that clear for newcomers, especially.
>
> Dude... this is a special case, many of us have talked about over  
> and over.  This would should have been done on trunk, but from lack  
> of support from the PMC to get that done we have been forced to  
> work on a branch.
>
> So, I'd say that newcomers are already a little mystified as to  
> what is going on and I do not think that by simply resolving a few  
> JIRA issues that we have not completely baffled them into a  
> stupor.  Most of the issues have comments to show what is going on  
> and most have Subversion details showing exactly what has changed,  
> where, when and by whom.
>
>
>>> How is this different than all the other subtasks under 2071 that  
>>> have
>>> gone into m2migration branch and thus has been marked resolved ?
>>> Example: http://issues.apache.org/jira/browse/GERONIMO-2201
>>
>> I'd say it's yet another example of us managing jira issues in an
>> uncontrolled way. Say, we don't apply the patches to the trunk before
>> 1.2 is released. Will you remember to correct it in jira? It will go
>> to the release notes of 1.2, but won't be there. I don't think we  
>> want
>> it, do we?
>
> DUDE!!!! Again, this is not the norm... please don't try to lump up  
> the special-case m2 work (which is most certainly going to be in  
> 1.2 by the time we cut that release) with all other work that is  
> going on... or will go on.
>
>
>>> It has been discussed on the devlist that m2 migration work would be
>>> in the m2migration branch. So end-users would know where to  
>>> expect it
>>> and hopefully wouldn't/shouldn't go looking for it in the trunk.
>>
>> There're tons of emails every day and you expect people will follow
>> it? Ok, you might be right - they could follow the mailing list which
>> requires artifical skills, imho ;-) So, what's your opinion about
>> jira? Should it complement what we're doing or it introduces a burden
>> in our development process?
>
> I expect that the people involved with the m2 migration to follow  
> the flow of messages related to that work... yes I do.
>
> JIRA should at all times complement the development process...
>
> And it is my opinion that right now that the best way to complement  
> the work we are doing wrt m2 migration is to resolve issues that  
> have been committed (and verified good) to m2migration.
>
>
>>> I'd like to learn something new everyday. So I don't mind being
>>> corrected and advised on how we can better manage this. Any other
>>> suggestions ?
>>
>> Sure, me too. Think about us and how much we need to remember as it's
>> not written anywhere. If we start losing control on what we're doing,
>> we'll lose users' patience and they'll fly away. I think misleading
>> information (like creating a report of what's been fixed between 1.1
>> and today) are worse than lack of any.
>>
>> Of course, I may be mistaken, but regardless of where we'll end up
>> eventually I appreciate your reasoning and patience with bearing with
>> me :-)
>
> Come on Jacek... lets try to keep things simple while we work  
> through this painful conversion.
>
> It seems like every chance you get you want to inject more policy  
> and procedure that will slow down this work.
>
> Lets just get this over and down with... we are very close.
>
> Anyways, if the rest of the PMC would like to comment on this...  
> and if there is agreement then we can re-open these issues.
>
> I think doing so will only make it harder for those of us actually  
> working on the problem to resolve and it will certainly confuse  
> others more as to what is really going on.
>
> --jason


-sachin



Mime
View raw message