12:39:18 defon another front, in #SeaMonkey, Sompi compained that the links to nightly buiklds and langpacks on this page https://www.seamonkey-project.org/dev/nightly didn;t work. I added redirect intdex.html pages on my website to tgtrdh to the appropiate locain on stchive.seamonkey-project.org 12:40:06 this should really be altered on the seamonky-project webite to just go directly to the correct place on aerchive and avoid these redirects. 12:42:13 alternatively could just have one link to https://www.wg9s.com/seamonkey-253-nightly/ and change the text to say it has builds, langpacks, and source tarballs. 12:44:22 what do you think? 12:58:37 wron channel, sorry 21:24:06 frg: how do you accept contribution to SeaMonkey web site repository https://gitlab.com/seamonkey-project/website ? 21:25:30 not sure now but you can send me a patch via a pm 21:25:55 iss this for 2.53? 21:26:25 if for comm-central not so much 21:28:26 only updates to seamonkey-project.org/dev/nightly to link directly your wg9s.com/seamonkey-253-nightly 21:28:57 WG9s: why do you not update it yourself and publish the website from the repo ? 21:28:58 bet thivest is to file a bug and attach the patch 21:30:24 the ieas is to not be dependent as mush on my website being up now that we have an offial setmonkey-project.org site 21:31:31 as you mention here: 21:31:40 so only need to have backup servers and redunancy on the official site so my webserver is not single point of failure still point of failure for builds but once build and posted to archive a more officially supported site 21:33:07 will be fising the links to go direactly to the officai site but we have some issues hoingf on preventing updateing the sebsite so i made the incorrect links work via redireects on my website 21:33:14 https://ircbot.comm-central.org:8080/seamonkey/20240227#c225700 the info in dev/nightly contains outdated links which can easily be updated with a standard GIT pull request followed by a merge 21:33:35 WG9s: as I clear 2 year old moonchild crap off my older server there is a bunch of space could you use a 10-20gbs as a mirror 21:34:54 guest_: I am just leaving the channel now. yhank you so much for being a complete asshole! 21:34:56 "standard git pull request" isn't a thing, is it? 21:35:15 AFAIK "pull requests" are a workflow mostly specific to github's web interface 21:36:49 gitlab does support forking a repos and also pull request - this is not a github specific workflow 21:37:17 I did say "mostly". It's far from "standard git" 21:37:42 with pull & merge request you can keep the master repo clean from all experimental commits 21:38:13 agree but definitively a good idea 21:38:49 hm, yeah, but last I checked these things didn't really map well to the usual git workflow 21:39:19 WG9s: why have you been so friendly to me ? 21:39:24 with git and mercurial you can export patches, and then attach to bugzilla or otherwise share them (but usually it'd go into bugzilla) 21:39:49 with git you'll reach more developers than with hg / mercurial 21:40:08 I'll have to see the data on that 21:40:33 that sounds more like something I'd see on news.ycombinator.com :-P 21:41:16 in reality, both are DVCS systems, so there isn't even a so big difference in how the "clone a remote, work locally" thing works 21:41:31 many larger company are switching to Git repository - is this not a big sign about the future of hg/mercurial ? 21:41:48 I can't quite wrap my mind around the concept some people would be turned away because things are in the wrong kind of DVCS 21:42:05 guest_: are switching to git from what? 21:42:29 and how can you be sure about their reasons to switch? 21:42:49 and also, more importantly: that something is used, does not mean it's the only acceptable choice, or the only one that works 21:42:51 SourceSafe, SVN, TFVC 21:43:16 this could easily be all emacs v. vim again 21:44:17 sure but for the time beeing more developers are common to git than to anything difference as long as they're not living in a mainframe env 21:45:16 ^different 21:48:40 if SM project team is comitted to hg/mercurial why are they up-to-date repos maintained on gitlab.com ? reaching a wider audience ? 21:53:08 guest_: Please stop whatever this is. SeaMoneky's development status quo is a bit, unorthadox at the moment but it also happens to be working for them for now. WG9s was more than kind offering to personally accept your patches rather than basically the same proceedure it has always been.. File a bug attach a patch and satisfy the project requirements. 21:54:59 glad he is gone. i am boack 21:55:05 back 21:55:40 next time being as asshole will result in a kick/ban 21:57:04 it might be just somebody with very strong ideas about there being only one software way to do things 21:57:31 I meant to at some point ask them what is the github or gitlab equivalent to mercurial queues 21:58:02 njsg i don;t think there is one 22:06:08 is this the new communication style in SeaMoney devs ? https://ircbot.comm-central.org:8080/seamonkey/20240227#c225743 WG9s next time being as asshole will result in a kick/ban 22:06:09 no wonder that SM suffers from developer support 22:06:11 have a nice day 22:07:27 njsg: lol i don't think there is one mq is not a thing in git and rebase ain't that 22:09:22 no but wow someone is trying hard to get under people's skin for the log-look-and-see-i-told-you-so-ness i dunno why they think it will improve anything especially with the damned embodyment of it literally not working sitting in here. 22:13:27 there are people who seem to truly think like this and believe that if their project doesn't, I don't know, switch VCS to github/gitlab, or their documentation to a Wiki instance, or their textual support message system to discourse, that "people won't want to participate" 22:13:55 I think that, grabbing this example, while git might be more popular, that does not preclude people knowing and/or using other systems 22:14:20 sure, there will also be people who *will* turn something down because it's not on github or on facebook 22:15:20 now the way this conversation went, it could have gone more the "how do I contribute" route and less the "you should do things in this great way instead of whatever" route 22:15:24 but maybe that's just me 22:16:43 and - for anyone reading the channel log - the mq thing was intended to bring up a topic where, AFAIK, git and hg are visibly different in the feature set, and that could count as one reason not to use git 22:23:08 amd the reaon hq is so slow for mozilla is the completely obnoxious amount of history they try to keep in the repo should not heep so mych and have a seperate history thing 22:23:30 using git would make little difference here 22:25:00 whn you clone mozilla central you get all the change shitory since when changed form cvs to mercurail for the repository 22:25:18 so like mozilla2.0 time 22:26:32 nice to have all that history, but I don;t need it in my local repo 22:39:02 well he was specifically pushing at you, I have noticed several people doing that over time.. 22:42:04 njsg: hi 22:44:16 well at least it would seem Guest_ was not Tobin 22:44:36 no dude i have no desire to upset you 22:44:45 i want you to be decidedly NOT upset actually 22:45:27 he started out normal asked how to contirbute and tried to anser and then it all wentvery sideways 22:46:45 There would be no real way to do what is currently done for 2.53 on git alone I understand that now .. doesn't mean I can't turn around and git cinnabar me up a git repo off it ;) 22:46:54 you know, if i care to do that 22:48:11 robin well funny thing is heptapod is a mercural front end for a git backend so ther must be git repos there somewhare 22:48:29 heptapod is just git trpo with hg commands 22:48:47 sounds like cinnabar 22:48:59 but on the forge side? 22:50:04 so you can hg clone and get a mercural repo but the real backend repo on heptapod is really git 22:50:16 as far as i know 22:53:59 I think because frg's instructions work and the fact you are still doing patch by request or patch by bugzilla what repo system you are using doesn't matter much beyond that 22:55:07 If I ever get my own bug tracker working I am basically gonna make pull requests just create a bug and apply the patch file and then close the PR with a link to the bug 22:55:22 attach* 22:55:31 that is what I think I will do personally for my stuffs 22:57:09 I have never been a fan of the pull request concept 22:59:18 i like the concept mozilla had of module owners and you have to get an r+ form someone responsible for the module you are patching, but, unfortunately this has somehow degenerated into you r+ mine and i will r+ yours. 22:59:38 and no one is actually doing any reviews 23:10:46 I also think i don;t like that all the review process is now in phbricator and not within the bug itself 23:10:59 less transparent 23:11:17 an less consistent with open source prinsiples 23:12:02 well no one is gonna add the phabricator functions to bugzilla 23:12:03 lol 23:18:20 the only person actaully doing seamonkey patches that hs a phabricator account is IanN so, just me neing me, I call him mr Phabulous (a Blues Brothers reference) 23:20:05 so when we need a mozilla-central thing changed we have to get Mr Phabulous to do the bug 23:20:24 and less easy to use, possibly more like "pull requests" and other github/gitlab workflow 23:24:06 njsg: it IS basically a pull request just sent from cli 23:24:10 direct to mozilla 23:24:27 code changes, code comments, diffs, etc 23:24:43 phabricator can basically BE the forge 23:24:48 replacing bugzilla 23:30:51 bbl