April irc dev meeting log

[denise]

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!




9:53:57 PM: xb95: so, welcome everybody!
9:54:08 PM: xb95: I'm sorry we're starting late. best laid plans etc.
9:54:19 PM: Sophira: Hi!
9:54:20 PM: foxfirefey: I'm so glad we're starting late! I got stuck in traffic!
9:54:29 PM: Clifstan: Hi
9:54:31 PM: xb95 shakes his fist at Seattle.
9:54:31 PM: foxfirefey: I even tried logging in on my boyfriend's mobile phone but it wasn't working very well.
9:55:30 PM: xb95: This is designed to be a very free-form, open-ended discussion.
9:55:59 PM: xb95: The goal is to get a bunch of folks who are in the DW development group together to discuss, chat, etc.
9:56:36 PM: xb95: So feel free to jump in at any time. :)
9:56:58 PM: xb95: Anyway!
9:57:03 PM: xb95: Hi, welcome, etc.
9:57:23 PM: xb95: I think I'd like to kick this off with topics anybody wants to submit to discuss, so we can have a good list of what is important to hit up.
9:57:49 PM: xb95: There were a few comments on the dw_dev post, would anybody like to add anything else?
9:57:57 PM: foxfirefey: I promised vlion I'd ask about where code for projects from the GSoC might have ended up.
9:58:38 PM: exor674: I know the... poll improvement and stats.. { those WERE two, right? } got merged
9:58:48 PM: Sophira: I'd be interested in discussing how to do a particular bug that I'm eyeing up.
9:59:35 PM: Sophira: Not sure whether that's something appropriate for these meetings or not, though.
9:59:41 PM: Sophira: Let me know if it isn't!
9:59:48 PM: exor674: Sophira: I don't think you really need *ALL* the people around for that
9:59:55 PM: xb95: Sophie -- we can definitely hit that, probably twoards the end tho!
9:59:58 PM: exor674: I'm not saying it's not appropriate, but
10:00:13 PM: xb95: right, fey
10:00:16 PM: xb95 takes notes
10:00:16 PM: Sophira: Okay.
10:00:56 PM: xb95: okay, so, I'll go with that and if anybody thinks of anything in the meantime, fire away. plus the few subjects on the dw_dev post
10:01:42 PM: xb95: so on a meta, organizational level, let me start there.
10:01:58 PM: xb95: Apologies for being slightly disorganized, the 2^24 issue kind of threw me off of my expected prep :)
10:02:14 PM: foxfirefey: Very understandable!
10:03:03 PM: Sophira: Hmm. Actually, I think I may be getting rather drowsy. - it's 3am. I probably won't last long.
10:03:16 PM: Sophira: So ignore my thingy :)
10:03:35 PM: xb95: first up -- you all are awesome, and I want to be very up front and say thank you to all of you for your efforts on dreamwidth. it blows my mind how much dreamwidth has been growing in the past six months, and that's because
10:03:40 PM: xb95: we've built a site that people have decided to call home.
10:03:48 PM: xb95: a site that people are proud and happy to use
10:04:17 PM: xb95: and it got built because of the blood, sweat, and tears of all of you :)
10:05:37 PM: allendw: yay blood, sweat, and tears!
10:05:46 PM: allendw: (wait, was that not the applause line?)
10:05:46 PM: xb95: hehe
10:05:55 PM: allendw: :D
10:06:01 PM: xb95: well, I don't know, I like a challenge and usually am happy after a tough battle with the code monster
10:07:10 PM: xb95: I was hoping rah would be here to talk more about organizational direction stuff. I don't know what she had in mind for that.
10:07:34 PM: xb95: I can say that we're trying to figure out how to get to a point where I can be back on DW fulltime.
10:07:40 PM: foxfirefey: Oh fancy
10:07:57 PM: Sophira: And what a wonderful day that will be!
10:08:33 PM: exor674: xb95: easy solution to that! Moar profits!
10:08:36 PM: xb95: hehe
10:08:52 PM: xb95: and as true as that is, I can never bring myself to prioritize the $$ projects
10:09:23 PM: xb95: priority has always been, and I want it to always be, on what the community really needs
10:09:27 PM: xb95: on how to really make the site bettert
10:09:28 PM: exor674: what? no "charge users .00075 per comment loaded"
10:09:42 PM: foxfirefey: Well, getting vgifts out would probably help a bit
10:09:49 PM: xb95: yeah, vgifts would be nice to get out
10:09:51 PM: foxfirefey: They're most of the way there
10:09:57 PM: foxfirefey: Kareila's done a great job
10:09:59 PM: xb95: I'm honestly not sure what they still need
10:09:59 PM: xb95: yes
10:10:13 PM: exor674: what's missing on the implementation?
10:11:04 PM: xb95: fey, do you knwo?
10:11:18 PM: foxfirefey: I do not, offhand
10:11:29 PM: exor674: and is it anything that can/is desired to be done by someone else
10:11:34 PM: xb95: bug 215
10:11:37 PM: Bugsy: Bug http://bugs.dwscoalition.org/show_bug.cgi?id=215 enhancement, P5, L - Launch, kareila, IN_PROGRESS , Implement v-gifts
10:11:52 PM: xb95: last touched 2010
10:11:58 PM: xb95: all the patches are marked as committed
10:12:09 PM: xb95: you know, it's probably the UI stuff
10:12:17 PM: xb95: the admin UI?
10:12:22 PM: foxfirefey: I know there's an admin UI
10:12:22 PM: exor674: admin exists
10:12:29 PM: foxfirefey: Because I've been looking at it for possible TT conversion
10:12:44 PM: foxfirefey: I've been doing that some evenings, because it's not high-load thinking to do
10:12:52 PM: foxfirefey: And the admin area is good practice to convert
10:13:03 PM: xb95: right
10:13:07 PM: xb95: let me comment and ask what the current state is
10:13:13 PM: xb95: it sounds like it's mostly done
10:13:24 PM: xb95: and if so, we should definitely put some time on that
10:13:24 PM: foxfirefey: That's the impression I've gotten
10:13:31 PM: exor674: Speaking of the TT conversion... I think at some point within the next year we should stop accepting patches to existing BML pages ( that are not OH SHIT SECURITY HOLE/performance OMG ) or something like that. Thoughts?
10:13:55 PM: exor674: maybe with some leeway for other reasons { existing work, the page in question is talkread/talkpost, etc }
10:14:24 PM: deborahGU: I am all in favor of that if it can be made workable. I don't think anybody ENJOYS having to edit BML
10:14:28 PM: xb95: yes
10:14:34 PM: geekosaur: was going to ask how that would work with talkread/talkpost :)
10:14:43 PM: foxfirefey: I need to sit down and add more info about TT-izing
10:14:46 PM: foxfirefey: I've added a couple hints
10:14:51 PM: exor674: hopefully we can kill talkread at some point soon
10:14:57 PM: deborahGU: it might involve a developer commitment to say "we will hold your hand if the bug you have taken on involve converting something to tt and you didn't think that was what you signed up for "
10:15:00 PM: foxfirefey: But I'm starting to read the point where I can start making a better guide
10:15:03 PM: xb95: I am also in favor of that, but I want to be careful not to make it impossible for less experienced devs to contribute patches
10:15:04 PM: foxfirefey: *reach
10:15:23 PM: exor674: xb95: yeah, I just want to give ttization another huge shove
10:15:28 PM: xb95: agree
10:15:55 PM: Sophira will admit that at this point in time she actually finds the idea of editing TT to be less enjoyable, but that's because she doesn't know TT or how it's used. I know you can use Dre's tool to find out what file does a particular URL, but that's about it.
10:16:29 PM: foxfirefey: Sophira: I think once you get more comfy with it, you'll like it
10:16:39 PM: foxfirefey: It helps split up the code parts from the display parts
10:16:42 PM: Sophira: It would be nice to have some sort of introduction to TT for people who are more used to BML at the moment.
10:16:46 PM: deborahGU: exor674: would you be able/willing to make a dev post at some point about the state of the project?
10:17:11 PM: exor674: deborahGU: in what way? I'm not opposed, but I'm not sure what kinda state we need
10:17:41 PM: Sophira: The non-straight mapping of URL to file makes things a bit harder, but I suppose I probably shouldn't complain about that because I suspect it's a rather minor thing.
10:17:45 PM: deborahGU: I don't know, just like a log of how it stands now, how much is done, how much is left to be done, rough estimates. Where it would be appreciated if other people decided to help out.
10:17:46 PM: jeshyr oopses in late, sorry. Here now.
10:17:54 PM: exor674: besides that all our siteschemes are now TT { besides global, but that's for reasons }
10:18:02 PM: exor674: heh, yeah, I can probably dig stats on that up
10:18:14 PM: deborahGU: :D
10:18:16 PM: exor674: Sophira: that makes things a whole lot more powerful, though
10:18:35 PM: xb95: awesome, dre, thank you
10:18:35 PM: Sophira: exor674: I know. That's oartly why I don't want to complain about it.
10:18:44 PM: Sophira: ^partly
10:19:36 PM: xb95: alright, so summary, dre will post some stats about the TT migration, fey is going to work on improving the guide, and let's aim for .. maybe by the end of 2012, we stop accepting patches to BML unless they're security
10:19:47 PM: foxfirefey: Sounds like a lpan
10:20:10 PM: foxfirefey: Maybe we could make a list of "most needed translations" to try and make it so the pages most people would want to change would already be translated
10:20:15 PM: exor674: xb95: maybe leave talkread in that group, unless that ends up being the last straggler or we move to siteviews for that
10:20:20 PM: xb95: right
10:20:20 PM: xb95: a
10:20:23 PM: xb95: a prioritized list
10:20:38 PM: Sophira: "Translations" is probably a bad word, but yes. :)
10:20:51 PM: exor674: I have a list somewhere of BML pages by conversion difficulty
10:20:56 PM: xb95: dre: leave talkread == don't migrate it? b/c we're moving to the siteviews?
10:20:58 PM: exor674: from trivial to "uh, poke Dre"
10:21:02 PM: exor674: xb95: yeah
10:21:05 PM: xb95: hehe nice list
10:21:31 PM: exor674: and a few that were marked "can't go away at this point"
10:21:43 PM: jeshyr: should I know what a siteview is?
10:21:53 PM: exor674: jeshyr: the s2-in-sitescheme style
10:22:14 PM: xb95: siteview makes it so we don't have to maintain parallel codepaths for site-scheme and separately thee S2 stuff
10:22:19 PM: exor674: yeah
10:22:23 PM: xb95: which makes modifying the whole flow way, way easier
10:22:37 PM: xb95: in other words a kick-ass project and dre is awesome, but we knew that
10:22:40 PM: xb95: :)
10:22:52 PM: exor674: I think we're actually going to kill the monthpage in bml soon
10:22:53 PM: exor674: foxfirefey: ^^ status?
10:23:11 PM: exor674: I don't recall if your shiniyness covered that page
10:23:14 PM: foxfirefey: I just need to CSS the month page that exists for siteviews S2 fallback some
10:23:21 PM: exor674: ta
10:23:24 PM: xb95: nice
10:23:27 PM: foxfirefey: I could definitely work on that some tonight
10:23:35 PM: foxfirefey: I've done pretty much every single other page in all the site schemes
10:23:41 PM: foxfirefey: archive, tags, etc
10:23:47 PM: foxfirefey: Although I want to add some things
10:23:52 PM: foxfirefey: They're at least readable
10:24:12 PM: xb95: another upcoming-ish project is recurring billing. this is probably squarely on me, but I mention it for completeness. as much as I hate messing with payment stuff, it would be great for us to have monthly options for people
10:24:38 PM: foxfirefey: Yes, that would be a good revenue booster
10:25:30 PM: jeshyr: definitely
10:25:31 PM: Sophira: Ouch. I don't know that looking at this as a revenue booster is a great idea, considering that the only revenue it would pick up that it wouldn't otherwise have would be from people who can't turn it off.
10:25:43 PM: foxfirefey: Sophira: I disagree
10:25:59 PM: Sophira: (Because those people who would use it would pay anyway)
10:26:03 PM: jeshyr: I don't think that's right Soph, heaps of people forget to pay who'd *prefer* monthly billing as a general rule (not DW-specific I mean)
10:26:26 PM: foxfirefey: I'm one of those people--I'd sign up for recurring billing, because it would be nice, and I like to support it
10:26:27 PM: Sophira: O hwait.
10:26:28 PM: exor674: having to remember to pay *can* be a burden
10:26:30 PM: deborahGU: Sophira: not DW-specific, but I give more money to charities that let me do it on an automated monthly recurring basis
10:26:40 PM: Sophira: Monthly billing. I thought we were just talking of recurring billing.
10:26:58 PM: foxfirefey: The other thing it helps with is evening out cash flow
10:27:00 PM: exor674: I think that'sw what was meant
10:27:09 PM: foxfirefey: It helps to know that X people in general will pay X a month
10:27:10 PM: jeshyr: Sophira: Who'd be under the category of "can't turn it off", anyway? Nobody should be in that group as far as I know?
10:27:32 PM: exor674: That may be easily implementable as a 2-part thing
10:27:42 PM: exor674: Automatically refill my points to X if they drop below
10:27:53 PM: xb95: you can still pay the same as now, with the monthly or whenever you want
10:27:54 PM: exor674: and then grab from the points balance
10:28:12 PM: xb95: but some people really hate having to dig out their credit card every few months. I do. so I personally sign up for monthly
10:28:17 PM: exor674: that might add complication, bleh
10:28:47 PM: exor674: ( clarification needed, I think xb95 means "charge me monthly" not "I want to pay for a month amnd just a monht"
10:29:00 PM: Sophira: They shouldn't, but it happens, I believe. For the record, I'm not against recurring billing, although if my account were paid then I probably wouldn't use it. It's just that the idea of saying it would bring in revenue is kind of... I don't know. But anyway, I see what you're saying.
10:29:03 PM: xb95: yes, charge me monthly is my preference
10:29:23 PM: exor674: Sophira: we mean "bring in revenue" in a whitehat way
10:29:30 PM: foxfirefey: Yes, this is an option that nobody gets forced into
10:29:30 PM: exor674: not a "take advantage of people" black-hat way
10:29:38 PM: jeshyr: exor674: Auto-refill points, you mean like a prepaid phone that will auto-recharge itself when it runs out of credit? That's a pretty cool idea actually....
10:30:07 PM: xb95: Sophira: maybe we can do some sort of auto-shutoff thing if you don't log in for a month
10:30:11 PM: Sophira: *nods* I know, I've just seen so many people get bitten by that sort of thing. I do trust you all though.
10:30:22 PM: xb95: so that way if you stop using the service (which we know), then we can stop charging you
10:30:39 PM: exor674: xb95: as long as we send a LOT of warnings about that too
10:30:39 PM: Sophira: xb95: Ohhhh, I like that.
10:30:54 PM: exor674: xb95: especially if we have things we throw away after X months of being free ever
10:30:56 PM: xb95: exor674: yeah, we would send appropriate emails.
10:31:09 PM: xb95: exor674: yeah, we don't currently, but if we did we'd have to think hard about that
10:31:10 PM: Sophira: It would be nice to have that as an option the user can set so that it doesn't bother them if they don't want it. But I know, more options = :/
10:31:15 PM: xb95: yeah
10:31:19 PM: foxfirefey: Tricky business
10:31:23 PM: xb95: always is
10:31:25 PM: foxfirefey: ANYWAY I think it would be good.
10:31:26 PM: exor674: well
10:31:28 PM: xb95: anyway
10:31:30 PM: jeshyr: xb95: I'd think 1 month might be a bit short? But yes great idea!
10:31:33 PM: exor674: also, there's an upper limit to how long the user can be charged
10:31:37 PM: exor674: without taking action
10:31:52 PM: exor674: because we can't charge a card w/o knowing its new experation date
10:31:56 PM: xb95: right
10:32:12 PM: xb95: another big project, and one we're starting to prioritize (as in, I will be working more on it soon, and would of course welcome help) is photo hosting
10:32:18 PM: xb95: I think one of our big holes right now is media storage
10:32:28 PM: foxfirefey: Agreed
10:32:34 PM: Sophira: True, though that's the case for any similar site. But anyway.
10:32:37 PM: exor674: I can't speak personally as I run my own dev env
10:32:40 PM: Sophira: Yes, media storage.
10:32:43 PM: jeshyr: Absolutely xb95.
10:33:03 PM: deborahGU: it's too bad we won't be in a place to take advantage of people upset about scrapbook shutting down, since we won't be fast enough
10:33:06 PM: exor674: but a lot of stuff is hard to use/test for people who use the hack box
10:33:13 PM: deborahGU: which is not to say that we should be taking advantage of anything -- I phrased that badly!
10:33:23 PM: xb95: scrapbook is shutting down?
10:33:23 PM: foxfirefey: deborahGU: I'm pretty sure everything is going to work out fine there eventually
10:33:24 PM: deborahGU: But I know some people who are already upset and looking where to store their photos, and we won't be able to be that site for them.
10:33:26 PM: exor674: I assume photo hosting will be mogile-only
10:33:26 PM: xb95: wait wait?
10:33:32 PM: Sophira: Wait, they're shutting ScrapBook down? I am *so* out of touch//.
10:33:33 PM: Sophira: -//
10:33:34 PM: deborahGU: yeah
10:33:35 PM: foxfirefey: They're just transferring it to a new system
10:33:37 PM: deborahGU: I just thought tonight.
10:33:37 PM: foxfirefey: That's all
10:33:41 PM: deborahGU: saw it
10:33:44 PM: foxfirefey: Which is good
10:33:48 PM: deborahGU: with a lot less storage though, foxfirefey
10:33:57 PM: foxfirefey: I'm willing to wait to see how it shakes out
10:33:58 PM: Sophira: Where did you see that?
10:34:06 PM: xb95: yeah, do you have a link please?
10:34:07 PM: foxfirefey: I know that old code was crufty as heck
10:34:11 PM: deborahGU: hang on, I will get the link. It was originally Russian only, but I think they have done an official translation
10:34:15 PM: foxfirefey: http://lj-pics-beta.livejournal.com/862.html?thread=101470#t101470
10:34:44 PM: deborahGU: (the parent post has been translated itself now)
10:35:16 PM: deborahGU: apparently some people who are in the beta saw the storage get knocked down to 2gb, but this is entirely hearsay from news, and it is sometimes hard separating the wheat from the chaff in news posts
10:35:38 PM: foxfirefey: I'd be surprised if the storage got knocked down in the final product, for paying customers
10:35:38 PM: xb95: right
10:35:48 PM: xb95: I wish I had known about this, I would have busted some ass to get it ready
10:36:00 PM: xb95: or at the very least as "download my scrapbook" option
10:36:03 PM: xb95: I wonder if they'll shut down the API
10:36:21 PM: foxfirefey: They're going to need to have SOME kind of API to work with their mobile app, methinks
10:36:23 PM: exor674: xb95: could of sworn you were the one I sent a fotoup patch to
10:36:26 PM: foxfirefey: Even if they don't document it
10:36:36 PM: exor674: xb95: when you were playing with it and it was broken
10:36:43 PM: exor674: or whatever the scrapbook client is
10:37:02 PM: xb95: exor674: you did
10:37:10 PM: exor674: okay good, so I am not on crack \o
10:37:13 PM: xb95: hehe nope
10:37:47 PM: xb95: fey asked about the old GSoC code
10:37:49 PM: xb95: for vlion
10:37:53 PM: foxfirefey: I totally did!
10:37:54 PM: xb95: I imagine this is specifically related to the iOS stuff
10:37:59 PM: foxfirefey: Yes
10:38:08 PM: foxfirefey: Although if we end up making superdupershiny REST JSON api
10:38:10 PM: exor674: ^^ I am interestd in the other stuff, though

[light redaction]

10:41:34 PM: foxfirefey: (prev topic: asked about API for new scrapbook here http://lj-pics-beta.livejournal.com/862.html?thread=186206#t186206)

[more light redaction]

10:47:57 PM: xb95: so! next up, github
10:48:07 PM: xb95: right now we're using mercurial and we're hosting it
10:48:28 PM: xb95: we've done some experimenting with github for hosting the code, and I think it could be really interesting and beneficial for us and for having more visibility on development and such
10:48:32 PM: deborahGU: ooh github
10:48:43 PM: foxfirefey: Is there a good run down of the spiffies it would get us?
10:48:48 PM: deborahGU: yes -- lower barrier to entry for many, since it's so popular now
10:49:32 PM: xb95: it's become the market winner in OS group collaboration, IMO
10:49:33 PM: jeshyr: Fu was very enthusiastic about it
10:49:42 PM: xb95: it's very visual and easy to use for people
10:50:10 PM: xb95: trying to ffind a good example
10:50:14 PM: deborahGU: It increases visibility among other FLOSS folks. I haven't drunk the kool-aid, but I do like on the projects for which I use it.
10:50:30 PM: xb95: https://github.com/xb95/nagios-api here's one of my projects
10:50:50 PM: xb95: https://github.com/xb95/nagios-api/pull/5
10:50:55 PM: xb95: check that, someone made some commits and wanted me to upstream them
10:50:57 PM: xb95: in to the main project
10:51:15 PM: exor674: xb95: or you could point at the test pull request me and Fu did on the DW repo
10:51:20 PM: xb95: oooh
10:51:35 PM: exor674: https://github.com/dreamwidth/dw-free/pull/3
10:51:35 PM: xb95: https://github.com/dreamwidth/dw-free/pull/3
10:51:53 PM: jeshyr: There seems to be free GUI wrappers for most OSs which will be great for babydevs
10:52:00 PM: xb95: yeah, that too
10:52:05 PM: xb95: gitx, git tower, etc etc
10:52:19 PM: xb95: https://github.com/dreamwidth/dw-free/network
10:52:20 PM: xb95: that's fun too
10:52:31 PM: xb95: you can visually see excatly what people have done and are doing
10:52:36 PM: xb95: so you can explore where code came from
10:52:50 PM: exor674: I am slightly opposed to git because it'll be a little harder to do something mq-like
10:53:04 PM: jeshyr: mq-like in what ways?
10:53:06 PM: exor674: when I have either a long-running feature or a deep-nested feature but I can deal :P
10:53:22 PM: exor674: like a few of my projects have been 4 or 5 patches deep
10:53:39 PM: xb95: yes, that is definitely a drawback, the quilt stuff is nice
10:54:01 PM: xb95: IMO quilt/mq is nice for when you're off doing a lot of development on something that is many layers, i.e. lots of work etc
10:54:03 PM: exor674: because with git I'd have to do rebase, rebase, rebase
10:54:13 PM: xb95: but git is designed to encourage a much smaller, faster, iterative development process
10:54:53 PM: exor674: xb95: I'm not sure if we want to have multiple-features per pull request or a pull request with like, a few dozen commits
10:55:07 PM: exor674: { the second can be fixed by flattening before the initial pull request, but }
10:55:13 PM: exor674: just thoughts
10:55:24 PM: xb95: good thoughts, we will have to experiment and find the right balance for our project
10:55:45 PM: xb95: so it sounds like nobody has any major blockers.
10:56:07 PM: xb95: I don't know when we'd transition, but fu and I (and whomever wants to help!) will spend some time on it and start moving us that way
10:56:16 PM: exor674: xb95: one thing I Think that would be great about git, assuming we use git-flow on the repo itself
10:56:24 PM: xb95: yeah, I want to git flow
10:56:24 PM: exor674: xb95: is it'd make things like what you had to do today SO MUCH EASIER
10:56:30 PM: xb95: yes, truth
10:56:31 PM: exor674: do it in a hotfix branch instead of a develop, win
10:56:37 PM: xb95: yesssssssss
10:56:39 PM: jeshyr: Does anybody happen to have "How To Use Git" resources they could point us at? I really only know what people have told me here I've never used it
10:57:25 PM: xb95: http://learn.github.com/p/intro.html I've heard good things about
10:57:31 PM: deborahGU: jeshyr: I think the OTW have some really nice docs, let me check
10:57:33 PM: xb95: the GitHub folks are pretty good on the education side
10:57:40 PM: xb95: oh! and if OTW has it, that's probably even better
10:57:43 PM: xb95: they use git? awesome

[light redaction]

10:59:38 PM: xb95: speaking of, I want to get rid of our whole process of using this cvsreport thing. it makes me so sad.
10:59:59 PM: exor674: xb95: that may be a little difficult because of our overlay repos
11:00:20 PM: xb95: yea
11:00:25 PM: xb95: it's a fever dream, but I have hope
11:00:28 PM: exor674: and I really don't think there's anything better

[light redaction]

11:03:02 PM: foxfirefey: I'm all for the switch as long as we have instructions in place for folks making the transition
11:03:16 PM: foxfirefey: And make sure we have docs on the whys so people understand

[light redaction]

11:04:04 PM: jeshyr: documents are totally vital, as foxfirefey said.
11:04:06 PM: xb95: yeah
11:04:10 PM: exor674: { totally off-topic of this meeting
11:04:13 PM: jeshyr: Also perhaps a post on dw-dev that it's cominhg up, etc etc.
11:04:37 PM: foxfirefey: Yes, basically. dw_dev post saying: we're going to do this, this is why, comments/questions, timeframe
11:05:10 PM: xb95: also, we will still accept patches from bugzilla for a while until we really iron it out
11:05:33 PM: xb95: so people can chosoe when they want to jump on the bandwagon. early if you want to help iron out the process, later if you want to wait for docs and help
11:05:39 PM: xb95: i'll write something up after talking to fu
11:06:25 PM: xb95: a related discussion is whether or not we want to move bugzilla to github. they have issue tracking. I don't know if it would fully replace our bugzilla needs, but it would be kind of nice to exist in one system
11:06:29 PM: xb95: and not have many different locations to go
11:06:51 PM: exor674: xb95: I really do not think the github issue tracker is optimal for our uses
11:07:26 PM: exor674: would not work for non-code patches/work { say, docs }
11:07:39 PM: xb95: sure it does. you don't have to attach code to it
11:07:46 PM: exor674: I men
11:07:48 PM: exor674: mean
11:07:58 PM: exor674: like submitting moodthemes to be converted
11:08:04 PM: xb95: oh gotcha
11:08:10 PM: exor674: or doc work
11:08:24 PM: jeshyr: Oh that would be a problem
11:08:28 PM: exor674: or any security bugs
11:08:35 PM: exor674: I don't think github has the concept of private issues
11:08:36 PM: xb95: well
11:08:52 PM: xb95: yes, you're right
11:09:12 PM: xb95: for docs/files though, you can upload a gist on github and attach files, then make an issue from that.
11:09:17 PM: geekosaur: which reminds me, dw_nonfree? think that requires their pay service?
11:09:36 PM: exor674: given it's not a private repo, I don't see why not
11:09:38 PM: geekosaur: or might make them think it does...
11:09:38 PM: xb95: you only have to pay for private
11:09:44 PM: xb95: and I'm fine with paying
11:09:53 PM: exor674: I don't think anything on github says things have to be OMG FOSS
11:10:05 PM: xb95: dreamwidth can afford to pay for services. we just can't pay real salaries. but we have enough money for servers and services
11:10:24 PM: geekosaur: ok, thought it was a FOSS requirement last I checked
11:10:28 PM: exor674: you may have to pay if you move dw_private over there
11:10:35 PM: xb95: yeah, would definitely have to pay for that
11:10:47 PM: foxfirefey: $25 for 10 private repositories
11:11:12 PM: exor674: foxfirefey: also, DW's a "company"
11:11:15 PM: exor674: not an individual
11:11:21 PM: foxfirefey: Dre: That's the lowest business plan, yes
11:11:28 PM: xb95: anyway, think we've hit the end of the github discussion~~
11:11:31 PM: xb95: for now anyway
11:11:34 PM: exor674: no, the free business plan has a private, I think?
11:11:45 PM: foxfirefey: https://github.com/plans -- don't see it
11:11:48 PM: foxfirefey: Anyway
11:11:50 PM: foxfirefey: NEXT TOPIC
11:11:51 PM: xb95: hehe
11:12:01 PM: xb95: has anybody else something to bring up or discuss?
11:12:23 PM: foxfirefey: You were talking about API stuff at one point
11:12:30 PM: foxfirefey: I would like to subscribe to your newsletter
11:12:31 PM: xb95: yeah, I will go there but I wanted to open the floor a bit
11:12:32 PM: xb95: explicitly
11:12:45 PM: foxfirefey: Okay, coolbeans
11:12:47 PM: xb95: b/c we're technically at the end of the scheduled time, so if there's anything pressing, go now
11:13:16 PM: xb95: if not .. some other meta stuff that's come back to me ..
11:13:38 PM: xb95: we've started regularly hitting 40 Mbps
11:13:47 PM: xb95: of outbound traffic at our weekly peek
11:13:50 PM: xb95: and we hit 30 Mbps every day
11:14:07 PM: xb95: in mid-December, we were regularly hitting 10-15 Mbps
11:14:17 PM: foxfirefey: That's a huge leap
11:14:17 PM: exor674: shiny
11:14:17 PM: xb95: yeah
11:14:34 PM: xb95: we've definitely levelled off some, april has been relatively flat at the 30-40Mbps level
11:14:58 PM: xb95: but each of the major things we implement, we'll start capturing more and more people
11:15:04 PM: xb95: media storage will be a big bump
11:15:33 PM: xb95: mobile clients, if we could get some, would be great
11:15:50 PM: foxfirefey: OSCON has some workshops on APIs I have been eyeing
11:16:02 PM: xb95: which, speaking of, if someone has a real desire to start doing mobile development, but if you need books or an Apple development license, Dreamwidth will spring for it on your behalf
11:16:09 PM: allendw: mobile clients for the media storage, too. :)
11:16:13 PM: xb95: oh yeah
11:16:18 PM: foxfirefey: Oooh
11:16:26 PM: foxfirefey: I have access to books, and hardware, just no Apple license
11:16:28 PM: exor674: I really just wish I had people to *work with* on client
11:16:50 PM: jeshyr: Having somebody who's great at API design would be fantastic
11:16:58 PM: jeshyr: exor674: Android client?
11:16:59 PM: exor674: I may work on just a Dreamwidth-specific android client instead of the "IT WORKS ON ALL SITES YAY!"
11:17:03 PM: exor674: yeah
11:17:07 PM: foxfirefey: Dre: I'd really recommend that
11:17:08 PM: exor674: especially if I ever get OAuth done
11:17:12 PM: foxfirefey: Oh man OAuth
11:17:14 PM: xb95: the license is $100 last I checked, if you need one and want to get into it, let's chat
11:17:24 PM: exor674: xb95: 100$/year I think
11:17:26 PM: xb95: right
11:17:27 PM: xb95: that's doable
11:17:31 PM: xb95: mobile would be big for us, I want to see us go there.
11:17:38 PM: exor674: foxfirefey: I can help you with the iPhone client too
11:17:47 PM: foxfirefey: Vlion would want to work on it, too
11:17:47 PM: geekosaur: afaik you don't even need it immediately, it becomes necessary wen you need to sign an app
11:17:49 PM: exor674: I'm not sure if my { now plan-less } iPhone still works
11:17:51 PM: exor674: but I know the thing
11:17:57 PM: jeshyr: Apple licence isn't needed until fairly late in development
11:17:58 PM: exor674: geekosaur: or run the app on a real device
11:18:00 PM: xb95: oh gotcha
11:18:07 PM: exor674: which should be done more then less IMO
11:18:16 PM: foxfirefey: Too true, we could wait until we had something actual worth iterating through before getting to that license point
11:18:19 PM: geekosaur: dre, yeh, that's what the cert enabled
11:18:21 PM: exor674: It's probably less of an issue with say... a *client* and not a game
11:18:25 PM: xb95: and honestly, it doesn't have to be fancy
11:18:36 PM: xb95: log in, write entries, read your reading page.
11:18:38 PM: foxfirefey: Iterative development
11:18:41 PM: foxfirefey: Woo woo
11:18:43 PM: xb95: right
11:18:48 PM: geekosaur: but you could od quite a lot before reaching the point (or even, find a developer with a jailbroken iphone :)
11:18:48 PM: exor674: because there is an iPhone Simulator, but yeah, that's running the app with your full computing resources
11:18:58 PM: geekosaur: for initial dev
11:19:21 PM: exor674: anyway, I digress { I may be bitter over a few iPhone apps I had that ran slower then a Wolfenstien 3D port }
11:20:26 PM: xb95: API STUFF
11:20:28 PM: xb95: oops, caps
11:20:41 PM: xb95: you've probably noticed that I'm kind of on a "modernize the things" kick
11:20:45 PM: foxfirefey: Yes!
11:20:48 PM: xb95: github, kill cvsreport, TT, etc
11:20:50 PM: xb95: mobile clients
11:21:02 PM: xb95: I feel like Dreamwidth will only succeed long-term if we make ourselves relevant
11:21:06 PM: xb95: and that does NOT mean omgfacebook
11:21:15 PM: xb95: fuck that
11:21:32 PM: allendw: if we'd just add a Like button....
11:21:32 PM: xb95: sorry for the language, but this is kind of a sore point for me with modern startups and omgweb2.0 companies
11:21:44 PM: xb95: there are some things that facebook has done well
11:21:53 PM: xb95: i would love for dreamwidth to make it easier to contribute for people
11:21:56 PM: exor674: xb95: aw, and I was going to suggest a thing people can inject into their websites
11:22:00 PM: exor674: that lets them stalk their friends
11:22:22 PM: xb95: easy media storage, more live page updates, more ability to integrate with other sites (crosspost to facebook/twitter if you want), etc
11:22:28 PM: jeshyr: Lowering barriers to entry is wonderfully good
11:22:31 PM: xb95: yeah
11:23:04 PM: exor674: I honestly could at least get associating with twitter done easily if I had a little help with the UI
11:23:06 PM: xb95: I have this vision in my head of Dreamwidth (and I had this vision for LJ back before the 6A/etc stuff).. we are the "deep" kind of place
11:23:13 PM: exor674: I am pretty sure I have the backend maybe 60% done
11:23:19 PM: xb95: facebook and twitter are very shallow
11:23:35 PM: xb95: they're good at what they are, but they don't really lend themselves to depth
11:23:58 PM: foxfirefey: And WordPress is good at deep, but not so good at intimate
11:24:01 PM: xb95: right
11:24:03 PM: foxfirefey: Which is what LJ/DW excel at
11:24:11 PM: foxfirefey: Deep and intimate
11:24:14 PM: xb95: deep and intimate and as anonymous/pseudonymous as you want
11:24:22 PM: foxfirefey: And also discussion
11:24:24 PM: xb95: right
11:24:25 PM: foxfirefey: With the notifications going on
11:24:43 PM: foxfirefey: *relevant* discussion that is--
11:24:58 PM: xb95: related to this, I want to modernize our APIs
11:25:19 PM: xb95: which means abandoning the XML-RPC and flat and various XML protocols. we wouldn't rip them out ofr a long time, if ever, but we would stop iterating on them
11:25:45 PM: foxfirefey: Sounds pretty reasonable, as it doesn't break anything for anybody using old LJ clients
11:25:49 PM: xb95: a good example of what I want is https://stripe.com/docs/api .. it doesn't have to be that exactly
11:26:09 PM: xb95: also http://documentation.mailgun.net/quickstart.html
11:26:44 PM: exor674: would it make sense to use the same backend for them? or do we want to REALLY MODERNIZE?
11:27:04 PM: xb95: same backend?
11:27:06 PM: xb95: oh you mean
11:27:14 PM: exor674: like how flat and xmlrpc use the same code
11:27:18 PM: xb95: right
11:27:27 PM: exor674: just have /api/v1/postevent
11:27:32 PM: exor674: or whatever
11:28:02 PM: xb95: we could move the frontend to that sort of thing at some point, yeah. but probably not for a while, if ever. I'm not sure if that's necessary, but
11:28:08 PM: xb95: what we WOULD want to do is definitely
11:28:17 PM: xb95: cgi-bin/LJ/Talk.pm provides all of the methods that do the fetching/storing/whatever
11:28:26 PM: xb95: then the API and the web site both use those methods
11:28:35 PM: xb95: so we don't have two ways that comments get inserted, etc
11:28:43 PM: exor674: also, I recommed that we, where possible, implement standard APIs
11:28:48 PM: exor674: like we have with the ATOM posting API
11:28:56 PM: exor674: but still have our own for more advanced usage?
11:28:56 PM: xb95: if there are standard APIs, yes
11:29:16 PM: exor674: probably better to have our own API + the standard for basic usage
11:29:26 PM: exor674: then extend the HECK out of the standard API to the point where it's all woes and sadness
11:29:37 PM: xb95: right
11:30:59 PM: xb95: I'm not sure what the state of the art is
11:31:09 PM: allendw: REST is getting to be a pretty standard API pattern, anyway.
11:31:26 PM: exor674: allendw: that's an API pattern, not an API though
11:31:33 PM: foxfirefey: I can try to find books on O'Reilly
11:31:33 PM: allendw: well, skipping the question of actually using PUTs and DELETEs, anyway.
11:31:37 PM: exor674: like there's the ATOM publising protocol or whatever it's called
11:31:37 PM: foxfirefey: I have a Safari subscription
11:32:26 PM: xb95: I don't know what ATOM dictates, and whether or not we should use it, or if it's gone crusty in its age
11:32:30 PM: allendw: exor674, yeah, but i get the feeling places are moving away from standard APIs.
11:32:49 PM: allendw: standard shared APIs, anyway.
11:34:04 PM: xb95: the problem mostly is that Facebook et al don't support Atom really
11:34:32 PM: xb95: FB is a walled garden, they will never support the standards
11:37:02 PM: xb95: there's so many things I want to do, so little time :)
11:37:23 PM: exor674: while we're on API-ish things, can I ask a question related to my OAuth stuff
11:37:27 PM: xb95: sure
11:37:48 PM: exor674: would a "control what actions the 'consumer' can make" be *vital*
11:37:59 PM: exor674: because that's currently the largest blocker in my implementation
11:38:19 PM: xb95: can you explain what you mean?
11:38:23 PM: xb95: I'm not super familiar with oauth
11:38:40 PM: exor674: xb95: OAuth is a way that lets you, after doing a complex dance
11:39:20 PM: exor674: being all I am af7491deadbeef, I have a access token f00dbeef
11:39:32 PM: exor674: here's a signature proving that I am who I say I am and I have the token
11:39:39 PM: exor674: that's really ALL OAuth itself is
11:39:44 PM: xb95: right
11:39:59 PM: exor674: the access token is tied to the user, the other token is tied to the "consumer" ( akak remote site/client )
11:40:12 PM: xb95: ah-hah, so
11:40:25 PM: xb95: what you are asking about is whether or not we need fine-grained access controls once you've given a consumer access
11:40:37 PM: exor674: the question is, will it be a "OnlineReadingPageOfAwesome wants to do ALL THE THINGS"
11:40:39 PM: xb95: i.e. the difference between "I authorize X-app to use my account" and "I authorize X-app to use my account to read entries only"
11:40:42 PM: exor674: yeah
11:40:50 PM: foxfirefey: Which could be really useful in contexts
11:40:53 PM: exor674: and what level of granularity
11:40:57 PM: xb95: yes, but not necessary at launch, i.e.
11:41:08 PM: xb95: we can gate what the consumers can do by implementing it on a server-wide level
11:41:14 PM: exor674: yeah
11:41:22 PM: exor674: I was thinking for now, until we have a better API
11:41:38 PM: exor674: I'd give OAuth access to the flat API ( might be able to do XML-RPC 0
11:41:46 PM: exor674: but NOT sessiongenerate
11:42:01 PM: exor674: and the ATOM posting API implementation we have
11:42:31 PM: exor674: that is, could do anything through the API, but couldn't go around back, get a session cookie
11:42:34 PM: exor674: and then do ALL the things anyway
11:42:47 PM: xb95: ahhh
11:43:01 PM: xb95: that sounds reasonable
11:43:05 PM: foxfirefey: Indeed
11:43:12 PM: exor674: I need some help with the UI then ;P
11:43:12 PM: jeshyr: Sounds great Dre! You are amazingcakes
11:43:15 PM: xb95: we can be explicit about "if you give someone access to your account, they can act as you. post, delete, etc. be cautious"
11:43:34 PM: xb95: in an ideal world we can do granularity but honestly most people don't care about that
11:43:43 PM: xb95: and even if they do, most people don't understand how to really use it
11:43:45 PM: foxfirefey: I think it would be nice to have eventually
11:43:48 PM: foxfirefey: But shouldn't be a roadblocker
11:43:49 PM: exor674: xb95: at least an action log might be nice
11:43:55 PM: xb95: yes, we should log everything we can
11:43:57 PM: exor674: maybe not at feature-launch
11:44:00 PM: exor674: but soon after
11:44:34 PM: xb95: does the consumer have to have their own id? i.e., do we pre-authorize applications/developesr/something?
11:44:46 PM: allendw: we still have (undocumented) access to getfriendspage in the API, don't we?
11:45:03 PM: allendw: that might be good to shut off--make it so you can grant access for anything in your account,
11:45:23 PM: allendw: but couldn't grant access to read others' locked posts.
11:45:27 PM: foxfirefey: I think one level of granualarity that would be pretty straightforward is a "read-only" one
11:45:38 PM: foxfirefey: Aka, you can access information, but not write anything
11:45:40 PM: exor674: I can deny that too, yeah -- that might make people who want clients unhappy though but we can think about that leter --- xb95: my implementation currently allows anyone to create a consumer
11:45:59 PM: exor674: xb95: I could do pre-authorized developers, or have to authorize each application
11:46:19 PM: exor674: xb95: I think I talked to Fu about that, and really, if a site wants to do bad things with your data
11:46:25 PM: exor674: they could just ask for a username/password
11:46:42 PM: xb95: yeah
11:46:53 PM: exor674: so I don't see what's wrong with having it set-up on a "reject" model
11:46:56 PM: exor674: not an "approve" model
11:47:07 PM: exor674: ( and you can sysban an account from creating consumers
11:47:29 PM: exor674: and if you do that, all their existing ones "break", and if you suspend an account, all the consumers they own stop working too )
11:47:52 PM: exor674: am tempted to add some kind of ratelimit on that, but otherwise
11:48:10 PM: jeshyr: sounds sensible given, yeah, the "could ask for user/pass and scrape" thing
11:48:12 PM: exor674: not only because the process noms a fair bit of entropy *G*
11:48:35 PM: xb95: right, yeah, seems fair
11:49:44 PM: exor674: I am not going to commit to anything, but I bet I can have OAuth in review shape in about 2 weeks
11:49:49 PM: exor674: and then I want it OMG!reviewed
11:49:55 PM: xb95: oh nice!
11:49:57 PM: xb95: yeah, I'd be happy to
11:49:57 PM: jeshyr: \o/
11:50:09 PM: xb95: I.. really should do more reviewing
11:50:27 PM: xb95: but I don't have a lot of time to work on DW as it is, so I usually spend it coding
11:50:33 PM: exor674: xb95: p.s. can you look at http://bugs.dwscoalition.org/show_bug.cgi?id=4084
11:50:37 PM: Bugsy: Bug 4084: minor, P4, -undecided-, anall, IN_PROGRESS , Tools to manage %LJ::SECRETS
11:50:37 PM: exor674: as that is a blocker
11:50:58 PM: xb95: generally speaking though, if there is a high priority or security sensitive review, you can poke me about it and I'll take some cycles on it
11:51:01 PM: xb95: yes, dre, I will do that
11:51:02 PM: exor674: I might make it not and make the consumer secret pure-random
11:51:18 PM: exor674: xb95: but right now, I sign the consumer token to get the consumer secret and yeah
11:52:48 PM: xb95: well, when you have the patch ready, let me know!
11:52:50 PM: exor674: { and speaking of secrets, I really think one of LJ's changes.. the uh, signing one of the cookies is a good idea
11:52:56 PM: exor674: well the patch on 4084 is ready
11:53:01 PM: xb95: right, I'll work on that post-meeting
11:53:02 PM: exor674: I'll poke you when I get the OAuth patch ready
11:53:05 PM: xb95: anything else anybody want to discuss?
11:53:12 PM: exor674: I have to untangle a few things in the queue
11:54:07 PM: exor674: I don't think I have anything
11:54:29 PM: jeshyr: I don't hvae anything, except I'm really happy to have Deborah around as accessibility co-lead :)
11:54:33 PM: xb95: yay!
11:54:35 PM: exor674: \o
11:54:44 PM: allendw: :)
11:54:45 PM: deborahGU: I'm really pleased to be here to help!
11:54:56 PM: xb95: I'm really happy she (I'm not entirely certain or pronoun) agreed!
11:54:58 PM: xb95: *of
11:55:55 PM: xb95: well then, without anything further, I adjourn the official portion of this meeting
11:55:57 PM: deborahGU is she
11:55:59 PM: xb95 gavels or something
11:56:03 PM: exor674: \o
11:56:05 PM: xb95: thank you! I will note that
11:56:16 PM: exor674: xb95: ... hah I am reminded of a video I saw somewhere of a meeting
11:56:27 PM: exor674: where someone was using a ( hopefully broken ) laptop as a gavel-surface
11:56:40 PM: xb95: hah

Comments

[mark]

As mentioned in a previous post, too -- if you have comments or want to discuss or whatever, go for it! I'd like to keep the discussion relatively central to this post here, but if you want to start a new dw_dev post about something in particular, go for it!

[denise]

In short, IF YOU WANT TO TALK ABOUT SOMETHING, WE WANT TO TALK ABOUT IT WITH YOU TOO

[vlion]

I'd like to publicly reiterate: I have a Mac and an iPhone. I would love to support and work on an iPhone app. I'm not an Objective C expert *or* have a lot of free time, so if a lot of work needs to happen, I'm not it. But I can assist with hosting, build tools, testing, etc.

On another note:

I also would like to point out that git is generally considered harder to use than hg, and in my experience, the free GUI clients for Git on OSX and Linux are phenomenally terrible. I work on the version-control support team at work and have a good deal of experience dorking with version control and ideas and git does NOT (and has NEVER) sound(ed) baby-dev friendly. But Github is teh awesome and I recognize that's the current wave.

[sophie]

I don't like git much either, to be honest! I do hope we can stick with hg/Mercurial.

[kareila]

I have some deep misgivings about moving to Github. I understand the perceived advantage of more easily accepting contributions from the wider Open Source community, but I think that is more likely to happen with focused tools than with the kind of kitchen-sink project that the DW/LJ codebase has become over the years. Dreamwidth contributors have been people who are highly motivated to add or fix a particular thing because they use and love the site, and I don't see that changing. The lack of tangible results from our last round of participation in GSoC is pretty good proof of that, I think.

I personally have been working on vgifts for almost three years now, using a cloned repository that doesn't require me to deal with rebasing every time I want to compare my work with the newest committed changes. Everything I've read leads me to believe that using Git for that sort of project is a nightmare compared to Mercurial. That doesn't even touch the issue of patch queues, which I don't personally use but I know people who develop primarily on their dreamhack accounts find very useful. I feel we chose the best tool for the job, and I think that's more compelling than chasing the more popular choice. (How many of us use Macs instead of Windows? Windows is still the PC "market winner" but I've barely touched that OS since 1999.)

Anyway, not trying to say "I'm right and you're wrong" here, but I think this needs (a) more discussion and (b) a very cautious, incremental approach if we do transition. One other thing to consider, I expect changing the VCS mid-project like this would make all of our project's development history up to this point more difficult to access going forward, and I find having easy access to that history very helpful in tracking down bugs. I think that covers everything I wanted to mention.

[exor674]

Re. history: There are tools to convert hg repositories to get repositories -- see all the history on the "test" version of dw-free on github: https://github.com/dreamwidth/dw-free/commits/master

[alexbayleaf]

I don't know much about how DW uses mercurial so I might be asking a weird question here, but... is your work on vgifts visible to people other than you? Are other people looking at it/reviewing it/taking part in that development? If not, that would worry me a bit, from a dev process POV. I realise I'm saying this kind of from the outside, but I just wanted to raise a flag and suggest that "easily being able to work on one's own for three years" may not actually be all that desirable feature, if you take the broad view.

[kareila]

Other people are looking at it when I submit the patches on Bugzilla; I just haven't done that in a while.

I'm not particularly happy about it taking me so long, but I haven't found a lot of time to work on it recently.

[alexbayleaf]

*nodnod*, I didn't mean to suggest you're taking too long or that there's anything wrong with that... everyone here is a volunteer and we appreciate the work you do at whatever rate you do it.

I guess my thought is that, from an infrastructure/process point of view, it bothers me that it's possible to go for ages between patches submitted to Bugzilla, and hence between people looking at it. One thing I like about github (with what little experience I've had with it) is that people's work on branches is highly visible, and people can follow along as it happens, rather than the onus being on the developer to actively push their patches out for review.

[fu]

It is possible to publish changes on your personal repository when using mercurial on a longer-term basis, but it seems less... natural? supported? Needs more personal initiative, rather than being assumed default to the process? I strongly agree that we need to make it easier to publish incremental changes, without making it a big deal, or putting the onus on the individual developer to set up a more transparent window into their code on their own.

[pauamma]

It's visible at http://bugs.dwscoalition.org/show_bug.cgi?id=215 - is that what you're asking?

[alexbayleaf]

No, I meant more in terms of people seeing each commit/comment as it's made, looking at the code, understanding the steps and choices taken along the way, etc. My concern is that if a huge patch comes through at some point in the future, representing years of work, it'll be too big for any reviewer to get their head around and fully understand, and if there are problems (of course I have no idea about this, just speaking from experience on other projects) then a huge pile of "this needs fixing" notes can stall the patch indefinitely, whereas collaboration/visibility along the way can help head those things off early, before they seem overwhelming.

I guess what I mean by visibility is... if I wanted to see the code kareila's working on right now, and offer comments/tweaks to it, would I be able? Is her branch publicly available, and are commits to it as visible as commits to the trunk would be? Or is it off to the side somewhere where people can't see it or aren't aware of it?

[alierak]

That sounds like it could be addressed in some way by asking for visibility into her dreamhack, independent of VCS.

Also, I'll say it because she won't, but the more well-intentioned efforts to change major underpinnings of this project, the more Dreamwidth risks losing kareila as a developer. Or never inducing people to contribute major feature development in the first place. It's hard enough to learn all the interlocking systems you need to understand in order to make even a minor contribution, that building something significant on a shifting foundation might seem impossible.

[fu]

I've done the big projects, with years (well months) worth of work bundled into a huge patch in zilla and based on that experience, I'm all for a workflow that encourages publishing changes in a more digestible manner, where they can be reviewed in a timely manner, and tweaks can be more easily reviewed separate from (but in the context of) the previous patch.

And I'm not saying that devs who go purely through Zilla are the ones doing it wrong! On a project level, we, Dreamwidth, have not made it easy to do it any other way. And we need to change that, whether it's Mercurial or Git (or whatever) we use as a repo.

[alexbayleaf]

This. I was definitely trying to talk about "what the project makes easy for developers to do", paths of least resistance, etc., though I may not have been as clear as I might have hoped to be.

[pauamma]

Speaking as one of the few people who will review large patches (like the new update page), I think slicing and dicing them would be a mixed blessing. Yes, it's easier to check each of a large number of small patches separately for style compliance, code clarity. proper use of libraries, error checking, etc., and it may be easier for the patch author to deal with piecemeal reviews as well. But that's only part of the problem, because I'd still want to review all patches as a whole, since the overall design may only be visible there, which means all those reviews would only be preliminary.

An alternative would be for the patch author to document the design before handing the first patch of the set for review, so it can be reviewed against the design (and the design itself for sanity) as well as for style etc as described above. This, however, is a change of habits and workflow that may cause as many problems as it may solve, or perhaps more.

[fu]

One of the advantages of having the entire branch history in front of you is that you a potential reviewer can do a diff of the entire branch starting from the very base, so that you can still get an overview of all the changes. I believe it'll be understood that the reviews will be preliminary in nature, but also that having more sharing of changes as they happen will lead to any issues with the overall design being caught earlier, before too much work has been done.

I think that documenting the design is going to be a big barrier, and will probably as you note cause its own set of problems.

[pauamma]

but also that having more sharing of changes as they happen will lead to any issues with the overall design being caught earlier, before too much work has been done.

Maybe (and if it happens, it woud be a good thing, no argument about that). I'm not sure, in practice, how soon the design woud emerge from the partial series of changes. (But worst case, it will emerge with the ast change, so we lose nothing from a monolithic-change approach. Is that what you mean?)

[afuna]

(Yup, preciesly)

[fu]

Is there anything we can do to help figure this out, kareila? I don't want to just spring this transition onto all the devs. I promise this isn't happening immediately; moving to a more branch-y model is something I'd like to encourage strongly, but I'd like to run through a proposed workflow using both git and mercurial first, so we can compare and contrast the two, before we make any final decision either way.

I do worry, though that major feature development on Dreamwidth has too many barriers the way we do it now. The review process through Zilla works for smaller patches, but breaks down a bit when we have:

a) bigger patches on major projects that need development over time; or
b) patches that take multiple reviews and need multiple tweaking


In particular, with b), there's a stigma attached to the review- flag. It's perceived as a rejection of all that work, and hey I can sympathize with that *wry grin* It sucks to get that email and those comments, and reapplying the patch + tweaking + regenerating the new patch feels like starting from scratch. I hate to say it, but we've lost people over that. It contributes to general drift, and it's something I feel strongly about reversing.


Which is why I'm pushing for a more branch-like system. Based on what I've read, Git makes it easier to publish feature branches and merge them back into the main repository, without cloning to a new repository (which seems harder to juggle with cvsreport.pl. I'm not sure this will be an entirely moot point even once we get rid of the bulk of overlaid repositories; that's one of the things that needs to be settled).

I use MQ to manage my own patch queue, and it makes it easy, but by its temporary nature, it's hard to share it around, which doesn't help with transparency and encouraging feedback from other devs.

*but*, and very importantly, it looks like you've got things working quite well for you in Mercurial, and this is precisely the thing I'd like us to talk about: how you're making things work, and whether what works for you would be applicable to general development.

Bringing up one point specifically, have you looked into Git named branches in comparison to cloned repositories in Mercurial? I get the impression that the two are roughly the same, except that with Mercurial the feature development happens in a separate folder. This isn't a rhetorical question by the way! The way Mercurial and Git deal with branches seems to be one of the main big issues that will affect workflow, and it's among the things we need the most information about in terms of practical use.

[kareila]

Just having the conversation, and making it clear that you're considering people's concerns, is good. :)

You speak of having issues with managing multiple clones in deployment, but I don't do that. All of my clones are on my local disk, and I generate and upload patches to my dreamhack when I want to test them. Because I also have to generate and upload patches to Bugzilla for review, this is a natural workflow for me, but it does make testing less fluid.

What our setup really discourages (IMO) is collaborative development. You can't assign multiple people on a bug, and although it is possible for multiple people to upload patches on a bug, it's generally perceived as stepping on the bug owner's toes. I would be all for a more public and functional branched system of development if it helped to break down those walls. Otherwise, I'd rather spend my available time working on code than learning a new system.

[fu]

Re: uploading patches

I had not thought of that. Thanks, I was wondering :)


Re: multiple development

Good point. That's definitely something I'd like to have fixed. It would help a *lot* with frontend vs backend thingums, too, and one thing I hope will work out.

I'd working on hammering out a suggested workflow, so that no one is left flailing about in a new system with insufficient information. (moving from by-patch to per-branch/changeset submission is going to be a change). I think this is crucial to helping everyone adjust. Before *anything* gets settled on permanently, we're going to ask for volunteers to go through the process of submitting a pull request using this new method, and iron out the kinks. I really don't want any part of this to be more painful than absolutely necessary!

[pauamma]

we're going to ask for volunteers to go through the process of submitting a pull request using this new method, and iron out the kinks

I think it may need more extensive banging-on than that for user-acceptance testing. (And I can provide some of the extra banging-on, if needed.)

[afuna]

Sounds good! I'll do a general shout out in an entry at some point once we've got more than a rough idea of what needs to be done.

GSoC code

[brainwane]

I know that the Google Summer of Code 2010 code is here: https://code.google.com/p/google-summer-of-code-2010-dreamwidth/downloads/list for five students, and I know Dreamwidth accepted seven students but perhaps two of them didn't complete the summer.

If you're ever looking for final GSoC code for the last few years, you can search for the label "google-summer-of-code" on Google Code -- as a requirement for finishing the program, every student has to upload their finished work to a Google Code project that's named google-summer-of-code-YEAR-ORGNAME.

Re: GSoC code

[pauamma]

Thanks!

Re: GSoC code

[foxfirefey]

...you can come sit by me.