lobbes: http://younghands.club/2019/12/24/ejb-plan-week-2-jan-2-jan-5/#comment-261 << diana_coman: I've not really ever tested in an automated fashion before. I just kinda manually try to break things as I go (and really even then I'm not too organized in exactly what to be testing for).
lobbes: diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
whaack: diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
whaack: actually i may be able to use asdf:load-system instead, i see that in trinque's ircbot
whaack: err in trinque's ircbot USAGE file
whaack: trinque: I think I may understand this if you never got around to it. The thread that normally calls ircbot-reconnect is the ircbot-ping-thread. However the ping-thread commits suicide because ircbot-disconnect calls (sb-thread:terminate-thread (ircbot-ping-thread bot)) . So when the ping thread calls ircbot-reconnect after calling ircbot-disconnect it never gets to the ir
whaack: cbot-connect or ircbot-connect-thread. If you test ircbot-reconnect (in the repl or such) you will not see the bug because then ircbot-reconnect is being run from a different thread.
ossabot: (trilema) 2019-02-07 trinque: now that we're at something of a cuntoo interude while folks are testing, I'll find some time to figure out what deedbot gags on time to time re: reconnecting
whaack: diana_coman: EOD Report: I spent another long day on TheFleet and published my article. I said I would publish a plan for building my computer but instead all I had time for was to publish my disassembling notes. I also said I would take inventory of the parts but I did not yet go through all the cables.
ossabot: Logged on 2020-01-02 16:22:49 whaack: I will do that now and publish a plan for building my computer as my article for tomorrow and otherwise get back to working on TheFleet for now.
whaack: I should have my review / plan for the week done by tomorrow. But I am not 100% sure I will, because of my mother's arrival and everything having been pushed from me trying to get TheFleet running.
diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014609 - how about Sundays 7:30pm utc ?
ossabot: Logged on 2020-01-04 20:38:45 lobbes: diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014610 - ahahaha, the beauty of lisp, right? lmao.
ossabot: Logged on 2020-01-04 22:17:17 whaack: diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
diana_coman: whaack: in any case, 7 will have to do for the pilot test, so at least there's that.
diana_coman: billymg: since you've been working on mp-wp anyway, what would your thoughts be on a mp-wp plugin for vpatches display+review? As hinted a bit earlier around here.
ossabot: Logged on 2019-12-29 12:01:05 trinque: incidentally this is a tool I want, a commentary tool for vpatches.
whaack: diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014610 - ahahaha, the beauty of lisp, right? lmao. << to see the beauty you just need Lisp Memory Usage Positivity
ossabot: Logged on 2020-01-04 22:17:17 whaack: diana_coman: I have my bot running now connected to 7 networks with a more robust reconnect feature. I am capped at 7 because of memory issues - the problem is I load quicklisp in my environment which by itself is ~70MB. So a next step is to figure out how to load my dependencies without quicklisp.
lobbes: http://logs.ericbenevides.com/log/ossasepia/2020-01-05#1014632 << sounds good to me. Thank you!
ericbot: Logged on 2020-01-05 08:15:57 diana_coman: http://logs.ossasepia.com/log/ossasepia/2020-01-04#1014609 - how about Sundays 7:30pm utc ?
ossabot: Logged on 2020-01-04 20:38:45 lobbes: diana_coman: I can definitely see how this can be an in depth discussion. You know, I think we have at least two items in a conversation queue now, so I wonder if we oughta have like a standing meeting at a certain interval?
whaack: diana_coman: I connected to 7 more networks on another VM.
whaack: a few were banned / dropped so the total connected right now is ~9
billymg: diana_coman: yeah, i think that would be great to have. i'm imagining something like phf's patch viewer with the added ability to add inline comments
billymg: btw, whaack: http://logs.ossasepia.com/log/ossasepia/2019-11-07#1009221 << finally did this
billymg: diana_coman: in mp-wp, i could see the addition of a new post type and comment type. let's say post_type="vpatch", and this is selectable from within the mp-wp UI when creating a new post. if this post type is selected, the user gets an additional <textarea> where they can paste the full contents of a vpatch. this text is stored in a new column in the posts table, e.g. post_code. when rendered, post_content will
billymg: be rendered first, followed by post_code (which will be formatted similar to the existing patch viewer)
billymg: alternatively, instead of pasting the vpatch contents into a <textarea>, it could prompt the user to upload a .vpatch file, store it in a sensible (organized) directory, and store a reference to the file in a new column on posts, e.g. post_code_filepath. the rendering would be the same
billymg: i personally like the latter because it would result in a cleaner UI and doesn't require copy/pasting a vpatch into a text area (which just seems cumbersome). also, depending on the size of some patches, this avoids blowing up the mysql database
billymg: line-level commenting would require a minimal amount of JS (just enough to insert an inline comment box at a given line number)
billymg: less clear is how revisions after a discussion would be handled. perhaps just a new published article after the author addressed all of the comments in the first round
billymg: and this is just off the top of my head, i figure after some discussion here i could spend some time publishing a formal spec for the feature (for review) before starting any code
diana_coman: billymg: there might be 2 parts to it and not even necessarily tied together really
diana_coman: the upload vpatch + store in sensible place is really a script that can even be outside mp-wp, not much to do with the mp-wp itself
diana_coman: for the text/article itself though, why not make it simply a different type of tag? e.g. like one has (()) for footnotes, use [[]] or something else for "this is vpatch content"?
diana_coman: I think the whole viewing + reviewing can happen perfectly fine on the existing blog article structure, can't it?
diana_coman: all it needs is this new tag+corresponding plugin to do the formatting (perhaps similar to that vpatch viewer, sure)
diana_coman: and then the comments to the post can simply reference that
diana_coman: if/when there's a new version of the vpatch, it's up to whoever *signs* the new vpatch to publish it as a new article, no?
diana_coman: I wouldn't really go otherwise much along the slippery path of "automate a vpatch's lifecycle" because of the fundamental of V that *reading* is authorship of code (and that can't be automated really).
diana_coman: billymg: re inline comments - would it be possible for the plugin to update the article's content to provide perhaps inline links to the relevant comments or something of this sort?
billymg: that makes sense. my reason for not suggesting the route of [[]] or similar was out of consideration for very large vpatches
diana_coman: but tbh I think this is one of the situations where it's perhaps better to wait and see what is actually *needed* because it's unclear to me that at this stage, before any serious use, one can fully tell really
billymg: i think [[]] works well for snippets of code, but not entire thousand+ line vpatches
diana_coman: ie you risk overspecifying/making choices too quickly/before knowing the problem really
diana_coman: billymg: very large vpatches are a bit of trouble in themselves
diana_coman: I know we still end up with those but ...they *are* trouble so I wouldn't base the viewer on them.
diana_coman: because also, who the fuck reads thousand+ line vpatch?
diana_coman: maybe it's for the better if this even *forces* one to split the damned thing.
diana_coman: billymg: also, why wouldn't it work well anyway? not like there aren't otherwise articles of thousands of words published fine with mp-wp?
diana_coman: trinque: would you care to add your view/ideas on this thread?
billymg: diana_coman: >billymg: also, why wouldn't it work well anyway? not like there aren't otherwise articles of thousands of words published fine with mp-wp? << yes, true
billymg: re: uploading inside mp-wp, i think it was the concept of code shelves that brought me to this (along with the idea of separating code from article content)
billymg: as in, if a code shelf is a concept inside mp-wp, then that justifies mp-wp having some features for managing that shelf
diana_coman: billymg: on one hand I can see the appeal of having mp-wp basically maintain the code shelf as simply an automatically updated page with all vpatch+sigs uploaded, sure
diana_coman: but otoh why mix it with the discussion /review of code (since perhaps I even want to discuss some vpatch *before*/without adding it yet to my shelf for instance?)
diana_coman: and also: what's the separation you see between code and article content? the way I see it, for some code review, the code may very well *be* the article content, no? and the reviews are the comments, naturally.
diana_coman: billymg: you might have made for yourself 2 pieces of work ([[]] + shelf mgm) instead of 1, heh.
diana_coman: the additional potential trouble that I see if you go the route of having [[]] take directly the vpatch from disk rather than its text is that any annotations you add inline to it would then be separated from the text?
diana_coman: aka you end up with that situation where the content of your article is partially in db and partially on disk; it's already rather annoying that this is the case to some extent for wp (eg categories iirc and at any rate, images...)
diana_coman: not sure I see the case for extending that sort of situation.
diana_coman: and uhm, I'd much, much rather have *no* JS whatsoever.
billymg: i didn't mean that publishing an article would automatically add the vpatch to the code shelf, only that the concept of a code shelf hosted in mp-wp makes mp-wp somewhat of a code hosting tool as well. and since mp-wp is being used to host the code, it follows that this would be a logical place to discuss/review the code as well (not in the shelf, but elsewhere in mp-wp)
diana_coman: billymg: sure.
billymg is thinking about the other comments...
diana_coman: no rush.
billymg: ok, annotations from the author is something i didn't factor in. this would be much more complicated than necessary if the vpatch is stored on disk (UI would need to render the vpatch after upload and allow the user to annotate before publishing, ugh)
billymg: re: stored in [[]] in post_content vs. stored in post_vpatch_code, i think with footnotes they are always tied to the article that contains them. vpatches are more portable. it makes sense to be able to display them inline in an article (for discussion/annotation), but they can also stand alone (be downloaded by a reader, be moved/promoted to the code shelf when ready)
billymg: it gives more flexibility for later display or retrieval of all the code in ones mp-wp, rather than having to parse post_content looking for [[]]
diana_coman: billymg: the .vpatch file + the .sig file surely need of course to be standalone files too, there was no idea of NOT having them separate too; just NOT mixing the two at all: there's .vpatch files and those are indexed by the code shelf (which is singular because it's meant as one single entry point) and then there is - to the extent the author makes/wants it- a bunch of articles that discuss vpatch contents (and this can be ...
diana_coman: ... anything,even just parts of a vpatch at the end of the day, even not yet signed vpatch etc)
diana_coman: so certainly not parsing post_content, no.
billymg: re: no javascript. yes, inline commenting could be done in the regular comment box if the commenter adds some annotation, e.g. ">>path/to/file.php#L22 comment text follows..."
billymg: and then when rendered that comment is displayed at the correct file/line number
diana_coman: billymg: perhaps the [[]] can simply add html hooks for each line and then commenters can use those, right?
diana_coman: my potential suggestion - but more of an idea for laters, if needed - was to have it work backwards as well ie when a comment is approved, to collect the ref to any line-html hook and then update to add there a link to the comment; it might be overkill, not needed anyway, I don't really know atm, just throwing it out there.
billymg: what do you mean by an html hook?
diana_coman: billymg: I meant an anchor for each line of code; but come to think of it, there's in principle already the selection mechanism, might even be enough, hm.
billymg: ah, no, the anchor makes sense, e.g. <a href="#L22"> (the server-side selection mechanism still relies on a #select anchor to scroll to the selection)
diana_coman: billymg: yes, exactly.
billymg: i was thinking that file name would need to be encoded in the anchor as well, but i see now that in the existing patch viewer the line numbers are cumulative
billymg: not per file
billymg: typing "#L22" at the beginning of a comment to make it render inline doesn't seem too bad
diana_coman: yeah, no need for more than that really; and it has this advantage that I see that one can in principle update the text too to list there for each line the links to comments that refer it (basically the non-js automated inline annotations if you want)
diana_coman: something like that; if it turns out it's useful.
diana_coman: I need to go now but I'll be back in ~1.5 hours or so.
billymg: ok, i'll think on this some more, and watch for additional comments from others
diana_coman: lobbes: btw, if you publish your plan, we can start with that later today.
diana_coman: billymg: sure and if you publish some plan, I'll certainly read it.
diana_coman will bbl
lobbes: diana_coman: sounds good. I just published the plan now, should be coming through feedbot soon. I'll brb in ~7 mins
diana_coman: lobbes: read it; what happened to the mp-wp polish idea as it seems entirely dropped?
lobbes: diana_coman: well I'm still going to work through that today. Probably another 4 hours or so dedicated to it left
diana_coman: lobbes: ah, so you aim to finish it today then?
lobbes: diana_coman: I aim to at least get it up and running on the 'prod server' along with some rudimentary manual testing of bits
lobbes: by the end of today, that is
diana_coman: ok, just don't let it drop afterwards in that forever-started-on state
diana_coman: taking the topics in order, there was the procrastination question - did you figure out anything re why?
lobbes: diana_coman: this is a good point on the dropping. I will add it to my "Things that I need to think on" items in this week's plan just in case there is spillover
feedbot: http://younghands.club/2020/01/05/ejb-plan-week-3-jan-6-jan-12/ << Young Hands Club -- ejb plan: week 3 (Jan 6 - Jan 12)
lobbes: as for the procrastination q, the best thing I could up with besides "I'm just being lazy" is that it is some sort of instant gratification vs delayed gratification thing
diana_coman: lobbes: hm; do/did you ever have any project/something you actually found it easy /fast to start on?
lobbes: diana_coman: if it is something that I keep 'loaded in my head' already then I usually have no issue picking it up / putting it down day-to-day. If that makes sense.
diana_coman: lobbes: it covers one part - it is easier to start on and therefore you start, yes.
diana_coman: lobbes: do you procrastinate the same on relatively simpler tasks? because it starts sounding possibly related to the "too big jump in one step" simply.
lobbes: diana_coman: it is true that I don't really procrastinate on small things that I can get my head around quickly. It does seem to be more with things that I am unsure of where to start on
diana_coman: kind of ties in with your preference for clearly stated & neatly ordered stuff, yes.
diana_coman: so break stuff into smaller & clearer steps and if unable /unsure of that, maybe just ask for more specific direction to get you started & anyway, until you start getting the hang of this part too
lobbes: diana_coman: this makes sense. I will do just that
diana_coman: laziness is essentially just a signal like many others.
lobbes: I never really thought of it like that before, but it does make sense
diana_coman: heh, I have yet to meet a single person (me included!) who has never been/can't be lazy, lol.
diana_coman: lobbes: re bugs & testing, what was your question there to start with? because it seems more like an overall confusion tbh so not sure where to start you from on that.
lobbes: diana_coman: well, I think I get your meaning on the "will eliminate possibility of bugs" point and on the "learning code is like writing well, you won't improve overnight by some series of steps"
lobbes: but wrt to testing in an automated fashion, this is something I've never done
lobbes: *will never eliminate possibility of bugs
diana_coman: lobbes: you can improve anything by a series of steps - it just needs to be the steps that fit the cause of the trouble, not the steps that fit the result of the trouble, generally speaking, lol.
diana_coman: lobbes: hm, let's see then from beginning: what's a bug?
lobbes: I guess I'd generally define a bug as 'behavior that is unwanted'
diana_coman: unwanted by whom?
lobbes: by whomever is the authority of those using the code I suppose
lobbes: or the authority of the environment that the code will run within
diana_coman: lobbes: heh, in that case what are you even testing there? if I run it on my comp, I'll find bugs because my authority vs yours or what?
lobbes: diana_coman: hm, well I mean in the case of the mp-wp-bot, MP is paying me for a product, and he gave a spec. So in this case he'd be the authority I reason; or the one to determine 'this is a bug / this is not a bug'
diana_coman: lobbes: but in that case you can't test without him by your side, no?
lobbes: diana_coman: well, I do have the specifications he gave me. I can test against that without him present
diana_coman: lobbes: aha, so your def of bug is wrt to spec: a difference between specified behaviour vs actual behaviour of your code.
lobbes: diana_coman: yeah, I would agree with that
diana_coman: heh, it's one of the usual definitions, yes.
diana_coman: anyway, next step then: since a bug is defined as above, what would "thorough testing" of some code mean?
lobbes: I'm thinking at a minimum I'd be running a series of tests that would show me that the bot's actual behavior lines up to specified behavior
lobbes: but I guess I see what you mean by "how to define thorough"
diana_coman: lobbes: there is even quite a large body of uhm, effort let's say, poured into what is technically called formal specification precisely with a view towards formal verification aka "as thorough as it gets when testing god dammit" ; preferably even formal *proof* of correctness (which is even pushing it further).
diana_coman: lobbes: at any rate, if you want "thorough", you'd need to take the spec, extract all desired behaviour at the very least and then check that; there is of course further trouble caused by all sorts, not least of which...how do you actually check?
diana_coman: which brings us neatly to the very problem with testing itself as an activity: say you have a very neat and simple spec, it just says program should give result A to input B
diana_coman: so you'll test that simple thing - how?
lobbes: diana_coman: in that example I would input B, and see if I get A
diana_coman: lobbes: right; how many times?
lobbes: statistically, I think I 'should' do 20 times for a sample population. But now I'm starting to see the issues..
lobbes: i.e. if I have 100 inputs..
diana_coman: ahaha; statistically based on what ...assumptions? you do know that *each* statistical model in fact has some very cumbersome assumptions (although in general they are never mentioned and ~always silently assumed only, mainly because it's convenient)
diana_coman: (or rather: because otherwise wtf are we to do???)
lobbes: yeah, lol. I do recall some heavy assumptions back in my stats 101 days (and really with anything to do with 'models', be they financial models or whathaveyou)
diana_coman: thing is: above your population of inputs has only one item so not exactly *that* the trouble even, no; the trouble is that your code is running in a whole environment and it's not in fact as isolated of it as you'd like to think; what if it's a pointerfuck that reads nonsense on the 100001th attempt for instance?
lobbes: this does makes sense on the 'can't isolate' point; you'd need to know the totality of the environment, which is very expensive
diana_coman: then there is of course the slightly more complicated spec that is still very simple: program should do simple addition of integers; how are you going to thoroughly test even the *inputs* on this one?
diana_coman: lobbes: not to mention that then it will get run in a different environment anyway and given current state of "software", you can't guarantee anything really.
diana_coman: lobbes: do you know what black box and white box testing are?
lobbes: diana_coman: I do not
diana_coman: eh, so there's a whole to say on testing alone to start with; but even beyond that, the fundamental there is essentially that a test that passes does *not* give you any information as to the correctness of the code really
diana_coman: it's only a test that fails which tells you something useful
diana_coman: and that something useful is "this is surely broken"
diana_coman: however, the opposite of that (this is surely NOT broken) can *never* be found out just from testing, no matter how much you test it there.
lobbes: hm, I see what you mean. So really, the most I can aim for is "simply not found to be broken yet"
diana_coman: if you are really curious, there are even studies re how many bugs one finds on what amount of time spent for testing (and even when having a more informed approach to testing rather than the naive one)
diana_coman: the main result though is that some tests are useful (because most bugs are found through some use, basically) but then it's too much trouble to search for them through this sort of method.
diana_coman: lobbes: pretty much, yes.
diana_coman: now back to black/white box because it's a simple and otherwise useful thing: black box means that you don't look inside - basically you consider it as a whole of which you are interested strictly only in inputs and outputs
diana_coman: so you design tests based solely on whatever correspondence of inputs/outputs you have
diana_coman: white box means that you DO take into account the insides of whatever it is, in this case of your code
diana_coman: hence you design tests based *also* on the code itself
diana_coman: for both of those, there are specific strategies based essentially on heuristics of "most likely ways/places in which code breaks"
diana_coman: lobbes: the most useful part of this whole thing and the main reason why I went in such detail for you here is that the approach as a whole is more generally valid though, it's not just specific to software.
diana_coman: whatever you are interested in and you are trying to understand or assess - if you go at it by "testing", you'll have quite the same type of trouble (only probably magnified because more complex than software)
lobbes: diana_coman: hm okay. This is all helping quite a bit. So if I understand correctly, when testing something I should be focusing primarily on a black box testing approach with an eye towards tests that are most likely to illuminate the most bugs
diana_coman: lobbes: why do you say focus on black box primarily?
lobbes: diana_coman: hm, I misunderstood you above when you said 'approach as a whole'; I equated that to the black box testing (since you said that is when you consider it as a whole)
diana_coman: lobbes: no; the approach is all the above, lol.
lobbes: now I gotcha
lobbes: so, I have a few q's: for one, what is the benefit anyway to testing separately like that (looking at code vs not), and two, how do I know which tests will illuminate the most bugs?
diana_coman: black box means considering an item as a whole (different stuff!)
diana_coman: lobbes: they tend to catch different bugs & black box frees you from what you "think/know the code should do" esp if it's your code & in some cases you can't do the white box; you can't know upfront really; if you want to choose only one approach, you'd go for white box rather than black box at all times.
diana_coman: lobbes: or do you mean how to design the tests for either?
lobbes: diana_coman: ah okay, I understand what you mean now on 'why do separate white/black box testing'.
diana_coman: in a nutshell, for black box testing you'd partition the inputs space into whatever partitions are relevant + choose testing inputs so you cover each partition through at least one value + all boundaries (because that's the most usual case of fail)
diana_coman: for white box testing, you'd aim in principle to cover at least once all the control and data flows in your code.
diana_coman: this would be the most basic stuff really.
lobbes: this makes sense, thank you!
diana_coman: lobbes: see, the power of a few questions; you're welcome.
lobbes: diana_coman: well, I definitely have a much better plan of attack for testing this bot now. However, I definitely think I'll need to plan more time to work on it as well
diana_coman: re automated testing, the idea is that you write them once but you can run them as many times as you need and that is *very* useful for next time when you change something/add something to the code.
diana_coman: lobbes: one important implication of that limitation of what you can find by testing is that it's *always* a much better pay off in the long term to not have to test much ie to know what it does rather than test for what it does.
diana_coman: again, extremely relevant and valid for life, not only for code.
lobbes: I can definitely see the general applications of that advice, that is for sure
diana_coman: lobbes: did you have further stuff to implement for mp-wp?
diana_coman: I seem to recall something else to enable a move from current display of logs.
lobbes: diana_coman: hmm, well I mean that is the bot. It'll display the logs in the blogs (as seen in my haphazard testing blog)
lobbes: though now that you mention it there was a related change to the xmlrpc.php I had to make; I'll need to vpatch that too at some point
diana_coman: lobbes: does it update in db if it's current log?
diana_coman: more to the point: what would I need to do in order to have the content of currently logged channels spit out in real time into corresponding daily articles on my blog?
lobbes: diana_coman: you'd just need to press my mp-wp-bot vpatches, configure it for your mp-wp install database, and then run the bot
lobbes: though I do still need to release a second vpatch that is not found in above link
diana_coman: lobbes: so perhaps once you are done, you do that & illustrate it since you have a logger running anyway, right?
diana_coman: lobbes: also, why the latency throughout?
lobbes: diana_coman: sure thing, like put together an install manual on my blog?
lobbes: diana_coman: am I slow to respond? I'm honestly just this slow lol
diana_coman: lobbes: yes; preferably after you had it running and basically living proof that everything is working great.
lobbes: diana_coman: I'd love that. Sounds like a plan to me
diana_coman: lobbes: relatively slow, yes; and at times visibly slow, to the point I wonder if I lost you/ it's too much in one go, lol.
lobbes: diana_coman: nah, sometimes I'll just be reading and grokking, though sometimes I can sense you are moving a point along so I'll let you finish
lobbes: diana_coman: I'll let you know if it ever becomes too much in one go. So far it hasn't been for me
diana_coman: lobbes: the let finish part is fine, obviously.
lobbes: kk
diana_coman: lobbes: btw, it's not like it has to be a meeting spec as such; you know I tend to be around from about 7pm on most days so you know, just ask then/say something, it's fine
diana_coman: for that matter, anyone else
diana_coman: lobbes: was there anything else?
lobbes: diana_coman: makes sense, and good to know. Though (and I think dorion_road mentioned this at some point for himself) I kind of like scheduled meetings. idk why
lobbes: diana_coman: nothing else from my end
diana_coman: heh, you like scheduled everything, don't you
lobbes: though this was very helpful, so thank you again for your time
lobbes: hahaha for some things, yes I do!
diana_coman: lobbes: do note though that you keep pushing those remaining 2 articles
lobbes: diana_coman: noted
diana_coman: there's always some reason to push them to next week, ahem; so I'd say 2 pushes is fine, but then can't push it 3rd time.
lobbes: diana_coman: okay, I'll make sure I get working on article 2 by week 4
diana_coman: good; and you're welcome.
lobbes will bbl; food