incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: A modest suggestion about testing versus release votes
Date Wed, 06 Jul 2011 11:45:48 GMT
Dan,

I feel your pain. Let me know if you need my help fending off the
multiple voices pushing disparate views of the requirements.

--benson


On Wed, Jul 6, 2011 at 7:30 AM, Dan Haywood <dkhaywood@gmail.com> wrote:
> Hi Benson,
> Sure, do appreciate what you are saying, and it has become clear to me as
> I've been cranking out these RCs how to do dry-runs all the way up to a
> staged release.    Indeed, I did do several trial uploads for RC5 to the
> staging repo, found an issue, and then dropped that repo in order to go
> round the loop again.
>
> If I'm cranky it's cos I've noticed various inconsistencies in releases of
> some TLP and other incubating projects, along with various incomplete and
> sometimes contradictory advice.  Can be frustrating trying to get the
> "perfect" release out when the definition of "perfect" is variable.
>
> Thx anyway, do appreciate your advice.
> Dan
>
>
> On 06/07/2011 11:51, Benson Margulies wrote:
>>
>> I'm just a mentor. I don't make judgements the quality of the code, or
>> about the QA process in general. I try to be helpful with the Apache
>> release process. First releases are bound to be somewhat lumpy. As
>> Mark writes, some of that lumpiness is a result of people using the
>> release test process as a QA opportunity (which is what got me
>> started) and some of it is the process of finding and swatting legal
>> issues.
>>
>> For the former, I am really with Mark. It's mostly a matter of making
>> sure that everyone understands that the formal release process is not
>> so much about bugs. Later on in life, when you have regressions to
>> worry about, you might come to see a serious bug that pops up in
>> release testing as blocking, but for now, not the main point.
>>
>> For the later, my point was to emphasize the relative ease of
>> dry-running the release. You *can* dry-run with the real version
>> number. You'll just be typing 'svn rm' from time to time to discard
>> tags, and you might be among the people who get itchy about creating
>> release packages that are relatively far from being the real release.
>> In which case, you have the option of making use of the 'RC' trick --
>> set version to n-RC-x, run the release plugin, and invite people to
>> scrutinize the packages on repository.apache.org. When people run out
>> of complaints, drop the staged repo, set version to n, and do it one
>> more time. Now vote.
>>
>>
>> On Wed, Jul 6, 2011 at 4:18 AM, Mark Struberg<struberg@yahoo.de>  wrote:
>>>
>>> basically +1. But there is always n+1 more bug which needs to be fixed ;)
>>> So somewhen you just need to start to get a release out of the door.
>>> The first release is always the hardest...
>>> It doesn't need to be technically perfect imo, but we _must_ be perfect
>>> on the license + legal side!
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Tue, 7/5/11, Mohammad Nour El-Din<nour.mohammad@gmail.com>  wrote:
>>>
>>>> From: Mohammad Nour El-Din<nour.mohammad@gmail.com>
>>>> Subject: Re: A modest suggestion about testing versus release votes
>>>> To: isis-dev@incubator.apache.org
>>>> Date: Tuesday, July 5, 2011, 6:40 PM
>>>> To brief what Benson suggested and to
>>>> put it into steps we can do the following:
>>>>
>>>> 1- Declare the intention of preparing a release
>>>>   1.1- Stop committing new changes to trunk
>>>>   1.2- Make primary tests for building from source and
>>>> running unit tests
>>>>   1.3- Making sure that all features addressed for
>>>> that release are
>>>> done and bugs are solved
>>>>   1.4- If new bugs which can block the release are
>>>> found, then we
>>>> start again from step 1.2
>>>>
>>>> 2- Produce the release artifacts
>>>>   2.1- Given the steps in section (1) are completed as
>>>> described
>>>> above, this step is mainly to make sure that produced
>>>> release
>>>> artifacts hold the
>>>>          criteria required by
>>>> ASF.
>>>>   2.2 If problems found, we cut a new release and we
>>>> keep do till we
>>>> produce _the_ release candidate with which we can go to the
>>>> general@.
>>>>
>>>> Thoughts ?
>>>>
>>>> On Tue, Jul 5, 2011 at 3:57 PM, Benson Margulies<bimargulies@gmail.com>
>>>> wrote:
>>>>>
>>>>> Right. And my point is, using the release process as
>>>>
>>>> the primary QA
>>>>>
>>>>> driver makes a lot of extra work for you. It's just
>>>>
>>>> messy to be
>>>>>
>>>>> getting bug reports and deciding what to do about them
>>>>
>>>> off of a vote
>>>>>
>>>>> thread.
>>>>>
>>>>> On Tue, Jul 5, 2011 at 9:12 AM, Mohammad Nour El-Din
>>>>> <nour.mohammad@gmail.com>
>>>>
>>>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> More specifically we are still getting used to the
>>>>
>>>> release process.
>>>>>>
>>>>>> On Tue, Jul 5, 2011 at 2:39 PM, Benson Margulies
>>>>
>>>> <bimargulies@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> Might I suggest some sort of informal testing
>>>>
>>>> process *before* you
>>>>>>>
>>>>>>> call a vote? Go ahead, if you like, and stage
>>>>
>>>> XXX-RC-1 to nexus, but
>>>>>>>
>>>>>>> don't call a vote. Get people to test it and
>>>>
>>>> find problems like broken
>>>>>>>
>>>>>>> links and missing notices. When it all looks
>>>>
>>>> clean, just drop the
>>>>>>>
>>>>>>> staged repo, and run the release with the
>>>>
>>>> actual release version. Then
>>>>>>>
>>>>>>> your votes can look like 95% of all the other
>>>>
>>>> votes at apache; a
>>>>>>>
>>>>>>> pretty rapid verification process.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>

Mime
View raw message