Re: Status of more regular code deployments

"Neil Kandalgaonkar" <neilk <at> wikimedia.org> wrote in message 
news:4DE56CF9.9090608 <at> wikimedia.org...
> On 5/31/11 3:20 PM, MZMcBride wrote:
>
>> taking a page out of the rest of the business world's book, you set a
>> deadline and then it just fucking gets met. No excuses, no questions.
>
> I think you have an optimistic view of how businesses actually work. :)

The only modification needed to bring that sentence in line with business 
reality is adding "it just fucking gets met **or someone's head rolls**.

> But, in any case, in a business, there is a Plan that everyone is trying
> to follow and in theory, deviations from that Plan are avoided. In our
> environment we want to be responsive to the schedule of a volunteer
> developer, who may be completely unaware or uninterested in our plans.

Plenty of businesses work on a rolling-development model, probably more 
businesses than have totally static specs.  The difference between that and 
WMF, and even between WMF and other non-businesses like Linux and Mozilla, 
is that if a release is mandated by some higher power and something is 
holding up that release, **whatever it is gets steamrollered out of the 
way**.  If there is a clear roadmap that says that any feature that's not 
debugged and ready-to-go by Wednesday morning, by the first Tuesday of the 
month, by the 32nd of June, whenever, then it gets reverted, no one is going 
to complain when lo and behold, such features get reverted.  *Everyone* is 
going to complain if the 32nd of June becomes the 32nd of December before 
the feature even makes it onto the cluster.

Re: Status of more regular code deployments

On Tue, May 31, 2011 at 4:31 PM, Happy-melon <happy-melon <at> live.com> wrote:

> >"Brion Vibber" <brion <at> pobox.com> wrote in message
> >news:BANLkTinZzef=oRVuw9dWiCVAHYBUWXniqg <at> mail.gmail.com...
> >
> > Sing it, brother! We're getting *some* stuff through quicker within the
> > deployment branches, but not nearly as much as we ought to.
>
> The fact that some things are *not* getting stuck in the CR quagmire is
> part
> of the *problem*, not the solution.  The upper levels of the developer
> hierarchy ***obviously know*** that the mainline CR process is
> substantially
> broken, BECAUSE ***THEY'RE NOT USING IT*** FOR THINGS THAT ARE IMPORTANT TO
> THEM.

That's not correct -- the same code review tools are being used to look over
and comment on those things, AND THEN THE DAMN THING ACTUALLY GETS MERGED TO
THE DEPLOYMENT BRANCH BY SOMEBODY AND PUSHED TO PRODUCTION BY SOMEBODY.

It's that step 2 that's missing for everything else until the accumulated
release pressure forces a system-wide update.

The unavoidable implication of that observation is that the work of
> the volunteer developers *DOESN'T* matter to them.  Whether or not that
> implication is correct (I have confidence that it's not) is irrelevant, the
> fact that it's there is what's doing horrible damage to the MediaWiki
> community.
>

Re: Code review process (was: Status of more regular code deployments)

"Russell N. Nelson - rnnelson" <rnnelson <at> clarkson.edu> wrote in message 
news:777BC8A5A78CC048821DBFBF13A25D39208F1141 <at> EXCH01.ad.clarkson.edu...
> Robla writes:
> 1.  We say that a commit has some fixed window (e.g. 72 hours) to get
> reviewed, or else it is subject to automatic reversion.  This will
> motivate committers to make sure they have a reviewer lined up, and
> make it clear that, if their code gets reverted, it's nothing
> personal...it's just our process.
>
> Worse than pre-commit review. What if you make a change, I see it, and 
> make changes to my code using your changes. 72 hours later, they get 
> reverted, which screws my code. Okay, so then nobody's going to compile 
> anything, or use anything, if it has 72-hour code in it. The alternative, 
> if they want the code badly enough, is to review it so it will stick. 
> Well, that devolves to the same thing as pre-commit review.
>
> And ... this only makes sense for core, or maybe for stable extensions. It 
> doesn't make sense for experimental extensions where only one person is 
> likely to understand or care what the code says.

By far the most likely outcome of this is that in the two months following 
its introduction, 95% of all commits are reverted, because the people who 
are supposed to be reviewing them don't spend any more time than usual 
reviewing them.  If I make a change to the preprocessor, HipHop, Sanitizer, 
SecurePoll, passwords, tokens, or any of a number of other things, I'm going 
to need Tim to review them.  I don't begrudge Tim the thousand-and-one other 
things he has to do besides review my code within 72 hours.  Does that mean 
that no one should make *any* changes to *any* of those areas?  More 
dangerously still, does that mean that **only people who can persuade Tim to 

Re: Code review process (was: Status of more regular code deployments)

On Tue, May 31, 2011 at 7:49 PM, Happy-melon <happy-melon <at> live.com> wrote:
> Every way of phrasing or describing the problem with MW CR can be boiled
> down to one simple equation: "not enough qualified people are not spending
> enough time doing Code Review (until a mad rush before release) to match the
> amount of code being committed".
>

Maybe people shouldn't commit untested code so often.

I'm not joking.

-Chad

Template:Extension

I changed the extension info box template:

added "open bugs", so that the info box footer now shows

    open bugs - all bugs

See example on http://www.mediawiki.org/wiki/Extension:OpenID
The extension status (stable, beta, ...) colour scheme is
http://www.mediawiki.org/wiki/Extension_status

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

Extension:OpenID trunk version: beta -> stable

Changed status of this extension to:

    stable,

because since January 2011, I discovered _not a single problem._

For legacy MediaWiki versions, I have working OpenID extensions as
"tarballs" for MediaWiki 1.15.1, 1.16.1.
Changes were not committed to the branches (no experience, how to do
this; no requests to do this; no time to do this).

Tom

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

Re: Code review process (was: Status of more regular code deployments)

"The Tiki community is a heavy user of SVN. While many open source communities have a
send-a-patch-and-someone-else-will-commit approach, in Tiki, we encourage everyone to commit
directly to the source code.  Think of it as applying the Wiki Way to software development. Over 220 people
have done it so far and it works very well."

http://dev.tiki.org/How+to+get+commit+access

I don't know if this is feasible in this community - but wanted to put it out is as a possible direction.

Best, Mark

On 31May2011, at 4:52 PM, Chad wrote:

> On Tue, May 31, 2011 at 7:49 PM, Happy-melon <happy-melon <at> live.com> wrote:
>> Every way of phrasing or describing the problem with MW CR can be boiled
>> down to one simple equation: "not enough qualified people are not spending
>> enough time doing Code Review (until a mad rush before release) to match the
>> amount of code being committed".
>> 
> 
> Maybe people shouldn't commit untested code so often.
> 
> I'm not joking.
> 
> -Chad
> 
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l <at> lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: Template:Extension

On 01/06/11 02:35, Thomas Gries wrote:
> I changed the extension info box template:
>
> added "open bugs", so that the info box footer now shows
>
>      open bugs - all bugs
>
> See example on http://www.mediawiki.org/wiki/Extension:OpenID

This is a very good idea! Thanks 

--

-- 
Ashar Voultoiz

Re: Code review process (was: Status of more regular code deployments)

On 31/05/11 23:13, Brion Vibber wrote:
> I tend to agree that a more active 'pull good fixes&  features in from
> feeder branches' model can be helpful, for instance in allowing individual
> modules, extensions, etc to iterate faster in a shared-development
> environment without forcing the changes to trunk/mainlines's production
> deployment&  release channels until they're ready.

What prevents us to actually implements this? We could just restrict the 
/trunk/ to a few merging people, they will only take care of merging 
revisions set from other branches.

Developers then build their fixes / features in their own branches and 
get it reviewed / signed-off by others.  Once done, it is submitted to 
the merge team.

This is much like the REL branches which only a few people are able to 
merge trunk changes in. Just with another layer 

The VCS would be up to the developer (thus solving the "migrate from svn 
to git" issue in the meantime). Subversion will only be used to actually 
merge patch sets in trunk or REL branches.

> But these need to be combined with really active, consistent management;
> just like keeping the deployment&  release branches clean, working, and up
> to date consistently requires a lot of attention -- when attention gets
> distracted, the conveyor belt falls apart and fixes&  features stop reaching
> the public until the next giant whole-release push, which turns into a
> circus.

Then we need merge windows. A date by which everyone would have to make 

Software "First aid checklist"

Hi developers,

for streamlining (my) support (to users), I created a kind of

    first aid checklist [1]

which I ask users coming with questions to read and answer first. If
possible.

- adapted to my needs
- comprises most of the questions and "have you already done this and
that" I needed to ask them over and over again
- currently not a template (I don't think that this is necessary or
useful at the moment)

You may also find it useful for integrating, adapting to your needs, on
your extension or whatever page/s.

[1] http://www.mediawiki.org/wiki/Extension_talk:OpenID#First_aid_checklist

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