28 Apr
2011
28 Apr
'11
5:07 p.m.
Hi Caleb,
On Thu, Apr 28, 2011 at 16:51, Caleb James DeLisle <calebdelisle(a)lavabit.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
wrote:
On 04/28/2011 10:25 AM, Vincent Massol wrote:
Agreed. That's actually already the policy for RC releases. Not sure whether
it applies for Milestones though.
In any case, committers are supposed to fix the tests that fail because of
their commits, so I'm fine with a reversal policy (after, say, for instance,
a week) for commits that make tests fails, when those tests are not fixed.
Guillaume
Caleb
On Apr 28, 2011, at 4:24 PM, Vincent Massol wrote:
>
> On Apr 28, 2011, at 3:40 PM, Caleb James DeLisle wrote:
>
>> I offered to take over the release since Jerome was unable to do it and
right now we have 38 test
>> failures.
>> 16 selenium1 tests,
>> 6 selenium2/ui-tests
>> 16 webstandards tests.
>>
>> We have 3 options:
>> 1. We can release now and accept bugs in the release.
>> 2. We can have volunteers to take over tests and get them passing for
tomorrow so tomorrow I can
>> release.
>> 3. We can opt to postpone the release. If I work on these alone I
expect
it to take about 1 week as
>> long as nobody commits code which
introduces further regressions.
>>
>> I don't think postponing the release is wise at this point and #2 is
contingent upon volunteers
>> claiming ownership of specific tests so I
think #1 is the lesser of the
evils.
>>
>> Do I hear any objections/volunteers?
>
> I fear 1 will make a precedent meaning that we'll consider it in the
future too to do that, meaning that tests will have less and less values.
Right now they don't seem to have any value since apparently nobody cares
about them since we keep having issues when doing releases whereas they
should just all run all the time. Normally when someone commits something
and it fails the tests, that person must fix the code/test and not wait till
the release happens. So we need to fix this somehow. Ideas anyone?
If I am the release manager then I will propose a lock period when nobody
commits anything except
stabilization code for a week. During that time I will sort out what
changes broke tests and if the
committer is unwilling to fix them then revert their patches. If we need
quality then we need a
policy with teeth.
>
> So I'm fine with 1 but only provided it's decided in conjunction with a
plan to fix the tests as otherwise we'll just have a doubling of failing
tests for the next 3.1M2 release....
Actually what would be good is also to verify manually that the tests are
not real
issues because if they are we shouldn't release or if we do release
then it's because we've considered the bugs to be non blocking and they'll
need to be detailed in the release notes as regressions.
Thanks
-Vincent
>
> More precisely we need to answer:
> * Who's going to fix the currently failing tests?
> * What strategy to put in place so that failing tests don't creep in for
more than, say, 1 full day?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs