[00:00] tuxxy__, are you using hte email addresses registered in Launchpad? [00:00] barry, are you around? [00:00] yes im using the correct ones, I receive all information just cannot send out information [00:01] all the other mailing lists are fine, just the one I own heh [00:01] tuxxy__, what's your team name again? [00:01] ~64-bit ? [00:01] https://lists.launchpad.net/64-bit/ [00:01] my mail list is 64-bit@lists.launchpad.net [00:02] k [00:02] looking at your settings now [00:02] ok tuxxy__, as far as I can see, your team settings and personal settings appear correct. [00:03] I've asked someone to look at the mailing list machine just in case something is awry [00:03] our mailing list expert has left for the day so I may need you to file a question with the issue [00:03] note that you won't receive copies of the email you send, but it should show up in the log [00:03] (because you're on gmail) [00:04] ok no problem, the mailing list originally got rejected but then activated once the bug 237210 got fixed [00:04] Launchpad bug 237210 in launchpad-foundations "should be a way to delete/disconnect a mailing list" [High,Fix released] https://launchpad.net/bugs/237210 [00:05] its been active for a few days now and my e-mails dont show up in log even if i send it from an e-mail account not associated with launchpad [00:05] I must have sent 15 now heh [00:07] ok [00:07] I just sent a test email [00:07] and it arrived [00:07] yep it worked [00:07] yes, everyones does, except mine for some reason [00:08] it just goes into a blackhole? no bounce msg? [00:08] nothing [00:08] like it has been successful but then my members dont receive it and also its doesnt appear in logs [00:09] k [00:09] That sort of suggests to me that it is held for moderation [00:09] and mthaddon just found an issue that, on the surface, appears to be related [00:09] no, its not moderated [00:09] and if i do click the moderate link no msgs appear [00:10] and they won't [00:10] who is moderating it then heh [00:10] as I understand it, we intercept inbound msgs and if we see they need to be moderated, they get put in the queue. [00:11] it appears the process which check those and puts them in the queue might not be working [00:11] hmm well its been 2 or 3 days now, also why are mine not getting through but others mails are which are sent more recently [00:12] tuxxy__, we made a change recently to the internals to something we thought was no longer being used. The error that was found suggests we missed something. [00:12] Let me queue this up for our mailing list guru to check in the morning. [00:14] ok no problem, you want me to make a report or anything [00:14] tuxxy__, could please email the list again from your google account? [00:14] ok [00:14] and yes, tuxxy__ can you please file a bug report on it. Please include the team name and what you've explained above [00:14] I'll make sure it get's over to our mailing list guru in the morning [00:15] inlcude that you talked to me in the bug report please [00:15] and that I verified proper setup in LP [00:15] and was able to send a test post [00:16] ok no problem, is this correct address https://bugs.launchpad.net/bugs/+filebug [00:17] I sent the e-mail also [00:18] tuxxy__, https://bugs.launchpad.net/launchpad/+filebug [00:18] that will get you to filing against Launchpad itself [00:18] thanks [00:37] Rinchen: https://bugs.launchpad.net/launchpad/+bug/273790 [00:37] Ubuntu bug 273790 in launchpad "Mailing list errors, owner unable to send out information to team, can only receive inbound messages" [Undecided,New] [00:39] tuxxy__, cheers for that. [00:39] no problem [00:39] =) === RAOF_ is now known as RAOF [01:44] Is there some reason that project bugs won't expire, even though the project is setup to have them expire? Like bug 151612 [01:44] Launchpad bug 151612 in mythbuntu "Remote not supported" [Wishlist,Incomplete] https://launchpad.net/bugs/151612 [03:01] How the eff do I add an additional affected branch to a bug? [03:03] mkanat: A project series? [03:03] Sure. [03:03] mkanat: "Nominate for release", under the status table. [03:03] Okay. And then what? [03:03] I'm the owner... [03:04] Select the series, and you're done. [03:04] It just says "Nominated for Bugzilla-3.0 by Max Kanat-Alexander" [03:04] Ah, you apparently don't have privileges... [03:04] I'm the project owner. [03:05] Is there a driver assigned? [03:06] There is now. [03:06] * mkanat notes to self, "Don't make my bug-tracker work this way." [03:08] Can you point me to the project and bug so I can actually see how things are? [03:08] And how should it work, in your opinion? [03:10] wgrant: Well, that would be a little bit of helping the competition, wouldn't it? :-D No, I'd be happy to. [03:10] Just give me a second while I'm doing what I was doing. [03:11] The only relevant bugs I can see on your list seem to already have tasks against 3.0. [03:11] wgrant: I just did it. [03:11] wgrant: That is, I appointed my team the Driver. [03:12] wgrant: The main problem that I have with Launchpad is that things take a lot of explicit setup in order to get them to start working. [03:12] wgrant: For example, the Driver should be the project owner, if not set. [03:12] For example? [03:12] I would have thought that the owner should have that privilege, right. That sounds like a bug. [03:12] wgrant: Okay. [03:12] It doesn't make sense how it is now. [03:12] wgrant: When I was originally setting up the project, also, I felt a bit overwhelmed by all the things that I had to set up. [03:12] Yeah. [03:13] (I am not a Launchpad developer, I just file lots of bugs and complain a bit) [03:13] wgrant: I kind of just want a single page that says "what's the name of your project, list your branches, do you want to report bugs here?" [03:13] wgrant: Fair 'nuf. :-) [03:14] Launchpad has a bit of a problem that some of my apps have sometimes--that it exposes the UI based on how its backend objects are structured. [03:14] Hmm, it is a bit strange that the project creation form doesn't ask for which bits of Launchpad will be used [03:14] wgrant: Well, also that I first had to create a series and then assign a branch to it, and there's SO MUCH navigation on every page. [03:15] I'm sure it's handy for somebody who's very experienced with the system, but not so much for me. [03:15] It's not like a normal form, where there's just labels and values. [03:15] mkanat, we're working on making that easier [03:15] Those I understand, there can be a lot of that on a page (even though ideally there shouldn't be). [03:15] beuno: Cool, cool. I figured you were. :-) [03:16] a lot will happen a few months from now [03:16] If I had the same resources to throw at Bugzilla that you guys have to throw at Launchpad, it would be beautiful and amazing. :-) [03:16] beuno: So Launchpad developers have been saying for years... [03:16] Of course, Bugzilla also does a lot less. :-) [03:16] wgrant: Well, that's the nature of s/w development. :-) [03:16] It is. [03:16] wgrant, well, I'm new here. So it's a new promise :) [03:16] Woah. [03:17] This is an ugly page: [03:17] https://bugs.staging.launchpad.net/blahblahblah/+filebug [03:17] Three lovely big yellow alers. [03:17] *alerts [03:17] it is icky [03:17] I'm less concerned about the aesthetics than the confusion for new users. [03:18] mkanat, that's my focus, improving usability [03:18] beuno: Cool. :-) [03:18] aesthetics is secondary [03:18] focused on making worflows optimal [03:18] Great. :-) [03:18] planning tons of user testing [03:18] One thing that's confusing to me is that Launchpad considers "Fix Committed" to be an open bug. [03:19] yeah, because it hasn't been released [03:19] It is, to users. [03:19] Yeah, but not to me. :-) [03:19] And "List Open Bugs" is the only convenient bug browsing link that's on any page. [03:20] The search UI really needs a makeover. [03:20] it does [03:20] it's also one of the hardest things to do properly [03:20] You're telling me. :-) [03:21] beuno: I know. [03:21] wgrant, so, we're picking our battles :) [03:21] mkanat: Hm, I was able to target to a release fine without being the driver. [03:21] beuno: But that is perhaps the oldest battle in all of Launchpad. [03:21] wgrant: Yeah, so can another member of my team. [03:21] wgrant: Just I couldn't. [03:21] It hasn't been touched in years. [03:22] The pages in bug #272343 come close to being as ignored, and CVE pages similarly. [03:22] Launchpad bug 272343 in launchpad-foundations "All six (yes, 6) views relating to upstream linking are broken/different/inconsistent/strange/outdated/unmaintained/[etc.]" [Undecided,New] https://launchpad.net/bugs/272343 [03:22] But there aren't many of that grade around Launchpad. [03:24] wgrant, as I said, we have many battles to fight. Others seem to be more of a priority [03:25] This is a problem with proprietary software. If the maintainers don't feel that distributions or security or searching are important, they stagnate for years and torture us. [03:25] And there's not a thing we can do about it. [03:28] wgrant, torture seems a bit extreme [03:29] and, there are a lot of users to make happy [03:29] so it's expectable for open or closed software [03:29] to have unhappy users [03:29] we still want to do our best with limited resources [03:29] Yes, but if it's open then $IGNORED_MINORITY can fix their pet issues. [03:30] not always, no [03:30] you have to understand the code [03:30] understand the development procress [03:30] It's a lot easier to do that when it's possible. [03:30] convonce others it's important [03:30] etc etc etc [03:30] yes [03:30] Launchpad will be open next year [03:30] we'll see how that changes things [03:30] Indeed. [03:30] But how open is open? [03:30] The question is will canonical accept code from non-employees [03:31] yes they will [03:31] That is the big one, yes. [03:31] Or are we going to have a GCC/NetHack style catheridal development model [03:31] no, code will be welcome [03:31] Is it open as in "oh look, here's our code, so we're not evil any more. run along now", or "come along and contribute"? [03:31] Aha. [03:32] why would we throw away useful contributions? [03:32] Because I don't think anybody imagines that Launchpad would be opened for the sake of being open. [03:32] Or else it would already be opened [03:33] something tells me that Canonical != Microsoft [03:33] just a hunch though [03:33] tgm4883_laptop, Microsoft in its early days was very hacker friendly [03:33] * tgm4883_laptop notes NCommander's idea of Canonical becoming more like MS. Makes note to squash him. [03:34] * NCommander is a firefighter, and thus not bothered by squashing [03:34] or splatting, fire, guts, gore [03:34] vomit (as long as its on my partner), [03:34] :-) [03:34] silence infidel! [03:34] Opening the code just opens up the possibility for people to contribute. [03:34] I said *early* Microsoft [03:35] It doesn't mean that they'll make good contributions, or contribute at all, but it does make it possible to do so. [03:35] i.e., back when they shipped a UNIX [03:35] I'm more interested in running my own Launchpad for its archive tools for Nexenta. [03:36] I think the only place one's own Launchpad would make sense would be internally in organizations. [03:36] If it's open source stuff, might as well use the central one. [03:37] What about something like Debian, I don't think they'd want their development hosted by Canonical, but I could see them dumping dak for Soyuz [03:37] don't underestimate the value of someone else hosting it, and taking care of all the infrastructure for you [03:37] and, being able to cross-link to ther projects [03:37] Yeah, the hosting is helpful. [03:37] Some projects don't trust being hosted by a central authority. Or else every project would be on sourceforge, or FSF Savannah [03:38] NCommander: No, because those suck. :-) [03:38] .... [03:38] Yeah, SF is awful. [03:38] * NCommander was a FSF Savannah admin [03:38] :-P [03:38] I agree at the moment Launchpad slaughters any SF based solution [03:38] NCommander: Yeah, but I'm talking about the UI, not the administration. :-) [03:38] * NCommander is not going there [03:38] I'm too tempted [03:38] That's fine. :-) [03:39] Well, for better or worse, at least Savannah's UI remains constant(ish) [03:39] Something VA Linux should learn [03:39] * NCommander notes the current SF interface can cause eyes to bleed [03:39] Hahahaha. [03:40] it will be interesting to see what happens when launchpad gets open sourced, to say the least [03:40] mwhudson: Very much so. [03:40] I'd be willing to work to seperate Soyuz and publisher [03:40] so its possible to keep control and the fun stuff on launchpad.net [03:41] But projects like Nexenta or Baltix can handle the build infrastructure [03:41] wgrant: I expect a certain amount of "aiee! my eyes!" [03:41] wgrant has immunity to eyes burning [03:41] especially from people with interests like NCommander :-p [03:41] mwhudson: Can't be worse than some of the code I've had to work with. [03:41] no, it's not so bad [03:41] Its an intrinsic from x86 real mode ASM programming [03:41] * NCommander REALLY needs to stop playing nethack [03:42] soyuz is a beast anyway you look at it though :) [03:42] Heh. :-) [03:42] mwhudson, I've committed code to dak [03:42] It can't be THAT bad [03:42] mwhudson: Considering what it does, it has to be. [03:42] wgrant: right [03:42] I'd like to remind you all that I've been refactoring Bugzilla for years. And it can't be worse than Bugzilla 2.14. :-) [03:42] NCommander: ah, you come pre-scarred then? :) [03:42] Bugzilla is proof for me that Perl is a write-only language [03:43] NCommander: You haven't seen it lately, though, I'm sure. :-) [03:43] mkanat, you can refactor crap, but its still crap [03:43] (although its object oriented crap) [03:43] NCommander: I've actually had quite a few people say to me, "The architecture is really nice now!" [03:43] Maybe its nicer now [03:43] Yeah, that'd be an understatement. [03:44] However, perl by definition has write only tendencies [03:44] Every language has the ability to create write only code [03:44] (with the possible exception of python) [03:44] perl and C have high chances of becoming write only [03:44] brainfrack is write only ;-) [03:45] Hahahaha, for sure. [03:45] And no, you can create write-only code in Python. [03:45] Well, if you hack Python to give it COME FROM [03:45] Just pick really bad names for all your variables. [03:45] * NCommander notes he's touched COBOL [03:45] NCommander: Heh. :-) [03:45] You know, its not hard to know why my pain tolerances are so screwed [03:46] ALthough even my hack-o-meter explodes from time to time [03:46] gcl [03:46] source tarball is 15MB [03:46] The diff is 70MB [03:46] (uncompressed) [03:46] yeah [03:46] That is your eyes burning [03:47] I touched that once... ow. [03:47] most of us have more sense than that [03:48] ajmitch, your talking to people who write real mode code. [03:48] Sense was undefined years ago [03:48] so? [03:48] :-) [03:55] hey emgent [03:56] * NCommander plays nethack [03:59] heya :) [04:02] what's up emet [04:02] er emgent [04:02] emgent, still interested in WMubuntu? [04:07] yep, but we have some problem in wmaker now [04:07] we are waiting new infra [04:07] emgent, well, we can spin the meta-package with a PPA [04:08] Then its a matter of creating CDs [04:08] sure we can [04:09] but i think that first we should propose ubuntu-minimal ehehe [04:09] Use server as a base [04:09] And disable the server packages [04:09] uhm yep, good idea for start [04:10] anyway when i have time i will take a look, this isnt a good period now [04:11] heh [04:11] cya emgent [04:11] i have some other priority-stuff to write for ubuntu [04:11] hehe :) [04:12] 5.12 am arghhhhh i should sleep [04:12] see you later NCommander and thanks ;-) [04:12] cya emet [04:14] * persia peers about to see if anyone feels like discussing workflows for branch merging, and automation of branch status values [04:15] * NCommander shoots a hand up [04:15] * mwhudson points persia at thumper [04:15] * NCommander gets a finger in an light socket and is electrocuted [04:15] * NCommander dies [04:15] * NCommander wants his possessions identified ;-) [04:15] mwhudson: OK. jml and spiv were deeply engaged about 18 hours back: were those not the right people? [04:16] persia: they're good too [04:16] persia: but thumper is actually working on this stuff right now [04:16] persia, we're working on that right now [04:16] persia, what would you like to see changed about the current workflow? [04:16] what mwhudson said [04:17] persia, we've got *very* good results up to now, and the process should be very simplified soon [04:17] we've been doing workflow changes [04:17] and UI changes [04:17] Actually, it's not so much about what to change, and how to change the automated detection of branch status, and looking at workflows for branch merging or patch hunting to ensure the end-state is desireable. [04:17] persia, one of the changes we have will mark branches as merged automatically [04:18] if they already where [04:18] auto-merge-detection [04:18] beuno: Right. It was mentioned that the process to manually set branch status would be lost once that landed, and I wanted to discuss only losing some of it. [04:18] * persia prepares a pastebin with a summary of desired state for those not involved in the discussion ~18 hours back) [04:19] persia, it won't loose any manual status changes [04:19] just wil set it merged automatically [04:19] it does the work for you [04:19] but doesn't make automatic mandatory [04:19] beuno: Right, but we *should* lose some: when a branch is merged, it should go from "Development" to "Merged", and back to "Development" and the next unmerged push. [04:20] persia, sure, that's for branches, not merge proposals [04:20] and yes, that's exactly the idea [04:21] (we've been working on merge proposals specifically these days) [04:21] other parts of code will come after that, one of them being branch listings/statuses [04:21] Right. It was suggested that as a result of that, it would be possible to automate all branch statuses. I believe that it's not possible to automate "experimental" or "abandoned" as these represent the input of human opinion [04:22] persia, do you think those statuses are useful? [04:22] beuno: Yes. [04:23] persia, you would be able to set something as inactive [04:23] which is basically abandoned [04:23] but experimental would go [04:23] What does "inactive" mean? Also, why change established nomenclature? [04:24] active/inactive seem like better terms, don't they? [04:24] Anyway, http://paste.ubuntu.com/49919/ represents the set of statuses I'd like. [04:24] No. [04:24] Inactive sounds to me like it should be determined by time since last commit. [04:24] activity is observed [04:25] that's a very tricky thing to get right [04:25] "Abandoned" carries the explicit implication that the developer no longer believes that the path pursued in the branch is useful. [04:25] persia: you can observe that something is abandoned too [04:25] wgrant: That's not very helpful. What if I've a stable branch that hasn't gotten any updates in over a year because there are no bugs, and it is feature complete? [04:25] lifeless: How> [04:25] s/>/?/ [04:26] persia: branches are marked as stable by associating with a series [04:26] OK. s/Trunk/Stable/ in my paste then :) [04:26] persia: no activity[no bug links, commits, merges-from, merges-to, commits-to, whiteboard, etc], not a release branch. [04:26] persia, and showing merged branches is a bit pointless, so they should become inactive [04:27] beuno: I don't think they should become inactive [04:27] beuno: I think they should not be shown, but thats different [04:27] lifeless: And what if I want to abandon something after two days of work? How can I distinguish this from someone who only codes on weekends? [04:27] persia: Right, so that state shouldn't mean "abandoned". [04:27] lifeless, sure, I mean not shown. With the status "merged" [04:27] lifeless: Also, whiteboard doesn't show in the branch list, so is useless for branch discrimination purposes. [04:27] persia: Activity is surely objectively measured. [04:27] Abandonedness cannot me. [04:27] *be [04:27] wgrant: Precisely. Which is why I want a manual flag for that. [04:28] persia: You challenged an assertion, I think I've shown it. Now you want to talk about whether it makes sense to 'only observe' but I didn't claim that that was sensible. [04:28] lifeless: fair :) [04:28] with this, as with most things, I think a tasteful melange of inference and explicit information gives the best results [04:29] persia, your statuses make sense to me. I'll add that to the wiki so it's part of the discussion [04:29] beuno: Thanks. [04:29] specifically, I want to be able to correct lp when it infers it wrongly [04:29] Now, about "Experimental". [04:29] I'd like it to infer abandoned branches [04:29] Sometimes people work on stuff that *should not be merged* and *should not be considered for cherrypicking* because it is far too invasive. [04:29] and to notice when things are merged [04:30] I'd like to have this be another thing people can set on branches, so those who are looking to cherrypick stuff know not to go there. [04:30] lifeless: I'm fullly behind noticing when things merge, and when they diverge again. [04:30] persia, in general, you should know better than go around merging into random branches. no matter what people say about them [04:30] inference of abandonment is harder. [04:31] persia: I think lp is in a good position (see the list of things I made above) to do a decent job [04:31] beuno: See, I disagree fundamentally with the style of development that your claim asserts. [04:31] If I know a body of code, and I'm bored, there's no good reason for me not to go peering around in other people's branches for cherrypicks. [04:31] Letting them flag things as "Experimental" tells me I probably don't want to look there. [04:32] I like having a 'bleeding' flag [04:32] I am not sure that in my head its in the same dimension as activity [04:32] Well, I mostly like "Experimental" because I'm conservative regarding nomenclature changes, but yes. [04:33] I'm not sure either of "Experimental" or "Abandoned" are about activity, but more about branch owner's opinion about the branch. [04:33] In the first case, it's stuff that is *very* new and probably kills kittens, and in the second case it represents a blind alley (and I'd rather see stuff abandoned than deleted, just to help build a better map of which alleys are blind) [04:33] persia: so in terms of choosing what branches are interesting to show [04:34] persia: a lack of discernable activity is a good default filter; [04:34] lifeless: Is it? That assumes someone who pushes a branch has some attachment to the project to which the branch is associated. [04:35] persia: No it doesn't [04:35] Let's say someone branches locally to make something work better for them, but they aren't feeling particularly socially responsible. Because someone pokes them on IRC, they push their branch to LP, and then let it rot. How does this make the branch uninteresting without inspection? [04:36] persia: after 6 months with no comments, merges-to-, merges-from- (fuck it, read the list above) [04:36] persia, I have a hard time believe people will use the experimental flag reasonably, or, at all. But it's going to be widely discussed before taking a decision, so I'm sure we'll go with the overall best change [04:36] persia: its not going to be easy to merge, to work with, and clearly the contents *have not been interesting to anyone so far* [04:36] beuno: We have an Experimental flag now. It doesn't get used much, but I don't see how it's better to take it away. [04:37] lifeless: OK. I can see that argument. And given that it has rotted over time, it becomes increasingly hard to use for anything. [04:38] persia, the only benefit I can see is that it simplifies things a bit. Less choices makes it easier for you to choose. But I'm not strongly set on this, especially if others feel strongly about keeping it [04:38] beuno: I'd rather tags than an experimental bit [04:38] beuno: Well, the only things I think are sensible choices are "Experimental" and "Abandoned". We ought be able to infer all the rest of the available statuses from the branches directly. [04:39] lifeless: The main reason I like having it as a flag is so there is a standard text to show in the default listings. [04:40] persia: that implies a standard reasoning behind its use [04:40] lifeless, persia, wouldn't a description of the branch be enough? "this branch is experimental. It *will* kill your baby" [04:40] lifeless: Indeed it does. [04:40] persia: and I *don't* believe for a second that we all share that in this currently-limited group, let alone thousands of devs [04:40] beuno: I don't see either the description or the whiteboard in a standard branch listing. [04:41] persia, right. And it won't be. But if you're interested in something, go to it's page, read about what youre going to do [04:41] lifeless: In the same manner as bug use of various bug statuses, if we can achieve some loose consensus and document it, we can create a common reasoning behind their use. [04:41] persia: anyhow, you could always have a stock text for the tag experimental [04:41] plenty of people will have experimental branches as "new", which will make the status a bit pointless and random IMHO [04:41] persia: to date, bug statuses have failed to do that [04:42] lifeless: Well, given that we *still* don't have any way to differentiate interface based on tags in Malone, I'm not tempted by that. [04:42] writing descriptions to what the rational behind that branch is makes more sense to me [04:42] Tags are useless as status indicators; you can't see them unless you dig deep into each bug, which is slow and painful. [04:42] fooding [04:42] beuno: But "New" will go away as it becomes time-based. [04:42] wgrant: don't conflate things :) [04:42] lifeless: What was I conflating? [04:42] persia, well, "development" [04:43] beuno: Also, if I'm bored, and want to look at likely branches from which to cherrypick, I want a smaller set, not to have to check the bug page for *each* page. [04:43] beuno: Well, I'm anticipating that it's not hard to tell people in a given project to use "Experimental" for the kills kittens stuff. [04:44] Especially so if that matches the documentation presented by LP in the case where someone tries to edit the branch status. [04:44] persia, I fully understand your use case. The thing is, our experience is that no one really uses it properly, and tends to confuse users [04:45] hence the inclination to kill it [04:45] beuno: I use it properly. I'm not confused. I don't want my feature to go away :) [04:45] but it's not a terrible thing to leave it around if there are enough use cases for it [04:45] Why are my users looking at the branch listing? [04:45] persia, well, if you say it like that, it's hard to take it away from you... ;) [04:46] also, for your use case, *everybody* has to use it properly [04:46] but, well, we'll see what comes out of it [04:46] beuno: Well, yes, but the documentation on LP seems to encourage proper use. Generally everything that isn't "New" today is the result of someone trying to do it properly. [04:46] I see your point for keeping it [04:47] and I don't think removing it will solve much [04:47] If the standard workflow (New -> Development -> Merge Proposed -> Merged -> Stable) is automated, that's a big win. [04:47] I just fear that automation of most of it will cause that which cannot be automated to be dropped. [04:48] so, at least from my perspective, I'm inclined to leave it [04:49] Cool! Only about 7 billion people left to convert :) [04:49] sure, change is scary. We should make it as less scary as possible [04:50] Note that I'm not overly fussed about implementation, as long as it's visible from the standard branch lists. If it's easier to do it as tags (but can still be shown), that's fine too. [04:51] persia, well, good news is, the more people you convince, the easier it should be. It's exponential! [04:51] I really don't want more tags on LP just yet [04:51]