Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

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

 

 

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


robla at robla

Sep 20, 2010, 4:47 PM

Post #1 of 31 (3965 views)
Permalink
MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)

On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride <z [at] mzmcbride> wrote:
> Quite a few people are under the impression that MediaWiki 1.17 will be
> released in October or November of this year.

I don't think there's been many public references to this, but that is
more or less the timeframe many of us have discussed. There is at
least one public reference here:
http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14

Several of us have a desire to get back on a more regular release
cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed
like a good place to start.

The goal, as I recall, was branching October 15 or thereabouts, with
first beta in November, and a release sometime after that (perhaps as
late as January, depending on how well we do with the first beta). We
really haven't had an organized discussion of the topic since that one
meeting above, but maybe this email thread can be that conversation.
Nothing about the schedule is carved in stone, so now is as good a
time as any to bring up any objections to that timeline.

Rob

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


Simetrical+wikilist at gmail

Sep 20, 2010, 4:53 PM

Post #2 of 31 (3801 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier <robla [at] robla> wrote:
> I don't think there's been many public references to this, but that is
> more or less the timeframe many of us have discussed. There is at
> least one public reference here:
> http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14
>
> Several of us have a desire to get back on a more regular release
> cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed
> like a good place to start.
>
> The goal, as I recall, was branching October 15 or thereabouts, with
> first beta in November, and a release sometime after that (perhaps as
> late as January, depending on how well we do with the first beta).  We
> really haven't had an organized discussion of the topic since that one
> meeting above, but maybe this email thread can be that conversation.
> Nothing about the schedule is carved in stone, so now is as good a
> time as any to bring up any objections to that timeline.

I think the primary objection would be that we don't want to do a
release of code that hasn't run on Wikimedia for a while. We never
have before, certainly. Not many people use wikis running RCs or
betas compared to the number who use Wikipedia, so we'll get vastly
fewer bug reports and thus ship a much buggier release if we don't
scap the code well before we release it. It's also kind of sketchy to
say that trunk is good enough for release when it hasn't been vetted
as suitable for Wikimedia deployment.

So whatever the timetable is, we need to have "scap" placed somewhere
significantly before "branch for release". If we say a month before,
then that would be five days ago according to your timetable, so I
don't think that's a good idea.

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


gpaumier at wikimedia

Sep 20, 2010, 5:01 PM

Post #3 of 31 (3789 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

Hi,

Le lundi 20 septembre 2010 à 16:47 -0700, Rob Lanphier a écrit :
>
> I don't think there's been many public references to this, but that is
> more or less the timeframe many of us have discussed. There is at
> least one public reference here:
> http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14

The only incoming link for [[Meetings/Release/2010-07-14]] is
[[Meetings/Release]], whose only incoming link is [[Meetings]], which
doesn't have any incoming link.

Discussions involving as major a decision as a release date should
probably be a little more advertised :)

--
Guillaume Paumier


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


tparscal at wikimedia

Sep 20, 2010, 5:08 PM

Post #4 of 31 (3796 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

I think someone (RobLa) is planning on populating these areas of the
wiki as more meetings take place - so I'm not sure we should be so
critical of the number of links in [[Meetings/Release]] - but yeah,
you've got a fair point, if we are going to be keeping meeting notes in
a public place (a big thank you should go to RobLa here!) some links to
the meetings page would help make the public notes a little more public.

I would add some myself, but I'm not sure I know where the link to
[[Meetings]] should go.

I sometimes wonder if we are better at talking about things than doing
them. How easy would it be to just add a link the [[Meetings]] and be
done with it. Yet, here we all are typing away about it... Not sure if
this is all bad... but it doesn't seem all good.

- Trevor

On 9/20/10 5:01 PM, Guillaume Paumier wrote:
> Hi,
>
> Le lundi 20 septembre 2010 à 16:47 -0700, Rob Lanphier a écrit :
>> I don't think there's been many public references to this, but that is
>> more or less the timeframe many of us have discussed. There is at
>> least one public reference here:
>> http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14
> The only incoming link for [[Meetings/Release/2010-07-14]] is
> [[Meetings/Release]], whose only incoming link is [[Meetings]], which
> doesn't have any incoming link.
>
> Discussions involving as major a decision as a release date should
> probably be a little more advertised :)
>

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


gpaumier at wikimedia

Sep 20, 2010, 5:20 PM

Post #5 of 31 (3790 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

Le lundi 20 septembre 2010 à 17:08 -0700, Trevor Parscal a écrit :
> I think someone (RobLa) is planning on populating these areas of the
> wiki as more meetings take place - so I'm not sure we should be so
> critical of the number of links in [[Meetings/Release]] - but yeah,
> you've got a fair point, if we are going to be keeping meeting notes in
> a public place (a big thank you should go to RobLa here!) some links to
> the meetings page would help make the public notes a little more public.
>
> I would add some myself, but I'm not sure I know where the link to
> [[Meetings]] should go.
>
> I sometimes wonder if we are better at talking about things than doing
> them. How easy would it be to just add a link the [[Meetings]] and be
> done with it. Yet, here we all are typing away about it... Not sure if
> this is all bad... but it doesn't seem all good.

Oh, I'm not specifically criticizing the number of links. I actually
think it's great the notes are being posted publicly.

I'm just generally commenting on the fact that it's difficult to find
the information if you don't know it's even there. Adding a link to
[[Meetings]] is easy, but probably not much more helpful in attracting
eyeballs.

I guess my main general point was "Keeping people informed is as easy as
sending an email to wikitech-l".

--
Guillaume Paumier


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


lists at caseybrown

Sep 20, 2010, 5:22 PM

Post #6 of 31 (3787 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Mon, Sep 20, 2010 at 8:08 PM, Trevor Parscal <tparscal [at] wikimedia> wrote:
> I sometimes wonder if we are better at talking about things than doing
> them. How easy would it be to just add a link the [[Meetings]] and be
> done with it. Yet, here we all are typing away about it... Not sure if
> this is all bad... but it doesn't seem all good.

We're not always sure where or how something should be done, so we
talk about it and look for ideas. Take this issue for example, we're
not sure where something should be linked, but mention it here knowing
that someone else probably has some ideas -- that person is then free
to be bold and add a link wherever he thinks would be good.

Speaking more generally, the reason that people might be better at
talking about doing things rather than doing them themselves could be
because they're afraid they'll just get reverted if they try to be
bold.

--
Casey Brown
Cbrown1023

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


robla at wikimedia

Sep 20, 2010, 7:09 PM

Post #7 of 31 (3797 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Mon, Sep 20, 2010 at 4:53 PM, Aryeh Gregor
<Simetrical+wikilist [at] gmail> wrote:
> On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier <robla [at] robla> wrote:
>> The goal, as I recall, was branching October 15 or thereabouts, with
>> first beta in November, and a release sometime after that (perhaps as
>> late as January, depending on how well we do with the first beta). [...]
>
> I think the primary objection would be that we don't want to do a
> release of code that hasn't run on Wikimedia for a while. We never
> have before, certainly. Not many people use wikis running RCs or
> betas compared to the number who use Wikipedia, so we'll get vastly
> fewer bug reports and thus ship a much buggier release if we don't
> scap the code well before we release it. It's also kind of sketchy to
> say that trunk is good enough for release when it hasn't been vetted
> as suitable for Wikimedia deployment.

This seems like a fine line of reasoning, though not one that I had
thought was set in stone. For earlier releases, the MediaWiki
releases benefited from deployment being pretty close to trunk, but
presumably the reason why that drifted was because it became
progressively harder for us to use our production environment as the
de facto MediaWiki testbed.

So, 1.16wmf4 and 1.16 shared the same branch point, which was perhaps
the start of a tradition. Is this the new rule? I don't have a
strong opinion about whether that should be the case, but it does
change how I think about 1.17 planning.

My understanding is that we will probably want a new deployment branch
soon because of ResourceLoader (at least).

> So whatever the timetable is, we need to have "scap" placed somewhere
> significantly before "branch for release". If we say a month before,
> then that would be five days ago according to your timetable, so I
> don't think that's a good idea.

I'm not sure what you mean by this. October 15 would be the branch
point, not the release date. Are you saying that we have to release
to production one month before even branching off of trunk?

Rob

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


z at mzmcbride

Sep 20, 2010, 8:23 PM

Post #8 of 31 (3792 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

Rob Lanphier wrote:
> On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride <z [at] mzmcbride> wrote:
>> Quite a few people are under the impression that MediaWiki 1.17 will be
>> released in October or November of this year.
>
> I don't think there's been many public references to this, but that is
> more or less the timeframe many of us have discussed. There is at
> least one public reference here:
> http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14

Thank you for this. I'm sure a lot of people will be watching the root page
with a lot of interest. I agree with a lot of the other posters in this
thread that publicly posting notes like this is a really good step in the
right direction. :-)

> Several of us have a desire to get back on a more regular release
> cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed
> like a good place to start.

I think there's a much greater desire for the live Wikimedia sites to be
updated more regularly, far more than MediaWiki being released more
regularly. Not that they're mutually exclusive, though with the current
branch system, I suppose they could be, which raises further questions.

> The goal, as I recall, was branching October 15 or thereabouts, with
> first beta in November, and a release sometime after that (perhaps as
> late as January, depending on how well we do with the first beta). We
> really haven't had an organized discussion of the topic since that one
> meeting above, but maybe this email thread can be that conversation.
> Nothing about the schedule is carved in stone, so now is as good a
> time as any to bring up any objections to that timeline.

Personally, I see a rough parallel between the concept of FlaggedRevs on a
wiki and the current code development cycle. Nobody wants to make a
contribution if it's going to sit in a queue indefinitely. It's much more
satisfying to see your work (bug fix, article fix, whatever) go live in a
relatively short amount of time.

Has there been any discussion about killing the branch system altogether?
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. There isn't nearly as much incentive to fix trunk when the branches are
stable. But with that stability comes very little code development, aside
from high priority Wikimedia Foundation projects being pushed into the
branches directly by a few people. It also creates a lot more work (and
commit noise) to merge from trunk rather than keeping trunk up and
relatively stable (or stable enough to run the live sites). Has it been
raised that going back to how things used to be might be better?

MZMcBride



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


bryan.tongminh at gmail

Sep 21, 2010, 1:34 AM

Post #9 of 31 (3805 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 4:09 AM, Rob Lanphier <robla [at] wikimedia> wrote:
>
> So, 1.16wmf4 and 1.16 shared the same branch point, which was perhaps
> the start of a tradition. Is this the new rule? I don't have a
> strong opinion about whether that should be the case, but it does
> change how I think about 1.17 planning.
>
I would strongly recommend this. Having a running MediaWiki on a top
10 site is a very good form of quality control. And this way we are at
least sure that code is pushed to the WMF serves on a regular
interval. (Although I would prefer a shorter interval, I'm not sure
whether this is feasible at this moment)


Bryan

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


maxsem.wiki at gmail

Sep 21, 2010, 6:29 AM

Post #10 of 31 (3795 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 21.09.2010, 6:09 Rob wrote:

> I'm not sure what you mean by this. October 15 would be the branch
> point, not the release date. Are you saying that we have to release
> to production one month before even branching off of trunk?

Yes, if we really care what we release. Currently, trunk is quite
broken due to Resource Loader and other things, which is absolutely
understandable: no one can write a major feature that works flawlessly
from commit one. Even in best scenario it will take at least a couple
of weeks to be ready for Wikipedia. Then, there are lots of other
things, and even more will be revealed during a thorough code review.
And you shouldn't even try to assume that RL will work smoothly once
rolled out to the WMF cluster - more fixes will be needed, as
experience with previous JS-heavy Usability Initiative features shows.

To summarize: we will have more or less sane code in 6-8 weeks from
the time when our next CR begins. Only then it will make sense to
branch for at least one month of final bug-squashing before releasing.
All schedules faster than this are unrealistic. If WMF wants to keep a
predictable release schedule, they should aim for full scaps at least
once per month.

Of course, everything said above is only my personal opinion and I'm
not pretending to say The Absolute Truth(tm), but believe me, even I'm
overpessimizing things, I'm not overpessimizing them too much.

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


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


robla at robla

Sep 21, 2010, 9:26 AM

Post #11 of 31 (3786 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 6:29 AM, Max Semenik <maxsem.wiki [at] gmail> wrote:
> On 21.09.2010, 6:09 Rob wrote:
>
>> I'm not sure what you mean by this. October 15 would be the branch
>> point, not the release date. Are you saying that we have to release
>> to production one month before even branching off of trunk?
>
> Yes, if we really care what we release.

Doesn't this kinda depend on what our priorities are and what the
priorities of people running MediaWiki are? There are many demands
placed by Wikipedia that most websites don't have. In the rest of the
software world, high traffic websites are the *last* ones to upgrade,
not the first. Don't we want to get the benefit of other people using
the software more heavily before we put it on Wikipedia?

I realize that this isn't how it's traditionally been done, but then
again, I think our tradition has drifted. Once upon a time, trunk was
very regularly deployed in production. Providing releases was merely
an alternative to telling MediaWiki admins "just go checkout trunk;
that's what we're using". Now that we're a lot more cautious about
what we put into production, we should question whether we still need
to be even more cautious about what we release as MediaWiki.

> Currently, trunk is quite
> broken due to Resource Loader and other things, which is absolutely
> understandable: no one can write a major feature that works flawlessly
> from commit one. Even in best scenario it will take at least a couple
> of weeks to be ready for Wikipedia. Then, there are lots of other
> things, and even more will be revealed during a thorough code review.
> And you shouldn't even try to assume that RL will work smoothly once
> rolled out to the WMF cluster - more fixes will be needed, as
> experience with previous JS-heavy Usability Initiative features shows.
>
> To summarize: we will have more or less sane code in 6-8 weeks from
> the time when our next CR begins. Only then it will make sense to
> branch for at least one month of final bug-squashing before releasing.
> All schedules faster than this are unrealistic. If WMF wants to keep a
> predictable release schedule, they should aim for full scaps at least
> once per month.

Assuming that ResourceLoader is still in pretty rough shape a month
from now, then yeah, there's no point trying to foist that on
MediaWiki users, no more than it will make sense pushing it to
Wikimedia sites.

Rob

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


dgerard at gmail

Sep 21, 2010, 9:36 AM

Post #12 of 31 (3793 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 21 September 2010 17:26, Rob Lanphier <robla [at] robla> wrote:

> Doesn't this kinda depend on what our priorities are and what the
> priorities of people running MediaWiki are?  There are many demands
> placed by Wikipedia that most websites don't have.  In the rest of the
> software world, high traffic websites are the *last* ones to upgrade,
> not the first.  Don't we want to get the benefit of other people using
> the software more heavily before we put it on Wikipedia?


Speaking as someone who installs MW from tarball every now and then
... it feels like there's WMF development, for WMF purposes, and
there's also an occasional tarball of variable quality.

Arbitrarily declaring "release time!" from trunk for untested code
means development is effectively forked between trunk-to-tarball and
the WMF version.

(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.)

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.


- d.

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


robert at rhl

Sep 21, 2010, 9:38 AM

Post #13 of 31 (3793 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 2010-09-21, Rob Lanphier wrote:
> On Tue, Sep 21, 2010 at 6:29 AM, Max Semenik <maxsem.wiki [at] gmail> wrote:
> > On 21.09.2010, 6:09 Rob wrote:
> >
> >> I'm not sure what you mean by this. October 15 would be the branch
> >> point, not the release date. Are you saying that we have to release
> >> to production one month before even branching off of trunk?
> >
> > Yes, if we really care what we release.
>
> Doesn't this kinda depend on what our priorities are and what the
> priorities of people running MediaWiki are? There are many demands
> placed by Wikipedia that most websites don't have. In the rest of the
> software world, high traffic websites are the *last* ones to upgrade,
> not the first. Don't we want to get the benefit of other people using
> the software more heavily before we put it on Wikipedia?
>
> I realize that this isn't how it's traditionally been done, but then
> again, I think our tradition has drifted. Once upon a time, trunk was
> very regularly deployed in production. Providing releases was merely
> an alternative to telling MediaWiki admins "just go checkout trunk;
> that's what we're using". Now that we're a lot more cautious about
> what we put into production, we should question whether we still need
> to be even more cautious about what we release as MediaWiki.

It was my impression that production release had slowed down due to a
lack of resources, not due to additional caution. Has this changed
then?

End users have an expectation that the software released by us is of
the high standard we have always provided, and this is in part due to
it being run on one of the worlds largest websites. End users are not
and should not be guinea pigs for Wikipedia.

The last release took a year, so I see no reason why we shouldn't delay
this one until we are in a position to release reviwed and reasonably
tested code.

Robert

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


innocentkiller at gmail

Sep 21, 2010, 10:05 AM

Post #14 of 31 (3790 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 12:26 PM, Rob Lanphier <robla [at] robla> wrote:
> I realize that this isn't how it's traditionally been done, but then
> again, I think our tradition has drifted.  Once upon a time, trunk was
> very regularly deployed in production.  Providing releases was merely
> an alternative to telling MediaWiki admins "just go checkout trunk;
> that's what we're using".  Now that we're a lot more cautious about
> what we put into production, we should question whether we still need
> to be even more cautious about what we release as MediaWiki.
>

Providing releases not an alternative to telling people to use
trunk, it was a mark of actually releasing the software (as
opposed to just having the source available). When we release
the software we're making a commitment to the end user. The
release should be something we're all proud of and are willing to
stand behind.

Trunk is not something I'm willing to stand behind and release
to the public right now. It needs lots of review (over 10k revs
since the last branch point) and lots of testing. In my experience,
we don't get a whole lot of feedback from 3rd parties on a beta
release, probably because people are naturally cautious, and
a beta still carries the "may have bugs" connotation. OTOH,
releasing to the sites tends to provide a *lot* of feedback, most
of it incredibly valuable.

You really can't beat a WMF deployment as the ultimate beta
test group for MediaWiki.

-Chad

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


robla at wikimedia

Sep 21, 2010, 10:09 AM

Post #15 of 31 (3802 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 9:36 AM, David Gerard <dgerard [at] gmail> wrote:
> On 21 September 2010 17:26, Rob Lanphier <robla [at] robla> wrote:
>
>> Doesn't this kinda depend on what our priorities are and what the
>> priorities of people running MediaWiki are? There are many demands
>> placed by Wikipedia that most websites don't have. In the rest of the
>> software world, high traffic websites are the *last* ones to upgrade,
>> not the first. Don't we want to get the benefit of other people using
>> the software more heavily before we put it on Wikipedia?
>
>
> Speaking as someone who installs MW from tarball every now and then
> ... it feels like there's WMF development, for WMF purposes, and
> there's also an occasional tarball of variable quality.

I've experienced that myself.

> 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.

> (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.

> 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?

Rob

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


dgerard at gmail

Sep 21, 2010, 10:18 AM

Post #16 of 31 (3791 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 21 September 2010 18:09, Rob Lanphier <robla [at] wikimedia> wrote:
> On Tue, Sep 21, 2010 at 9:36 AM, David Gerard <dgerard [at] gmail> 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.


>> (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 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."

The consequence of what you're proposing is to throw the notion of
releasing a useful tarball out. Perhaps WMF is at the stage where it
needs to do that. You tell me.


- d.

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


gpaumier at wikimedia

Sep 21, 2010, 10:48 AM

Post #17 of 31 (3796 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

Hi,

Le lundi 20 septembre 2010 à 23:23 -0400, MZMcBride a écrit :
> Personally, I see a rough parallel between the concept of FlaggedRevs on a
> wiki and the current code development cycle. Nobody wants to make a
> contribution if it's going to sit in a queue indefinitely. It's much more
> satisfying to see your work (bug fix, article fix, whatever) go live in a
> relatively short amount of time.
>
> Has there been any discussion about killing the branch system altogether?
> 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. There isn't nearly as much incentive to fix trunk when the branches are
> stable. But with that stability comes very little code development, aside
> from high priority Wikimedia Foundation projects being pushed into the
> branches directly by a few people. It also creates a lot more work (and
> commit noise) to merge from trunk rather than keeping trunk up and
> relatively stable (or stable enough to run the live sites). Has it been
> raised that going back to how things used to be might be better?

Alolita and I were chatting informally about this a few days ago. If I
understand correctly the way we currently do things, trunk contains the
development code, the wmfdeployment branch contains the code that
Wikimedia sites run, and releases are branched from trunk.

Code updates on Wikimedia sites rarely happen, and when they do happen,
they're huge, meaning a lot of small bugs & quirks all happen at the
same time. Some developers don't want to commit unfinished or broken
code to trunk, and yet trunk isn't reliable enough for production use.

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:
* Developers wouldn't be afraid to commit unfinished work to the
development branch fearing they're going to break trunk.
* Tarballs for non-Wikimedia MediaWiki users would be more stable.
* Updates to Wikimedia sites would happen more often.
* Getting to a release would be easier, since it would be the result of
many incremental changes already merged into the stable trunk.
* Wikimedia users would probably not mind encountering small bugs &
quirks if it's the downside of benefiting from more regular code
updates.

That said, I guess there are obvious drawbacks I'm not seeing.

--
Guillaume Paumier


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


dgerard at gmail

Sep 21, 2010, 11:15 AM

Post #18 of 31 (3809 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 21 September 2010 18:48, Guillaume Paumier <gpaumier [at] wikimedia> wrote:

> That said, I guess there are obvious drawbacks I'm not seeing.


The hard part would be when you turn the dev branch into the production branch.

Didn't MediaWiki have this problem before, which led to adopting the
idea of trunk being live? Although obviously that's fallen by the
wayside. It seems to be completing a cycle. Is there a sweet spot on
this cycle, or is it better being a cycle?


- d.

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


maxsem.wiki at gmail

Sep 21, 2010, 11:19 AM

Post #19 of 31 (3787 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On 21.09.2010, 21:48 Guillaume 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:

Things are currently reversed: stable (but outdated) branch and
bleeding-edge trunk broken 99% of the time. It doesn't really matter
how we do the development, this or other way around, the only problem
here is how often does the stable code gets updated.

> * Developers wouldn't be afraid to commit unfinished work to the
> development branch fearing they're going to break trunk.

Even unstable trunk/branch is supposed to be runnable at all time, for
semi-finished features there are "private" branches. Several sites
(notably, translatewiki.net) run off trunk, so even bleeding-edge code
shouldn't contain random chunks.

> * 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.

> That said, I guess there are obvious drawbacks I'm not seeing.

The problem here is that our stable code is way *too* stable.
Implementation details may vary.


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


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


Simetrical+wikilist at gmail

Sep 21, 2010, 11:38 AM

Post #20 of 31 (3798 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Mon, Sep 20, 2010 at 10:09 PM, Rob Lanphier <robla [at] wikimedia> wrote:
> This seems like a fine line of reasoning, though not one that I had
> thought was set in stone.  For earlier releases, the MediaWiki
> releases benefited from deployment being pretty close to trunk, but
> presumably the reason why that drifted was because it became
> progressively harder for us to use our production environment as the
> de facto MediaWiki testbed.

The reason why that drifted is because our review system was already
overloaded before Brion left, and completely collapsed after that,
because we failed to decentralize review properly. Today the practice
is roughly that most employees get their code reviewed and deployed
quickly by other employees or even themselves; volunteers (and maybe
some employees) get their code reviewed by (generally) Tim whenever he
has time, which he doesn't have enough of, so their code never gets
deployed, or only once in a blue moon. This is a terrible situation,
and we need to fix it so that all committed code is being reviewed and
deployed on a regular basis before we even consider a release, IMO.

> I'm not sure what you mean by this.  October 15 would be the branch
> point, not the release date.  Are you saying that we have to release
> to production one month before even branching off of trunk?

Yes. There's such a huge deployment backlog that even after careful
review, there's going to be a flurry of new problems that are quickly
discovered and will have to be fixed. I don't think it makes sense to
try backporting the inevitable flood of fixes to a separate branch.
Instead, we should wait until deployment and trunk are relatively in
sync again (we are aiming for that, right?) and then wait a while for
things to stabilize before branching.

On Tue, Sep 21, 2010 at 12:26 PM, Rob Lanphier <robla [at] robla> wrote:
> Doesn't this kinda depend on what our priorities are and what the
> priorities of people running MediaWiki are? There are many demands
> placed by Wikipedia that most websites don't have. In the rest of the
> software world, high traffic websites are the *last* ones to upgrade,
> not the first. Don't we want to get the benefit of other people using
> the software more heavily before we put it on Wikipedia?

No, because other people are in a much worse position to track down
bugs. MediaWiki developers are mostly heavy Wikimedia users, and
Wikimedia users are much more likely to know about Bugzilla and know
where they can complain about problems. Moreover, Wikimedia employs
(practically?) all paid MediaWiki developers. If a third-party site
has a bunch of serious problems, its sysadmins will probably throw up
their hands and revert to an earlier version; if Wikimedia has a
problem, it's likely that it can be fixed in minutes by its employees.

Incremental deployment is a much better overall development strategy.
Back in the days when we had scaps every week or two, as soon as a
user reported a problem, we'd sometimes all say "Oh, I remember the
commit that must have caused that." I remember one time when a user
reported a problem in #wikimedia-tech, and Brion and I had a commit
conflict due to committing the exact same fix at the same time in (I
think) something like two minutes or less -- both of us remembered the
commit that touched that problem (me because I had committed it, he
because he reviewed it) and the problem was obvious given the bug
report. This was standard; whoever did the scap would make sure to
hang around for a few hours in #wikimedia-tech to fix any problems,
and savvy users who watched that channel would see the scap and know
to report any regressions there immediately. There'd be only a
handful, so all of them could be fixed quickly.

Even if we didn't remember the exact commit, we'd have very few
changes to look at in the log for the relevant files before we found
the issue. At worst, we could almost certainly just revert the
problematic commits with no conflicts. When you have months of old
code being deployed at once, you're going to have tons of problems
crop up all at once, instead of a few at a time, and they'll be harder
to fix -- you won't remember what could have caused them, you'll have
to look over more commits to find the problem, and when you do, you
probably can't easily revert them.

Trying to use third-party sites to test the code before we deploy it
isn't feasible. First of all, few of them will test it and fewer
still will report bugs, and that will only get worse if we release
less-tested code. Second of all, Wikimedia will run into problems
that other sites won't, and then all the problems I discuss above are
inevitable.

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.

Indeed, contrary to what you suggest, high-traffic websites are
usually the first and only users to deploy the software *that they
develop*. Most such software is in fact secret, so no one else can
use it even if they wanted to. When it is open-source, the vendor's
site is usually the first to upgrade, in my experience.
vbulletin.com/forums/ runs alphas of vBulletin before they're released
to customers, for example. I'd be interested to know if sites like
drupal.org or phpbb.org use anything but cutting-edge versions of
their own software -- I'd bet most of them deploy betas or release
candidates, at the very least.

> I realize that this isn't how it's traditionally been done, but then
> again, I think our tradition has drifted. Once upon a time, trunk was
> very regularly deployed in production. Providing releases was merely
> an alternative to telling MediaWiki admins "just go checkout trunk;
> that's what we're using". Now that we're a lot more cautious about
> what we put into production, we should question whether we still need
> to be even more cautious about what we release as MediaWiki.

I wouldn't say we're more cautious about what we put into production.
I'd say it's more like some people get their stuff put into
production, and others don't. As far as I can tell, the difference is
mostly whether they're paid by Wikimedia. What employees have their
code waiting in trunk for months without deployment? What volunteers
have their code put into production on any kind of regular basis? I
expect a few of the former exist, but a minority of employees; and I
don't think the latter category exists at all. Correct me if I'm
wrong, please -- I never followed the deployment branch closely. It
includes none or almost none of my changes, so I never saw a reason
to.

On Tue, Sep 21, 2010 at 1:48 PM, Guillaume Paumier
<gpaumier [at] wikimedia> 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:
> * Developers wouldn't be afraid to commit unfinished work to the
> development branch fearing they're going to break trunk.
> * Tarballs for non-Wikimedia MediaWiki users would be more stable.
> * Updates to Wikimedia sites would happen more often.
> * Getting to a release would be easier, since it would be the result of
> many incremental changes already merged into the stable trunk.
> * Wikimedia users would probably not mind encountering small bugs &
> quirks if it's the downside of benefiting from more regular code
> updates.
>
> That said, I guess there are obvious drawbacks I'm not seeing.

The problem isn't the policy for committing to various places. The
problem is review and deployment procedures.

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


gpaumier at wikimedia

Sep 21, 2010, 11:55 AM

Post #21 of 31 (3783 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


robla at wikimedia

Sep 21, 2010, 11:59 AM

Post #22 of 31 (3789 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 10:18 AM, David Gerard <dgerard [at] gmail> wrote:
> On 21 September 2010 18:09, Rob Lanphier <robla [at] wikimedia> wrote:
>> On Tue, Sep 21, 2010 at 9:36 AM, David Gerard <dgerard [at] gmail> 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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


hashar+wmf at free

Sep 21, 2010, 1:44 PM

Post #23 of 31 (3786 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Sep 21, 2010, 1:53 PM

Post #24 of 31 (3784 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz <hashar+wmf [at] free> 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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Sep 21, 2010, 2:03 PM

Post #25 of 31 (3795 views)
Permalink
Re: MediaWiki 1.17 release target (Re: UsabilityInitiative extension...) [In reply to]

2010/9/21 Chad <innocentkiller [at] gmail>:
> On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz <hashar+wmf [at] free> 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
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.