s there's an upstream who responds, which in
this case there is.
I think the choice of platform matters when we're talking about "ease of
installation/upgrading" to some degree so we don't make the ops angry,
but that's a total non-issue with Gerrit because installa
could've had the same argument years ago and said
"why use a database, SVN stores information in a linear history
that's useful for articles." Having diverging articles may be cool/
desired, but using Git is not the answer.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
progress of my uploads
for 10+ years now.
> Many frameworks are available.
> See for example ownCloud http://owncloud.org/ http://gitorious.org/owncloud
>
Useless link. Could you link to the source that uses it so we don't
have to search through 15 git repos to find it?
-Chad
___
rver will do ;-)
But yes: thank you so much Ryan and Asher for taking care of
this!
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ere at least a bug for that?
>
It's because the URLs are based on who was using the wiki at the
time and caused the e-mail to be generated. If I'm using HTTP,
you'll get an HTTP e-mail.
Really, we should probably make this always fall back on HTTPS
when it exists.
-Chad
_
se that you've never touched is not usually
something people can pick up in an afternoon. I imagine most people try to
find something they do understand, grep around, and then slowly expand the
areas of code they know their way around.
It's just very enterprise-y Java. It's not real
ry profiling in ishmael which should assist with
>> further optimizations.
>
>
> I wish email had a "like" button. :-)
>
Me too. I've been wanting us to fix this ever since we were
forced to put them in different datacenters
ps bring it up on the talkpage?
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jul 5, 2012 at 7:04 PM, Chad wrote:
> On Thu, Jul 5, 2012 at 1:57 PM, Chad wrote:
>> Hi,
>>
>> Just giving everyone a head's up that we'll be upgrading Gerrit this evening
>> from 2.3 to 2.4.2.
>>
>> We're not expecting any extensive
On Thu, Jul 5, 2012 at 7:06 PM, Roan Kattouw wrote:
> On Thu, Jul 5, 2012 at 2:11 PM, Chad wrote:
>> Yes, but we can't even get people to type `php -l` before pushing,
>> which is why having Jenkins do this for us is crucial.
>>
> Yes, I don't disagree that jsh
On Thu, Jul 5, 2012 at 1:57 PM, Chad wrote:
> Hi,
>
> Just giving everyone a head's up that we'll be upgrading Gerrit this evening
> from 2.3 to 2.4.2.
>
> We're not expecting any extensive downtime for Gerrit, but we've scheduled
> a one-hour window from
hing,
which is why having Jenkins do this for us is crucial.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
reminder (and spam IRC) right before we begin the upgrade
process, and again when we're done. Please let me know if you have
any questions.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
core. My position hasn't changed in the past month and is
unlikely to change in the near future.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
e work when you want to stash it (and it should be
viewable by Gitweb, if you want others to see it).
Happy hacking!
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jul 2, 2012 at 10:45 AM, Niklas Laxström
wrote:
> I think the upstream keyword in bugzilla is useless. Can we replace it
> with a field which takes an url to the upstream bug report?
>
When I've filed an upstream but, I usually put it in the URL
field. Does that no
On Fri, Jun 29, 2012 at 7:23 PM, Platonides wrote:
> On 29/06/12 22:41, Marcin Cieslak wrote:
>> $ git reset --hard
>> HEAD is now at de13c31 Actually we have many contributors
>> $
>>
>> Chad, you made my day:)
>>
>> //Saper
>
> Great commit!
&
use the same repository on beta project, but
> right now it's really hard to test stuff submitted to gerrit because
> we need to merge stuff by hand.
>
I don't see any problem with this really, as long as the branches
don't get wildly out of s
On Mon, Jun 25, 2012 at 10:19 AM, Petr Bena wrote:
> This isn't discussion about git, but feeds we have in #mediawiki, feed
> from git is definitely not the only one
>
Then please feel free to move it to a better name. I really
don't care what the pa
But some people will
>> find it difficult because they would have to switch channels more
>> often.
>
> The problem is not as much as switching channels, but seeing the changes
> after the fact, when you'd have liked it 5 minutes earlier.
> A solution could be to config
asked to /ignore every random bot they see.
Is there some middle ground here?
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
nd wikitech-l isn't really the forum for that. Perhaps meta or
foundation-l would be more appropriate.
wikitech-l only would need to be involved once a decisions's been
made and there's technical details to work out.
-Chad
___
Well, -codereview isn't terribly active these days, since we've
moved off CodeReview and onto Gerrit, so there shouldn't be an
overall increase in announcements compared to what we're used to.
-Chad
___
Wikitech-l maili
we've had bots in the channel for years--I don't think another
weekend is going to kill us.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
me in #mediawiki
>
> If there was some problem we can always put it back, I moved wm-bot
> feeds for now to that new channel
>
Well let's not shut anything off in #mediawiki just yet. This has only
been on the list for an hour so let's allow some other
gt;
Well the IRC spam from L10n was a separate issue, that's been silenced.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ent discussion will follow to
the new channel and this is a bad thing.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Branch creation rights aren't something that can be assigned--I believe
it's hardcoded based on project ownership. That's something worth
investigating and fixing if possible.
-Chad
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikim
rhaps it would be simpler to just add the code
> snippet to [[MediaWiki:Vector.js]] for the duration of the cleanup?
>
Wikitech should probably be upgraded to something newer :p
Probably not worth adding Gadgets.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ut showing where you can fix it is what's most useful here.
Nobody wants to be at the top of the wall of shame, so they fix their
code and learn as a result. Something similar here would be useful.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
ocess is to ask on-wiki[0]. People have a chance to
give a quick yay/nay, and it's given out. I can't see any reason to say
nay :)
-Chad
[0] https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership
___
Wikitech-l mailing list
Wikitech-l@lis
rsonally think IE6/7 users would be better served by ditching
IE entirely--preferably to a WebKit-based browser. Others might
suggest Firefox. Others would say to grab the latest IE. There's
even some weird kids who might suggest moving to Opera ;-)
We should not implicitly advertising any browsers.
aders (roughly,I don't believe that number's ever been set in stone).
Once they are less than 1%, continue supporting unless it's a burden
to do so and/or makes support for newer browsers impossible. And lastly,
never purposefully break a browser if you can help it.
-Chad
__
On Wed, Jun 13, 2012 at 4:31 PM, David Gerard wrote:
> On 13 June 2012 21:29, Chad wrote:
>> On Wed, Jun 13, 2012 at 3:43 AM, Antoine Musso wrote:
>
>>> Organizing a logo context, just like we did for the Wikipedia logo, is
>>> probably the best idea. Thanks Trev
On Wed, Jun 13, 2012 at 3:43 AM, Antoine Musso wrote:
> Chad wrote:
>
>> What support would there be for changing the MediaWiki logo and
>> being consistent with it?
>
> That was asked back in Nov 2010:
>
> http://comments.gmane.org/gmane.science.linguistics.w
On Tue, Jun 12, 2012 at 8:03 PM, Tim Starling wrote:
> On 13/06/12 07:47, Chad wrote:
>> 1) It scales much nicer. The current version looks absolutely awful at
>> higher resolutions, and at lower ends becomes rather featureless. A
>> version natively designed as an SVG (but
d to update it on MediaWiki.org to match.
So...thoughts? Should we do this more formal-like in an RfC or
something? Other colors you'd like to paint the bikeshed?
-Chad
[0] http://commons.wikimedia.org/wiki/File:Mediawiki_logo_reworked_2.svg
[1] http://shop.wikimedia.org/p
Again, almost nobody should be affected (unless you've been adding
users), but just
FYI.
-Chad
[0] https://gerrit.wikimedia.org/r/#/admin/groups/119,members
[1] https://www.mediawiki.org/wiki/Git/Gerrit_project_ownership
PS: If you are do
e and dandy, but those kinds of "Please donate" pages in
software just scream "GIVE US MONEY" at me. Especially ones that
continue to pop up on each upgrade.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
th the production sites (yet). This is the way it's been for
years, and until we get more things available to labs, we should test our
code the way we've always done it--locally. I don't think it's reasonable to
hold up projects *just because* they haven't been through labs
the user would *also*
> need to include the math extension in LocalSettings. That line should go
> in the extension package, not in MediaWiki DefaultSettings.php
>
>
>
> = Summary =
> Out of 4 patches, only 1 seems to be 'useful'.
>
> Even that, it could be
I agree with Petr, I see no reason to put them on different wikis.
Namespaces are cheap.
-Chad
On Jun 7, 2012 11:20 AM, "Petr Bena" wrote:
> I don't understand why? Wikitech is a perfect place for bots
> documentation as well, especially when it comes to large bots oper
We should kill those distro-specific pages and I've been saying that for
years. Most of the advice ends up being rather generic, it forks the
content, and they generally end up being abandoned and out of date.
-Chad
On Jun 7, 2012 10:26 AM, "David Gerard" wrote:
> On 6 June
any of the mediawiki sites complete with all the tools to manage
> the software source code and the process of distribution. I would gladly
> assist in this.
Moving the distribution of MediaWiki off of mediawiki.org will just
fork the efforts in the long run, imho. I think we can accompl
On Wed, Jun 6, 2012 at 2:39 PM, Mark A. Hershberger wrote:
> On 06/06/2012 02:29 PM, Chad wrote:
>> Well since we introduced a CLI installer ...
>
> Side note: we re-introduced the CLI installer. I discovered this while
> tracking down ancient MediaWikis last week, an anc
at work
has been done (if any), but the groundwork's been laid on our end.
The other big complaint we've had over time is moving stuff around
to the typical Debian-esque locations (eg: putting LocalSettings in
/etc). Don't know what the status is on that though.
-Chad
_
On Tue, Jun 5, 2012 at 7:55 PM, Bergi wrote:
> Platonides schrieb:
>
>> On 01/06/12 17:41, Chad wrote:
>>>
>>> I did make a new "Project Creators" group that I'm more than willing to
>>> add
>>> people to, once they've lear
ncern as addressed and start handing out the
> rights?
> Diederik
>
I've whipped up a quick tutorial for people who want to create new
repositories[0]. If people can read and make sure they understand
this page (with its various caveats), then yes, we can start handing
this out.
-Cha
> productivity in Ori's case (for E3) since he's been unable to firstly get
>> gerrit access and then wait for someone from the release engineering team
>> to be available to create repos for him.
>
> Did anyway say, Ask about it? I'm sure if you followed up with t
discuss this almost a year ago?
Indeed, we did:
http://lists.wikimedia.org/pipermail/mediawiki-l/2011-July/037710.html
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
uld be deleted. We'd love to have some
> community support for this, if anyone wants to help out.
>
If we enabled wikitech as an import source for labsconsole, this process
could get underway. I'd suggest making some new category on wikitech
"Stuff to be moved to Labscons
So yeah, its not as easy as it sounds on the tin, so I don't want to hand
this out en masse. In an ideal world, I want us to have a special page
where people can request repos and we can automate the icky backend stuff.
-Chad
On Jun 1, 2012 10:33 AM, "Diederik van Liere" wrote:
>
On Thu, May 24, 2012 at 9:24 PM, Rob Lanphier wrote:
> Hi folks,
>
> Chad alerted me to the notes of the Gerrit Hackathon, which happened May 7-11:
> https://groups.google.com/forum/#!msg/repo-discuss/kEL3FPT2rLo/w39qjsmnrwwJ
>
> No one from WMF was there, but I thought you a
refs/for/`
If you want to change the default branch (say for a long-term
development branch), you can also change 'defaultbranch' in
your .gitreview file.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
open source? We've got tons of users on Windows and OSX,
shouldn't we mention their security releases too?
PHP/MySQL/Apache security releases that affect MediaWiki
are probably worth mentioning. $yourFavoriteSoftware is not.
-Chad
___
Wikitech-l
Yeah but its a PITA.
-Chad
On May 21, 2012 6:25 PM, "Roan Kattouw" wrote:
> On Mon, May 21, 2012 at 3:17 PM, Tomasz Finc wrote:
> > On Mon, May 21, 2012 at 2:25 PM, Mark A. Hershberger
> wrote:
> >> The Developer works with the Director to help the Director de
;
>> How is it related to this list?
> we all are heavily using open-source software, aren't we ?
> In short: you have been informed !
There are thousands upon thousands of open source projects
out there. Let's avoid spamming the list with their releases
unless its directly rel
On Mon, May 21, 2012 at 2:17 PM, Andrew Otto wrote:
> Chad, I'm not sure if this matters for what you are doing, but I recently
> moved this
> http://svn.mediawiki.org/viewvc/mediawiki/trunk/udplog/
> to
> https://gerrit.wikimedia.org/r/gitweb?p=analytics/udplog.git;a=su
for letting those original dates slip. I've got a bunch
of projects looking to make the jump to Git, that page included.
Looking to get this done this week.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimed
On Sun, May 20, 2012 at 2:44 PM, Antoine Musso wrote:
> Le 20/05/12 18:27, Chad wrote:
>
>> I personally think it'd be useful to avoid the "merge and immediately
>> have Gerrit yell because it needed rebasing" scenario. It's also been
>> pointed out t
and
> #semantic-mediawiki channels, and possible others as well.
>
We can already customize this on a per-project basis for IRC
reporting. Just submit the config change to hookconfig.py.erb
in the puppet repo.
-Chad
___
Wikitech-l ma
On Sun, May 20, 2012 at 1:45 PM, Platonides wrote:
> On 20/05/12 19:15, Jeremy Baron wrote:
>> On Sun, May 20, 2012 at 12:55 PM, Chad wrote:
>>> PS: Here's the default review rules
>>> http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog
On Sun, May 20, 2012 at 1:15 PM, Jeremy Baron wrote:
> On Sun, May 20, 2012 at 12:55 PM, Chad wrote:
>> PS: Here's the default review rules
>> http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/gerrit_common.p
>
> Make that
> http://co
e a working post-commit review
> workflow like we used to have, for those projects where gated trunk does
> not work due to lack of quick review.
>
I'm open to suggestions here. We could write some custom approval/review
rules in Prolog for extensions that want them (put them in ru
onally think it'd be useful to avoid the "merge and immediately
have Gerrit yell because it needed rebasing" scenario. It's also been
pointed out to me that it could be confusing to people as well to have
the button disappear.
Thoughts?
-Chad
___
wikimedia.org/r/#/c/8037/
Regarding extensions skipping review -- I agree this is totally evil
and it needs to change *right now*. I'm working on a way for
auto-approving of extensions that don't want to be reviewed. I'll
have more to say
On Fri, May 18, 2012 at 12:10 PM, Jeroen De Dauw wrote:
> Hey,
>
> Can some gerrit admin create two new (empty) git repositories named
> Wikibase and WikibaseClient with the wikidata user group as repo owner?
>
Please file a request on-wiki[0].
-Chad
[0] https://www.mediawi
ome guidelines if
extensions want to use them--but please let's tread carefully here. Shiny
new features are not always better features.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
h the "Force" option
checked.
Please revoke it as soon as you're done because it opens your repo
up to Breaking Things if people do forces all the time.
The actual push will be `git push -f [remote] [branch]`
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
will be on hand to answer any questions you have about
the git migration so far, the process moving forward, and
anything else interesting you can think up.
Have a great week, and I hope you can join us next Tuesday!
-Chad
___
Wikitech-l mailing list
Wik
rgely misused), I recategorized these 31 bugs and deleted
HP from the platform field.
A small victory, I suppose.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
as GPL 3.0 even though it
> is not explicitely licensed that way.
>
I'm not 100% sure what's being asked here? Is this a request to relicense
MediaWiki under GPLv3 instead of v2? Or is this a question of it being
mis-licensed under v3 when we actually specify v2? Clarification is
ne
On Wed, May 9, 2012 at 7:17 PM, K. Peachey wrote:
> On Thu, May 10, 2012 at 8:14 AM, Sam Reed wrote:
>> No history of these files have been imported.
>
> Any reason for this?
>
Some of them have had private info in them in the past
(usually by
is would be the same as querying "is:open CodeReview+2" in Gerrit[0],
but in a scriptable format. (There's also --format=TEXT if you're looking
for something a little more human-readable)
For full docs on the feature, see here [1]. Have a great week.
-Chad
[0] https://gerrit.wik
On Sat, May 5, 2012 at 7:46 PM, Siebrand Mazeland (WMF)
wrote:
> I like the initiative. I do wonder if it could have been embedded in the
> community more. Any comments?
>
I agree. This is the first I've heard of it either.
-Chad
njoy the new version of Gerrit. Please let me know if
you find any regressions.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
.3 which is slated to
happen this week.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Apr 28, 2012 at 8:42 AM, Stephan Gambke wrote:
> Am 28.04.2012 14:37, schrieb Chad:
>> If you start changing files or trying to merge branches then
>> you run the risk of getting conflicts...
>
> Even on files I did not even touch?
>
If you didn't touch them
is just: `git pull origin master`
If you start changing files or trying to merge branches then
you run the risk of getting conflicts, but there's zero reason
a simple clone & pull would conflict.
-Chad
___
Wikitech-l mailing list
Wikitech-l@li
On Fri, Apr 27, 2012 at 4:08 PM, Thomas Gries wrote:
> Am 27.04.2012 20:01, schrieb Chad:
>> Hi everyone,
>>
>> I've migrated the 22 extensions that were on the queue today.
>> I set permissions based on the requests--if anything needs
>> adjusting, just
Hi everyone,
I've migrated the 22 extensions that were on the queue today.
I set permissions based on the requests--if anything needs
adjusting, just let me know.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
's why we have the "gerrit 123" linking
in BZ.
> - Commit SHA-1s for deployment log entries and follow-ups to merged commits
>
We'd have to come up with an auto-linking regex for this.
Right now the I... hashes (gerrit change-ids) will auto-link
in the Gerrit UI.
-
gt;
If we're auto-generating a schema, I think putting comments
there are pretty useless. They should be documented at the
abstract level and on mediawiki.org.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>> That is it, I was +o.
>>>
>>> Is there any point in keeping the CIA bots in #mediawiki ? We might as
>>> well remove it.
>>>
I don't see any need to keep CIA around anymore.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
r and faster
>
I agree with Petr here. I think doing it like we do FileRepo stuff
would make the most sense--have an abstract base that can
either connect via DB and skip those HTTP requests (for in-
cluster usage) or via the API (3rd-party sites).
-Chad
_
This information is fetchable from refs/notes/review.
-Chad
On Apr 21, 2012 9:51 AM, "Platonides" wrote:
> On 21/04/12 04:18, MZMcBride wrote:
> > Regarding help, is the Gerrit commit metadata available in some
> replicated
> > form on WMF Labs? The Toolser
is is a good idea: the having to wait for a reviewer before
> your changes show up elsewhere is great for the core code, but not so
> great for fast-n-furious early prototyping of a big feature. Perhaps we
> can add it to gerrit once everyone thinks we have a mostly stable
> prototype?
>
n/management, extensions should
register these sorts of things there.
For now...is this an active problem, or are we just looking for one?
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
erride .gitreview in your git config?
>
Not that I know of. The best solution is just updating our
.gitreview files I guess.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
er traffic.
>
I think we should probably work on mediawiki.org (subpage of
RfC?). This is something that needs to be thought out properly,
and I think on-wiki would be more productive than on-list.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
as you're consistent
within an extension, the prefix can be anything that makes
sense.
For example, in CodeReview we use code_* for our table
names.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
the group in each item-row,
>> and
>> if the group has to change, no need to change all item-rows.
>>
>> -- Krinkle
>>
>
> Am I reading this right as suggesting and encouragement of database
> denormalisation in extensions?
>
You're right, I was thinking the same thing. I don't know why we'd
suggest such a thing :)
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
27;s disabled by default. We can link up on
IRC this afternoon and I'll tweak permissions to let you
push the new history and then disable that.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yes, but if you read the release notes for 2.3 you will see they've
upgraded to jgit 1.1.
I'd like to upgrade our gerrit install in a week or two.
-Chad
On Apr 15, 2012 3:34 AM, "Thomas Gries" wrote:
> Am 14.04.2012 20:17, schrieb Chad:
> > If you read my commen
t;
Everyone: either keep it on topic (namespace changes and making
sure the right people are notified) or take it offlist.
Thank you.
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If you read my comments on that bug you will see I believe it is an
upstream issue and is probably fixed in 2.3.
-Chad
On Apr 14, 2012 12:31 PM, "Thomas Gries" wrote:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=35949
> I think, this issue should be solved as soon as p
such things in git without hacking stuff, and
they're evil. If we're going to version API modules, we should
come up with some other standard that doesn't rely on commit-
rewriting magic.
-Chad
___
Wikitech-l mailing list
Wik
> Initialized empty Git repository in /work/tmp/core/.git/
> *error: RPC failed; result=22, HTTP code = 500*
>
> My git client version is 1.7.1
>
> Any idea why ?
>
Perhaps related to issue 769?
-Chad
[0] http://code.google.com/p/gerrit/issues/detail?id=769
_
On Wed, Apr 11, 2012 at 12:03 PM, Petr Bena wrote:
> On Wed, Apr 11, 2012 at 5:47 PM, Chad wrote:
>> On Wed, Apr 11, 2012 at 11:15 AM, Petr Bena wrote:
>> If this is done properly with classes and ids, this should all be
>> customizable by via site CSS/JS. But a sane defau
ole interface using MediaWiki:
> pages, the table with drafts could look better or the style should be
> customizable using interface of mediawiki.
>
If this is done properly with classes and ids, this should all be
customizable by via site CSS/JS. But a sane
701 - 800 of 1648 matches
Mail list logo
