Fwd: What do we need to establish?

[Deng Ching-2]

---------- Forwarded message ----------
From: Brett Porter <brett@...>
Date: Wed, May 7, 2008 at 2:37 PM
Subject: Re: What do we need to establish?
To: private@...



On 07/05/2008, at 4:04 PM, Maria Odea Ching wrote:

 Hi Everyone,
>
> I thought I'd start a thread to discuss the things we need to establish
> for
> Archiva :-) I've made a rough list of things which we could start on..
>

Great idea... we've pseudo adopted the Maven stuff but it might be a good
time to review and formalise so everyone is in agreement :)

>
> 1. Rules/Conventions/Guides
>   - When applying patches
>   - Releasing
>   - Codestyles
>   - Commit message template
>
> 2. Voting Process
>
> We might not need to establish all of these, I just put everything in the
> list that I thought we might cover.
> Any thoughts or additions? :-)
>

Maybe when to use private@ :) I know this hits the right group, but we're
all on dev@ too. Maybe we should post this there instead?

- Brett


>
>
> Thanks,
> Deng
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Deng Ching-2]

Maybe we could start with the release procedure?

This is what we currently have:
http://cwiki.apache.org/ARCHIVA/archiva-release-process.html

It's basically adopted from Maven's release procedure.
Does anyone think the 72 hrs. voting time is not enough for testing the
release? Or there's something wrong with the ordering of the process that we
have now? Thoughts, anyone? :-)

-Deng


On Wed, May 7, 2008 at 2:50 PM, Maria Odea Ching <oching@...> wrote:

>
>
> ---------- Forwarded message ----------
> From: Brett Porter <brett@...>
> Date: Wed, May 7, 2008 at 2:37 PM
> Subject: Re: What do we need to establish?
> To: private@...
>
>
>
> On 07/05/2008, at 4:04 PM, Maria Odea Ching wrote:
>
>  Hi Everyone,
>>
>> I thought I'd start a thread to discuss the things we need to establish
>> for
>> Archiva :-) I've made a rough list of things which we could start on..
>>
>
> Great idea... we've pseudo adopted the Maven stuff but it might be a good
> time to review and formalise so everyone is in agreement :)
>
>
>>
>> 1. Rules/Conventions/Guides
>>   - When applying patches
>>   - Releasing
>>   - Codestyles
>>   - Commit message template
>>
>> 2. Voting Process
>>
>> We might not need to establish all of these, I just put everything in the
>> list that I thought we might cover.
>> Any thoughts or additions? :-)
>>
>
> Maybe when to use private@ :) I know this hits the right group, but we're
> all on dev@ too. Maybe we should post this there instead?
>
> - Brett
>
>
>>
>>
>> Thanks,
>> Deng
>>
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/
>
>
>

[Wendy Smoak-3]

On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...> wrote:

>  This is what we currently have:
>  http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>
>  It's basically adopted from Maven's release procedure.
>  Does anyone think the 72 hrs. voting time is not enough for testing the
>  release? Or there's something wrong with the ordering of the process that we
>  have now? Thoughts, anyone? :-)

72 hours is the minimum, the RM can decide to wait longer (especially
if someone asks for more time.)  The process will evolve, I'm not
concerned with getting every step exactly right, as long as the end
result is the same.

I'd like to see an announcement a couple of days prior to the tag.
Nothing formal, essentially what James did, letting us know he's
planning on a release this weekend.  A tag should not be a surprise to
anyone who is watching the dev list.

I'd also like to discuss versioning.  I"m not a fan of baking the
quality into the version number (as 1.1-beta-1).  My preference is
that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
doesn't pass a vote, we discard it and move on.  Quality is determined
after the release distribution exists, during the vote. (This is the
httpd/Tomcat/Struts style of releasing.)

--
Wendy

[James William Dumay]

On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:

> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>  
> wrote:
>
>> This is what we currently have:
>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>
>> It's basically adopted from Maven's release procedure.
>> Does anyone think the 72 hrs. voting time is not enough for testing  
>> the
>> release? Or there's something wrong with the ordering of the  
>> process that we
>> have now? Thoughts, anyone? :-)
>
> 72 hours is the minimum, the RM can decide to wait longer (especially
> if someone asks for more time.)  The process will evolve, I'm not
> concerned with getting every step exactly right, as long as the end
> result is the same.

+1

>
>
> I'd like to see an announcement a couple of days prior to the tag.
> Nothing formal, essentially what James did, letting us know he's
> planning on a release this weekend.  A tag should not be a surprise to
> anyone who is watching the dev list.

+1

>
>
> I'd also like to discuss versioning.  I"m not a fan of baking the
> quality into the version number (as 1.1-beta-1).  My preference is
> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
> doesn't pass a vote, we discard it and move on.  Quality is determined
> after the release distribution exists, during the vote. (This is the
> httpd/Tomcat/Struts style of releasing.)

Thats an interesting point Wendy. With Confluence we decided that most  
of the versioning should not be done, as you said, with baking in the  
relative quality of the release but  on the progress of the final  
product.

I think the idea is that released versions encourage our more involved  
users into trying out incremental builds so we can catch problems  
before the final.

I would be in favor of having more frequent releases of trunk once  
certain milestones are met. Users who test those builds will then know  
exactly what changes they are in for.

>
>
> --
> Wendy


On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:

> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>  
> wrote:
>
>> This is what we currently have:
>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>
>> It's basically adopted from Maven's release procedure.
>> Does anyone think the 72 hrs. voting time is not enough for testing  
>> the
>> release? Or there's something wrong with the ordering of the  
>> process that we
>> have now? Thoughts, anyone? :-)
>
> 72 hours is the minimum, the RM can decide to wait longer (especially
> if someone asks for more time.)  The process will evolve, I'm not
> concerned with getting every step exactly right, as long as the end
> result is the same.

+1

>
>
> I'd like to see an announcement a couple of days prior to the tag.
> Nothing formal, essentially what James did, letting us know he's
> planning on a release this weekend.  A tag should not be a surprise to
> anyone who is watching the dev list.

+1

>
>
> I'd also like to discuss versioning.  I"m not a fan of baking the
> quality into the version number (as 1.1-beta-1).  My preference is
> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
> doesn't pass a vote, we discard it and move on.  Quality is determined
> after the release distribution exists, during the vote. (This is the
> httpd/Tomcat/Struts style of releasing.)

Thats an interesting point Wendy. With Confluence we decided that most  
of the versioning should not be done, as you said, with baking in the  
relative quality of the release but  on the progress of the final  
product.

I think the idea is that released versions encourage our more involved  
users into trying out incremental builds so we can catch problems  
before the final.

I would be in favor of having more frequent releases of trunk once  
certain milestones are met. Users who test those builds will then know  
exactly what changes they are in for.

>
>
> --
> Wendy

[James William Dumay]

Forgot to add: I propose that the next release of Archiva will be 1.1-
milestone1. As each major feature is completed, we increment that  
number and the last milestone becomes 1.1.0.

James

On 10/05/2008, at 4:21 PM, James William Dumay wrote:

>
> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>
>> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching  
>> <oching@...> wrote:
>>
>>> This is what we currently have:
>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>
>>> It's basically adopted from Maven's release procedure.
>>> Does anyone think the 72 hrs. voting time is not enough for  
>>> testing the
>>> release? Or there's something wrong with the ordering of the  
>>> process that we
>>> have now? Thoughts, anyone? :-)
>>
>> 72 hours is the minimum, the RM can decide to wait longer (especially
>> if someone asks for more time.)  The process will evolve, I'm not
>> concerned with getting every step exactly right, as long as the end
>> result is the same.
>
> +1
>
>>
>>
>> I'd like to see an announcement a couple of days prior to the tag.
>> Nothing formal, essentially what James did, letting us know he's
>> planning on a release this weekend.  A tag should not be a surprise  
>> to
>> anyone who is watching the dev list.
>
> +1
>
>>
>>
>> I'd also like to discuss versioning.  I"m not a fan of baking the
>> quality into the version number (as 1.1-beta-1).  My preference is
>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>> doesn't pass a vote, we discard it and move on.  Quality is  
>> determined
>> after the release distribution exists, during the vote. (This is the
>> httpd/Tomcat/Struts style of releasing.)
>
> Thats an interesting point Wendy. With Confluence we decided that  
> most of the versioning should not be done, as you said, with baking  
> in the relative quality of the release but  on the progress of the  
> final product.
>
> I think the idea is that released versions encourage our more  
> involved users into trying out incremental builds so we can catch  
> problems before the final.
>
> I would be in favor of having more frequent releases of trunk once  
> certain milestones are met. Users who test those builds will then  
> know exactly what changes they are in for.
>
>>
>>
>> --
>> Wendy
>
>
> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>
>> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching  
>> <oching@...> wrote:
>>
>>> This is what we currently have:
>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>
>>> It's basically adopted from Maven's release procedure.
>>> Does anyone think the 72 hrs. voting time is not enough for  
>>> testing the
>>> release? Or there's something wrong with the ordering of the  
>>> process that we
>>> have now? Thoughts, anyone? :-)
>>
>> 72 hours is the minimum, the RM can decide to wait longer (especially
>> if someone asks for more time.)  The process will evolve, I'm not
>> concerned with getting every step exactly right, as long as the end
>> result is the same.
>
> +1
>
>>
>>
>> I'd like to see an announcement a couple of days prior to the tag.
>> Nothing formal, essentially what James did, letting us know he's
>> planning on a release this weekend.  A tag should not be a surprise  
>> to
>> anyone who is watching the dev list.
>
> +1
>
>>
>>
>> I'd also like to discuss versioning.  I"m not a fan of baking the
>> quality into the version number (as 1.1-beta-1).  My preference is
>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>> doesn't pass a vote, we discard it and move on.  Quality is  
>> determined
>> after the release distribution exists, during the vote. (This is the
>> httpd/Tomcat/Struts style of releasing.)
>
> Thats an interesting point Wendy. With Confluence we decided that  
> most of the versioning should not be done, as you said, with baking  
> in the relative quality of the release but  on the progress of the  
> final product.
>
> I think the idea is that released versions encourage our more  
> involved users into trying out incremental builds so we can catch  
> problems before the final.
>
> I would be in favor of having more frequent releases of trunk once  
> certain milestones are met. Users who test those builds will then  
> know exactly what changes they are in for.
>
>>
>>
>> --
>> Wendy
>

Forgot to add: I propose that the next release of Archiva will be 1.1-
milestone1. As each major feature is completed, we increment that  
number and the last milestone becomes 1.1.0.

James

On 10/05/2008, at 4:21 PM, James William Dumay wrote:

>
> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>
>> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching  
>> <oching@...> wrote:
>>
>>> This is what we currently have:
>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>
>>> It's basically adopted from Maven's release procedure.
>>> Does anyone think the 72 hrs. voting time is not enough for  
>>> testing the
>>> release? Or there's something wrong with the ordering of the  
>>> process that we
>>> have now? Thoughts, anyone? :-)
>>
>> 72 hours is the minimum, the RM can decide to wait longer (especially
>> if someone asks for more time.)  The process will evolve, I'm not
>> concerned with getting every step exactly right, as long as the end
>> result is the same.
>
> +1
>
>>
>>
>> I'd like to see an announcement a couple of days prior to the tag.
>> Nothing formal, essentially what James did, letting us know he's
>> planning on a release this weekend.  A tag should not be a surprise  
>> to
>> anyone who is watching the dev list.
>
> +1
>
>>
>>
>> I'd also like to discuss versioning.  I"m not a fan of baking the
>> quality into the version number (as 1.1-beta-1).  My preference is
>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>> doesn't pass a vote, we discard it and move on.  Quality is  
>> determined
>> after the release distribution exists, during the vote. (This is the
>> httpd/Tomcat/Struts style of releasing.)
>
> Thats an interesting point Wendy. With Confluence we decided that  
> most of the versioning should not be done, as you said, with baking  
> in the relative quality of the release but  on the progress of the  
> final product.
>
> I think the idea is that released versions encourage our more  
> involved users into trying out incremental builds so we can catch  
> problems before the final.
>
> I would be in favor of having more frequent releases of trunk once  
> certain milestones are met. Users who test those builds will then  
> know exactly what changes they are in for.
>
>>
>>
>> --
>> Wendy
>
>
> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>
>> On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching  
>> <oching@...> wrote:
>>
>>> This is what we currently have:
>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>
>>> It's basically adopted from Maven's release procedure.
>>> Does anyone think the 72 hrs. voting time is not enough for  
>>> testing the
>>> release? Or there's something wrong with the ordering of the  
>>> process that we
>>> have now? Thoughts, anyone? :-)
>>
>> 72 hours is the minimum, the RM can decide to wait longer (especially
>> if someone asks for more time.)  The process will evolve, I'm not
>> concerned with getting every step exactly right, as long as the end
>> result is the same.
>
> +1
>
>>
>>
>> I'd like to see an announcement a couple of days prior to the tag.
>> Nothing formal, essentially what James did, letting us know he's
>> planning on a release this weekend.  A tag should not be a surprise  
>> to
>> anyone who is watching the dev list.
>
> +1
>
>>
>>
>> I'd also like to discuss versioning.  I"m not a fan of baking the
>> quality into the version number (as 1.1-beta-1).  My preference is
>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>> doesn't pass a vote, we discard it and move on.  Quality is  
>> determined
>> after the release distribution exists, during the vote. (This is the
>> httpd/Tomcat/Struts style of releasing.)
>
> Thats an interesting point Wendy. With Confluence we decided that  
> most of the versioning should not be done, as you said, with baking  
> in the relative quality of the release but  on the progress of the  
> final product.
>
> I think the idea is that released versions encourage our more  
> involved users into trying out incremental builds so we can catch  
> problems before the final.
>
> I would be in favor of having more frequent releases of trunk once  
> certain milestones are met. Users who test those builds will then  
> know exactly what changes they are in for.
>
>>
>>
>> --
>> Wendy
>

[Deng Ching-2]

Sounds good to me.. I just prefer the final version to 1.1 instead of 1.1.0
(i'm just being vain) :-)

-Deng

On Sat, May 10, 2008 at 2:38 PM, James William Dumay <james@...>
wrote:

> Forgot to add: I propose that the next release of Archiva will be
> 1.1-milestone1. As each major feature is completed, we increment that number
> and the last milestone becomes 1.1.0.
>
> James
>
>
> On 10/05/2008, at 4:21 PM, James William Dumay wrote:
>
>
>> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>>
>>  On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>
>>> wrote:
>>>
>>>  This is what we currently have:
>>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>>
>>>> It's basically adopted from Maven's release procedure.
>>>> Does anyone think the 72 hrs. voting time is not enough for testing the
>>>> release? Or there's something wrong with the ordering of the process
>>>> that we
>>>> have now? Thoughts, anyone? :-)
>>>>
>>>
>>> 72 hours is the minimum, the RM can decide to wait longer (especially
>>> if someone asks for more time.)  The process will evolve, I'm not
>>> concerned with getting every step exactly right, as long as the end
>>> result is the same.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd like to see an announcement a couple of days prior to the tag.
>>> Nothing formal, essentially what James did, letting us know he's
>>> planning on a release this weekend.  A tag should not be a surprise to
>>> anyone who is watching the dev list.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd also like to discuss versioning.  I"m not a fan of baking the
>>> quality into the version number (as 1.1-beta-1).  My preference is
>>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>>> doesn't pass a vote, we discard it and move on.  Quality is determined
>>> after the release distribution exists, during the vote. (This is the
>>> httpd/Tomcat/Struts style of releasing.)
>>>
>>
>> Thats an interesting point Wendy. With Confluence we decided that most of
>> the versioning should not be done, as you said, with baking in the relative
>> quality of the release but  on the progress of the final product.
>>
>> I think the idea is that released versions encourage our more involved
>> users into trying out incremental builds so we can catch problems before the
>> final.
>>
>> I would be in favor of having more frequent releases of trunk once certain
>> milestones are met. Users who test those builds will then know exactly what
>> changes they are in for.
>>
>>
>>>
>>> --
>>> Wendy
>>>
>>
>>
>> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>>
>>  On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>
>>> wrote:
>>>
>>>  This is what we currently have:
>>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>>
>>>> It's basically adopted from Maven's release procedure.
>>>> Does anyone think the 72 hrs. voting time is not enough for testing the
>>>> release? Or there's something wrong with the ordering of the process
>>>> that we
>>>> have now? Thoughts, anyone? :-)
>>>>
>>>
>>> 72 hours is the minimum, the RM can decide to wait longer (especially
>>> if someone asks for more time.)  The process will evolve, I'm not
>>> concerned with getting every step exactly right, as long as the end
>>> result is the same.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd like to see an announcement a couple of days prior to the tag.
>>> Nothing formal, essentially what James did, letting us know he's
>>> planning on a release this weekend.  A tag should not be a surprise to
>>> anyone who is watching the dev list.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd also like to discuss versioning.  I"m not a fan of baking the
>>> quality into the version number (as 1.1-beta-1).  My preference is
>>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>>> doesn't pass a vote, we discard it and move on.  Quality is determined
>>> after the release distribution exists, during the vote. (This is the
>>> httpd/Tomcat/Struts style of releasing.)
>>>
>>
>> Thats an interesting point Wendy. With Confluence we decided that most of
>> the versioning should not be done, as you said, with baking in the relative
>> quality of the release but  on the progress of the final product.
>>
>> I think the idea is that released versions encourage our more involved
>> users into trying out incremental builds so we can catch problems before the
>> final.
>>
>> I would be in favor of having more frequent releases of trunk once certain
>> milestones are met. Users who test those builds will then know exactly what
>> changes they are in for.
>>
>>
>>>
>>> --
>>> Wendy
>>>
>>
>>
> Forgot to add: I propose that the next release of Archiva will be
> 1.1-milestone1. As each major feature is completed, we increment that number
> and the last milestone becomes 1.1.0.
>
> James
>
>
> On 10/05/2008, at 4:21 PM, James William Dumay wrote:
>
>
>> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>>
>>  On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>
>>> wrote:
>>>
>>>  This is what we currently have:
>>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>>
>>>> It's basically adopted from Maven's release procedure.
>>>> Does anyone think the 72 hrs. voting time is not enough for testing the
>>>> release? Or there's something wrong with the ordering of the process
>>>> that we
>>>> have now? Thoughts, anyone? :-)
>>>>
>>>
>>> 72 hours is the minimum, the RM can decide to wait longer (especially
>>> if someone asks for more time.)  The process will evolve, I'm not
>>> concerned with getting every step exactly right, as long as the end
>>> result is the same.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd like to see an announcement a couple of days prior to the tag.
>>> Nothing formal, essentially what James did, letting us know he's
>>> planning on a release this weekend.  A tag should not be a surprise to
>>> anyone who is watching the dev list.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd also like to discuss versioning.  I"m not a fan of baking the
>>> quality into the version number (as 1.1-beta-1).  My preference is
>>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>>> doesn't pass a vote, we discard it and move on.  Quality is determined
>>> after the release distribution exists, during the vote. (This is the
>>> httpd/Tomcat/Struts style of releasing.)
>>>
>>
>> Thats an interesting point Wendy. With Confluence we decided that most of
>> the versioning should not be done, as you said, with baking in the relative
>> quality of the release but  on the progress of the final product.
>>
>> I think the idea is that released versions encourage our more involved
>> users into trying out incremental builds so we can catch problems before the
>> final.
>>
>> I would be in favor of having more frequent releases of trunk once certain
>> milestones are met. Users who test those builds will then know exactly what
>> changes they are in for.
>>
>>
>>>
>>> --
>>> Wendy
>>>
>>
>>
>> On 10/05/2008, at 1:45 AM, Wendy Smoak wrote:
>>
>>  On Fri, May 9, 2008 at 1:19 AM, Maria Odea Ching <oching@...>
>>> wrote:
>>>
>>>  This is what we currently have:
>>>> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>>>>
>>>> It's basically adopted from Maven's release procedure.
>>>> Does anyone think the 72 hrs. voting time is not enough for testing the
>>>> release? Or there's something wrong with the ordering of the process
>>>> that we
>>>> have now? Thoughts, anyone? :-)
>>>>
>>>
>>> 72 hours is the minimum, the RM can decide to wait longer (especially
>>> if someone asks for more time.)  The process will evolve, I'm not
>>> concerned with getting every step exactly right, as long as the end
>>> result is the same.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd like to see an announcement a couple of days prior to the tag.
>>> Nothing formal, essentially what James did, letting us know he's
>>> planning on a release this weekend.  A tag should not be a surprise to
>>> anyone who is watching the dev list.
>>>
>>
>> +1
>>
>>
>>>
>>> I'd also like to discuss versioning.  I"m not a fan of baking the
>>> quality into the version number (as 1.1-beta-1).  My preference is
>>> that the next release is 1.1 (or 1.1.0) and then 1.1.1, 1.1.2.  If it
>>> doesn't pass a vote, we discard it and move on.  Quality is determined
>>> after the release distribution exists, during the vote. (This is the
>>> httpd/Tomcat/Struts style of releasing.)
>>>
>>
>> Thats an interesting point Wendy. With Confluence we decided that most of
>> the versioning should not be done, as you said, with baking in the relative
>> quality of the release but  on the progress of the final product.
>>
>> I think the idea is that released versions encourage our more involved
>> users into trying out incremental builds so we can catch problems before the
>> final.
>>
>> I would be in favor of having more frequent releases of trunk once certain
>> milestones are met. Users who test those builds will then know exactly what
>> changes they are in for.
>>
>>
>>>
>>> --
>>> Wendy
>>>
>>
>>
>

[Wendy Smoak-3]

On Fri, May 9, 2008 at 11:38 PM, James William Dumay
<james@...> wrote:
> Forgot to add: I propose that the next release of Archiva will be
> 1.1-milestone1. As each major feature is completed, we increment that number
> and the last milestone becomes 1.1.0.

Why? What's so special about 1.1?  Version numbers are free, we can
make more.  And there is no marketing department involved here. :)

One of the reasons we made this change for Struts is that it makes no
sense in a volunteer organization to have to re-do a release and vote
(a non-trivial amount of work and time) just to change the filename on
a distribution.  (Assuming 1.1-beta-3 is good, you have to re-do the
process to get it changed to 1.1.)

If it's milestones I'd prefer 1.1-M1 to spelling out milestone.  Or
just go with 1.1-beta-1 since that's what people are used to.

That's it from me, at this point I'll defer to the people actually
doing the work on releases. :)  Anyone else have an opinion?

(And for the record, I was not awake at 1AM. :)  For some reason the
mac didn't shut down when I closed it..)

--
Wendy

[brettporter]

I suggest we take this one to a vote (perhaps Wendy could kick it  
off), with the options:

- Maven style (alpha, beta, final, point release)
- Eclipse style (M1, M2, M3, final, point release - though Eclipse  
don't have the last ones)
- httpd style (.0.0, .0.1, .0.2, .0.3)

And here are my opinions:
- I'm tired of the Maven style. I've heard people actually saying it's  
ok to break things because it's just an alpha. I would rather  
encourage development practices that mean every release should be  
production quality.
- But I'm a realist - releases need broader testing to assess  
production quality.
- milestones seem more akin to a set roadmap per release that gets  
done in stages, rather than timeboxing
- httpd-style can be a little confusing to users, at least at first  
(will the real release please stand up?). I think this is mitigated by  
only putting the final final releases on release repo and mirrors
- httpd-style is not very effective for "milestones", since you end up  
making the 20th or 30th release your first "real" release
- Hudson uses the extreme of the last style (everything is a feature  
release, everything is a final release)

Cheers,
Brett

On 11/05/2008, at 12:01 AM, Wendy Smoak wrote:

> On Fri, May 9, 2008 at 11:38 PM, James William Dumay
> <james@...> wrote:
>> Forgot to add: I propose that the next release of Archiva will be
>> 1.1-milestone1. As each major feature is completed, we increment  
>> that number
>> and the last milestone becomes 1.1.0.
>
> Why? What's so special about 1.1?  Version numbers are free, we can
> make more.  And there is no marketing department involved here. :)
>
> One of the reasons we made this change for Struts is that it makes no
> sense in a volunteer organization to have to re-do a release and vote
> (a non-trivial amount of work and time) just to change the filename on
> a distribution.  (Assuming 1.1-beta-3 is good, you have to re-do the
> process to get it changed to 1.1.)
>
> If it's milestones I'd prefer 1.1-M1 to spelling out milestone.  Or
> just go with 1.1-beta-1 since that's what people are used to.
>
> That's it from me, at this point I'll defer to the people actually
> doing the work on releases. :)  Anyone else have an opinion?
>
> (And for the record, I was not awake at 1AM. :)  For some reason the
> mac didn't shut down when I closed it..)
>
> --
> Wendy

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[brettporter]

On 09/05/2008, at 6:19 PM, Maria Odea Ching wrote:

> Maybe we could start with the release procedure?
>
> This is what we currently have:
> http://cwiki.apache.org/ARCHIVA/archiva-release-process.html
>
> It's basically adopted from Maven's release procedure.
> Does anyone think the 72 hrs. voting time is not enough for testing  
> the
> release? Or there's something wrong with the ordering of the process  
> that we
> have now? Thoughts, anyone? :-)
>

I think this process will evolve, but I think it's fine. I would ask  
that only publicly announc-able, final, releases go to the mirrors and  
repo1, whatever the version scheme we use (we can use  
people.apache.org/builds for the rest).

72 hours is a minimum as Wendy said - I'd leave it up to the person  
doing the release to extend that if they feel it's necessary due to  
the significance of changes.

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[brettporter]

On 07/05/2008, at 4:50 PM, Maria Odea Ching wrote:

>> 1. Rules/Conventions/Guides
>>  - When applying patches
>>  - Commit message template

These are probably related. I think our current habits are good, but  
maybe they need to be written down :)

I also started adding contributors to the parent POM - I hope that's  
something we can continue.

>>
>>  - Codestyles

Something in me wants to say "use the Eclipse default so the patches  
are always right" :)

Honestly, I don't care about this any more, as long as it is  
consistent, can be checked in checkstyle, can be formatted in Eclipse,  
IDEA and NetBeans.

The things I do care about:
- spaces, not tabs
- 4 spaces for Java
- 2 spaces for XML
- 120 column wrap, not 80.
- wrap on spaces, not on '.' in a method call

:)

>>
>>
>> 2. Voting Process
>>

I think we pretty much follow the Apache guidelines here, so we can  
stick to that. May be worth documenting some things specifically though.

So, who wants to start a "how we do things" page on the site that we  
can grow over time? :)

Cheers,
Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Maria Odea Ching-2]

Brett Porter wrote:

>
> On 07/05/2008, at 4:50 PM, Maria Odea Ching wrote:
>
>>> 1. Rules/Conventions/Guides
>>> - When applying patches
>>> - Commit message template
>
> These are probably related. I think our current habits are good, but
> maybe they need to be written down :)
>
> I also started adding contributors to the parent POM - I hope that's
> something we can continue.
>
>>>
>>> - Codestyles
>
> Something in me wants to say "use the Eclipse default so the patches
> are always right" :)
>
> Honestly, I don't care about this any more, as long as it is
> consistent, can be checked in checkstyle, can be formatted in Eclipse,
> IDEA and NetBeans.
>
> The things I do care about:
> - spaces, not tabs
> - 4 spaces for Java
> - 2 spaces for XML
> - 120 column wrap, not 80.
> - wrap on spaces, not on '.' in a method call
>
> :)
>
>>>
>>>
>>> 2. Voting Process
>>>
>
> I think we pretty much follow the Apache guidelines here, so we can
> stick to that. May be worth documenting some things specifically though.
>
> So, who wants to start a "how we do things" page on the site that we
> can grow over time? :)

I can start writing this up :-)

>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@...
> http://blogs.exist.com/bporter/

Thanks,
Deng

[Wendy Smoak-3]

On Sat, May 10, 2008 at 1:15 PM, Brett Porter <brett@...> wrote:
> I suggest we take this one to a vote (perhaps Wendy could kick it off), with
> the options:
>
> - Maven style (alpha, beta, final, point release)
> - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't
> have the last ones)
> - httpd style (.0.0, .0.1, .0.2, .0.3)

Do we need a vote?  I'm pretty sure the consensus is milestones ->
final -> patch releases.  Maybe more Spring than Eclipse?

1.1-M1,  1.1-M2,  1.1,  1.1.1,  1.1.2

Works for me. :)  Any objections?

--
Wendy

[Deng Ching-2]

Fine with me too :)

-Deng

On Sun, May 11, 2008 at 12:46 PM, Wendy Smoak <wsmoak@...> wrote:

> On Sat, May 10, 2008 at 1:15 PM, Brett Porter <brett@...> wrote:
> > I suggest we take this one to a vote (perhaps Wendy could kick it off),
> with
> > the options:
> >
> > - Maven style (alpha, beta, final, point release)
> > - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't
> > have the last ones)
> > - httpd style (.0.0, .0.1, .0.2, .0.3)
>
> Do we need a vote?  I'm pretty sure the consensus is milestones ->
> final -> patch releases.  Maybe more Spring than Eclipse?
>
> 1.1-M1,  1.1-M2,  1.1,  1.1.1,  1.1.2
>
> Works for me. :)  Any objections?
>
> --
> Wendy
>

[Wendy Smoak-3]

On Sat, May 10, 2008 at 1:15 PM, Brett Porter <brett@...> wrote:
> I suggest we take this one to a vote (perhaps Wendy could kick it off), with
> the options:
>
>  - Maven style (alpha, beta, final, point release)
>  - Eclipse style (M1, M2, M3, final, point release - though Eclipse don't
> have the last ones)
>  - httpd style (.0.0, .0.1, .0.2, .0.3)

Over on dev@continuum, Brett commented:

> I never shared my actual preference :)

I hope I didn't imply that you did... I just said you gave your opinions.

The consensus I'm referring to on Archiva is James and Deng agreeing
on milestones, you not objecting, and me deferring to the people who
are actually doing the work.

I suspect a vote would be close between httpd-style and milestones...
and since James wants milestones _and_ is going to do the work for
1.1-M1... I'm not going to argue.

--
Wendy

[brettporter]

On 12/05/2008, at 8:28 AM, Wendy Smoak wrote:

>
>> I never shared my actual preference :)
>
> I hope I didn't imply that you did... I just said you gave your  
> opinions.

Right :)

>
>
> The consensus I'm referring to on Archiva is James and Deng agreeing
> on milestones, you not objecting, and me deferring to the people who
> are actually doing the work.

Yep, I agree.

- Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/

[Arnaud HERITIER]

I'm also tired with maven style (I said it several times) which doesn't help
us to create good quality deliveries. Moreover it's very confusing for our
users with some plugins that are always in alpha or beta for several years.
Between eclipse and httpd styles, I don't know. I like both of them.
I can understand that it is probably more difficult for some users to
understand the httpd ones, thus I'll vote for eclipse style.

About the frequency of releases, I hope we could have more frequent releases
but in opensource land it's difficult. Without being at the level of Hudson
(which is sometimes annoying with 2 or 3 releases for one day) I think it
will be better if we can have one or two releases by month.

(What we can try to copy about hudson, it is the facility to install/upgrade
it)

Arnaud

On Sun, May 11, 2008 at 6:55 AM, Maria Odea Ching <oching@...> wrote:

> Fine with me too :)
>
> -Deng
>
> On Sun, May 11, 2008 at 12:46 PM, Wendy Smoak <wsmoak@...> wrote:
>
> > On Sat, May 10, 2008 at 1:15 PM, Brett Porter <brett@...> wrote:
> > > I suggest we take this one to a vote (perhaps Wendy could kick it
> off),
> > with
> > > the options:
> > >
> > > - Maven style (alpha, beta, final, point release)
> > > - Eclipse style (M1, M2, M3, final, point release - though Eclipse
> don't
> > > have the last ones)
> > > - httpd style (.0.0, .0.1, .0.2, .0.3)
> >
> > Do we need a vote?  I'm pretty sure the consensus is milestones ->
> > final -> patch releases.  Maybe more Spring than Eclipse?
> >
> > 1.1-M1,  1.1-M2,  1.1,  1.1.1,  1.1.2
> >
> > Works for me. :)  Any objections?
> >
> > --
> > Wendy
> >
>

[Fabrice Bellingard-3]

+1 as well with what Wendy suggested

--
Fabrice
- bellingard@... -


On Sun, May 11, 2008 at 6:55 AM, Maria Odea Ching <oching@...> wrote:

> Fine with me too :)
>
> -Deng
>
> On Sun, May 11, 2008 at 12:46 PM, Wendy Smoak <wsmoak@...> wrote:
>
> > On Sat, May 10, 2008 at 1:15 PM, Brett Porter <brett@...> wrote:
> > > I suggest we take this one to a vote (perhaps Wendy could kick it
> off),
> > with
> > > the options:
> > >
> > > - Maven style (alpha, beta, final, point release)
> > > - Eclipse style (M1, M2, M3, final, point release - though Eclipse
> don't
> > > have the last ones)
> > > - httpd style (.0.0, .0.1, .0.2, .0.3)
> >
> > Do we need a vote?  I'm pretty sure the consensus is milestones ->
> > final -> patch releases.  Maybe more Spring than Eclipse?
> >
> > 1.1-M1,  1.1-M2,  1.1,  1.1.1,  1.1.2
> >
> > Works for me. :)  Any objections?
> >
> > --
> > Wendy
> >
>