Social presence 2023
Hey all, This is just a quick email to start a brainstorming thread about our public presence on the Internet. We have some presence at the moment, e.g. https://wiki.mercurial-scm.org/SocialMedia https://wiki.mercurial-scm.org/ProjectInfrastructure I'm not sure how active these accounts are, and I have no urge to even dip my toes into big corporate social networks for some reason. But, watching all these news about current Twitter and Reddit "executive decisions" made me think about maybe getting an official account on federated social networks aka the Fediverse. For example, there's fosstodon.org for microblogging (e.g. announcing releases) and programming.dev for general discussions (e.g. user support and sharing blog posts, etc). Of course, if anyone has a better suited instance in mind (self-hosting??), feel free to suggest. For an example microblogging style of content, here's Heptapod: https://fosstodon.org/@heptapod Finally, if we do get some official accounts on the Fediverse, I personally wouldn't mind posting something there occasionally and/or be a backup moderator just in case, but unfortunately I'm not in the position to be in charge of those accounts at this moment. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
14.02.2023 17:20, Georges Racinet пишет: Internally, Heptapod relies on the `branch:topic` syntax, more specifically as keys in the branchmap. Well, it relies on lots of Mercurial and evolve internals (I dare not say APIs). In 11.0.0rc0+ branchmap will have keys in the "branch//namespace/topic" format. There are more places when you'll see this format instead of branch name alone now and we intend to use it locally more widely in future. The good news here is that simply replacing `:` with `//` makes all the tests pass. Given the full coverage, I'm fairly confident that there are no other problems, as far as we're only talking about the compatibility itself with (server-side) Heptapod. Make sure you look though examples for formatfqbn() and parsefqbn() in topic/common.py. Overall it looks like an unnecessary complication to try and support both syntaxes in Heptapod. I'm more comfortable keeping my compatibility fixes around and making the switch once Evolve 11.0.0 is released. My questions: - will there be in 11.0 a way for clients to specify topic namespaces? There is a debug-topic-namespace command that will let you do it. - what will happen when topic namespaces are fully implemented and users with, say hg-evolve 12.0, push to a server with hg-evolve 10.5? Can I simulate that from a Python interpreter already? Topic namespaces are not understood by older clients, so those clients will simply see branches+topics only. So if you had branch "b", topic namespace "tns" and topic "t", then newer clients would see "b//tns/t", and older clients would see "b:t". It's been deemed to be safe, because the worst case is you're using new version and trying to push "b//foo/t" and older server has "b//bar/t": you won't be able to push freely because server sees them both as "b:t". Simulating locally is not yet possible, but adding that (for testing purposes) is on my plate for the final release. - will 11.0 be required to support the upcoming Mercurial 6.4? Probably not evolve version 11.0.0 specifically, since it's planned to be released before hg 6.4, but we will release a bugfix/maintenance release with support for new versions of Mercurial. So most likely, 11.0.1 will support hg 6.4. Although if we see hg 6.4rc0 soon, then we can support that version in 11.0.0. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
30.01.2023 19:24, Anton Shestakov пишет: The release candidate is coming out in the next few days, and the final feature release will most likely be ready in about 2 weeks after that. During these 2 weeks you can reach out to us and tell if you notice something being broken, and we'll obviously try and fix it before the final release. And after numerous compatibility fixes and tweaks (and some delays) 11.0.0rc0 is finally out! If you want to test it, you might need to specify the new version explicitly to install it, e.g. `pip install hg-evolve==11.0.0rc0`. If you spot any issues with it, feel free to contact the developers in your preferred way (e.g. via bugzilla, #mercurial or #hg-evolve on libera.chat or replying to this email on list or to me directly). ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
04.02.2023 22:56, Uwe Brauer пишет: Maybe we have a misunderstanding here. I don't mean the result hg branches I meant that sometimes hg log (with my template, I am not going to post here would give me) ◍ changeset: 674:5c76f339a2eb │ tag: tip │ Branch:year-2022-23//git-manual │ Author:Uwe Brauer │ Date: Sat, 04 Feb 2023 18:45:29 +0100 │ Topic: git-manual │ Phase: draft │ Summary: Old text out, tutorias programadas │ Well, this is most likely not done by evolve/topic extensions. As I said, no released version of evolve or topic uses '//' as a separator in the UI yet. What's more, even the default branch (not released) doesn't override `hg log` entries to be in this format. What versions of evolve and topic are you using, after all? There's one case where topic extension (briefly and internally) uses '//' to separate branch and topic, and it's used for experimental.topic.linear-merge implementation. If it's visible in the UI during normal operations, this could be a bug that needs to be fixed. However, from what I know now, this really seem to be your custom log template that's doing it. And that I found very annoying. Why? ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
04.02.2023 14:56, Uwe Brauer пишет: 03.02.2023 00:34, Uwe Brauer пишет: By "this" do you mean "branch:topic" or "branch//topic"? I meant "branch//topic" So can I switch the new namespace feature of, if I don't like it? That depends on what you think "the new namespace feature" is. If you don't want to use topic namespaces, then you don't have to. There's a default namespace that will not be shown (similar to default branch or empty topic). On the other hand, if you want to forever use "branch:topic" format that was never intended to be usable (e.g. hg up "branch:topic" doesn't necessarily do what you expect), then you can use old versions of evolve and topic. What version of evolve do you have? I think it is 10.1. It has been quite some time I installed it, and I don't recall whether I did it by pip or compiled it myself. Eye balling the help, I can find a command to determine evolve's version It's `hg version -v` and no, 10.1.0 definitely didn't have any topic namespaces. The new "branch//namespace/topic" format at the moment is only used in current default branch of evolve, which is not yet released, but will be a part of the upcoming release candidate (i.e. rc of 11.0.0). Also 10.1.0 is nowhere near "the current evolve version", it's from 2+ years ago, topic namespaces were still only in the plans. But the old "branch:topic" format was used in certain places like `hg branches`, where it shouldn't be. This will likely change in the future, since the UI part of topic namespaces feature is still being worked on. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: Testing an RC of evolve 11.0.0 and topic 1.0.0
03.02.2023 00:34, Uwe Brauer пишет: Hello, users of Mercurial, Evolve and/or Topic! We're planning to release a feature release candidate of evolve and topic extensions that contains an implementation of a concept that was in the plans for quite some time: topic namespaces (the name could change, if we find something better) But we did change some things in the UI. Remember seeing "branch:topic" format in `hg branches`? Well, it was a temporary implementation detail. With the implementation of topic namespaces we introduce a more thought-out way to represent branches plus topics. In this new format, topic namespaces become sort of a glue for all things related to (named) branching, e.g. this is what you'd see in hg log: branch//namespace/topic or, if you don't set topic namespace: branch//topic I use topics quite extensively, but my collaborators not. Strangely enough I see this structure sometimes in the current evolve version (and it annoys me quite a bit). Will this behavior be configurable (ie. Switch it off)? By "this" do you mean "branch:topic" or "branch//topic"? What version of evolve do you have? BTW what are the minimum requirements for this evolve version you describe. At the moment we're planning to still support Mercurial 4.8. Would be hg 5.2 ok (either compiled with python 3.5 or 2.7)? It would, but you should upgrade. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Are you using evolve.serveronly and serverminitopic extensions?
Hello, users of Mercurial, Evolve and/or Topic! Some of you may be using the following server-only extensions: evolve.serveronly and serverminitopic, that live in the same repo as regular evolve extension: https://www.mercurial-scm.org/repo/evolve These extensions were used by Bitbucket when it still supported Mercurial, because they were very lightweight and supported the minimum logic required for proper changeset exchange and obsmarker discovery (for example), but without any extra bits like new hg commands in CLI. Back in the day, people chose these extensions because in theory they would have lower risk of breaking things; after all, evolve and topic do have some experimental features. However, it currently seems that evolve.serveronly and serverminitopic aren't tested (neither by our test suite nor by the users) as extensively as the main evolve and topic extensions, which in the recent years became much more polished after being test-driven daily in real circumstances on real projects by both the developers and the users (who are also developers sometimes (:). So if you use evolve.serveronly and serverminitopic, we would really suggest you to switch to evolve and topic on the server side. The good news is that this shouldn't have any adverse effects on your setup. If you have any questions, don't hesitate to ask them in a response to this email, or starting a separate thread on this mailing list, or emailing me directly. Also we're on IRC: #mercurial on libera.chat, https://www.mercurial-scm.org/wiki/IRC The bad news is that while preparing a feature release candidate, we noticed that it's no longer viable to add features and cover them by tests in multiple extensions, so we're going to deprecate evolve.serveronly and serverminitopic in the coming release candidate and then REMOVE BOTH extensions in the coming feature release. If you really cannot switch to the main extensions in your server setup, you will still be able to use the old extensions from evolve 10.5.3, but obviously they won't support newer features that are coming soon. If you're interested in testing the new features from the release candidate (and/or knowing why this feature release needs an rc at all, which is unusual for evolve), I have sent another email to this mailing list about evolve 11.0.0 and topic 1.0.0. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
Testing an RC of evolve 11.0.0 and topic 1.0.0
Hello, users of Mercurial, Evolve and/or Topic! We're planning to release a feature release candidate of evolve and topic extensions that contains an implementation of a concept that was in the plans for quite some time: topic namespaces (the name could change, if we find something better) https://www.mercurial-scm.org/wiki/TopicPlan#sub_branches.2C_namespacing_and_representation In short, topic namespaces are trying to fix one of our major UX flaws: branches can continue to be used for release management, and topics can still be used for implementing features, but now there would be something for organizing topics into wider concepts. Topic namespaces, just like topics, are designed to go away when you publish your commits, and we tried to make them as unobtrusive as possible, to not get in the way of current workflows. There is a default topic namespace that will not clutter the UI, and users can keep using only branches and topics as usual. But we did change some things in the UI. Remember seeing "branch:topic" format in `hg branches`? Well, it was a temporary implementation detail. With the implementation of topic namespaces we introduce a more thought-out way to represent branches plus topics. In this new format, topic namespaces become sort of a glue for all things related to (named) branching, e.g. this is what you'd see in hg log: branch//namespace/topic or, if you don't set topic namespace: branch//topic In the future, we're going to support providing branches, topic namespaces (if you decide to use them) and topics in this format to all commands where it makes sense. Now, what these topic namespaces are aimed at? Among other things, topic namespaces are supposed to help users manage topics; their own and other users'. Previously, some people were already using username as a prefix for their topic names - this was an ad-hoc implementation of separation and/or ownership of work, and now with topic namespaces it's becoming more standardized and user-friendly. Here are more details on what aspects of workflow topic namespaces try to improve (taken from the wiki page linked above): * on the client side, they could be used to safeguard history-rewriting operations and in particular avoid conflicting with other people's work * code hosting providers and forges could map topic namespaces to their user or team concepts, and hence ultimately to their permission model * they could be used to narrow user view and exchange to the part that are relevant to them by default Although the UI didn't change much, and a big part of the planned features is not implemented yet, the changes that are included are quite extensive. We have changed a significant part of topic's representation locally and over the wire during the exchange. Given the scale of these changes we encourage people to test this release candidate. That would definitely help us pinpoint real issues that we didn't foresee during the planning and the development. It could also possibly give you some ideas how to integrate topic namespaces into your workflows early. The release candidate is coming out in the next few days, and the final feature release will most likely be ready in about 2 weeks after that. During these 2 weeks you can reach out to us and tell if you notice something being broken, and we'll obviously try and fix it before the final release. That being said, topic namespaces are here to stay, although maybe under a different name and with some changes after testing in real circumstances. ___ Mercurial-devel mailing list Mercurial-devel@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
