MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Guillaume Paumier-3
Le mardi 21 septembre 2010 à 22:19 +0400, Max Semenik a écrit :
> On 21.09.2010, 21:48 Guillaume wrote:
>
> > * Wikimedia users would probably not mind encountering small bugs &
> > quirks if it's the downside of benefiting from more regular code
> > updates.
>
> You got it wrong: the less often the updates go live, the more bugs
> they contain due to the amount of untested code. Frequent updates
> actually mean less bugs.

I thought that was what I said. If not, it's definitely what I meant.

--
Guillaume Paumier


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Rob Lanphier-4
In reply to this post by David Gerard-2
On Tue, Sep 21, 2010 at 10:18 AM, David Gerard <[hidden email]> wrote:

> On 21 September 2010 18:09, Rob Lanphier <[hidden email]> wrote:
>> On Tue, Sep 21, 2010 at 9:36 AM, David Gerard <[hidden email]> wrote:
>
>>> Arbitrarily declaring "release time!" from trunk for untested code
>>> means development is effectively forked between trunk-to-tarball and
>>> the WMF version.
>
>> No one is suggesting that we be completely arbitrary.
>
>
> I didn't say "completely"; however, picking a release date with no
> consideration of baking the code in production does seem arbitrary.

I didn't say there would be no consideration of baking the code in
production.  In fact, one discussion I just had was finding out what
the latest thinking was with respect to the production branch.

I think we can all agree that it doesn't make sense to cut a new
release of MediaWiki until the ResourceLoader stabilizes.  Here's the
project page for that:
http://www.mediawiki.org/wiki/ResourceLoader

I'll pester the crew responsible for that to put in a brief "roadmap"
paragraph in there somewhere, but the gist of my understanding is that
we're talking  about deploying it December at the earliest (don't
quote me on that).

The new installer is something that would be nice to get out sooner
rather than later.  I'm not saying we should, but we *could*
conceivably branch 1.16wmf4 to create a 1.17 branch, port the new
installer + plus whatever nicities are already ready to go to that
branch, and start stabilizing that for a 1.17 release.  I doubt that
we should do this, though.

So, let's assume that the existing trunk (ResourceLoader and all) is a
required part of 1.17.  What's the earliest reasonable time we could
expect to branch point for 1.17?

>>> (This may then lead to the tarball being volunteer effort and the WMF
>>> version being paid effort, per Simetrical's note on the subject. I
>>> submit this might also turn out not to be a good idea.)
>
>> Regardless of who gets paid by whom for what, it seems like further
>> detangling the WMF production release process from the MediaWiki
>> release process might not be a bad idea.
>
>
> Reifying the fork (so paid developers do WMF and volunteer developers
> do tarball, and never the twain shall meet again) - rather than fixing
> it - strikes me as a *terrible* idea, as someone with cause to use the
> tarball. The fairly obvious consequence of your plan is an unusable
> tarball no-one goes near.

I didn't say "paid developers do WMF and volunteer developers do
tarball", nor did I mean that.  WMF has no plans of getting out of the
MediaWiki release process.  I merely suggested that we don't
necessarily have to have the same release process for the two.  One
thing that's easier about MediaWiki releases versus Wikimedia site
releases is that MW releases lend themselves better to more
traditional QA practices.  I'm not saying (yet) that we're going to do
this, but (for example) we could conceivably hire outside QA to run
test passes on basic MediaWiki installs, and generally stabilize
MediaWiki tarballs in a different fashion than we stabilize WMF site
releases.

>>> I found really basic bugs in 1.16 betas (e.g. an install bug that made
>>> it literally impossible to install on a fresh server) that destroyed
>>> my confidence in 1.16 and left me still installing 1.15.x by
>>> preference.
>>> I submit that making the tarball version even less tested than at
>>> present is not going to get more testing achieved, but less.
>
>> I don't think it's a matter of "more" or "less", but rather a question
>> of dependencies.  How much testing did the installer get by being
>> deployed to production on Wikimedia sites?  There is going to be code
>> that doesn't get tested at all (e.g. installer, sqlite support) solely
>> by virtue of being deployed in WMF production.  So, what do we gain by
>> putting an arbitrarily long lead time of sitting in production prior
>> to releasing a MediaWiki tarball?
>
>
> Any of the code actually gets tested and used before you shove out a
> tarball that you expect people to use.
>
> What you've said in that last paragraph is "our testing is inadequate,
> so let's give up testing entirely."

No, I didn't.  I suggested that the worst problems with MediaWiki
releases may have less to do with how long they've been baking in
production than we collectively seem to think, so insisting on baking
them in production for a long time may merely slow things down without
increasing the quality of the tarball release.

Rob

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Antoine Musso-3
In reply to this post by Guillaume Paumier-3
On 21/09/10 19:48, Guillaume Paumier wrote:
> I can see a number of reasons to have a stable trunk (also used by
> Wikimedia websites), that contains reviewed&  tested code, along with a
> development branch that/can/  be broken:

Hello,

I haven't posted in a long time but I though I could share some old
knowledge and my experience on the matter.

  In september 2004 (according to CVS logs), Brion or Tim made a new
branch named 1.3A meant for the WMF website. The process was roughly :
users commit to an unstable branch and sysadmin would choose wich
commits could make it to the live site.
  I remember I personally crashed the site a few time by sending an
incorrect patch in production (we even talked about a blank page day for
me :( ).  The 1.3A made it less likely since someone else reviewed trunk
patches before making it to 1.3A.

  With 1.6, brion started the continuous integration cycle. As I
understand it, it was more about releasing stable snapshots when more
and more users were begging for a new version.  By this time the 1.3A
idea has been abandonned and trunk was meant to be production ready.
   That made it hard to commit unstable patches in trunk. Instead
developers made new branches that were later merged in trunk once
"proven" stable.
  Brion, Tim, Jeluf or any old school developers would probably be more
talkative about it.

  In my experience, the main issue in releasing a new version is
establishing a schedule and make sure the release is as bugproof as
possible. The schedule could be something like :
  - at T0 : new features frozen (no more new code)
  - at T1 : i18n frozen (no new message only bug fixes / typos)
            create an alpha snapshot for people to test new features
  - at T2 : freeze non urgent commits.
            create a beta snapshot
  - at T3 : by this time most bugs have probably been tracked down. It
is time for a release candidate.
  - at T4 : release !

   That kind of schedule would help volunteer, senior developers,
testers, users, translators to *focus* on a given task. Between T1 and
T2 translators will be busy. In between T2 and T3 you will focus on
tracking and fixing important bugs ...
   Of course new features can still live in their own branch.

  Maybe whoever is the release manager nowaday (Tim?), could have a look
or contact other release manager. KDE, Gnome, Symphony come to mind.

cheers,

--
Ashar "hashar" Voultoiz


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Chad
On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz <[hidden email]> wrote:
>  - at T0 : new features frozen (no more new code)
>  - at T1 : i18n frozen (no new message only bug fixes / typos)
>            create an alpha snapshot for people to test new features
>  - at T2 : freeze non urgent commits.
>            create a beta snapshot

I've suggested freezes of varying degrees several times, and
have been shot down each and every time.

"It discourages contributions" or something like that

-Chad

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Roan Kattouw-2
2010/9/21 Chad <[hidden email]>:
> On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz <[hidden email]> wrote:
>>  - at T0 : new features frozen (no more new code)
>>  - at T1 : i18n frozen (no new message only bug fixes / typos)
>>            create an alpha snapshot for people to test new features
As mentioned on IRC, i18n tracks development so closely that this is
stage probably not needed.

> I've suggested freezes of varying degrees several times, and
> have been shot down each and every time.
>
> "It discourages contributions" or something like that
>
It'll discourage people from committing to trunk, yes, and I think
that's a bad thing. Branching then freezing the branch to various
degrees is fine by me, but trunk should remain open to changes that
are neither insane nor necessarily very stable.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Max Semenik
In reply to this post by Chad
On 22.09.2010, 0:53 Chad wrote:

> On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz <[hidden email]> wrote:
>>  - at T0 : new features frozen (no more new code)
>>  - at T1 : i18n frozen (no new message only bug fixes / typos)
>>            create an alpha snapshot for people to test new features
>>  - at T2 : freeze non urgent commits.
>>            create a beta snapshot

> I've suggested freezes of varying degrees several times, and
> have been shot down each and every time.

> "It discourages contributions" or something like that

> -Chad

The only viable technical method of feature freeze is branching,
otherwise you'll have to come up with messages like "Okay, I
declare a feature freeze. Whomever commits a new feature to trunk
whill have their fingers smashed with a hammer." Not very practical.
Some developers don't read wikitech-l, some are weeks behind on
reading their mails.


--
Best regards,
  Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Antoine Musso-3
In reply to this post by Aryeh Gregor
On 21/09/10 20:38, Aryeh Gregor wrote:
<snip>
> I think the correct course of action is to revamp our review structure
> so that we can return to the status quo ante of keeping deployment
> roughly in sync with trunk.  We should aim for all commits should be
> reviewed for deployment less than a week after being committed --
> perhaps just immediately reverted if they're badly flawed, but still
> reviewed.
<snip>

The code review tool is a good start. Android use a similar system :
   https://review.source.android.com/
It acts as a purgatory for new patches. Once reviewed by another
developer, the patch can be pushed to the release manager for approval.

  To help the release manager, maybe commits should be made to branches,
reviewed and aggregated in one clean patch to be approved and then
merged.  This is something really easy to do with git, you can even edit
your commit history to make it cleaner for review / release manager.
The way it works :

  developer A creates a branch
   - commit
   - commit x 20
  developer A ask for a review to developer B
   - more commits by developer A & developer B

  developer A create a patch with test cases, documentation and so on.
He then submit it to a special branch such as "for-release-manager".

  Release manager look at the "for-release-manager" branch history. For
each commit in there he either :
  - delay it for later review
  - pull approved patches and push them to "trunk"
  - reject the commit

This tends to raise the signal/noise for other developers as well. I am
not sure though how it can be translated to MediaWiki :-/

cheers,

--
git clone Ashar://hashar/Voultoiz


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Neil Kandalgaonkar
In reply to this post by MZMcBride-2
On 9/20/10 8:23 PM, MZMcBride wrote:

>  From my perspective, the initiation of branching has slowed down code pushes
> dramatically. This may be a false correlation I'm drawing, but I don't think
> so.

I do not know enough about the history at Wikimedia to say, but in
general, that's why people go to a branching system in the first place
-- to introduce a buffer between development and production.


> Has there been any discussion about killing the branch system altogether?

After much experience with branch-based deployment systems -- including
designing and implementing some for largish web properties -- I now
think branches are a bad idea for most website development.

Every time I have worked with a system designed to isolate streams of
development (dev, test, production) it has proven to be a net negative.
Critical bugs are harder to fix, big refactorings are harder to put into
production.

Flickr argues that the entire concept of "releases" is based on an
outmoded notion of shrink-wrapped software. For websites, you don't want
a system that tries for unattainably perfect releases. Instead you want
a system that makes deployment easy, and recovery from problems routine.
Flickr deploys 10+ times a day, and does a revert of a deploy probably
once a week.

Check out this presentation, which explains the radically different
development and deployment practices at Flickr:

   http://velocityconference.blip.tv/file/2284377/

There are pros and cons to this approach.

It's not entirely appropriate for us because we do in a sense have a
shrink-wrapped product -- MediaWiki -- and its releases ought to be stable.

Also, Flickr relies on the entire team being experienced and careful;
they can't afford even one bad or naive developer.

--
Neil Kandalgaonkar  |) <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Antoine Musso-3
In reply to this post by Max Semenik
On 21/09/10 23:03, Max Semenik wrote:
<snip>
> The only viable technical method of feature freeze is branching,
> otherwise you'll have to come up with messages like "Okay, I
> declare a feature freeze. Whomever commits a new feature to trunk
> whill have their fingers smashed with a hammer." Not very practical.

That is actually the aim.  The frozen date can be seen as a dead line, a
day by wich you must have something 'ready to show'.  If it is not
ready, you have missed the deadline and the feature will made it in the
next release.  Keep the feature in your branch.

The freeze itself might just last a couple weeks.

> Some developers don't read wikitech-l, some are weeks behind on
> reading their mails.

Should they keep commit right to trunk ?  Maybe some patches could just
be sent by emails for review.  I personally found it hard to commit
anything without being on IRC or I will occasionaly face a silent revert.

--
Ashar Voultoiz


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

K. Peachey
On Wed, Sep 22, 2010 at 4:21 PM, Ashar Voultoiz <[hidden email]> wrote:
>> Some developers don't read wikitech-l, some are weeks behind on
>> reading their mails.
>
> Should they keep commit right to trunk ?  Maybe some patches could just
> be sent by emails for review.  I personally found it hard to commit
> anything without being on IRC or I will occasionaly face a silent revert.
>
> --
> Ashar Voultoiz
Silent reverting shouldn't happen, anyone with commit access should
have "allow others to email me" activated on their mw wiki account so
that code review can send them emails when people comment or take
action on code, although some older accounts might not have this
enabled it is now a requirement to get access[1] and people
don't/shouldn't be reverting without commenting on why anyway.

Sending patches via email isn't a really good idea, because it isn't
as easy to track them, easily lost/forgotten. Where as when directly
submitted/attached to Bugzilla report it means that they can be easily
searched and found if required and commented on, then just bugging
someone on IRC to get it applied (Yes I know there is a backlog of
patches on Bugzilla needing to be looked at[2]).

[1]. http://www.mediawiki.org/wiki/Commit_access#Requesting_commit_access
[2]. https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Patches%3A%20Open%20and%20Need%20Reviewing&sharer_id=9593

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

Aryeh Gregor
In reply to this post by Rob Lanphier-4
On Tue, Sep 21, 2010 at 2:59 PM, Rob Lanphier <[hidden email]> wrote:
> So, let's assume that the existing trunk (ResourceLoader and all) is a
> required part of 1.17.  What's the earliest reasonable time we could
> expect to branch point for 1.17?

Whenever the code is all reviewed.  If Wikimedia deployed enough
resources to reviewing code, I don't know, maybe that could be a month
or two from now.  If the status quo on code review is kept, it will
probably be never.  Of course, we could just accept that review won't
keep up with trunk, if we want to just give up on ever getting
volunteer code deployed in a timely fashion again.  In that case, we
could branch from the last reviewed revision, and base both production
and 1.17 off that.  But I'm kind of hoping that's not necessary or
desired by the powers that be.

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