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 ?

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


Reply via email to