Hi...
Well, JIRA management is up to the development team. But IMHO as a
good practice:
1- If someone started to work on an issue
1.1- He/She assigns it to him/her
2.1- Mark it as in progress
3- When finished
3.1- If He/She is already a committer it cab be resolved and then closed
3.2- If not, then attach a patch, *only* resolve so when it is
reviewed and the patch is applied it is closed by the reviewer.
As a general good practice
1- *always* use commit messages
1.1- In the commit message it is always better to be in that format:
JIRA-NUMBER1: Details
JIRA-NUMBER2: Details
Notice that one commit can have more than one JIRA related work.
2- Also *recommended* that JIRA(s) are commented with revision
number(s) into which related work has been committed.
> Johnathan
>
>
> On Tue, 2011-08-02 at 13:46 +0100, [email protected] wrote:
>> Patches are indeed a pain, so I would also be happy to work with CTR in
>> general.
>>
>> > Good thing you brought this up. I think we should go with CTR. We have
>> > already experienced problems with patches that gets outdated very fast.
>> > Manual rebasing is time wasting, error prone and extremely boring :) .
>> >
>> > // Roger
>> >
>> >
>> > On Aug 2, 2011, at 2:36 PM, Emmanuel Lecharny wrote:
>> >
>> >> Hi guys,
>> >>
>> >> now that you have commit access, I think it's a better solution to apply
>> >> your modification directly in the code base. Attaching patches to JIRA
>> >> is good, but it forces someone to apply them.
>> >>
>> >> If you'd like to discuss a proposed patch, then the best is to attach
>> >> the patch to a mail and start a discussion.
>> >>
>> >> Now, it's up to you. In fact, you have two options when it comes to
>> >> commits :
>> >> - c-t-r (commit-then-review)
>> >> - r-t-c (review then-commit)
>> >>
>> >> The first option is considered as the standard politic at Apache. Most
>> >> of the project just let people commit, then eventually review the
>> >> patches. It assumes than a -1 (veto) on a commit requires a reverse and
>> >> a discussion should then be started. Vetoing a commit is not an insult,
>> >> it's just a way to say that there might be an issue with the commit.
>> >>
>> >> The second option is used in mature projects (like httpd) which simply
>> >> can't accept a breakage. I'm not sure that deft is old nor stable enough
>> >> :)
>> >>
>> >> Keep in mind that what is important here is to ease the development
>> >> process, and as it seems you are very active, one way to avoid conflicts
>> >> (I mean, code breakage, not fights between people ;) is to split the
>> >> code in modules, with committers working on separate modules. In other
>> >> words, decoupling.
>> >>
>> >> This is just an advice, again, your choice :)
>> >>
>> >> --
>> >> Regards,
>> >> Cordialement,
>> >> Emmanuel Lécharny
>> >> www.iktek.com
>> >>
>> >
>> >
>>
>>
>
>
>
--
Thanks
- Mohammad Nour
Author of (WebSphere Application Server Community Edition 2.0 User Guide)
http://www.redbooks.ibm.com/abstracts/sg247585.html
- LinkedIn: http://www.linkedin.com/in/mnour
- Blog: http://tadabborat.blogspot.com
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
"Writing clean code is what you must do in order to call yourself a
professional. There is no reasonable excuse for doing anything less
than your best."
- Clean Code: A Handbook of Agile Software Craftsmanship
"Stay hungry, stay foolish."
- Steve Jobs
