On Mon, May 9, 2011 at 3:41 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> I realize there are some projects that have had success with this sort
>> of thing, I just do not think we are one of them. My main concern is
>> that it would actually slow down the release process as we get to a
>> point where we are somewhat waiting for feedback that never arrives.
>
> I wouldn't plan on holding the release pending feedback. We can
> invite people to provide it, but should they choose not to, we move
> ahead.
I have no objections to releasing milestones and if we get some
feedback great. I would just not want to see us adopt a plan where we
make getting feedback a critical part of the process. Or
alternatively, I think we would need to be more aggressive in getting
feedback. Such as asking for a certain number of users to signup for
the Beta and provide answers to some kind of questions we want to give
them about what they tried.
> One of the reasons I want to do alphas and/or betas is to test the
> actual artifact creation and distribution. A lot has changed in the
> tarball rolling process since 1.6.x (we don't create deps, various
> swig building changes), and we've not released on apache
> infrastructure before. I'd like to iron out any kinks in the rolling
> process before I create a borked rc1 (or rc2, ad nauseum).
Makes sense. Just a random idea. What if we were to make branches
like "1.7.0-beta1" etc. These would basically just be tags, but maybe
you alter a few things like version strings. This might make it
easier to use our existing scripts?
>> What is your concern with this? I do not see why it would be a
>> problem. I am not sure what your definition of "releaseable state"
>> is, especially in regards to an alpha/beta release, but I think trunk
>> is in this state. I have been publishing Windows binaries of trunk
>> builds and I believe that TortoiseSVN does as well.
>
> Historical reasons, mainly. If folks are comfortable cutting an alpha
> release from trunk, I'm fine too. It may require a slight
> modification of our dist scripts, though.
I would prefer to see us keep on trunk until we are ready for RC1 if possible.
>> If we really wanted to do something, I would suggest something like this.
>>
>> 1) Define a reasonable target date when we think we are going to
>> branch and be ready for RC1. Let me just make up a date and say June
>> 8th,
>>
>> 2) Issue a beta1, beta2, beta3 like clockwork every week leading up to
>> the date. These would just be cut from trunk and go through no or
>> minimal voting. I would probably just be sure to use a revision where
>> buildbot is green.
>>
>> 3) Publicize these plans and the betas leading up to it. Each beta
>> should list the known issues that are currently blocking the release.
>> Encourage users to report issues they see as release blockers.
>>
>> 4) We should obviously try to meet the date we set for ourselves as
>> other open-source projects do, but obviously the software has to be
>> ready to actually get to that final branch/rc1 state. All known
>> release blockers must be closed and the release would go through
>> normal release process.
>
> I like this plan, and don't mind proposing something similar in a
> separate thread (wherein people can debate the branch date, etc.)
If you guys don't get us to RC1 while you together in Berlin maybe you
can just discuss it there and post a proposal? I would think you have
all the right people in the room to agree to a date we can feel good
about for RC1. I think that date drives a lot of this. If RC1 is
right around the corner, which seems like a possibility, than we would
probably only release one or two betas at most before then.
>> I have been encouraging people to use the 1.7.0 milestone for anything
>> that is a blocker. Paul added issues for every XFail and annotated
>> the tests. Other things that normally slow us down like release notes
>> and CHANGES seem good. I think we should rely on the issue tracker to
>> enumerate the blockers. If people cannot be bothered to create an
>> issue for something than it is not a blocker.
>
> I agree with using the 1.7.0 milestone as that for blocking problems.
> I currently see only 10 issues marked as such, an improvement over the
> past couple of weeks.
One possible blocker that popped into mind. What is the current state
of upgrading 1.6 working copies? I seem to recall that it takes
longer than a new checkout and is possibly somewhat low hanging fruit
for someone that wants to apply some of the same SQLite optimizations
we have been making elsewhere. Is that accurate? I think we need to
put at least a little effort into speeding this up as it is the first
thing a lot of users will do with 1.7.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-05-09 22:21:26 CEST