Advertisement
Guest User

Untitled

a guest
Jun 24th, 2017
531
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
HTML 21.32 KB | None | 0 0
  1. [15:17:04] <chiiph> anyone has thoughts on ticket #1995? it's really simple, but people need to comment to see what's clearer...
  2. [15:19:56] <chiiph> arma: what should I do with tickets like #2093? I mean, this kind of desitions need consensus, but the feedback is almost null...
  3. [15:29:57] <-- Tas (~tas@83TAACJ6B.tor-irc.dnsbl.oftc.net) has quit (Remote host closed the connection)
  4. [15:31:14] --> Tas (~tas@9KCAACZYV.tor-irc.dnsbl.oftc.net) has joined #vidalia
  5. [16:09:08] --> finalbeta_ (~finalbeta@ip-83-134-176-20.dsl.scarlet.be) has joined #vidalia
  6. [16:15:57] <-- finalbeta (~finalbeta@ip-213-49-110-167.dsl.scarlet.be) has quit (Ping timeout: 480 seconds)
  7. [16:17:45] <Sebastian> chiiph: hey there
  8. [16:17:49] <Sebastian> sorry you get so little input
  9. [16:18:02] <Sebastian> Vidalia is a strange place for most of us :(
  10. [16:18:21] <Sebastian> Also arma is very busy
  11. [16:18:56] <chiiph> Sebastian: hey man... how are you?
  12. [16:18:57] <Sebastian> What works best is to keep pinging them if you are waiting for input; rather than just thinking if you wait long enough an answer will magically appear
  13. [16:19:48] <chiiph> Sebastian: it's ok... the problem I see... is that I really want to contribute, but if I need input for every move, it won't advance like it should...
  14. [16:19:56] <chiiph> and most of the things need input
  15. [16:20:09] <Sebastian> For example #2093, I don't see a clear question there. I'd just assume "chiiph identified some issues. I'm sure he'll solve them somehow or declare them as too difficult to solve. Cool, let me move on"
  16. [16:20:41] <chiiph> another possibility could be I just develop whatever I think, and may be someday, patches will be merged...
  17. [16:21:03] <chiiph> Sebastian: arma reported 2093, that's why I'm asking him...
  18. [16:21:25] <Sebastian> That latter approach is the more effective one. It might mean that someone will disagree with what you did once it is done; but that still means you learn something.
  19. [16:21:34] <Sebastian> In general sitting there wondering what to do doesn't work so well
  20. [16:21:38] <Sebastian> I wish I had a better answer for you
  21. [16:22:01] <chiiph> it's ok... I just want to define the "work mode" for all this...
  22. [16:24:05] <Sebastian> and thanks for prodding me wrt 1995
  23. [16:24:08] <Sebastian> there is a comment :)
  24. [16:25:01] <chiiph> Sebastian: I can just solve things however I think best, but I'll still need approval for the patch to get to the users...
  25. [16:25:19] <Sebastian> Yes
  26. [16:25:24] <Sebastian> The latter part is still a problem.
  27. [16:25:29] <Sebastian> We really need a maintainer for Vidalia.
  28. [16:25:47] <chiiph> deadlock :)
  29. [16:26:16] <Sebastian> I'm hesitant suggesting that this should be you "for now" while you're pretty new to Tor. We had some big issues when arm was created because its maintainer didn't understand Tor very well
  30. [16:26:28] <Sebastian> On the other hand, there isn't really an alternative.
  31. [16:27:19] <Sebastian> I'm not good at C++ and especially not at Qt, though I can probably help with identifying issues that users would have.
  32. [16:27:27] <chiiph> Sebastian: I don't follow what you mean...
  33. [16:28:26] <Sebastian> Which part?
  34. [16:28:40] <chiiph> I think what I've already done can give everyone a good idea of what I can do...
  35. [16:28:50] <chiiph> the part before "I'm not good at C++"
  36. [16:31:54] <nickm> So, free software best practice would probably be to act like you're doing a branch or set of branches to get merged, and maintain an "unofficial" branch for a while.
  37. [16:32:25] <nickm> In all likelihood, you will wind up with folks saying, "Yeah, you should just maintain the thing."
  38. [16:32:36] <nickm> This would be easier with git, of course.
  39. [16:33:44] <chiiph> nickm: the branch idea works better if the patches get merged... otherwise I'll just start merging the branches to master...
  40. [16:34:15] <chiiph> it's really hard to work for real in a project if I have to keep master like it's in the svn trunk...
  41. [16:34:22] <nickm> right
  42. [16:34:49] <chiiph> nickm: I'm not demanding anything, I just want to figure out how we can all work along...
  43. [16:34:54] <chiiph> *I'm just
  44. [16:35:01] <chiiph> bleh -I'm just
  45. [16:35:06] <nickm> yeah; I get it
  46. [16:35:49] <nickm> I'm trying to figure out how we can try to act more helpful & get out of your way.  It seems like our current positions are not conducive to you hacking effectively
  47. [16:36:21] <helix> I would be happy to commit to merging chiiph's stuff into master periodically, after a conversion to git, but I can't do any good code review I don't think
  48. [16:36:30] <nickm> So, what's the status?  You have patches, but nobody has time to review or merge them?
  49. [16:36:39] <chiiph> yep
  50. [16:36:46] <helix> if someone would approve his 'needs_review' bugs then I could do the other part
  51. [16:37:02] <nickm> approve in the sense of saying, "This is good code, run with it?"
  52. [16:37:06] <helix> yeah
  53. [16:37:46] <nickm> Well, that's the thing.  Who is competent to do vidalia code review right now?  Let's include people who do not have time.
  54. [16:37:52] <Sebastian> I could do the "the idea of this code is good, and the UI is not horrible" part. But I make enough embarassing mistakes with C
  55. [16:37:54] <helix> right :/
  56. [16:37:58] <nickm> I count edmanm, and chiiph, and...
  57. [16:38:09] <nickm> I can read the code, but I don't know vidalia.
  58. [16:38:35] <nickm> err
  59. [16:38:42] <chiiph> I can assure you I test the code as much as I can, and I trust it... hehe, but that's not enough... :)
  60. [16:38:42] <nickm> I can read the patches, but I don't know vidalia.
  61. [16:39:25] <nickm> Right.  This is dying for a git conversion.
  62. [16:39:38] <helix> ok. we can do that.
  63. [16:39:41] <chiiph> nickm: I don't follow how git would solve this...
  64. [16:40:25] <nickm> helix: Last I read, if I follow right, edmanm's response was more or less "okay, but I don't buy that git will raise the dead and bring peace to the holy land, which is fair enough..."
  65. [16:40:35] <helix> I don't think git fully solves it, but it starts to
  66. [16:40:36] <nickm> *," which is fair enough...
  67. [16:40:50] <nickm> ...but it doesn't sound like a veto to me
  68. [16:40:50] <helix> nickm: indeed. and actually, after I converted tbb to git, I got more contributors
  69. [16:41:24] <chiiph> git or svn isn't the problem here I think.... or I don't know something you guys do :)
  70. [16:42:28] <nickm> It looks like Vidalia development needs to go more distributed; commit rights to the svn repository are apparently blocking good development.
  71. [16:43:02] <chiiph> yes, but does git handle commit rights differently?
  72. [16:43:08] <chiiph> either you can, or you can't... afaik
  73. [16:44:26] <nickm> With git, everybody can commit to their own repository.  I am basically suggesting that your repository is going to be the most interesting place in vidalia development for a while.
  74. [16:45:23] <chiiph> nickm: then I can just develop as I see better, and whenever someone wants to see what's going on with vidalia, just looks there...
  75. [16:45:36] <chiiph> I don't like that... but there are like a lot of possibilities
  76. [16:46:14] <nickm> It's not a permanent solution or even a real solution to the "how can chiiph get enough code review?" question; it is an attempted solution to the "how can chiiph get anything done while we deadlock on the free time vs vidalia expertise problem
  77. [16:47:10] <nickm> Basically, I think we should move to a situation where you do official vidalia stuff.  But since edmanm isn't free to review your stuff and bless it as official, let's go with the community.
  78. [16:47:38] <chiiph> meaning, "just release it and see what people say"?
  79. [16:47:58] <nickm> I don't want to step on edmanm's perogatives here, but there is plenty of open source precendent.
  80. [16:48:05] <nickm> Like egcs -> gcc 3, and so on
  81. [16:49:08] <nickm> chiiph: Yeah. Call it vidalia-chiiph or whatever for a while. If it works out, and edmanm approves, merge it all into vidalia and have both things be one project.  Try to avoid big hard-to-merge architectural revisions, work with an eye to mergeability, etc
  82. [16:49:46] <chiiph> "merge it all into vidalia" <--- I can't do that part... and that's the problem hehe...
  83. [16:50:06] <helix> one of us can though, and we'd be happy to once someone gives us the okay :)
  84. [16:51:18] <chiiph> and what about releases and bundles? most users don't clone a repo and build it from source...
  85. [16:51:28] <chiiph> if the idea is to get user input, that's an important part IMO
  86. [16:52:00] <helix> well, you can make and sign the tarball, I build the packages
  87. [16:55:04] <Sebastian> That sounds like a very good idea.
  88. [16:55:21] <chiiph> helix: if you are willing to trust me, I can build a little road map or something like that... and we can release something in not too long...
  89. [16:56:35] <nickm> Yeah, my position is that Vidalia is edmanm's project, not mine, and I'm not going to go calling anything "the official vidalia" or granting anybody else commit rights without his go-ahead.
  90. [16:56:55] <Sebastian> Exactly
  91. [16:57:05] <chiiph> I agree...
  92. [16:57:12] <nickm> In my experiment, the best way to get a maintainer to give you their go-ahead to commit stuff is to make them decide that it is far easier for them to give you commit rights than not.
  93. [16:58:02] <Sebastian> So how about we do this:
  94. [16:58:03] <chiiph> :) well, edmanm is probably getting more highlights this past few weeks than he had in months... if he thinks that's annoying, then we won't have any problems :P
  95. [16:58:41] <nickm> It's not enough to annoy the maintainer; you also need to make the maintainer go, "Yeah, why am I second-guessing all of this"
  96. [16:59:07] <nickm> But I don't think it's fair to pressure matt this way anyway: that's why I'm suggesting a short-term fork
  97. [16:59:22] <chiiph> (yeah, I was just kidding)
  98. [16:59:26] <Sebastian> We convert Vidalia to git, and chiiph keeps making patches. I/helix give them a rough review, and I/helix merge them into my/her Vidalia tree if there aren't any obvious problem. From that tree we make a release or two and see what people think.
  99. [16:59:51] <nickm> Sebastian: suggested amendment.
  100. [17:00:01] <helix> alternately, we move stuff to a vidalia stable tree and merge them into master?
  101. [17:00:11] <helix> not move, but declare a vidalia stable tree
  102. [17:00:21] <helix> based on 0.2.10
  103. [17:00:23] <Sebastian> That way we still have some kind of control over what kind of features go into a piece of software that we ask users to ship, and chiiph can keep working on features.
  104. [17:00:27] -*- helix lets nick talk though
  105. [17:00:31] <atagar> Sebastian: Hu? Big issues? There was the scrubbing thing but nothing else is coming to mind.
  106. [17:01:57] <nickm> I am cool with vidalia going from svn to git, and I am cool with you/helix doing sanity-checking on chiiph's patches just so that there is another set of eyes on them, and I am cool with those patches getting merged to a repository/branch/whatever other than the official repository, and I am okay with experimental stuff getting built from that.
  107. [17:02:26] <nickm> I do not think it's okay to call the experimental thing just "vidalia", though.
  108. [17:02:33] <Sebastian> I agree
  109. [17:02:39] <nickm> Nor do I think that the right distinction between trees is "stable" vs "development"
  110. [17:02:41] <chiiph> if we have git, we can have master at 0.2.10 and an experimental branch with all the new stuff...
  111. [17:03:13] <nickm> If it's not getting reviewed by edmanm, and edmanm hasn't given somebody else permission to merge stuff into an official vidalia, it is an unofficial vidalia fork.
  112. [17:04:19] <nickm> With time, edmanm may review stuff & merge, or may give somebody else permission to merge stuff into an official vidalia, but unless he does, we should respect his authority as the project's author.
  113. [17:04:59] <helix> I'm fine with that
  114. [17:05:12] <chiiph> yep, me too, of course...
  115. [17:06:07] <nickm> great.  I'm not sure anybody was suggesting otherwise, but I like to be really clear about this stuff so that we don't piss off a good developer.
  116. [17:07:11] <-- Tas (~tas@9KCAACZYV.tor-irc.dnsbl.oftc.net) has quit (Quit: Tas)
  117. [17:07:53] <nickm> I think the git conversion is a prerequisite for this; having multiple repositories for a single project with branches that want to stay easily mergeable & re-mregeable is just too painful with svn
  118. [17:08:21] <chiiph> I think we still need edmanm's opinion on this though...
  119. [17:09:40] <nickm> It'd be nice to ask him what he thinks first, and if he'd rather we do it differently, yeah.
  120. [17:11:31] <Sebastian> Ok. There is another issue here.
  121. [17:11:40] <Sebastian> We don't have a good solution for translations with git.
  122. [17:12:34] <nickm> Leave the translations in svn, and have the final build process require that you checked out the svn stuff?
  123. [17:13:18] <nickm> s/the svn stuff/the translations/ .  Or Leave the translations in svn until we have a translation site that can commit to a git repo.
  124. [17:14:44] <Sebastian> The thing is that the translations clutter the source directories
  125. [17:15:23] <Sebastian> I'm not a fan of keeping the translations in the same repository as the code anyways, so that might be a good time to figure out a solution
  126. [17:15:39] <Sebastian> I think it'll be mostly relevant for helix.
  127. [17:16:29] <nickm> probably Runa too
  128. [17:16:58] <nickm> Can the translation files not live in a separate directory hierarchy?
  129. [17:17:11] <nickm> Is there another solution I'm missing here?
  130. [17:17:15] <helix> Sebastian: ultimately it doesn't matter a lot to me, I use tarballs when I build packages
  131. [17:17:33] <opello> just some naive googling, but it seems that pootle says they support git
  132. [17:17:35] <Sebastian> So it matters to the tarball makers
  133. [17:17:54] <helix> opello: yeah we switched to transifex. or were going to.
  134. [17:17:59] <opello> ahh
  135. [17:18:13] <helix> it seems like transifex supports git? maybe?
  136. [17:18:14] <chiiph> I don't have much experience with translations, so I can't help in here...
  137. [17:18:25] <Sebastian> nickm: I believe that they should live in a separate directory hierarchy. But then there's another step of getting the strings from Vidalia into pootle
  138. [17:19:07] <Sebastian> I'm not saying this means we can't switch to git. I'm saying that this probably requires some changes to our current translation setup. And we should have a way to make it work before converting.
  139. [17:19:22] <opello> helix: looks like they also seem to (help has an example for pointing at github fyi)
  140. [17:19:30] -*- helix nods
  141. [17:19:35] <helix> are we still using pootle for vidalia?
  142. [17:21:02] <Sebastian> I don't think this is dependant on git vs svn for translations.
  143. [17:21:13] <Sebastian> Or it need not be
  144. [17:21:48] <helix> I think we could convert to git before we worry about the translations then, if the stuff works with git. we'll just need runa to change some things when she returns.
  145. [17:22:08] <helix> or we can wait for both runa and matt
  146. [17:22:32] <Sebastian> That would mean giving transifex push access to our git repositories. I'm not happy to do that.
  147. [17:22:54] <chiiph> :D the dependency tree is really intricate in here
  148. [17:23:10] <helix> Sebastian: okay but you're not going to be happy until the translations are out of the main repo ;)
  149. [17:23:16] <nickm> Sebastian: you don't have to.
  150. [17:23:21] <nickm> Sebastian: this is git, remember
  151. [17:23:26] <Sebastian> I do remember.
  152. [17:23:28] <nickm> Sebastian: make a repo just for transifex to push to
  153. [17:23:29] <nickm> :)
  154. [17:23:51] <Sebastian> I think that is the solution. But it requires a script to put the strings from the main repository into the transifex repository. Or something.
  155. [17:24:09] <Sebastian> I'm not saying any of this is hard or a showstopper or something. But it requires a Runa to do, and it should work.
  156. [17:25:09] <nickm> well hm
  157. [17:25:57] --> Tas (~tas@1RDAAAK00.tor-irc.dnsbl.oftc.net) has joined #vidalia
  158. [17:26:07] <nickm> I wonder how we can do this with a minimum of making everything block.
  159. [17:26:13] <Sebastian> We basically need something to extract the relevant information (english strings) from Vidalia, feed them to $translationthing, and have them put in the tarball when it is tarball making time
  160. [17:27:01] <chiiph> Sebastian: grep "tr(\"" ?
  161. [17:27:32] <Sebastian> I don't necessarily think "commit translated strings into the main repository" is a part of this.
  162. [17:27:35] <helix> that seems way complicated for not a lot of gain to me
  163. [17:28:00] <Sebastian> helix: what does?
  164. [17:28:24] <helix> your description of how you want the translation stuff to work
  165. [17:30:17] <Sebastian> i think that's easier than maintaining an extra repository for translation commits and merging back and forth
  166. [17:30:21] <-- Tas (~tas@1RDAAAK00.tor-irc.dnsbl.oftc.net) has quit (Remote host closed the connection)
  167. [17:30:46] <Sebastian> Then you need to do all I described plus the merging
  168. [17:31:39] <nickm> Well, without the extra repository, where do translated strings get stored?
  169. [17:32:46] --> Tas (~tas@9YYAAAJTL.tor-irc.dnsbl.oftc.net) has joined #vidalia
  170. [17:33:13] <Sebastian> well, they do get stored in an extra repository, but we don't need to merge that repository into the main tree
  171. [17:33:21] <Sebastian> hm.
  172. [17:33:59] <nickm> "git fetch translations; git merge translations/translations" is not a complicated step
  173. [17:34:41] <Sebastian> Yes. Though Runa told me that never ever does a translation that you receive from pootle work witout many manual changes
  174. [17:35:07] <Sebastian> I'm just not sure this is a sensible workflow. I don't think translations belong with source
  175. [17:35:28] <Sebastian> It could also be that I just don't get it, and it would all work.
  176. [17:36:07] <nickm> I think that whoever is actually going to implement this can probably sort out a working solution here; the space of possibilities is big enough :)
  177. [17:36:44] <chiiph> how do other projects.... like, I don't know... kde, works this out?
  178. [17:37:42] <helix> kde is not at all concerned about eating your bandwidth and space
  179. [17:37:56] <helix> although I am surprised to hear pootle is so troublesome
  180. [17:41:40] <Sebastian> I'm only bringing this up because when I wanted to move gettor and torcheck to git recently Runa told me this wouldn't work with translations.
  181. [17:41:59] <helix> ugh.
  182. [17:42:47] <chiiph> everything will be easier if I have your trust and commit rights to the svn repo :)
  183. [17:42:50] <Sebastian> Since I hate all the translation stuff and I just see it break frequently I'm wary of just going ahead.
  184. [17:44:48] <nickm> chiiph: I say again.  Nobody but edmanm should okay commit rights.  My/your/sebastian's/helix's trust is irrelevant.
  185. [17:45:17] <nickm> (commit rights to an official vidalia, that is)
  186. [17:45:51] <chiiph> nickm: I know... I'm not trying to force anything or anybody... but translations aren't a minor thing with a package like this one...
  187. [17:46:15] <nickm> Yup.
  188. [17:46:23] <nickm> Nobody is suggesting that we say, "Screw translations!" either
  189. [17:46:26] <nickm> Are they?
  190. [17:46:28] <chiiph> everything I say with a ":)" at the end, has a touch of joke... hehe... may be I should talk like that in here, since you can't hear my voice tone...
  191. [17:47:23] <Sebastian> I don't think anyone says screw translations
  192. [17:48:21] <nickm> ok.
  193. [17:48:38] <nickm> So, there are two things that would be useful to moving forward here:
  194. [17:48:50] <nickm> 1) a sense of how edmanm feels about all this, and whether he'd prefer something else...
  195. [17:49:05] <nickm> 2) a short writeup of all the tasks involved, with some idea of who's doing what
  196. [17:49:15] <nickm> I volunteer for neither of these :)
  197. [17:50:16] -*- helix screenshots those words
  198. [17:52:17] <chiiph> depending on 1), I can take care of 2) because either way, if vidalia isn't going to die, it needs a serious plan...
  199. [17:52:41] <Sebastian> I'm happy to do the actual git migration
  200. [17:53:16] <nickm> Me too on the git migration.
  201. [17:53:38] <helix> happy to do merging and basic sanity checking of commits, to the extent that I am capable
  202. [17:53:42] <nickm> assuming that there's some idea of what's happening wrt translations
  203. [17:59:35] <chiiph> ok then... wait we do :)
  204. [18:27:07] <arma> is anybody mailing matt, or will we just hope to find him on irc? :)
  205. [18:27:21] <arma> in general, i think matt would be pleased to hand vidalia off to somebody who can maintain it for him.
  206. [18:27:32] <arma> i don't think he will say 'no' to anything that we ask.
  207. [18:28:08] <arma> so the followup question is, what can we do to maximize the chances that matt will continue to usefully contribute to vidalia? you're going to need him for development questions, for example.
  208. [18:28:43] <arma> we could say "do you mind if we move vidalia to darcs?", and he will say "go nuts, whatever", and then he'll never look at the darcs again. so that would be a non-ideal strategy.
  209. [18:36:51] <chiiph> the other question will be if matt, or whoever thinks that I am who you want to work in vidalia...
  210. [18:39:58] <chiiph> well, right now it seems I'm the only one...
  211. [18:50:56] <atagar> chiiph: No one is saying that we don't want you to work on vidalia. You're more than welcome to pick up the gauntlet, and we'd be happy to have you do so. We're just being cautious to say 'whoever maintains vidalia' since it isn't clear yet if you'll stick around for the long haul. :)
  212. [18:53:42] <atagar> Sebastian: and I'm still waiting to hear what these "big issues" are. I thought my development on arm has gone rather nicely.
  213. [19:09:12] <chiiph> atagar: of course... I totally understand the situation... that's why I said that was another issue to consider...
  214. [19:10:16] <chiiph> arma: did you mailed matt? I can do it, but I don't know if I'm the one that should do it...
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement