[01:13:23] --- Jeffrey Altman has left: Replaced by new connection [02:02:26] --- dev-zero@jabber.org has become available [02:05:59] --- dwbotsch has left [02:07:55] --- dwbotsch has become available [02:58:45] --- Russ has left: Disconnected [05:40:19] --- Jeffrey Altman has become available [06:27:31] --- dev-zero@jabber.org has left [08:14:18] --- cclausen has become available [08:58:44] --- dev-zero@jabber.org has become available [10:31:42] --- Russ has become available [10:56:00] --- shadow has become available [11:01:08] --- deason has become available [11:42:20] http://denise.dreamwidth.org/23600.html is a really excellent article from one of the founders of Dreamwidth, which has been doing exceptionally well at encouraging and attracting new contributors, about how to structure your open source project so that people will want to contribute to it. [11:42:59] There are several specific things noted there that we're not currently doing, such as documenting our target coding style. [11:43:34] We do document our coding style - it's just that it's in the form of a GNU indent command line that's pretty much useless for human beings :) [11:45:32] Well, yes. But also that's more the indentation style, but there's a bunch of other stuff that we don't really document. Such as "all changes to UNIX makefiles need corresponding NTMakefile changes" or "cast time_t to unsigned long for printf" or "don't introduce new functions that take buffers or arrays without an explicit length." [11:45:46] A lot of the stuff in that article is stuff that we said we'd do for the second Summer of Code, but never did. Our focus for Summer of Code seemed to shift from attracting interest, to scaring away all but the most determined. Which that article also says things about. [11:47:21] I think "keep a public task list" is really important. I don't think our RT instance helps with that at all. [11:47:34] Wholeheartedly agreed. [11:48:27] I think we're short on "how do I get the software running well enough to test patches" instructions too. We have a lot of general installation instructions, of varying degrees of up-to-dateness, but not a lot of documentation on "here's how you set up a minimal hacking environment." [11:48:40] Agreed. [11:50:29] The argument behind "Lower your pedantry level" is interesting, too. [11:51:32] Yeah, it is. [11:52:06] It makes me think that we should be amending other people's changes for minor coding style things, although given how Gerrit works, I think that may be more off-putting than fixing on commit as the document talks about. But maybe not. [11:52:49] I think it depends on who the person is, and how likely they are to be scared away by being asked to amend their patch. [11:52:55] Expanding the scope is a problem I'm particularly prone to personally. [11:53:32] I think the tendency is to try and get as much work done by the submitter as possible, because of how short handed we are. [11:53:51] I think in the long term that is a good plan, especially if the submitter is being funded to get the code into OpenAFS. [11:54:00] It's also how I personally tend to do work -- whenever I touch code, I try to do as much related cleanup as I have time for even when it isn't directly related to the picture. [11:54:02] pre-gerrit, derrick and I would always just recode the submission [11:54:16] But while that's nice for me, I can defnitely see how it's off-putting for a new contributor. [11:54:28] I don't think that approach scales, though (recoding the submission) [11:54:52] I think it's about picking the level of pickiness and push back according to the skill and 'stickiness' of the contributor. [11:54:58] Well, when it's minor coding style stuff, it takes only a little more time than verifying does right now. But of course the plan is to make verifying easier. [11:55:14] even with gerrit I think its less work than explaining three times how I would like it done in gerrit comments. especially for stuff that is trivial. [11:55:31] There's also something very off putting as a contributor about getting your code rewritten without an explanation that you can undestand. [11:55:41] --- stevenjenkins has left [11:55:43] Yeah, that was the bit that I was worrying about. [11:55:49] --- abo has left [11:55:56] it doesn't appear to be off putting to Heimdal contributors [11:56:03] --- deason has left [11:56:04] and Love rewrites everything [11:56:19] --- abo has become available [11:56:27] How many contributions does Heimdal receive, though? [11:56:28] * Russ rewrites everything for all my smaller projects too. [11:56:29] I was very happy that the recent port of Heimdal to Windows only had 78 changes [11:56:43] Heimdal receives quite a few. [11:56:45] But I don't get very many external contributions in a really commitable form. [11:57:16] That's not my perception (that Heimdal receives quite a few contributions) [11:57:20] What makes people excited to contribute is when the issues they raise or the ideas they put forward get into the source tree fast [11:57:22] --- haba has left [11:57:31] That's not true. [11:57:52] People care about how things get into the source tree, too. [11:58:11] If you constantly recode peoples contributions, they'll stop giving you code, and just start giving you ideas. [11:58:23] Having 3 people write all of the code for OpenAFS isn't sustainable. [11:58:24] what percentage of things get into linux without a re-write in some form by the top three? [11:58:30] Shedloads. [11:58:46] Look at the release statistics on lwn.net [11:59:33] that doesn't indicate much. even when Love or Derrick or I rewrite someone's submission they still get author credit [12:00:09] Yes, but have you actually looked at how the kernel development process works. Lots of code gets straight in without being touched by Linus, Andrew, Greg or that gang. [12:00:16] --- deason has become available [12:00:42] --- haba has become available [12:01:25] In fact, git by its very nature doesn't permit the kind of casual rewriting on merge that you're suggesting. [12:02:19] --- stevenjenkins has become available [12:02:21] --- abo has left [12:02:22] The fundamental question for any contributor is "does this project welcome my contribution"? [12:02:45] --- abo has become available [12:03:20] I will say as a contributor, I haven't really minded resubmitting a bunch of times per gerrit comments [12:03:33] i recoded things in some cases pre-git because it was easier than pulling a patch from rt [12:03:41] I mean, really, it takes less than a minute to resubmit a change that doesn't require testing; comments and such [12:04:12] Yes, gerrit does make things somewhat easier once you get your head round it. [12:05:01] oh, far worse. before i pulled changes to a test machine, by hand, then had to push to afs, pull to grand and commit [12:05:13] for changes which needed only visual inspection that was about 3 too many steps [12:05:37] Yeah, I do think some of the comments in Denise's post aren't as directly relevant to us because we have Gerrit. [12:05:47] She's writing from the perspective of patches sitting in Bugzilla. [12:05:57] Gerrit creates more of a point of interaction with the submitter that Bugzilla doesn't have. [12:06:13] The barrier for resubmission is way, way lower. [12:06:20] nor RT. i'd still like a gerrit-aware bugtracker, but life's hard [12:06:26] once I have a patch in my tree to verify it, amending it to address my concerns and pushing it back to gerrit is probably easier than writing line by line comments in gerrit. [12:06:35] The cost we pay is on the front side -- requiring people wrap their brain around Git and Gerrit before submitting patches. [12:06:59] Yes. Although people can still stick stuff in RT if they wish. [12:07:03] it depends how many lines, and whether you want to just fix the code, or engage a contributor [12:07:08] Well, we don't actually *require* it -- they can send patches to RT as before. But we certainly way prefer it. ==sxw. [12:07:29] What would be nice is an RT button that says "push this to gerrit" that does the right thing. [12:07:41] Oh, yeah, that would be lovely. [12:07:44] for the current RT machine it would be "hard" [12:07:49] not impossible [12:08:43] I'd have no interest in writing it for the archaic version of RT that's running on grand. [12:08:47] --- abo has left [12:08:56] well, sure [12:09:07] but the interface may well have not changes [12:09:09] d [12:09:21] --- abo has become available [12:09:35] I can also see it being pretty straightforwards, with a modern RT, for RT to notice 'FIXES' entries in gerrit and link them in to bugs, and to close bugs upon submit. [12:10:17] But I think we first need to decide whether RT is the correct tool for the job. [12:10:35] Because I think that the "them" and "us" situation that RT's accounts creates is part of the problem. [12:10:36] I would've thought that'd be something git-side, in a hook [12:11:56] i',m unsure RT is. i'm further unsure the right tool exists [12:12:08] Yeh, given that git sees refs/changes/ entries appearing it could be done there, too. [12:12:13] RT accounts: i fixed that for CMU. i don't run openafs's RT. [12:13:44] Lots of projects get contributors who start out commenting on bugs. Yet the barrier to commenting on OpenAFS bugs is higher than that to actually submitting code. I think that's wrong, and we should fix it. [12:17:10] I wonder if RT::Authen::OpenID is usable ... [12:28:19] --- cclausen has left [12:46:32] --- matt has become available [12:49:15] simon: exactly [12:53:55] --- cclausen has become available [13:33:58] one question related to moving away from RT is how hard will it be to convert the existing ticket history? [13:34:25] RT as it is today for OpenAFS is not a very good release management tool. [13:34:55] Nor is it particularly good at assisting users identify issues they might care about. [13:35:46] For example, there is no good way of tagging tickets as being applicable to particular releases or branches. [13:37:02] Before gerrit we had a ticket in RT for most issues. After gerrit it looks like we will have very few tickets in RT [13:42:37] Yeah, because opening a ticket in RT is actually harder than uploading a patch to Gerrit. [13:43:15] If we had automatic close of RT tickets on patch submission, I'd say that we should have automatic creation of new tickets for patches uploaded to Gerrit that don't already name a ticket. [13:43:27] But we'd need both ends or it would just be a bunch of annoying book-keeping. [13:43:35] ++ [13:44:37] automatic close however is not always appropriate. I would prefer a ticket remain open if it represents something that should be pushed to a maintenance branch [13:46:21] Oh, yeah, we'd want automatic close on submission to all active branches, otherwise keeping the ticket in some state reflecting that it's closed in the master but not in the maintenance branch. [13:46:28] Something like debbugs version tracking would be lovely. [13:47:17] even MIT Kerberos' tagging would work [14:48:14] Instead of asking how hard it would be to migrate from RT, you should ask for the features you actually want. For example, it is easy to arrange to be able to tag things with releases. [14:50:44] but as much as I know the current situation sucks, it would be really helpful if you would defer the whole question of what to do about ticketing/bug tracking for a couple of months so that I can actually participate usefully instead of tearing my hair out watching you rush headling into large changes and knowing there is absolutely nothing I can do about it because until we are done moving I just do not have the cycles [14:51:22] we have been discussing how much the RT situation sucks for five years. [14:52:00] we understand that you do not have the cycles [14:52:36] Jeff, we've been complaining about how slow it is for five years. If you want it to bahve differently, have features it doesn't currently have, have different access control, etc., what you as gatekeepers need to do is put together a coherent request for what you want, and I'll do it. I've been responsive every time in the past that someone has asked for specific changes to how RT is set up. [14:53:46] But I swear, another "we went off and had a discussion without you and decided that your cycles are better spent on X than on Y which you're already doing, so we decided to go off on our own and buy hardware to do Y with no clear plan and no interaction with you" will push me over the edge. [14:55:41] the hardware at Stanford seems to be workin g out nicely [14:55:45] RT _will_ be upgraded this fall, because work needs it and as I said, once I do it for one, another gets it for free. But it won't get touched before then, because work does not need it as badly as it needs to move into the new building on time. [14:57:15] It would be working out more nicely if you'd waited to buy it until it was actually going to do something, instead of deciding "we don't want Jeff to do XYZ any more, so we'll buy a machine". And don't tell me that's not what you were thinking, because you as much as told me it was, and if it werent' the case, you'd have asked me what resources we actually needed and what actually needed attention, and that wasn't it. [14:59:47] But I am done with this argument for now. I've asked you to wait until I have time. It's not like you haven't made plenty of changes already for people to get used to, and it's not like there isn't plenty else to do. If you can't or won't do me that courtesy, well, it's not like OpenAFS is the only thing I have to spend time on, either. In the meantime, I haven't eaten all day, and two other people are sitting in my living room waiting for me to finish so we can decide what to eat. [15:00:43] you should eat and be social with your friends instead of chatting in this forum [15:33:25] --- Russ has left: Disconnected [15:34:39] --- stevenjenkins has left [15:37:53] --- stevenjenkins has become available [16:02:36] --- Simon Wilkinson has left [16:04:03] --- dev-zero@jabber.org has left [16:49:12] --- Simon Wilkinson has become available [17:04:48] --- matt has left [17:28:46] --- edgester has become available [17:39:17] --- mdionne has become available [18:11:30] --- shadow has left [18:13:12] --- Simon Wilkinson has left [18:14:28] --- Simon Wilkinson has become available [19:08:48] --- edgester has left [19:46:25] --- dev-zero@jabber.org has become available [19:51:35] --- deason has left [19:57:29] --- mdionne has left [23:03:52] --- dev-zero@jabber.org has left: Replaced by new connection [23:03:53] --- dev-zero@jabber.org has become available [23:43:32] --- cclausen has left