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<[email protected]> 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<[email protected]> wrote:
From: Mohammad Nour El-Din<[email protected]>
Subject: Re: A modest suggestion about testing versus release votes
To: [email protected]
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<[email protected]>
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
<[email protected]>
wrote:
+1
More specifically we are still getting used to the
release process.
On Tue, Jul 5, 2011 at 2:39 PM, Benson Margulies
<[email protected]>
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
