On Mon, Mar 21, 2016 at 4:51 PM, Jim Jagielski <j...@jagunet.com> wrote: > Just tried: > > <jimsys:code/dev/whimsy> % vi README.md > <jimsys:code/dev/whimsy> % git commit -a > [master a4f772a] test > 1 file changed, 1 insertion(+), 1 deletion(-) > <jimsys:code/dev/whimsy> % git push > Username for 'https://git-dual.apache.org': jim > Password for 'https://j...@git-dual.apache.org': > Counting objects: 3, done. > Delta compression using up to 24 threads. > Compressing objects: 100% (3/3), done. > Writing objects: 100% (3/3), 285 bytes | 0 bytes/s, done. > Total 3 (delta 2), reused 0 (delta 0) > remote: To git@github:apache/whimsy.git > remote: 2f85f27..a4f772a master -> master > To https://git-dual.apache.org/repos/asf/whimsy.git > 2f85f27..a4f772a master -> master
Promptly mirrored: https://github.com/apache/whimsy/commit/a4f772ad61236ab9258746e54b32e9579fb26d3e Note the Git hash ("a4f772a...") is the same both places (all three, if you count jimsys). So any code change you push to the ASF git repository should be deployed on whimsy-vm2 and visible on whimsy.apache.org within 30 minutes (when Puppet next runs). I love it when a plan comes together! - Sam Ruby >> On Mar 21, 2016, at 4:44 PM, Sam Ruby <ru...@intertwingly.net> wrote: >> >> On Mon, Mar 21, 2016 at 4:38 PM, sebb <seb...@gmail.com> wrote: >>> On 21 March 2016 at 20:32, Jim Jagielski <j...@jagunet.com> wrote: >>>> I do, but I'm still unclear on dealing w/ the GH workflow. >>>> >>>> Can I just do it via svn, or even *our* git and not deal >>>> w/ GH at all? >> >> You can do it entirely using *our* git and not deal with GH at all. >> >>> You can certainly just work on a clone of our Git; no need to use >>> GitHub (once you are set up correctly). >> >> Nothing needs to be set up to use our git: >> >> https://git-dual.apache.org/repos/asf/whimsy.git >> >> Pushes there are automatically picked up. I've done it. >> >> Jim, perhaps you could try pushing a minor change to README.md and >> letting us know how it works out? >> >> - Sam Ruby >> >>>>> On Mar 21, 2016, at 4:19 PM, Sam Ruby <ru...@intertwingly.net> wrote: >>>>> >>>>> On Mon, Mar 21, 2016 at 3:14 PM, Jim Jagielski <j...@jagunet.com> wrote: >>>>>> Well, it looks like the format has been changing... so I >>>>>> can see concerns. >>>>>> >>>>>> But really, I'm not sure why it needs to be so >>>>>> "standardized" esp when it's mucking around with >>>>>> stuff it has no reason to. It's adding a line, so >>>>>> I don't see the reason why it has to "recreate" the >>>>>> file in the 1st place. Either it finds where a new >>>>>> proxy needs to go and adds it there, or find the >>>>>> line that needs to be updated, and modified *that* >>>>>> line, or it finds the line it needs to delete >>>>>> and trashes it. >>>>>> >>>>>> If a tool is updating a file which is also mostly edited >>>>>> by humans, it should be pretty lax about enforcing >>>>>> a "format" imo. If it doesn't need to mess with >>>>>> a line, it should leave it alone or output it >>>>>> exactly as it was read... >>>>> >>>>> Originally, this was a sorted index of files in the associated >>>>> proxies-received directory. >>>>> >>>>> I'm OK with the idea of requirements changing and/or this being a bug >>>>> in the first place. >>>>> >>>>> None of us like the idea of single maintainer tools. In this case, >>>>> what we have here is a small, standalone tool. After the dust settles >>>>> (i.e., after the meeting is over), anybody want to take a crack at >>>>> improving it? >>>>> >>>>> Note: improving it could mean rewriting in Python and moving to Steve, >>>>> I don't care. What I do care about is having multiple maintainers. >>>>> >>>>> - Sam Ruby >>>>> >>>>>>> On Mar 21, 2016, at 3:02 PM, Sam Ruby <ru...@intertwingly.net> wrote: >>>>>>> >>>>>>> I think having a proxy web interface continues to be a good idea; but >>>>>>> we need to come to a common understanding of the data format. Too late >>>>>>> for this meeting, but I'm inclined to change to a JSON format for >>>>>>> future meetings. >>>>>>> >>>>>>> Here's the relevant lines: >>>>>>> >>>>>>> https://github.com/apache/whimsy/blob/c5329abf90371ff2377bcb6f087abb59605bcea4/www/members/proxy.cgi#L163 >>>>>>> >>>>>>> Most importantly, lines that do NOT match / \S.*\(\S+\)$/ are lost. >>>>>>> >>>>>>> This is clearly problematic. >>>>>>> >>>>>>> Suggestions welcome! >>>>>>> >>>>>>> - Sam Ruby >>>> >
