On Tue, Aug 13, 2013 at 4:01 PM, Rob Lanphier wrote:
> On Tue, Aug 13, 2013 at 3:18 PM, Chad wrote:
> > You can rely on the Gitblit urls, they're not going anywhere or changing.
> >
> > Gitweb I had been making promises of killing for a long long time (and
> > n
we are
with Gitblit and partial url rewriting from the old Gitweb stuff.
> Also
> on the mirroring on repos to GitHub. I got quite a few things that will
> break if changes are made to it in non-bc way.
>
What do you mean?
-Chad
___
Wik
> >>
> >>
> >> On Sun, Aug 11, 2013 at 12:51:15PM +0200, rupert THURNER wrote:
> >>>>>
> >>>>> As chad points out, its being served now
> >>>>
> >>>>
> >>>> it's plura
this :(
>
>
We fixed this Thursday or Friday? https://git.wikimedia.org/robots.txt WFM.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
from outside.
>
>
> Is there anywhere they're actually listening? That's really not
> something Google is good at.
>
I decided to not care about the problem very much since I
assumed Google wouldn't either.
-Chad
___
W
s://en.wikipedia.org
> https://www.ssllabs.com/ssltest/analyze.html?d=en.wikipedia.org
>
>
We do better than the check site itself ;-)
https://www.ssllabs.com/ssltest/analyze.html?d=ssllabs.com
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jul 29, 2013 at 4:14 PM, Tim Starling wrote:
> On 29/07/13 16:09, Chad wrote:
> > I've always been in favor of getting rid of voting entirely since
> developers
> > don't use it for judging anything. Tried to once before, but people seem
> to
> > like
in Monday morning Prague
> time, but I just figured I'd mention this quickly.
>
I've always been in favor of getting rid of voting entirely since developers
don't use it for judging anything. Tried to once before, but people seem to
like using it for
quot; language should be suitable to build OS.
> Perhaps Zend VM could be "beefed up" itself to make PHP the same class as
> Java.
And on that note, this thread (like the other one) has run its course.
Like that one, I recommend everyone going back to y
go back to
watching silly cat videos or whatever else you like to do in your
spare time.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ho knows how it's gonna look like in few years
> given this python-epidemy :))
>
>
It was designed to do that from the get go. It's not Personal Home Page
for nothing ;-)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.
e tool you feel most
comfortable with because for all practical purposes it won't matter at all.
That being said, there's some things that each language may excel at, so
picking the right tool for the task at hand is important.
And no matter the tool,
your patience, help, bug reports, blood, sweat,
tears, firstborn
children...whatever you gave to this monumental effort over the past year
and a half.
I'm thinking of switching to Source Safe next year because migrations are
so fun ;-)
-Chad
___
Wikitech
On Tue, Jul 23, 2013 at 11:01 PM, K. Peachey wrote:
> On Wed, Jul 24, 2013 at 3:58 PM, Chad wrote:
> > Things should be much better since this afternoon.
> >
>
> You gave into the server kittehs demands for fresher tuna?
>
>
I blocked silly Chinese and Korean web spi
pens quite often for the last days:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=51769
>
>
Things should be much better since this afternoon.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[14:54] <^demon> !ask del
[14:54] Successfully removed ask
-Chad
On Tue, Jul 23, 2013 at 2:53 PM, Tyler Romeo wrote:
> Yeah I agree. Whenever I see it used I cringe a little bit thinking about
> how the other person is reading it.
>
> --Tyler Romeo
> On Jul 23, 2013
It's been flakey the past few days. I've been trying to get to the
bottom of it.
-Chad
On Tue, Jul 23, 2013 at 12:28 PM, Derric Atzrott <
datzr...@alizeepathology.com> wrote:
> Afternoon,
>
>
>
> Anyone else having issues getting at Gitblit? I've not bee
>
This isn't a good analogy. Assuming we'd had visual editing since
day 1, I would presume we wouldn't have had source editing...a
better way would be to say "if we'd had VE since day one and we
were trying to add source editing, would there be an
ain, I'm usually the first to say "yes, kill the preference" but really
we've
got a dozen more screwed up preferences and this one is completely sane.
I'll also mention it seems to have overwhelming support from both the
community as well as some other developers.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
Easier said than done. I've been fighting this fight for years and we're
only about 3 globals closer to doing so. I'm totally in favor of getting
rid of global scope usage, but let's please not trivialize the amount of
work it will take to get there.
-Chad
__
g me it's like cpan just brings back awful awful memories...
And a developer, please don't *require* me to use Composer. Don't want
it, don't need it.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
You're not convincing me ;-)
-Chad
On Jul 22, 2013 9:06 AM, "C. Scott Ananian" wrote:
> On Mon, Jul 22, 2013 at 12:00 PM, Mark A. Hershberger >wrote:
>
> > On 07/22/2013 11:43 AM, Chad wrote:
> > > Telling me it's like cpan just brings back awful awf
hat
extension that someone has installed. Sure you can grep mw/extensions,
but that only goes so far.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Jul 16, 2013 at 5:03 PM, Chad wrote:
> Hi everyone,
>
> So, we've got a bad disk on the Gerrit box that needs to be swapped out.
> This is going to
> cause a little bit of downtime while we fix things up. Therefore, Gerrit
> will be unavailable on
> Thursday
and going for 1 hour (until 15:00 UTC). Hopefully it won't take the full
hour, but I'd like to be
cautious :)
If you have any questions, please feel free to ask them here or e-mail me
privately.
Thanks for your understanding!
-Chad
___
Wik
Well, it's not a product (yet), so there's no place in BZ to
file bugs (yet). I assume any bugs or feedback could be
provided in this thread though :)
-Chad
On Sat, Jul 13, 2013 at 9:43 PM, Brandon Harris wrote:
>
> This isn't a product, so there isn't a place
;t have to wait till April 2017 when that LTS
> goes EOL before we can kill PHP 5.3.
>
I doubt it. I imagine we'll look to the new LTS when it comes out.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
eally a goal with this project as we'd
never use it on WMF sites.
Solr, while still an external dependency, at least doesn't require people to
build and configure a basically undocumented WMF-specific system to
have a sane search.
-Chad
___
;ve been updated already (if they're not, be bold ;-)). I'll be
trying to fix
the performance issue (lucene sucks) tomorrow, as well as setting up some
redirects from the old gitweb urls.
-Chad
___
Wikitech-l mailing list
Wikitech-l
(now-misnamed) file is rather ugly. Not that the existing file isn't
> also ugly, just less so.
>
I'm with Brad. Considering we document this in the tree and on
mw.org, I'm not entirely sure what the benefit of having it done
via Doxygen is.
-Chad
_
stall -U git-review". Then you need to create
> a configuration file: either /etc/git-review/git-review.conf (system-wide)
> or ~/.config/git-review/git-review.conf (user-specific).
>
Bummer we can't just use ~/.gitconfig, but hey, it's still an improvement :)
-Chad
_
n about both? ;-)
But you're right, using skins for this smells funny, and a dedicated "Turn
on experimental features" option makes a lot more sense to me.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wik
rginally faster (like, half a ms), then the reduced
output probably saves more in the long run. But without actual numbers
we're really just guessing at possible micro-optimizations.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
y items.
>
> So my question is if the byte reduction is really worth it, or if we would
> rather have a 37% reduction in escaping speed?
Sounds like you're comparing apples to oranges here. What
happens to the speed when you change Html::element() an
fix this.
FWIW, the request routing stuff is neat, but it's probably overkill
for what we're needing here. Incremental improvements can be
made to the bootstraping if anyone is brave enough to play with
Setup.php ;-)
-Chad
___
Wikitech-l
Making entry points isn't straightforward (which is why I suggested
maintenance), but it can be done.
We really need to cleanup the bootstrap process.
-Chad
On May 22, 2013 8:48 AM, "Tyler Romeo" wrote:
> What exactly do you mean by "load MediaWiki"? What's
Deprecated means we don't use it and other people shouldn't either. I think
you mean superseded, which an argument that can be made here. However, all
I've seen is vague hand waving about performance concerns.
-Chad
On May 20, 2013 9:32 AM, "Tyler Romeo" wrote:
> O
Where was any discussion regarding this? Or pointers to where it's been
causing problems.
-Chad
On May 19, 2013 11:35 AM, "Matthew Flaschen"
wrote:
> On 05/18/2013 03:40 PM, MZMcBride wrote:
> > These two diffs explain what happened better than I could. I think this
Yea, it's definitely being used. I've not heard of it causing problems, so
this deprecation is news to me.
-Chad
On May 18, 2013 2:53 PM, "Bartosz Dziewoński" wrote:
> Foreign file repo is using action=render to get file descriptions from a
> remote wiki. (I think th
n plugins, etc.
>
This pretty much makes the whole proposal a non-starter. Perhaps
we could look at it later once it's released under an OSI-approved
license[0].
-Chad
[0] http://opensource.org/licenses
___
Wikitech-l mailing list
Wikitech-l@lis
Wouldn't a purge also create refreshlinks jobs?
-Chad
On May 14, 2013 1:19 PM, "Brian Wolff" wrote:
> You can clear your job queue (run all jobs in it) by running
> maintenance/runJobs.php and disabling user write access temporarily to
> prevent new jobs from being cre
ed an acceptable usage of static functions.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, May 14, 2013 at 2:59 AM, K. Peachey wrote:
> On Tue, May 14, 2013 at 4:43 PM, Matthew Flaschen
> wrote:
>> Or set up some caching on Gitweb, so it's usable for this kind of thing.
>
> I believe Chad is planning on sending Gitweb to /dev/null/, in-turn
> for a
On Sat, May 11, 2013 at 3:31 AM, Dmitriy Sintsov wrote:
> On 10.05.2013 17:58, Chad wrote:
>>
>> On Fri, May 10, 2013 at 8:05 AM, Jeroen De Dauw
>> wrote:
>>>
>>> Hey,
>>>
>>> I can see why SPL might require extra work in HipHop to sup
ndalone implementation of PHP and
doesn't even really know about the php binary/libraries.
> Suggestion: If such a policy is implemented, I'd be great to have a job
> that checks for violations of it on our CI.
>
This is a very good idea, and something I'll take a stab at
eard HH didn't support them - is
> it safe to assume that support for them is coming?
>
Yes. As I understood it yesterday, this is just about to land in
master.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ye!
-Chad
On May 10, 2013 9:36 AM, "Brion Vibber" wrote:
> Yes, kill it with fire!
>
> -- brion
> On May 9, 2013 9:44 PM, "Daniel Friesen"
> wrote:
>
> > This one will probably be more controversial than my RDFa 1.1 RFC.
> >
> > I
we can either get it
fixed or turn the
feature back off (if it's patently broken).
Thanks!
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
MSSQL support is completely unmaintained.
-Chad
On May 9, 2013 12:09 PM, "Beebe, Mary J" wrote:
> Thanks for your very quick response.
>
> What about MSSQL?
>
> Thanks,
>
> Mary Beebe
> Battelle - Charlottesville, VA
> Office: 434- 951-2149
>
>
>
ping :)
Just for comparison, when you're doing a `git push origin master` (a
la Github), you're actually
just typing the shorthand version of `git push origin
refs/heads/master:refs/heads/master.`
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, that was the point of [[Git/Getting started]] because the Workflow
document sucks.
-Chad
On Wed, May 8, 2013 at 12:41 PM, Petr Bena wrote:
> I was using these tutorials in past, and they were pretty complicated
> for me to understand git. I don't say it should be cons
d eventually help
> some.
>
We've got [[Git/Workflow]], [[Git/Tutorial]] and [[Git/Getting
started]] (in decreasing
order of complexity/depth), so I would be hesitant to add yet another
howto page.
Considering this is supposed to be quick-and-easy docs, I&
u don't have permission to view deleted revision
> information"
> }
> }
>
For a personal wiki, this means you need the 'deletedhistory' and 'deletedtext'
permissions (which is by default assigned t
On Tue, May 7, 2013 at 3:07 PM, Bartosz Dziewoński wrote:
> On Tue, 07 May 2013 21:00:05 +0200, Chad wrote:
>
>>> The current process for release notes is fine; we just need someone to
>>> write
>>> a custom merge driver for JGit to avoid the merge conflicts. Thi
ne.
>
As I said many times before, this isn't really necessary since JGit now
supports recursive merges, it's just experimental so I hadn't turned it on.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
27;s no way in Gerrit either. I imagine like most hit counters (eg:
MediaWiki),
it'd be a huge drain on performance and caches mostly throw it off.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Apr 30, 2013 at 10:59 AM, Bartosz Dziewoński
wrote:
> On Tue, 30 Apr 2013 16:32:17 +0200, Chad wrote:
>
>> What about the Drafts extension?
>
>
> It seems to be slightly different, saving the drafts server-side instead of
> client-side, and apparently only on dem
What about the Drafts extension?
-Chad
On Apr 30, 2013 10:27 AM, "Bartosz Dziewoński" wrote:
> Somebody tried to implement that in MediaWiki core about a year ago:
> https://gerrit.wikimedia.org/**r/#/c/5130/<https://gerrit.wikimedia.org/r/#/c/5130/>.
> It turned out t
don't know of any WMF wiki that actually uses this, though.
>
This is actually the fundamental difference between FlaggedRevs
and PendingChanges (even though they're the same extension).
For the period of time that enwiki was using PendingChanges, it
was in this configuration.
-Chad
ech.wikimedia.org-2013-03-26
> I don't actually remember if I had completed the mirror but the size seems
> reasonable so I may. :)
>
Um, what stuff was lost? The page histories were all imported,
so stuff like the server admin log are there.
-Chad
___
Sorry everyone, was trying to ease the tension.
-Chad
On Fri, Apr 26, 2013 at 7:42 AM, Sumana Harihareswara
wrote:
> Cool it, Chad.
> -Sumana
>
> On 04/26/2013 07:33 AM, Chad wrote:
>> Look ma, I'm a lawyer!
>>
>> I'll note that yesterday I was a firema
Look ma, I'm a lawyer!
I'll note that yesterday I was a fireman.
And an astronaut the day before.
Isn't pretending fun?
-Chad
-Chad
On Apr 26, 2013 7:25 AM, "Sumana Harihareswara"
wrote:
> Luis, the thread:
> http://www.gossamer-threads.com/lists/wiki/wikitech
On Fri, Apr 19, 2013 at 3:02 PM, Chad wrote:
> Hi everyone,
>
> As you may have remembered reading. Huib--our longtime volunteer moderator
> for mediawiki-l and wikitech-l--resigned from his positions back in
> February[0].
> I let this slip longer than I should've, but I
lead section for one article but in the third
> section for another article this is bad from a user experience point
> of view.
>
I believe (anecdotally) that it's more often used on meta-style pages
(policy and discussion) where you want a couple of secti
lf. So is one approach preferred?
>
Special page, special page, special page. Actions suck.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We've also made a few improvements to Gerrit over the past week that should
help with stability and performance.
-Chad
On Apr 20, 2013 10:26 AM, "MZMcBride" wrote:
> Antoine Musso wrote:
> >Le 11/04/13 00:12, Jon Robson a écrit :
> >> Is anyone able to look in
volunteer. I'll give it a couple of
days for people
to think about it and e-mail me, and I'll pick some people by late next week.
Thanks, and have a good weekend :)
-Chad
[0] http://lists.wikimedia.org/pipermail/wikitech-l/2013-February/066320.html
s not match m/wiki/i. Please consider your
> audience before spamming hundreds of recipients.
>
> Thanks.
>
He spammed a number of lists. I've put him on moderation.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
unicorn kills a
> kitten :P
>
> Think of the kittens, don't blink ;)
>
Webkit doesn't support blink. Looks like Gecko may follow:
http://developers.slashdot.org/story/13/04/09/1445233/gecko-may-drop-the-blink-tag
So many kittens can now grow up ;-)
-Chad
_
We found him. He was playing in the dirt. He's
a very bad boy and has been punished.
-Chad
On Mon, Apr 8, 2013 at 8:47 PM, Tyler Romeo wrote:
> Jenkins is lost in the WMF network right now. Operations is in the process
> of searching subnets, but if we can't him, he's like
Yes, Jenkins is broken right now.
-Chad
On Mon, Apr 8, 2013 at 8:13 PM, Matthew Walker wrote:
> Does anyone know what this means:
>
> mwext-CentralNotice-merge : LOST
>
> ... or why I'm getting:
> "Please wait while Jenkins is getting ready to work
> Your browser
rl+F/Ctrl+G to
> search for the new reviewer's name.
>
> It's already filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=46792
>
This used to work, but the output format changed a couple of upgrades
ago. The hook scripts for
On Mon, Apr 8, 2013 at 3:05 PM, Yuri Astrakhan wrote:
> // Some magic method to add the entire message map into message cache
> messageCache->Add('custom-key1', $messageMap);
>
So, we used to have a $messagecache->add(), but it was removed
after a very very
On Thu, Apr 4, 2013 at 11:28 AM, Max Semenik wrote:
> On 04.04.2013, 19:17 Chad wrote:
>
>> On Thu, Apr 4, 2013 at 11:15 AM, Max Semenik wrote:
>>> On 04.04.2013, 16:04 Tyler wrote:
>>>
>>>> I still fully maintain that entirely static classes is
ve private variables,
> allowing to hide implementation.
>
And variables inside a global function are also scoped, so they
don't leak implementation either. The point is semi-valid for
functions, though.
-Chad
___
Wikitech-l mailing list
W
On Wed, Apr 3, 2013 at 1:55 AM, Chad wrote:
> Hi all,
>
> tl;dr: I've cleaned up the mediawiki/core repo, and performance for
> fetch/clone
> operations should be noticeably faster.
>
I've now done this for all other repositories, so everyone should
see the benef
; extensive, so switching to something more sane seems quite feasible.
>
It's like a global, only slower :D
If you've got any better ideas, I'm all for it.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
tion living on mw.
>
I totally support this.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Apr 3, 2013 at 1:55 AM, Chad wrote:
> I've now run this on mediawiki/core, and the repo went from 3.0G down to
> ~620M on disk.
>
I copy+pasted this wrong. This is actually 323M on disk. To give you an
idea of the kind of savings we're looking at for fetch & clone,
y faster--a fresh clone should now only be
limited by your
bandwidth, not how fast Gerrit can serve the repo from disk.
If you notice *any* problems with mediawiki/core, please let me know
immediately.
If everything looks good, we'll set this up as a cron to run weekly or
something
ntirely comfortable fetching it from MediaWiki.org on
the fly--but we can host the code within Gerrit.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 21, 2013 at 10:42 AM, Thomas Gries wrote:
> Am 21.03.2013 15:23, schrieb Chad:
>> You're confusing opcode caching with shared memory caching.
> thanks, as already mentioned, I anticipated that difference.
>> Having the Zend
>> Optimizer doesn't pr
g APC's shared memory caching. And
since Zend Optimizer doesn't do shared memory functionality, there's
no "support"
that needs to be added anywhere (now, if they introduce such a feature, that's
another story).
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
nce regressions (and fixes) were
introduced in the
course of just 1.6.x.y.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Mar 12, 2013 at 6:24 PM, MZMcBride wrote:
> I recently tripped across <https://wikitech-test.wmflabs.org/wiki/> which
> is using an interesting skin, but I'm not sure which.
>
I believe this was based off twitter
bugtracker.
>
I'd say the opposite is true--the vast majority of extensions in Gerrit *do use*
bugzilla.wm.o. Granted, some may not, so having a tracker uri would also be
nice (if not the default).
-Chad
___
Wikitech-l mailing list
W
oved, things accidentally checked
into ./extensions, etc. This could potentially greatly reduce object sizes
and allow for tighter repacks. Major issue with history rewriting is
everyone will have to reclone (all sha1s would change). I've not tested my
theory yet.
I'm open to any other ideas
ews there.
> We do not (yet).
You're joking, right?
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ime (nor do I really see it
as worth the effort).
Getting Github PR into the Gerrit ecosystem is on the Gerrit roadmap,
but we don't have a firm date just yet. I plan to announce this much
more widely when we're close to that.
-Chad
Those tags are arbitrary :(
-Chad
On Mar 7, 2013 12:09 PM, "Petr Bena" wrote:
> ah ok I was confused by it being flagged stable
>
> On Thu, Mar 7, 2013 at 8:35 PM, Tyler Romeo wrote:
> > On Thu, Mar 7, 2013 at 2:32 PM, Petr Bena wrote:
> >
> >> I just d
I care how our code is licensed (and headers are great for doing this),
but wasting 60+ e-mails over where to include these licenses just to satisfy
an overzealous tool...that's bikeshedding.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
he vast majority of the list (and I've always been an
advocate for the usefulness of this list).
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There's some upstream developers working on a github plugin. I was going to
mention it once there was something worth showing (which there isn't yet).
-Chad
On Mar 5, 2013 9:39 AM, "Jon Robson" wrote:
> I was wondering what the latest on this was (I can't seem to fin
defeats
part of the point)--and I think that "web labels" idea is equally silly.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
o
have people who want/use MSSQL, so I think taking the effort to
keep it working is worthwhile--if someone's willing to commit.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
bypassing review. (which makes sense if you look at the history)
> Maybe not updating the parent repo is a gerrit bug.
>
The auto-updating submodule magic only works if you're pushing
through Gerrit. Skip Gerrit, and you don't get the benefits of the
magic submodules.
-Chad
;ll go through a full change of putting the release
notes together. Then if any other things are done before the
release, you just submit another commit to it.
See:
https://gerrit-review.googlesource.com/#/c/39210/ and then
https://gerrit-review.googlesource.com/#/c/42790/ and
https://gerrit-rev
On Fri, Mar 1, 2013 at 2:59 PM, Daniel Friesen
wrote:
> On Fri, 01 Mar 2013 14:45:14 -0800, Nischay Nahata
> wrote:
>
>> On Sat, Mar 2, 2013 at 3:16 AM, Chad wrote:
>>
>>> Hi,
>>>
>>> This is a friendly reminder to everyone about the preferred
Well, that's true if you're only building release notes by copy+pasting
the first line. If it's scripted, it's trivial to pull the bug # from the footer
as well.
And no, commit messages cannot be auto-generated by Gerrit, as
that changes the sha1.
-Chad
On Fri, Mar 1, 2
Change-Id: Ia90.
"""
So when you do this, you're able to search for "bug:1234" via Gerrit.
By doing this, you're also removing it from the first line (which was
our old habit, mostly from SVN days), providing you more
401 - 500 of 1648 matches
Mail list logo
