[01:07] <sergio-br2> hey cjwatson, do you know what's the "epoch" equivalent string in the recipes ?
[01:07] <sergio-br2> {epoch}  ?
[01:14] <wgrant> sergio-br2: There's no variable for it; you have to include it in the version template manually.
[01:14] <sergio-br2> ok, thanks
[11:33] <slappymcfry> What is the best way to search through code in a project hosted on launchpad? Like github's "search this repository".
=== slackner_ is now known as slackner
=== [HeOS] is now known as HeOS
[20:44] <haasn> Am I stupid or is it virtually *impossible* to find an overview of the syntax used in launchpad's bug tracker?
[20:44] <haasn> I've been googling for 10 minutes on how to create a code block, and I can't “trial and error” it either because there's no “preview” button
[20:44] <haasn> nor can I create a comment and then edit it
[20:47] <haasn> I feel like I must have exhaustively searched through the entirety of https://help.launchpad.net/ by now and I still haven't found one sentence concerning the syntax, or how to make code blocks - or anybody else asking online
[20:47] <dobey> there is no special syntax. it's plain text
[20:47] <haasn> No code blocks in comments, then?
[20:47] <dobey> no
[20:48] <dobey> if you have a suggestion for a change, you can attach a diff
[20:49] <haasn> Would it be that hard to get e.g. basic markdown support into launchpad? Seems like every other bug tracker on planet earth has at least some form of syntax support for emphasis, pre-formatted text, etc.
[20:51] <haasn> Sorry if I come across as frustrated, it just sort of agitates me whenever a project's bug tracker is actively fighting my ability to contribute to the project. Launchpad has certainly been doing that every time I want to use it :(
[20:53] <wgrant> Launchpad comments are always monospaced, so the only thing code blocks would give you would be slightly more control over intra-line spacing and potentially syntax highlighting.
[20:54] <wgrant> We'd like to add Markdown to comments, but that has certain complex requirements around editing, previews etc. that require significant policy decisions.
[20:54] <haasn> Ah, with them always being monospace it makes a bit more sense now - I was not aware of this
[20:54] <wgrant> (yes, the comment input box isn't currently monospace, which is very weird)
[20:55] <haasn> Rather my browser always displays everything in monospace so I can't really tell when something *is* actually monospace
[20:55] <haasn> But I don't understand this: How does this implicate policy? It's not like the ability to use markdown + adding a preview dialog needs any drastic changes to the permission model or whatever
[20:55] <haasn> Seems like in principle it would be a matter of somebody implementing it, posting a diff, and it being merged
[20:56] <haasn> Since there's not much to discuss in terms of it being an improvement, or is there?
[20:57] <wgrant> The problem is that typos are more common and problematic in Markdown, so editing becomes a harder requirement.
[20:57] <wgrant> And comment editing isn't currently supported, because of the complex policy issues surrounding it.
[20:58] <haasn> Isn't that the point of a preview box? :p
[20:58] <haasn> (If you want to make typos hard make the preview a “live” preview that updates itself on changes)
[21:01] <haasn> But isn't this a bit over-thinking / bureaucracy for the sake of bureaucracy? I don't see, say, github agonizing over whether users should be allowed to edit their own comments after posting them :p
[21:03] <wgrant> GitHub's notoriously over-zealous with allowing editing.
[21:03] <wgrant> Repo owners can even edit others' comments on their repos.
[21:03] <wgrant> It's very open to abuse.
[21:03] <haasn> I've worked with hundreds of projects on github and not once has this hindered the growth of free software in any way
[21:03] <haasn> At least in my experience
[21:03] <wgrant> There's also the problem that people are already confused that when they delete their comments they might already have been emailed out.
[21:04] <wgrant> These problems are not impossible to solve, but they are substantially more complicated than they initially seem.
[21:04] <haasn> You can make a problem as complicated as you want but that doesn't mean there's any point in agonizing over it if the real world _impact_ is zero
[21:05] <haasn> Nobody agonizes over the metaphysical ramifications of “x += 1” when writing a line of code?
[21:05] <haasn> s/?//
[21:05] <wgrant> There is real-world impact.
[21:05] <wgrant> Just because you haven't seen it on the projects you work on doesn't mean it's not there.
[21:06] <dobey> and your inability to use formatting in comments does not hinder your ability to contribute. it simply means you can't do it with pink text
[21:07] <dobey> (also, launchpad is open source, so you are totally welcome to work on patches to enable some formatting, with the expectation that they will be reviewed when you submit them) :)
[21:07] <haasn> What makes launchpad's projects special in the way that they run into these issues more than projects hosted on other websites?
[21:08] <haasn> (The fact that they're written by companies large enough that bureaucracy starts getting in the way of code, I guess? :p)
[21:09] <dobey> github choosing to ignore problems doesn't mean those problems don't exist
=== commandoline_ is now known as commandoline
[22:40] <nacc> is there a simple way for me to indicate one bug (e.g., a request for a new version of a package which really is a set of packages) is blocked by another bug (e.g., an update of one of those specific packages)? not finding anything obvious in the UI immediately
[23:06] <nacc> nm, i see how it's meant to be done, i think