Dreamwidth Development

Rough outline of workflow -- aka let's talk

2012-05-17T15:45:34Z

I've been reading up on Git, trying to figure out how to document a process that works for everyone, and it just isn't working. All I know is how I want to do things, and I can only guess what would work best for everyone. So instead of my sitting here writing down guidelines, which might get set in stone even if they don't really work for you, let's actually talk about it, and then document the hell out of what we decide on.

Big bold critical disclaimer: If you are uncomfortable with really vague instructions and a process that might break at any point, just hang back and wait! This is the "We need people to try doing this so we know where the major stress points are" step.

Other disclaimer: We'll document what seems a reasonable way to do things to make it easier for anyone coming in, but that doesn't mean you need to stick to the script strictly. You can manage your code on your end however you'd like -- so long as you send that pull request!

Useful links:

github:help -- check out the beginner and intermediate sections, as well as further git resources. I don't think we'll need anything from the other sections, until we run into specific issues.
Git flow -- abstraction on top of Git to make the most common workflow more convenient

( here's what we need to figure out )

comments

Workflow overview

2012-05-11T01:20:45Z

After a bunch of discussion, we've decided to move from Mercurial to Git. Mercurial and Git are different version control systems. If you're not sure what that is, they basically manage code and the history of how the code has changed.

One big reason for using Git is Github. Github is a service that hosts code, and provides web-based tools to manage commits and reviews. This will make it a lot easier to work collaboratively, and simplify the process of submitting patches. The changeover may be a bit of a pain, but we will work to make it as easy as possible!

We've also decided to simplify our development environment. Instead of having the $LJHOME directory contain a bunch of repositories that need to be synced and copied around -- no one has ever understood this setup without a lot of explaining and re-explaining -- we will just have one set of directories. This means we can get rid of cvsreport.pl, which is the script that does the syncing between the $LJHOME directory and the repositories within it.

Nothing will change yet, but I thought (and denise agreed) it might be a good idea to post a very basic overview of how the process will be changing.

I'm still banging on the workflow; right now I'm just working with a couple of the more experienced devs so we can get a general idea of what needs to be done. We'll invite more people for a test run once to iron out the more fiddly bits once we have a list of steps to try.I expect we'll have to adjust again after people have tried it out for real.

Don't worry! Nothing is going to happen without a lot more in the way of information and tutorials and explanations, but here is a very high-level overview.

( diagrams and details within )

comments

dw_dev @ 2012-05-07T19:19:00

2012-05-07T12:07:46Z

I did a quick run through of a changeset submission process with exor674, one for Mercurial and one for Git.

Assumptions:

pulling from the dev branch back to stable is roughly equivalent between Git and Mercurial, or is easy enough to work around on the committer side, so this is not shown here.

we want to move away from asking for patches, to pull requests which include more context

we need to concentrate on the branching workflow. We will encourage branching even for small bugfixes or feature development, to make it easy for devs to pick up a different bug once they have submitted a pull request for what they are currently working on.

This is particularly important because we get devs that happily submit their first patch, and then get frustrated trying to clean up their repo when working on their second. This may also be useful when we discover that tweaks need to be done on review. Instead of doing:
1. clean up old/current work
2. grab patch from zilla or a saved file and reapply
3. do tweaks
4. generate a new patch containing the original patch + changes requested
We might do:
1. save current work on current branch
2. switch to previous branch
3. do tweaks
4. submit pull request again, with the tweaks as a separate commit
Thus the emphasis on branching in this run through.

we're trying to analyze the core features to determine whether they can work the way we need them to, so we've left github and bitbucket out of the equation (except as ways to make the code public)

( mercurial workflow using bookmarks )

( Git workflow using git branches )

Summary of what we found:

When using Mercurial bookmarks, we ran into an odd(?) issue where we lost track of where we were branching from (what would, in git, be the branch "master"). I'm assuming this is a bit of a workflow thing, and we can work around by creating the new bookmark upstream or master, so we could get back to the point in our repo before we started making any changes

Same issue, but this time from the committer side? or, since we've merged at this point, and won't need to eep track of bookmarks, perhaps less of an issue?

What am I doing when I pull then remove the bookmark? I ... managed to merge, right? That's what I did?

Commit messages are now an issue. We standardized around a commit format containing the bug id, commit message, and patch author and enforced it by having the committer supply the commit message.

Now, we'll either need to enforce a strict policy on commit messages before accepting the commit, or have the committer amend the commit messages beforehand. Other options are to make the changelog hook smarter (detect things of the form "Bug #"?), use a "changelog_bot" for all commits. We might also want to look into having the committer sign off the commit.

*Finally* this might become a moot point, depending on what's available to us from github/bitbucket that will let us put stuff into the changelog community.

need to determine what happens if you try to amend someone's commit in Mercurial by running it through MQ in order to fit guidelines above *points up*. At a guess, we'd end up with a dangling commit that would need to be stripped out of the submitting dev's repo, because the changeset hashes would no longer match

git index! oh git index. You might be a pain. The question is, are you a pain that can be hidden away?

it's much easier grokking branches, IMO, than bookmarks, because there's never any risk of forgetting where "master" is.

git lets me do a merge commit, in order make sure that the bug number is mentioned in a related commit. *Might* be a bit of a moot point if we end up doing a rebase instead of a merge

comments

Process documentation needed: automated test suite

2012-05-06T07:08:58Z

crschmidt pointed out in his bug walkthrough that the process of running the automated test suite is not very well documented! And I agree; I know I don't run the tests when I'm patching things since I don't really know much about it, and I don't contribute tests along with my code because I actually don't know how to write them or what they should do. I am probably not the only one! (The only thing I know about the test suite is that you shouldn't run it in production because it does weird and wonky things to the database.)

I do know that our test suite coverage is not extensive at all, and we've talked before about moving to a more test-driven devlopment mindset. If anybody wanted to write up some documentation on the Wiki about both how to run the tests (and what you should look for) and how to write new tests (and when you should), that would be awesome and I would love you forever. (Well, I mean, I love you all forever already. But I'd love you more forever.)

comments

hg branching

2012-05-04T05:53:56Z

per fu and pau's requests, A POST ON BRANCHING. [insert meme with a post on top of a tree branch]

hg branching falls into one of several models:

- clone branching

clone branching is where to make a line of development you execute an `hg clone`, do your development on that copy, and then push/pull back to the mainline. This has the advantage of being the simplest; it also has the disadvantage of being easy to mislay a given clone or to not correctly annotate what that clone does with a rename. It may also be very funky to get this to work right for a DW dev environment if I remember how those work right.

- bookmark branching

bookmark branching is like git branching. git branching is like hg bookmarks. (circular reference. :-) ) You have a name that you have to manually push/pull. Commits usually advance the name of the bookmark as you might expect. These branches can be deleted. So in order to create a branch...

`hg bookmark vlion_sweet_branch`, and then do your development on it, merging as needed from your mainline branch (which should also be bookmarked to be your stable/test branching). Push out to the server with hg push -B vlion_sweet_branch. They do have to be manually pulled, which hg tends to be a bit reluctant to about exposing to the other users. It never says, "Here are teh new bookmarks!"

Bookmarks can be deleted, which is good if you don't want bookmark names cluttering up your namespace.

You only need 1 repo to do development on with bookmarks; switching between bookmarks is as simple as `hg up bookmark_name`.

- named branching

Named branches are what I use at $DAY_JOB. They are permanent. They are very similar to bookmarks, but merging is a little different; the new branches don't actually merge (I can create graphs if wanted). Named branches do get sent up to the server and automatically downloaded.

These are more appropriate in situations where you want to track what happened when and where.
E.g., release is a named branch I frequently use. `Testing` is another.

---

One approach that seems like a good idea at this time to me is to have a `release` branch, a `test` branch, and a `dev` branch. Patches are developed on bookmarks referencing bug#, splitting off of `dev` until they are done... when the patch is basically done, it's merged into dev. Then when a push seems good, it gets merged by Fu (or other project lead person) into `test` and whatever tests she thinks is good are run... if it's still good, it gets merged to release and is live... if it's bad, then more work on dev is done until it's fixed.

YMMV, and "it seemed like a good idea at the time" doesn't always work out in practice. This sort of approach is fairly enterprise in how it is designed, and might not fully flow with how DW development works.

HTH,
~V'lion

P.S.,
I'm going to be functionally unavailable until Monday to answer questions (travelling), but I will do my best to answer all questions, even if it's a delayed answer.

comments

Code Tour - 12th March to 1st May

2012-05-03T23:08:06Z

Whew, my first code tour! This broke my mind a bit in places, and I think I mostly failed at the "being funny" part, but I hope it helps you understand what Dreamwidth has been up to!

( 28 bugs )

Aaand that's it for now.

comments

The death of cvsreport.pl

2012-05-01T06:52:40Z

All the talk about version control systems is great, but when fu and I sat down tonight to talk about the feedback and figure out where to go next, we realized that there's one thing that really complicates the whole situation horrendously: cvsreport.pl and overlaid repositories.

Therefore, it should die. This should happen before we go down the garden path to version control nirvana, so we're going to tackle this. It started tonight and will continue to happen until we get it taken care of.

The plan right now:

* Any modules that are on CPAN should be installed via CPAN or your local package manager. We should not be distributing files locally from random repositories. Dependency management is a burden we should offload where possible. Since we already have bin/checkconfig.pl which people should be running, we can use that to ensure people have the packages needed installed.

* External programs like Perlbal, MogileFS, ddlockd, etc should be managed separately. Since most of them aren't even necessary, we can just offload this to the person who wants to install a production quality system. (And honestly, with the advent of fpm this isn't a huge burden, building packages is so incredibly easy now.)

* Small utility files that were in various repositories (the s2 stuff, miscperl, etc) we will just fold in to dw-free. It adds very little burden to us and it makes things more sane.

* ssldocs should just mirror htdocs. We can't see any harm in allowing all URLs to be valid SSL URLs. This is a necessary step before we roll out an "ssl-everywhere" option for people, so we should just bite the bullet and do it.

This does not solve the problem of dw-nonfree yet. We have some ideas, but those depend on if we end up going with git or hg or whatever. For now we're going to put that off to the end and solves the above dependency issues first and then we'll go from there.

Comments, questions?

comments

Git, Mercurial, github, bitbucket

2012-04-29T18:54:10Z

I want to spin off a new post from the log of last night's IRC developer meeting. The topic of GitHub came up in the meeting, and some concerns with that idea have been raised in the comments of the previous post. vlion's concerns largely address the difference between mercurial and git, whereas karelia's concerns also address that difference but touch incidentally on the hypothetical benefit of working in the more public environment of Github.

I was talking to allen and he pointed out that there are really two different issues in play here, because we can go to a shared, public, relatively popular, FLOSS-friendly environment without ever leaving mercurial, namely, Bitbucket.

I'd actually say there are three questions:

Are there benefits to git over mercurial, and if so, are those benefits enough to outweigh the cost of switching to a new source control system?
Would we like to move our source control management to a public, shared, FLOSS-friendly environment? If so, why? Do we think it would be more friendly to our current developers, do we think it would make it easier to bring in new developers, some combination of the two, or something else?
If we want to move to a shared environment, do we feel that there is a strong reason that it should be Github? What are those reasons, if so? If we think git is worse than mercurial, but we do think there's a benefit to moving to Github, which reason should prevail?

Actually, we should probably add a fourth question, which is "would any of our needs be better served by using mercurial more in the fashion for which it was intended?"

Keep in mind when I write these questions that I use github for other projects and like it,and I have never used mercurial intensely enough to have strong feelings about it either way. Personally I fell in love with Perforce at an early date and find all other VCS systems to be it pale yet free imitations. But I do think that if we make a switch like this, these are the questions we need to answer.

comments

April irc dev meeting log

2012-04-29T07:35:24Z

Well, I managed to sleep through the meeting and mark was fixing the database comment limits problem, so the meeting started a little late. (It's a good thing we're cute?)

Here's the log, lightly redacted to remove discussion of personal and offtopic stuff (and to remove irc administrivia like joins and parts). We'll do this again in a few weeks!

( Meeting log )

comments

dw_dev @ 2012-04-26T20:23:00

2012-04-27T00:29:43Z

Applications to attend AdaCamp DC are now open! All y'all who are in/near DC should definitely attend. (It's an "application" in that the Ada Initiative will be doing basic screening to make sure people have a basic level of participation in open stuff and are not likely to be disruptive of the feminist goals.)

I will be there, and the rest of y'all should be too!

comments

April irc dev meeting

2012-04-26T20:57:45Z

The Doodle poll has spoken, and the time that works for the most people unfortunately doesn't work for mark, so we'll be using the second-most-popular time:

Saturday 28 April 9PM EDT - 11PM EDT (1AM GMT - 3AM GMT)

My apologies to those of you in EU timezones; our next meeting will be scheduled to be more convenient for y'all!

The meeting will begin precisely at 9PM EDT in irc (irc.freenode.net, channel #dreamwidth-dev) and will definitely run for at least two hours (if discussion is going well, we may continue a little past the 11PM end time). The meeting will be logged and logs will be publicly posted (lightly edited) to dw_dev afterwards.

If you have anything in particular you'd like to put on the agenda for discussion, leave a comment. Otherwise, the agenda will be "let's all talk about awesome things we are doing".

comments

YAPC::NA

2012-04-25T05:11:58Z

YAPC::NA is 30 registrations away from selling out (according to a blog post earlier today), eep! If you're planning to come and haven't contacted me about it yet, please register yourself ASAP and we'll reimburse you.

EDIT: Going by my registration #, there's only 6 slots left, and the pre-conference workshop has sold out. I'm so sorry, I didn't realize the conf was so limited-registration -- I'll see if I can find something comparable later in the year!

comments

April Dreamwidth dev irc meeting

2012-04-21T21:51:14Z

We've spoken in the past about having semi-regular dev meetings in irc, where everybody who's interested can gather in #dreamwidth-dev and have a conversation about what we're working on, what our priorities are, what interesting things have happened, what problems we've run into that others can learn from, what questions we've had itching at us that haven't been answered yet, what kind of help we can use, help-wanted requests for for a pair programmer/UI specialist/frontend person/backend person/someone to crack the whip/someone to bounce ideas off of/etc. (Not to mention, "let's bug denise about stuff we need that hasn't been done yet"!)

fu, mark, and I have all had periods of feeling really isolated and disconnected from each other and from you guys lately, so we're going to give this a try on a pilot basis. 'Staff meetings' will be held every few weeks. We'll log the channel during the meeting, and post the logs afterwards, so those who can't make a particular meeting or those who can't/don't use irc can still get the information. Because of the international nature of our contributor base and the fact that many of us have weird sleep schedules, the meeting times will rotate: if the times for meeting #1 are more convenient for EU people, we'll try to make the next meeting more convenient for US people and the one after that for AU people, etc.

Anyone who does any kind of DW work is welcome -- this isn't dev-specific, but at first we'll definitely be dev-focused, since we have a few ideas we'd like to start exploring for the dev process and we'd like to encourage more collaboration and team programming.

For the first meeting, I've picked a few random-ish times next weekend to try to find one that will work for the majority of people. If you are interested in attending, please fill out the Doodle poll linked below, with your DW username and the times that you would be available to attend! (If you have accessibility problems with it, let me know privately and I'll add your information for you -- I don't know how Doodle is on accessibility.) The poll has 9 separate times, chosen more-or-less at random/on a whim with a US-based audience in mind this time. By default the poll "accordion-collapses", so hit the accordion fold to expand it and get all the times.

Please vote by Tuesday; we'll set the time then. "Yes" means you'd definitely be able to attend at that time, "No" means you'd definitely not be able to attend at that time, and "(Yes)" means you might be able to attend but it would be inconvenient for you. The times should theoretically update to account for timezones (going by your IP and the reported geolocation thereof) but if that doesn't work for you, the poll was created in EDT; to tell if your timezone is being accurately set, the first option is 27 April at 8PM EDT. You don't need a Doodle account to answer the poll.

Fill out Doodle poll

comments

Some tools for S2 patching

2012-04-19T06:05:37Z

...mostly because as anyone who gets all the bugzilla and/or style notifs knows, I did a lot of that this week *g*

First, preview images - I'd been doing them with Ubuntu's screenshot utility and photoshop, which is 1) really slow and 2) doesn't really adequately strip and compress images. So! Enter Screen Capture for Google Chrome, which I've been using with the 'full page' setting, and set to skip pop-ups and save straight to a temp image directory, where I can then rename the screenshots. After that, geekosaur and exor674 (with a little sideline ImageMagick input from tamouse_ helped me write this handy little shell script, to process all the pngs in the directory you run them on - it resizes them, crops them, strips color profiles, and indexes them.

I've been using it on my own machine, as I run Ubuntu, but I believe all the appropriate packages are now on the Dreamhack server, too, for server-side use.

Second, rb posted a handy little script for sorting properties for color themes and generating appropriate headers. I updated it to match our current formatting for files, add sorting for a few more properties, and output more verbose instructions on what to do next at the end.

#!/usr/bin/perl
#
#

my ( $theme_human, $author_name, $layout_human, $is_nonfree ) = @ARGV;

sub diehelp {
    warn "Syntax: newtheme ThemeName AuthorName LayoutName IsNonfree";
    exit;
}

if ( !$theme_human ) {
    warn "No theme name provided.";
    diehelp;
}
if ( !$layout_human ) {
    warn "No layout name provided.";
    diehelp;
}

( $layout_name = lc ( $layout_human ) ) =~ s/\s//g;
( $theme_name = lc ( $theme_human ) ) =~ s/\s//g;

my ( @dropped, @css, @set, $in_css );
while ( <STDIN> ) {
    my $line = $_;

if ( $in_css ) {
        if ( $line =~ m/"""; }/ ) {
            $in_css = 0;
            next;
        }
        push( @css, $line );
    } elsif ( $line =~ m/function Page::print_theme_stylesheet/ ) {
        $in_css = 1;
    } elsif ( /^\.$/ ) {
        break;
    } else {
        next unless $line;
        if ( $line =~ m/^layerinfo / ) {
            push( @dropped, $line );
            next;
        }

push( @set, $line );
    }
}

# process @set lines
my ( @unknown, @presentation, @page, @entries, @modules, @fonts, @images );
foreach ( @set ) {
    if ( /userlite_interaction_links = / || /_management_links = / || /module.*order/ || /module.*show/ ) {
        push( @dropped, $_ );
    } elsif ( /font/ ) {
        push( @fonts, $_ );
    } elsif ( /module/ ) {
        push( @modules, $_ );
    } elsif ( /entry/ ) {
        push( @entries, $_ );
    } elsif ( /comment/ ) {
        push( @entries, $_ );
    } elsif ( /links/ || /layout/ ) {
        push( @presentation, $_ );
    } elsif ( /color/ ) {
        push( @page, $_ );
    } elsif ( /image/ ) {
        push( @images, $_ );
    } else {
        push( @unknown, $_ );
    }
}

my $filename = "$ENV{LJHOME}/temp/$layout_name-$theme_name.s2";
open TMP_FILE, "> $filename";

print TMP_FILE <<"EOT";
#NEWLAYER: $layout_name/$theme_name
layerinfo type = "theme";
layerinfo name = "$theme_human";
layerinfo redist_uniq = "$layout_name/$theme_name";
layerinfo author_name = "$author_name";

set layout_authors = [ { "name" => "$author_name", "type" => "user" } ];
EOT

# print @set lines
sub print_section {
    my ( $name, @lines ) = @_;

if (@lines) {
        print TMP_FILE<<"EOT";

##===============================
## $name
##===============================

EOT
        foreach ( @lines ) {
            print TMP_FILE $_;
        }
    }
}

print_section( "Presentation", @presentation );
print_section( "Page", @page );
print_section( "Entry", @entries );
print_section( "Module", @module );
print_section( "Fonts", @fonts );
print_section( "Images", @images );
if ( @css ) {
    print TMP_FILE "\n";
    print TMP_FILE 'function Page::print_theme_stylesheet() { """' . "\n";
    foreach ( @css ) {
        print TMP_FILE "    " . $_;
    }
    print TMP_FILE '"""; }' . "\n";
}
print_section( "Unknown - DELETE THIS SECTION after reclassifying lines", @unknown );
print_section( "Dropped - DELETE THIS SECTION after verifying none of it is needed", @dropped );
print TMP_FILE "\n";
close TMP_FILE;

print "Parsed theme now saved in file: $filename\n";
print "Be sure to check this for hardcoded font sizes and color codes that can be shortened.\n";
print "This new text needs to be put into the existing file named:\n";
print "$ENV{LJHOME}/bin/upgrading/s2layers/$layout_name/theme.s2\n\n";
if ( @images ) {
    print "This layout appears to have image(s). Change their url to $layout_name/$theme_name(_imagename, if multiple), rename the image to $theme_name(_imagename), and put in:\n";
    print "$ENV{LJHOME}/htdocs/stc/$layout_name/$theme_name.png\n\n";
    }
print "Theme also needs a preview screenshot. Resize to 150x114px and put in:\n";
print "$ENV{LJHOME}/htdocs/img/customize/previews/$layout_name/$theme_name.png\n\n";
print "(for additional reference on cleaning themes, see http://wiki.dwscoalition.org/notes/Newbie_Guide_for_People_Patching_Styles#Adding_a_New_Color_Theme )";

This is written to be used server-side right now, with a command-line input like './newtheme.pl "Human-Readable Theme Name" user "Layout This Theme Is For" yes < inputfile' I've been running it client-side by changing line 74, 'my $filename = "$ENV{LJHOME}/temp/$layout_name-$theme_name.s2";' to 'my $filename = "temp_themes/$layout_name-$theme_name.s2";' (otherwise it tries to write to root, and That's Bad. And unnecessary)

Third, for the tiny handful of people doing S2 work on gedit (shhh, I like it, okay), I made some mods to the CSS syntax highlighting file (pastebin because the file is big). I tried to get it to make a custom S2 language, but it was being fussy about parsing it, and a lot of the .s2 files are largely CSS anyway. So this adds highlighting for S2 variables and S2 keywords! It goes in a file called CSS.lang in home/.local/usr/share/gtksourceview-2.0/language-specs, which will probably not exist if you haven't made custom languages. If you're on newer versions that use GTK3, that 2.0 should be a 3.0. You may have to manually select the highlighting, for some reason it only registers the .s2 extension some of the time.

comments

\o/

2012-04-19T01:16:22Z

While looking for something else tonight I wound up running the "resolved/fixed" Bugzilla query, and sometime between the last time I looked and now, we have passed 3000 fixed bugs. (3068, to be precise.) That's only bugs that were resolved with an actual change, patch, or other action, too; if you count duplicates, invalid bugs, things that were fixed-by-proxy, stuff we decided not to do after all, etc, that number goes up to 3469.

Since we started using Bugzilla for keeping track of our tasks in mid-January of 2009, that gives us a rate of approximately 1000 bugs fixed per year. I think that is pretty fucking awesome.

comments

Reminder: conference sponsorship

2012-04-18T07:00:27Z

This is your naggy reminder that we still want to register you for YAPC::NA and the Zero to Perl workshop in Madison in June! If you are interested, email me (denise@dreamwidth.org) to let me know. I will probably be making the first round of registrations later on in the week, and I'd like to get a feel for how many people other than me and Mark will definitely be attending.

comments

Should we have a Mobile section in Bugzilla, or at least a why-mobile tag?

2012-04-15T04:56:06Z

Pros for: helps turn mobile development into an easily sectionable project and focus, which is good, because mobile is an important thing since more and more computing is being done on mobile devices. Without a category, or at the very least a "why-mobile" tag, there's no easy way to pull up work that specifically relates to mobile initiatives.

Cons against: so many categories already, I know we're reluctant to add to that.

We might also want a "mobile" tag on dw_dev!

(This post inspired by somebody asking after mobile initiatives in dw_dev.)

comments

Code tour: 24th March--11th April

2012-04-12T00:45:15Z

All aboard the code train! Today we'll be stopping at 12 stations...

( Read more... )

This train terminates here. Thank you for travelling with dw_dev; we hope you enjoyed your journey, and we trust we'll see you again soon. All change please.

comments

Many Eyes Wanted

2012-04-09T00:43:52Z

As http://bugs.dwscoalition.org/show_bug.cgi?id=4408 has the potential to blow up a lot of things/break a lot of things if I screwed up, I want as many eyes on that patch as possible.

Make sure that I have:

not told DW::Controller::controller to ignore the form_auth check when it is important to do one and I am not doing a check myself
did not supply form_auth => 0 and no form auth exists in the actual form ( either because it's not a "dangerous" action or that one should exist )

This change will also affect pages that are not supposed to be POSTed to ( and hence have no form auth ) -- would this be a problem or can we live with it?

---

Second thing: I noticed a few pages that are devserver only, except we do the check inside the handler sub. I am of the mind that these should not even end up in the routing table at all unless we have devserver enabled ( DW::Controller::EventOutput for one example ) -- thoughts?

comments

iDreamwidth code

2012-04-08T05:43:30Z

Hi,

I was wondering what had happened to the iDreamwidth app & code. Rumor has it that the developer disappeared after the GSOC 2010. I am interested in perhaps getting the app or maybe working on it... possibly helping admin the source control and such if I am not enough of an Objective C guru.

Anyway! What's the status? Does anyone have the code?

comments

RFD: changing the default value for $TRUST_X_HEADERS on development servers

2012-04-07T17:13:47Z

$TRUST_X_HEADERS is a configuration variable you should set to true (1) if you're using proxy you control and trust (eg, perlbal), so you can retrieve the real (external) source IP address of incoming requests, instead of seeing them as coming from 127.0.0.1 or the IP address your proxy/load balancer/whatever runs on. By default, it's 0, but for dreamhacks and other development hosts, that default isn't practical, so instead of making it default to 0 (with a commented-out line in etc/config.pl to change it to 1), I would make it default to the value of $IS_DEV_SERVER if not defined, with commented-out lines in etc/config.pl to force it to either 0 or 1.

This shouldn't affect production servers, who likely have IS_DEV_SERVER set to 0 and TRUST_X_HEADERS set to 1 already, but it might affect production servers, if any, with unexpected configurations, and the change may surprise developers who didn't set TRUST_X_HEADERS explicitely, so I'm throwing this for discussion here in case I missed some pitfalls, or if there's a way to make it better. I'm also opening a bug linking here, so whatever the outcome of the discussion is, it doesn't fall through the cracks.

comments

Site Messages: do we use these at all?

2012-04-03T07:07:10Z

I'm doing a little before-bed Template Toolkitting as a before-bed easy coding thing--I was thinking of converting the site messages area of the admin to TT, but I'm also wondering if we use it at all, or have plans of doing so, in case what I should be doing is figuring out how to jettison it?

comments

Conference sponsorship

2012-04-03T05:58:57Z

I am pleased to announce that this trend of "people giving us money" seems to be continuing, which means that we want to spend more money on y'all. (LET US SPEND MONEY ON YOU. REALLY. STOP THAT IMPOSTOR SYNDROME THINKING RIGHT NOW YES YOU I KNOW WHAT YOU'RE THINKING SO JUST STOP IT I MEAN IT IF YOU ARE READING THIS I MEAN YOU. YES YOU.)

If you have submitted at least five patches to us (since the DW project began) and at least one patch in the last year, we want to register you for YAPC::NA, the Yet Another Perl Conference in Madison, Wisconsin on June 13th - 15th. (Or, if you're not in North America, we'd be happy to send you to a local Perl conference of similar cost, if you know of one.)

There's also a two-day "Zero to Perl" workshop that I will be attending, and if you're newer to working in Perl (or to programming in general!) and think that you'd get some use out of it, I'd love for you to come keep me company. We'll also pay the registration fee for that workshop.

The small print: We reserve the right to put a cap on the number of attendees we send. (We're thinking a limit of 20 people total, and 4 people for the workshop; this may be adjusted based on interest.) I'm not sure yet if we'll register you and pay the conference directly, or if we'll ask you to register and pay and reimburse you; it depends on interest level and on how easy the conference makes it to do third-party invoices. We cannot, unfortunately, pay your travel costs (hotel or airfare) -- this year, at least! who knows about the future? If you almost qualify but not quite, you can have until the end of May to get your five patches in. If travel cost is prohibitive but there's more-local conferences or training you'd like to attend, let me know and we'll see what we can do. To take advantage of this, contact me at denise at dreamwidth.org and let me know you're interested, and we'll go from there.

And, a reminder, if travel isn't possible for you for whatever reason, we still want to buy you books or other resources!

(I really, really mean it on the impostor-syndrome thing. I have heard at least three of you who would qualify under the buy-you-stuff guidelines say that you don't think you do enough for DW to 'deserve' it. TOTALLY NOT TRUE. If you're coding for DW, we want to give you the tools to do it more efficiently and with greater skill. Period, end of sentence, full stop.)

EDIT: pauamma has also linked me to YAPC::EU, which will be in Frankfurt, August 20-22. Mark and I will not be able to go to that one, but if you're in the EU and that would be cheaper/easier/more convenient for you to go to, we can totally talk about sending you to that one! I can't say for sure that we'd be able to -- I need to research costs a bit more, etc -- but do check it out.

comments

Enabling beta features on your hack

2012-03-29T02:37:42Z

So, if you're looking to test/develop with the beta journal jquery or the upcoming update page, you are going to need to set the BETA_FEATURES hash in your hack like so:

    %LJ::BETA_FEATURES = (
        "journaljquery" => {
            start_time  => 0,
            end_time    => "Inf",
        },
        "updatepage" => {
            start_time => 0,
            end_time => "Inf",
        },
    );

You can then turn things on/off for individual accounts at: [YOUR_HACK_URL]/betafeatures

comments

Code tour: 14 Mar - 23 Mar

2012-03-24T06:14:45Z

Behind the cut: 12 resolved bugs, all of which are now live (thanks to tonight's code push).

( HOLY CRAP IT'S A CODE TOUR GET IN THE CAR )

As I mentioned, all of these fixes are live! You may need to opt in to the new Javascript on journals beta to see some of them. (Please do -- this is now the release candidate and we're trying to get as many eyeballs on it as possible.)

comments