Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 03 Jan 2007 11:19:27 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: new site added to SVN and published
In-reply-to: <AF01ACC6-3E1F-4AFA-BD3C-A6E8B50237DE@pobox.com>
Sender: Craig.Russell@Sun.COM
To: river-dev@incubator.apache.org
Message-id: <18ACD27E-A935-4704-ADA2-9C12148ECE37@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-22-566207862; micalg=sha1
References: <71A27A98-689D-4A83-A7A8-73040DCBBBB7@pobox.com>
 <8a81b4af0701022037y17cda7d6t1db3c889ee5224d@mail.gmail.com>
 <73FA91BC-771F-4159-AE72-C77E7B79578C@pobox.com>
 <459BA463.2080300@cheiron.org>
 <35F184C7-BD48-4FC1-90CB-CAC81A986C47@pobox.com>
 <459BB4F1.3090407@cheiron.org>
 <EF2DCC96-F30D-43FD-B28B-0C05710D20A9@pobox.com> <459BCBB8.60701@cheiron.org>
 <AF01ACC6-3E1F-4AFA-BD3C-A6E8B50237DE@pobox.com>

--Apple-Mail-22-566207862
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Jan 3, 2007, at 9:25 AM, Geir Magnusson Jr. wrote:

>
> On Jan 3, 2007, at 10:28 AM, Mark Brouwer wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>>> I disagree. For cheiron.org I do most of the work myself, but
>>>> nevertheless anything substantial is going through JIRA if it  
>>>> was only
>>>> to keep track of things done for the release notes. Especially  
>>>> when you
>>>> already have a stable codebase gradually improving and getting
>>>> bug-fixed. But I admit with complete new projects I tend to be less
>>>> bureaucratic.
>>> Do you mean
>>> a) you make all the changes, make a patch, submit it to JIRA,  
>>> download the patch, apply the patch to a fresh tree, and then commit
>>
>> Not exactly. I work either on the main codeline or in some version
>> branch, but not before there is an JIRA issue created for the  
>> task, bug
>> or improvement at hand. The JIRA issue is sent to the developer  
>> mailing
>> list (no seperate list for generated artifacts) so other interested
>> people can see whether they think the issue is relevant or not.
>
> I see
>
>>
>> When I start working on it, JIRA sends a message to the dev list so
>> people know I'm about to start coding.

JIRA is nice in that any change of status of an issue gets sent to  
the distribution. It's a matter of discipline that committers  
actually use JIRA to "start an issue" so the notices get sent.

>> After I check in my code
>> directly into the repository I resolve the issue which leads to a  
>> post
>> from JIRA to the dev list. In case of commit before review I  
>> suggest one
>> waits a while with resolving the issue.

Both JIRA and svn will generate notices to the rest of the team.
>>
>> No patches are submitted to JIRA, for those that have no commit  
>> rights I
>> also think that sending the patch to the dev list is the best  
>> thing to
>> do. No need to attach that one to the isse. When the patch is  
>> accepted
>> and committed by one of the committers the issue can be resolved.
>
> That's one thing you may want to modify - ask that patches are  
> posted to the JIRA, as it requires the submitter to explicitly  
> acknowledge that the stuff is contributed under the terms of the  
> Apache License.  Keeps any questions about what's a contribution to  
> a minimum...

This is a very important part of the Apache Way. Contributors really  
should sign CLAs which legally binds contributions. The tick box on  
JIRA attachments also reminds folks that the patch is in fact a  
contribution.
>
>>
>> I realize this won't work exactly the same way as for the projects  
>> I'm
>> working on, but still hope to see maybe a somewhat more formal way of
>> working or at least for some parts of the project.
>
> It's up to you guys.
>
>>
>>> b) note changes in JIRA afterwards
>>
>> Or during the process of receiving patches, discussing and  
>> committing them.
>>
>>> c) something else?
>>> I think b) is fine, if you are simply looking for a change  
>>> tracking tool, although if you build a decent commit message  
>>> discipline into the community, you can also just ask SVN what  
>>> changed between releases...  and that should be far more accurate.
>>
>> Often it requires multiple changes to the code for the same issue  
>> before
>> everybody is happy (I think/hope this will be a very picky  
>> community :-)

JIRA works well for this case as well. I like to have code uploaded  
to JIRA instead of scouring emails for patches. JIRA allows you to  
replace a patch with "the latest" code in progress, and it's easy for  
reviewers to apply the patch and comment, iterating on the proposed  
fix before svn commit.

>> and I admit I'm an infant with SVN (Perforce addict) but wouldn't a
>> report generated by SVN contain a lot of clutter in that case.  
>> Also for
>> release notes I really like the issue description instead of the
>> comments people in general use for their commit.

I agree. Once an issue has been beaten to death on JIRA, the commit  
message can be relatively brief. commit -m "RIVER-123 added  
snarfgargle to mediation requests" src/java

>>
>> If I recall correctly the Jini team didn't write a single character
>> before there was an issue in their tracking system. I adopted this  
>> style
>> and found it worth while on a rather stable codebase. I'm curious to
>> know what the others think of this.

I like this approach as well. I've seen both discuss on the dev alias  
and discuss on the JIRA issue work well, so this is a matter for the  
team to work on. It might not even be necessary to formalize where  
the discussion takes place. Some people like having it all on the  
JIRA issue; some prefer to follow threaded discussions on aliases.

But basically having a JIRA to track all code changes is a statement  
of formality that should be agreed by the community.
>>
>> And maybe I'm completely out of bounds here but I think that even  
>> some
>> form of issue planning (in what version to expect what) can be
>> beneficial as well, JIRA is great for that too.
>
> Yep.  It is.  But be careful to keep things as open and welcoming  
> to volunteers.  Rigid process is off-putting to some people.
>>
>>>>> JIRA is great for tracking, but there are things to be cautious  
>>>>> of -  I've experienced technical discussion moving into the  
>>>>> JIRA itself, which I think is not good, because it loses the  
>>>>> bigger audience (IMO).  I hate having to read JIRA discussions  
>>>>> on the JIRA-generated emails, and it makes it hard to  
>>>>> participate offline (unlike email) or search (unlike email...)
>>>>
>>>> I'm aware of that but in case of tasks to be implemented  
>>>> somewhere in
>>>> the future I like to see any conclusions of discussion in JIRA  
>>>> versus
>>>> digging them from my email archive.
>>> That's fine - that's a good use of JIRA.  But you can simply just  
>>> put a URL to the mail archive in the JIRA...  easy to find later.
>>
>> That is possible, but I'm inclined to describe the summary of such an
>> issue neatly in JIRA. But as I've not that much experience with  
>> working
>> in an ASF style project opposed to playing a dictator I really don't
>> know what will work the best.

Well, this should be interesting. There are a wide range of working  
styles in Apache projects that depends a lot on the community who are  
actively working on the project. It might be good to propose some of  
the guidelines as updates to the site and see what people think. That  
way, it's not just talk; it's proposed action.

Craig

>> -- 
>> Mark
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-22-566207862
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw
NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7
16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg
Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc
a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr
jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym
bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt
/CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6
eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTAzMTkxOTI4WjAjBgkqhkiG9w0B
CQQxFgQUhTCXyNvewhZVsrGU2Kbh1yOaHjQwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq
SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAKpjClUwu868prfQPbLrOYiCoEAReiys
2OE7+ZTNfvKKU20189caNJg0ShwOxhODQEGKgC6IahCH2LlSW7luLubE47iLq5Za2uG9ZZRIBOtw
kQwr5jf4mqJmtY4alRo3w8KNJMqgYBJ0SFGp7oWWB+4ur9hn6wAQjx7/k4xu5uoJ9VajPSkYZJkZ
WmA4/Ni/AeATWT3D2aFbjFtUpYSMZ8mkUlcN1lHpvZombdORzjDL4plKsHKr2f2wNbGgJiRqLkBv
fJKzVd3MrTy+6gT9viqnCwXkIltdyTLs1hj5KZ++vcMZTXZdkg1LDJsOtCQTpSQGHm4nOWtCDjX4
P6ckwUMAAAAAAAA=

--Apple-Mail-22-566207862--