[00:34:48] --- haba has left [01:25:38] --- haba has become available [01:44:37] --- dev-zero@jabber.org has become available [02:04:35] --- Simon Wilkinson has become available [02:41:55] --- Jeffrey Altman has left: Replaced by new connection [02:42:33] --- jaltman has left: Replaced by new connection [02:42:34] --- jaltman has become available [04:59:19] --- haba has left [05:56:30] --- haba has become available [06:00:39] --- dev-zero@jabber.org has left: offline [06:00:50] --- meffie has become available [06:14:48] --- reuteras has become available [06:14:53] --- reuteras has left [06:40:11] --- deason has become available [06:50:37] --- dev-zero@jabber.org has become available [06:56:53] --- dev-zero@jabber.org has left [06:57:45] --- dev-zero@jabber.org has become available [07:49:53] today, i want a script which given a gerrit change ID will fetch the most recent patchset, attempt a cherry-pick and if it's clean, push it. [07:56:49] Hmmm. Can't give you it by changeID, but [07:58:08] git fetch git://gerrit.openafs.org/openafs ; git checkout -b temp FETCH_HEAD; git rebase origin/master; git push ssh://gerrit.openafs.org/openafs; git checkout origin/master; git branch -D temp [07:58:22] (replace with the SHA1 of the newest patchset. [08:10:44] a refs/changes/YY/XXYY/latest maybe would be convenient, but you've got the sha1 on the page anyway [08:11:05] if i had the sha1 already .... [08:11:27] You can use refs/changes/YY/XXYY/ZZ there instead, if you want. [08:11:38] it's on the page. i'm lazier than that [08:12:03] But to determine ZZ you'll need a JSON client. The only place that can easily tell you 'latest' is the web interface. [08:12:24] Now, I have a JSON client ... [08:12:39] yeah, I meant if we wanted to request a feature in gerrit itself so you could specify '/latest' without having to give a number [08:13:10] I mean, patchset number (change # still required) [08:13:35] I suspect you'd probably want refs/latest/YYYY (or similar), so that the path could become automagic in the same way as refs/for is [08:14:03] I would imagine that wouldn't be hard to code for someone with a) time and b) Java-fu. Sadly I have neither. [08:15:49] I have some experience with java, unfortunately, it seems I have negative time [08:17:07] we need to find someone with java fu, and not just for gerrit [08:17:32] it'd be nice to do something about jafs. seppuku would also be ok [08:21:04] I think all of the java people I know have negative time [08:23:38] also, the libuafs stuff I've been doing (that will get submitted one of these days) can get you a SWIG interface, and java is supposedly one of the languages you get with swig [08:23:48] i believe it is [08:28:39] --- dev-zero@jabber.org has left [08:37:31] Gah, pinstall, mutter mutter mutter mutter [08:37:36] We're going to need an rc2 [08:37:58] what happened? [08:38:11] /usr/bin/afs_compile_et/compile_et [08:38:22] i.... didn't get that? [08:38:45] Do you use make dest to do your builds? [08:38:59] yes [08:39:09] double-checking... [08:39:18] (that i didn't get it) [08:40:23] Um. Are we renaming compile_et to afs_compile_et in this release? [08:40:43] Because that sounds like a backward-incompatible change [08:41:13] If you're looking for compile_et, you're going to be really sad if you get the AFS one. [08:41:45] So yes, it is a backwards incompatible change, because with 1.4.11 we broke you, and with 1.4.12, we don't. [08:42:13] --- abo has left [08:42:17] True, and it's a good change for 1.5/1.6. But not a good difference from 1.4.11 to 1.4.12, because it gratuitously changes the set of programs we provide, screwing not only people who want that compile_et but also people who already have some mechanism that gets rid of it. [08:42:28] --- abo has become available [08:42:34] 1.4.11 was no more broken that 1.4.10, was it? [08:43:50] It broke whenever the afs_ prefix appeared in front of all of our com_err symbols. [08:44:26] --- haba has left [08:44:34] of course it occurs to me the right fix, now [08:44:41] argv[0] and install it twice [08:44:52] called as afs_compile_et? be ours. no? don't [08:44:57] I'm pretty sure that's been a while, now. ISTR whining at the time because it caused me to have to jump through all sorts of hoops even though I already wasn't using AFS's compile_et. [08:45:26] it's so hard to remember what you've whined about. you have the problem mark poepping accused me of (correctly) [08:45:43] Anyway, do the Mac builds have this problem? [08:45:45] --- haba has become available [08:46:06] And probably for the same reasons. [08:46:13] yes [08:46:40] Looks like we can use the -f option to pinstall to make it go away... [08:46:46] quite possibly. what poepping answered me when i told him what you'll tell me has become true of me to you, so, i guess poepping was right [08:49:18] --- jaltman has left: Disconnected [08:49:26] --- jaltman has become available [08:49:44] I hate the 1.4 branch. None of the nice stuff works. [08:50:03] some of the nasty stuff doesn't either [08:50:19] make -j8 [08:50:26] Kaboom [08:51:26] That you know how to construct unparseable sentences? [08:53:44] that if you bitch too much at someone they won't capitulate. they'll not pay as close attention [08:55:36] Oh, that's what poepping told you. Fine. But what did you tell him? "Too many things are wrong" ? [08:56:10] no. it may well be true but you can't fix everything all at once anyway [08:59:48] http://gerrit.openafs.org/1099 [09:03:04] Don't I know it. [09:07:20] I'll kick of some builds with that patch applied, just to check there's nothing else lurking. [09:14:16] --- haba has left [10:27:21] --- haba has become available [10:31:18] --- Russ has become available [10:38:08] Oh, speaking of release notes (in a Gerrit comment), I've been thinking about this for a while. What would folks think about starting to keep a NEWS file so that the release notes are actually in the tree in the form of a (high-level, not GNU-style) changelog that, for instance, distribution packagers could be installing? [10:38:20] Basically summarizing the sorts of things that we put into release notes for each release in a NEWS file. [10:38:37] As opposed to our current NEWS file, which is not horribly useful. [10:39:13] that would be clever [10:39:29] something akin to the windows "changes since 1.4"? [10:39:39] I think we want the NEWS entries to go in via separate commits from the change themselves, since otherwise cherry-picking is obnoxious. [10:39:45] Yeah, exactly. [10:40:32] Basically, I'd go trawl our release announcements and use that as the initial content for the NEWS file, and then going forward each time we committed something significant, someone should add it to the NEWS file. Then release announcements should amount to copy and paste of the NEWS contents into the announcement plus the standard boilerplate. [10:40:47] That sounds reasonable. I think we also want to have some way of flagging changes that should be release noted. [10:41:00] That would be neat. [10:41:12] That would be one of those things that a better BTS would be good at. :) [10:41:27] Yeh. [10:41:40] Beat me to it. [10:41:59] Release planning, to. Like what are all of the things that should be fixed before 1.6. [10:42:29] I started trying to use RT's bug dependency stuff, but it's just horrific. There's no easy way of seeing whether a dependency has been closed or not from the list. [10:43:20] yes, i tried that with 1.4, milestones. it.... failed [10:43:50] What would be our alternatives if we were to consider a different BTS. [10:44:02] Bugzilla, newer RT with more whistles, Jira, [10:44:06] Anything else? [10:44:18] flyspray? [10:44:25] there's a couple more. [10:44:32] Jira seems to be what all the QA people I talk to love. [10:44:51] I'd really like something like Bugs Everywhere that has first-class Git integration, but I think that idea hasn't baked enough yet to really use. [10:44:59] um. trac [10:45:02] Redmine is the other big one. [10:45:08] Trac has crappy Git integration. [10:45:14] Trac has crappy scaling. [10:45:16] i'm just trying to list shit [10:45:24] Oh, yeah, listing is good. [10:45:39] I guess the other question is what features do we require. [10:46:07] it seems like someone should have already done this research. i wonder if they did. i wonder if they *shared* [10:46:29] --- deason has left [10:46:31] --- abo has left [10:46:41] Researched what features we require? That would be neat :) [10:46:48] Git integration (automatic close, that sort of thing), decent milestone tracking, branch tracking so that we know what branches a bug is fixed on, custom tagging of bugs for things like "this should go into the release notes," the ability to create a private security queue. [10:46:48] feature comparison [10:46:59] --- abo has become available [10:47:00] Someone did a huge feature comparison of BTSes and dumped the results in Wikipedia. [10:47:05] --- deason has become available [10:47:05] There are giant tables and shit. [10:47:21] Mail submission is a biggy. [10:47:26] yeah, it wasn't overly useful as such, being only tables and less commentary, istr [10:47:38] Also sending mail -- letting people who want to get all bug traffic in mail. [10:47:59] Useful privileges, so that we can give people the ability to comment on bugs without jumping through lots of hoops. [10:48:02] How important is open-source-ness ? [10:48:18] Yes - being able to open the system up simply would be a huge win. [10:48:20] Eh. I think it's ideal, but I'm not going to kick and scream if we run Jira. [10:48:31] ideal, but not required, if it's complete [10:48:45] I think Jira is the only real non-open-source candidate that I'd spend any time on. [10:48:46] if it's missing shit, it matters more but i don't want to write bugtracker code. done that [10:48:55] i find jira underwhelming. [10:49:07] not "right out" [10:49:17] Jira has the advantage of being pretty fast. [10:49:27] Bugzilla would seem an obvious contender, but there's a lot of bugzilla hate in the world, too. [10:49:28] However, it's e-mail configuration is... interesting. [10:49:37] its [10:50:31] i kinda hate bugzilla. configuration is fussy [10:50:40] Bugzilla, RT, Redmine, Trac, and Jira are the ones that I see the most people use. [10:50:47] if someone were going to configure it and make the configuration not suck (and keep it that way) i could deal [10:51:13] Bugzilla and RT are packaged for Debian. [10:51:17] Bugzilla's pain is that you have to bend it into doing email. It would really prefer that everything came in via the web. [10:51:19] As is Trac. [10:51:42] Redmine is one of those fascinating Ruby applications in which they decided that Java's application deployment model was the bee's knees. [10:51:43] I don't think Trac would cope with our current bug database, let alone adding new entries to it :) [10:52:13] the system cmu used for incident tracking didn't really like email. the scripting to make it work was unfortunate [10:52:23] (help center/"advisor") [10:52:46] Other people have made bugzilla work with email, certainly for submission. [10:53:10] --- deason has left [10:53:11] And it has an XMLRPC interface you can use to drive updates, so you don't have to use email for integration with other systems. [10:53:24] RT has very strong e-mail support. [10:53:34] --- deason has become available [10:54:09] I don't recall, is the debian bts not really a general-purpose thing? [10:54:12] RT's email support is excellent, i'll give it that [10:54:16] It seems to be what people with an e-mail-driven workflow tend to use. [10:54:16] I get the impression that RT can do a lot of things, if you're prepared to spend the time making it do them. [10:54:37] Debian's BTS absolutely rocks and would be awesome if you got Don Armstrong to set it up for you, like the Emacs folks did. [10:54:50] If you don't have Don Armstrong to set it up for you, you probably would have more fun removing your eyes with a spoon. [10:55:00] RT is like bugzilla in that regard. it'll do a lot if you wanna be an admin [10:55:12] okay, so it's like a custom set-up job each time or something; doesn't come in a box [10:55:20] Yup, exactly. [10:55:23] because I was going to say, I do like using debian's system [10:55:25] Yeh. One thing that I've never seen RT do well is allow third party modification of tickets. [10:55:45] CPAN RT is a perfect case in point of that. [10:55:48] Yeah, I do too. Debian's system is great. I do wish it were in a box. [10:56:27] I just really want a bug system that gets out of the way and lets work occur. [10:56:30] --- abo has left [10:56:53] --- abo has become available [10:57:07] Going to a newer version of RT with possibly a different configuration does have the significant advantage that we don't have to spend a bunch of time figuring out how to import our existing bugs. [10:57:08] note that automatic closing of tickets will probably need branch tracking and such, since some tickets won't want to be closed until they are in both 1.4 and master, I think [10:57:23] and some only need master, some only need 1.4 and so on [10:57:26] Yeah, I'd prefer a BTS that didn't ever "close" bugs as such, but just marked them fixed on branches. [10:57:33] okay, that too [10:57:35] Which is what the Debian system does. [10:57:46] I'm working on some gerrit hooks that can use the presence of FIXES to drive that kind of thing. [10:57:49] well, having commits marking "fixed" on something note it in the ticket at least would be nice [10:57:50] Well, it sort of has a close as well, but all the close is used for is "this is when I send mail to the reporter saying the bug's done." [10:57:54] You could do the same with git hooks. [10:57:56] ding! [10:58:31] (Basically, it falls out of the buildbot stuff - the same code that schedules builds when new patches come into gerrit can also update tickets with the fact that a patch has appeared) [10:58:41] All the actual "is this bug present in this version" is done based on fixed status, which takes a list of versions in which the bug is fixed and figures out if the version is later in a branch than a version in which it was fixed. [10:59:20] yeah, the ticketing system just needs a way to automate checking the box; the git/gerrit side can take care of actually deciding when to [10:59:37] --- haba has left [10:59:52] You want your ticketing system to be aware of your branch structure because you want to be able to ask it questions like "what bugs are fixed in master but not in the 1.4 branch?" [11:00:28] That does mean that you have to know which bugs are present on master, but not in 1.4 [11:00:36] Which is going to require manual intervention. [11:00:38] yes, but I mean I'm not sure you need "git integration" for that, you can just say "we have these branches" and git tells it "bug X fixed on branch Y" [11:00:41] Yup. [11:00:48] You can get a long way with "reported version" though. [11:00:59] ie, if the bug is reported against 1.5.68, assume it's not in 1.4 unless someone says it is. [11:01:17] But if someone reports it against 1.4, assume it's in 1.5 unless someone says it isn't. [11:01:22] True. [11:01:23] That is probably 80% right. [11:01:32] The rest it's hard to not have to handle by hand. [11:01:43] yeah, the number of 1.4-only fixes is very small, right? [11:01:57] Yeah, and is usually stripped-down versions of stuff we committed more general fixes for in 1.5. [11:02:09] There are occasional things like the pinstall thing we just fixed. [11:02:17] --- haba has become available [11:02:18] Which is 1.4-only because pinstall was ripped out of 1.5 entirely. [11:02:34] But they're pretty rare. [11:02:55] --- abo has left [11:03:14] --- abo has become available [11:04:33] I guess we need to decide if we're serious about solving our bug tracking problem, and what timescale we'd like to do it in. [11:04:52] it seems at least partially doable in rt just as it is now, if the number of branches we're talking about remains the small twoish it is now [11:05:17] I hope we never have more than three branches, and mostly try to keep it to two. [11:05:25] There are bunches of other problems with having lots of branches apart from the BTS. [11:05:33] I assume you can update a custom field for "status in 1.4" or whatever via a specially-formed http post or get, which would be triggered from a git/gerrit hook [11:05:42] (into rt that is) [11:06:05] --- Jeffrey Altman has become available [11:06:14] --- Jeffrey Altman has left [11:06:40] --- dev-zero@jabber.org has become available [11:06:55] --- dev-zero@jabber.org has left [11:07:11] --- dev-zero@jabber.org has become available [11:08:02] That still leaves us with the other issues we currently have with our RT, though - lack of milestone tracking, poor dependency management, no-third-party-access, the fact that there's a nunber of members of our community who refuse to add bugs to it, because they find dealing with it so unfriendly. [11:08:20] I see that RT3.8 solves the dependency problem, at least. [11:09:46] The third-party access problem is a really big one. [11:09:57] The MIT Kerberos folks seem to manage to do milestone tracking with RT without too much pain. [11:10:15] I suspect much of the dislike of the current RT is that it's really slow. [11:10:38] I think it's also seen as a place where bugs go to die. [11:11:08] That's also true, although I think that's more a process problem in some ways than it is a problem with the bts per say. [11:11:13] And there's a certain resentment of the fact that people have to ask for permission to be able to change things, so people don't ask, and we lose effort. [11:11:14] Automatic Git integration would help a lot. [11:11:20] we could fix that by never fixing anything someone didn't report, even if we report it ourselves first [11:11:43] Yeah, I think something OpenID-based like Gerrit is a better access model. I'd like to let anyone create an account and get the ability to at least comment on bugs, if maybe not close them. [11:11:53] Debian does pretty well with letting anyone in the world change anything about any bug. [11:11:57] I'm surprised it works, but it does. [11:12:04] You occasionally have to reverse stuff, but not that often. [11:12:10] I think you're fine, even letting people close things. [11:12:44] You don't want to let people delete bugs, but other than that, I would start by making it wide open (with OpenID, which will hopefully keep the spam down for right now) and then restrict if we need to. [11:12:45] It does require that there be enough people watching that stuff that gets closed incorrectly, or people who talk rubbish, are quickly corrected. [11:13:32] * Russ watches Kurt not really get what you're trying to say about development models. Oh well. [11:14:14] Yeah, I think we should do what the Kerberos team does and send all bug traffic to a mailing list for that purpose. [11:14:20] I think we'd get more people watching bug traffic that way. [11:14:20] I've no interest in arguing with Kurt, ultimately. When he wants the last word, he just doesn't approve your post to the mailing list. Been there, done that. [11:14:56] The OpenLDAP team has some truly fascinating social pathologies. It's very informative to watch them work in some respects. [11:15:17] Looks like the newest RT ships with an OpenID plugin. [11:15:24] Oh, cool. [11:16:58] Oh, btw, for the BTS candidate list, there's also Launchpad. [11:17:37] I think it has the major drawback, though, that unless something has changed, it's a service and not a package, so we have to go use their web site to use it. [11:17:43] > That would be one of those things that a better BTS would be good at. Now that I've found where this thread started... I can add fields easily enough for whatever you want to track. Adding custom behavior sometimes requires actually writing code. And sadly, I think OpenAFS's RT is a bit older than the other one I maintain. [11:17:47] Yes, it's hosted isn't it. [11:18:15] Which also has its pluses. None of us have to spend time maintaining it, in theory. [11:18:28] It has some big minuses though. [11:18:44] But really, if you want something from the BTS, consider asking for the feature you want before starting to talk about "what BTS should we transition to". [11:19:14] I think the first thing we should probably do is look at newer RTs. [11:19:21] > Useful privileges, The privilege model is fine. Tell me what you want. [11:19:40] I have the feeling that a number of our niggles would be solved by the changes that are in 3.8 [11:20:17] WRT the privlege model, I think what we really want is a way of enabling 'loosely authenticated' users (ones with OpenIDs, I guess) to comment on, and manipulate bug reports. [11:21:17] Oh, that is probably true. That's really just something I need to find time to deal with. Maybe I can trick my boss into letting me spend some time on RT soon, before I dive into KDC upgrades (anything I do will target work and OpenAFs simultaneously, and I really want to get work's off of this machine in my office) [11:21:28] Yeah, I think newer RTs is definitely the path of least resistance. I think the dependency tracking is the main reason why the existing RT probably isn't going to cut it without an upgrade. [11:22:12] Russ: I think part of the reason the debian bts works is that most people don't realize everyone can do anything :) [11:22:32] Right, so the issue isn't privileges; it's opening it up without opening it up. Well, adding new authentication methods to RT isn't that hard; I've done it before (and so has Derrick), and self or auto account creation isn't that hard either, if you don't have to deal with enrolling people for authentication [11:23:15] Let me get back to you in a couple of hours. Not with code, but with an idea of if/when I can spend real time on this. [11:23:24] Cool. Thanks. [11:24:11] On the privilege front, I think you want to be able to _view_ everything without feeling like you have to authenticate at all. So there's no "guest/guest" login - you just get in. I think that's psychologically very important. [11:25:49] It's a little tricky to do that _and_ have things you can't view without logging in. [11:25:57] Like the security queue [11:26:14] But I agree it's desirable. [11:27:16] --- abo has left [11:28:01] --- abo has become available [11:29:26] it doesn't really solve the problem, but if you just always link to rt with user=guest&pass=guest (or whatever it is), it kinda-sorta-notreally can give that illusion [11:30:18] CPAN's RT has a way round it [11:30:25] Try http://rt.cpan.org/ [11:34:32] they just have a link to login anonymously, instead of needing to type in guest/guest; that would seem very doable for us [11:35:23] Hmm. That's not what I see. You're automatically anonymous, but get prompted to login if you to do anything that requires priviledge. [11:36:20] it brings me to a login page, but I can click a link to log in anonymously [11:36:32] try clocking 'login' in the upper-right, which logs you out and brings you to the login page [11:36:37] > if you just always link to rt with user=guest&pass=guest we do that > CPAN's RT Is über-special [11:36:39] that should be what I saw [11:38:18] the fun thing is periodically some clever person changes guest's password [11:39:06] > some clever person changes guest's password Not since we made it so guest can't do that [11:43:01] --- haba has left [11:43:02] --- haba has become available [11:46:26] Russ: Have you looked at 'sd' - with your desire for a git-like distributed BTS? http://syncwith.us/sd/ [11:46:33] --- dwbotsch has left: Lost connection [11:50:34] --- dwbotsch has become available [12:16:00] I haven't -- haven't seen that one yet. [12:37:03] --- kaj has become available [12:43:46] --- haba has left [12:43:52] --- haba has become available [12:47:04] --- Jeffrey Altman has become available [12:50:20] --- Jeffrey Altman has left [13:06:34] --- haba has left [13:27:24] --- asedeno has left [13:27:25] --- andersk@mit.edu/ozok-the-destroyer has left [13:27:57] --- andersk@mit.edu/dr-wily has left: Lost connection [14:10:43] --- meffie has left [14:12:04] --- dev-zero@jabber.org has left [14:12:29] --- kaduk@mit.edu/barnowl has become available [14:13:50] --- asedeno has become available [14:15:16] --- andersk@mit.edu/dr-wily has become available [14:53:42] --- dev-zero@jabber.org has become available [15:03:29] --- dev-zero@jabber.org has left [15:03:42] --- dev-zero@jabber.org has become available [15:17:49] --- kaj has left [15:24:30] --- deason has left [16:40:54] --- Jeffrey Altman has become available [16:44:27] --- Jeffrey Altman has left [17:51:08] --- Russ has left: Disconnected [18:10:04] --- Russ has become available [18:24:08] --- mdionne has become available [18:50:34] --- Jeffrey Altman has become available [19:01:11] --- Jeffrey Altman has left [19:10:33] --- mdionne has left [19:55:38] --- jaltman has left: Replaced by new connection [19:55:39] --- jaltman has become available [20:47:10] --- abo has left [20:47:43] --- abo has become available [21:48:10] --- reuteras has become available [22:14:29] --- Jeffrey Altman has become available [22:14:37] --- Jeffrey Altman has left [22:17:56] --- jaltman has left: Replaced by new connection [22:17:57] --- jaltman has become available [22:19:17] --- Jeffrey Altman has become available [22:21:19] --- Jeffrey Altman has left