Mailing List Archive: Wikipedia: Wikitech

The State of Trunk

Index | Next | Previous | View Threaded

innocentkiller at gmail

Oct 24, 2009, 12:43 PM

Post #1 of 5 (823 views)
Permalink

The State of Trunk

All,

As we are all very aware, it is long past time for branching 1.16 for release.
Tim, as our release manager, has stated previously that the current state of
trunk is in no condition to be a release; I'm inclined to agree.

It's just shy of 6 months since 1.15 was branched, and we've had over 8000
commits since then, including 3 branches completed and merged. That is a hell
of a lot of code, and a hell of a lot of code to review. I've been thinking,
and I've mentioned it in a few places to some people, that perhaps it's time
for a code freeze prior to branching.

If we keep committing new code at the pace we've been going, we're never going
to catch up on review, and the 1.16 final release is going to be even longer in
coming. If, however, we can at least freeze trunk to new development, it could
perhaps aid in the review/cleanup process associated with a release. Focusing
solely on bugfixing/cleanup rather than trying to push even more new things
into 1.16 allows us to cleanup 1.16 and get it in a state we're happy
to release.

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Simetrical+wikilist at gmail

Oct 24, 2009, 5:32 PM

Post #2 of 5 (781 views)
Permalink

Re: The State of Trunk [In reply to]

On Sat, Oct 24, 2009 at 3:43 PM, Chad <innocentkiller [at] gmail> wrote:
> As we are all very aware, it is long past time for branching 1.16 for release.
> Tim, as our release manager, has stated previously that the current state of
> trunk is in no condition to be a release; I'm inclined to agree.
>
> It's just shy of 6 months since 1.15 was branched, and we've had over 8000
> commits since then, including 3 branches completed and merged. That is a hell
> of a lot of code, and a hell of a lot of code to review. I've been thinking,
> and I've mentioned it in a few places to some people, that perhaps it's time
> for a code freeze prior to branching.

We were in a similar situation for 1.15, and the way we solved that is
by branching from the last revision used on Wikimedia. In practice,
all our testing happens by means of deploying to Wikimedia and seeing
what happens. It would definitely be a bad idea to release any code
that hasn't been working on Wikimedia for a while (at least, if it's
meant to be used on Wikimedia). So I don't think a code freeze will
actually accelerate the release at all -- at most, it will mean more
revisions get released in 1.16 instead of 1.17.

The only advantage I can see in a code freeze is to try forcing devs
to spend their time fixing bugs instead of adding features. I'm not
sure that will work very well, and I'm not sure it would be valuable
if it did. Fixing a bug isn't inherently more valuable than adding a
feature. Adding a good feature can be worth much more than fixing a
minor bug. The only type of bug that really needs to be fixed in a
particular release (and isn't so serious that it would be fixed
anyway) is an intra-release regression -- that's good to fix before
release because fewer regressions mean more people willing to upgrade.
Any other type of bug fix could just as well be pushed to the next
release.

So that's MHO. It might be useful to flag bugs that are regressions
from 1.15, and make sure those specifically are fixed, but I don't
think there's much use in a proper code freeze. AFAICT, other
projects do code freezes only so that testers have something stable to
find bugs in -- but we already do all our testing intra-release on
Wikimedia. I don't think this particular development paradigm will
work well for us.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

tstarling at wikimedia

Oct 26, 2009, 9:53 AM

Post #3 of 5 (774 views)
Permalink

Re: The State of Trunk [In reply to]

Aryeh Gregor wrote:
> The only advantage I can see in a code freeze is to try forcing devs
> to spend their time fixing bugs instead of adding features.

I think the devs who were already inclined to fix bugs will fix bugs,
and the rest of the devs will just have a holiday. We would be
crossing our fingers and hoping that they'd come back at the end of
the freeze.

So yes, I think the only way to do it is to branch and then to do a
campaign of bugfix merges. If we branch early, then there will be less
features to review and fix bugs in. If we branch later, then we get a
fully featured 1.16 release with a minimal divergence from trunk.
That's the trade-off as I see it.

Anyway, if nobody is going to work on reviewing and fixing Michael's
code other than me, then it's going to be a while yet before we're in
a fit state to branch. It became pretty clear during the recent staff
meeting that I'm going to be pretty busy during the next couple of
weeks. I have to:

* Review a ton of usability initiative code and oversee its deployment.
* Review some fundraising code and make sure that a copious number of
fixes get done, then have it ready to deploy within a week.
* Do some DBA work, since it seems that I'm the only staff member who
knows MySQL.
* Fulfill my commitment to have SecurePoll ready for an arbcom
election. Roger Davies has just sent me a list of features that he
wants implemented before Friday UTC.
* Move house (removalists coming on Friday)

So I certainly won't have any time to work on the rest of MediaWiki in
the next week, and maybe not in the week after that either.

-- Tim Starling

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Platonides at gmail

Oct 26, 2009, 2:31 PM

Post #4 of 5 (777 views)
Permalink

Re: The State of Trunk [In reply to]

Tim Starling writes:
> So I certainly won't have any time to work on the rest of MediaWiki in
> the next week, and maybe not in the week after that either.
>
> -- Tim Starling

Yup. It seems you'll be quite busy.
Can't another developer handle the fundraising code? Loks like the kind
of thing that don't need a special prior knowledge, not being relevant
*who* does it*. SecurePoll is also quite separate, but if you were with
it, it may be better that you go on with it.

*If it's someone competent and trustable, of course.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

tstarling at wikimedia

Oct 26, 2009, 7:08 PM

Post #5 of 5 (760 views)
Permalink

Re: The State of Trunk [In reply to]

Platonides wrote:
> Can't another developer handle the fundraising code? Loks like the kind
> of thing that don't need a special prior knowledge, not being relevant
> *who* does it*. SecurePoll is also quite separate, but if you were with
> it, it may be better that you go on with it.
>
> *If it's someone competent and trustable, of course.

Four Kitchens has been contracted to write the code, but they don't
have much experience with MediaWiki extensions, so they need a fair
bit of review and guidance. You can see the relevant code in
extensions/DonationInterface.

-- Tim Starling

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads