Adequate anchorage length of rebars is a primary requirement for the safety of a member,especially a beam.When Analysis including seismic, structural design, manual design etc is important, proper detailing of a structure is equally important.
https://www.civilera.com/post/anchorage
Civilera offers world class Structural Engineering courses in a Structural consulting perspective covering basics,manual designs & software alike. We focus on ETABS Tutorials StaadPro Training, Revit structures, Foundation design using SAFE. We enable students to have a career in structures & help experienced engineers in other fields to shift their career to structural engineering. All civil engineering online courses are available in different payment plans.
visit here for full info: https://www.civilera.com
I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
Hi, may I ask how to join the wikimedia github "organization"? Thanks!
沈澄心
dringsim(a)qq.com
---Original---
From: "Brian Wolff"<bawolff(a)gmail.com>
Date: Tue, Jun 18, 2024 08:45 AM
To: "Wikitech-l"<wikitech-l(a)lists.wikimedia.org>gt;;
Subject: [Wikitech-l] Re: How to make commits from mirrored Wikimedia repos show up on your GitHub profile
The other solution is to ask to be added as a member of the wikimedia "organization".
On Monday 17 June 2024, Bartosz Dziewoński <matma.rex(a)gmail.com> wrote:
I'm digging up this ten-year-old message, because you may want to know
that this solution no longer works: GitHub no longer shows your
imported contributions in your starred repositories on your profile.
This changed some time in April or May.
You can follow the conversation about it here:
https://github.com/orgs/community/discussions/128895
On Tue, 9 Jul 2013 at 22:06, Bartosz Dziewoński <matma.rex(a)gmail.com> wrote:
>
> I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
>
> tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
>
> (Is there a place on mw.org to put this tidbit on?)
>
> ------- Forwarded message -------
> From: "Brian Levine" <support(a)github.com> (GitHub Staff)
> To: matma.rex(a)gmail.com
> Cc:
> Subject: Re: Commits in mirrored repositories not showing up on my profile
> Date: Tue, 09 Jul 2013 06:47:19 +0200
>
> Hi Bartosz
>
> In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
>
> The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
>
>
> Cheers
> Brian
>
>
> --
> Matma Rex
--
Bartosz Dziewoński
_______________________________________________
Wikitech-l mailing list -- wikitech-l(a)lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave(a)lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Hello,
I will be *upgrading Gerrit* from the 3.9 series to the 3.10 series. I
have scheduled the upgrade for *Wednesday 26th at 8:00am UTC*. It is
immediately after the UTC morning backport & config window.
The upgrade requires the Gerrit service to be stopped for the duration
of the upgrade. Given we do not need to reindex all the changes, the
downtime should be just a few minutes.
Gerrit 3.10 brings:
* Rebasing of merge commits from the web interface
* Updating author and committer from the UI
* Less email notifications (see the dedicated section in release notes
<https://www.gerritcodereview.com/3.10.html#less-email-notifications>)
The release notes: https://www.gerritcodereview.com/3.10.html
The upgrade task: https://phabricator.wikimedia.org/T367419
Deployment calendar entry <https://phabricator.wikimedia.org/T367419>
Antoine "hashar" Musso
Wikimedia Release Engineering
Dear Wikimedia Developers,
tl;dr: as part of continuing efforts [1][2] to speed up our CI jobs, we
have experimentally enabled parallel PHPUnit tests for WMDE maintained
extensions[3]. In experimental testing, this reduces the time taken to run
the longest CI tests from 25 minutes to around 8 minutes. If you see any
problems, please report them on Phabricator at
https://phabricator.wikimedia.org/T361190.
Arthur
Longer version
--------------------
The parallel testing implementation uses PHPUnit’s `--list-tests` function
to generate a list of test classes, then creates 7-8 “buckets” of test
classes which are executed as suites in parallel. Experimentally, this
reduces the time taken to run the longest CI tests from 25 minutes to
around 8 minutes.
We are rolling this functionality out progressively as we have some
concerns about its impact. We want to make the developer community aware of
our concerns and ask you to help us spot potential issues as they occur.
There are three main concerns:
1. Overloading the CI infrastructure
-----------------------------------------------
Having the job runners execute the tests in parallel means that fewer
runners will be using more CPUs. This may increase queuing time during busy
periods, or may lead to partial or complete denial of service depending on
how the jobs stack up and how the infrastructure copes with the new load
profile.
2. Unexpected test failures
-----------------------------------
Splitting the test suite and running the classes in a random order can
surface bad interactions between test cases that we didn’t see before - we
have a lot of global state in the system, and not all test classes are
careful in their use of `setUp` and `tearDown` methods. If you suddenly
start to see failures that were not present before, or you see failures
that you are unable to reproduce on your local machine, that might be a
result of the tests being run in a new combination because of the parallel
execution. If you see this, please file a task and make it a subtask of
T361190.
3. Incomplete test runs
------------------------------
Because of how we are extracting the list of tests from PHPUnit and
constructing a new suite, it may be the case that we “lose” test classes
from the Parallel run that were present in the serialized execution. We
have done some testing to increase our confidence that this is not the
case, but it is still a potential risk. If you think some tests are not
being run, please file a task and make it a subtask of T361190.
How do I report a problem?
------------------------------------
The changes were deployed today (June 25th) at 14h24 CEST. If you start to
notice problems with your CI jobs that were not there before, please let us
know with a comment on https://phabricator.wikimedia.org/T361190 . If the
problems are urgent and we need to roll back the change quickly, you can
contact Arthur (codders), Kosta (kostajh) or Antoine (hashar) to get the
parallel change reverted, in #wikimedia-releng.
What’s next
---------------
The current implementation is Python-based and all the changes are in
Quibble/Zuul - these changes only affect CI jobs. To help developers speed
up their local testing, we are also working on a PHP-/composer-based
implementation [4], and when that is mature we will switch from the Python-
to the PHP-based implementation in CI.
We have also looked at and continue to be interested in an implementation
based on paratest[5]. Our current test suite is complex in ways that
paratest does not currently support, and it looks like the support we need
will only be available when we have migrated our test suite to PHPUnit 10.
References:
1.
https://phabricator.wikimedia.org/T361190
2.
https://phabricator.wikimedia.org/T50217
3.
https://gerrit.wikimedia.org/r/c/integration/config/+/1047919,
1.
AdvancedSearch
2.
ArticlePlaceholder
3.
Cognate
4.
ElectronPdfService
5.
EntitySchema
6.
FileExporter
7.
FileImporter
8.
InterwikiSorting
9.
PropertySuggester
10.
RevisionSlider
11.
TwoColConflict
12.
Wikibase
13.
Wikidata.org
14.
WikibaseLexeme
15.
WikimediaBadges
4.
https://phabricator.wikimedia.org/T365567
5.
https://github.com/paratestphp/paratest
--
Arthur Taylor
Senior Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Keep up to date! Current news and exciting stories about Wikimedia,
Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
<https://www.wikimedia.de/newsletter/>.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B.
Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine,
Dr. Christian Humborg
We just released a new version of Research:FAQ on Meta [1], significantly
expanded and updated, to make our processes at WMF more transparent and to
meet an explicit FDC request to clarify the role and responsibilities of
individual teams involved in research across the organization.
The previous version – written from the perspective of the (now inactive)
Research:Committee, and mostly obsolete since the release of WMF's open
access policy [2] – can still be found here [3].
Comments and bold edits to the new version of the document are welcome. For
any question or concern, you can drop me a line or ping my username on-wiki.
Thanks,
Dario
[1] https://meta.wikimedia.org/wiki/Research:FAQ
[2] https://wikimediafoundation.org/wiki/Open_access_policy
[3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953
*Dario Taraborelli *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter
<http://twitter.com/readermeter>
We’re going to keep both Gerrit and GitLab.
Many of the repositories now on Gerrit require features that are lacking in
GitLab:
- Cross-repository dependent merge requests
- Project gating and deterministic, atomic merges
- Stacked patchsets
- Multiple reviewers
Likewise, GitLab has features that our developers have come to depend on:
- Familiar fork, branch, and merge workflow
- Self-service repository creation
- Jupyter Notebook rendering
- GitLab's self-service CI/CD pipeline
- Bring your own runners
- Artifact and packages registries
As a result, we'll be running both systems for at least the next two years.
More information is available on MediaWiki.org[0], summarized below.
___
*Details*
These repositories have requirements that mean they must remain on Gerrit:
- MediaWiki core
- The subset of extensions and skins which track MediaWiki core’s
mainline branch (including all Wikimedia production-deployed extensions,
skins, and MediaWiki vendor)
- SRE’s Puppet repository along with dependencies and dependent
repositories.
Other repositories on GitLab may return to Gerrit to lessen the mental
burden of working with two systems.
Likewise, some repositories on Gerrit may wish to continue to migrate to
GitLab.
We'll use the Phabricator tag "GitLab (Project Migration)"[1] to track
requests from project stewards to migrate between systems. We’ll be
monitoring that workboard closely through the end of this calendar year to
assist developers with their migrations.
___
*What now*
- We have no intention of shutting down either system for the next two
years.
- We've posted a longer explanation on MediaWiki.org[0]. Please use the
talk page there (rather than this mailing list) for discussion.
- We've gathered a list of questions we anticipate some folks may have
on MediaWiki.org[2].
- Specific requests from project stewards to migrate repositories
between either of our systems should use the Phabricator tag "GitLab
(Project Migration)"[1].
- We'll be hosting office hours to answer any questions. More details
about these sessions will come later.
The decision to keep both systems was challenging. Having two code forges
adds to the fragmentation of our systems, the mental overhead for our
developers, and the maintenance burden of stewards. But each system is
well-suited to a subset of our needs, keeping both systems safeguards the
productivity of our developers and the stability of our systems.
For more details, I encourage you to review MediaWiki.org[0] and engage on
the talk page.
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
[0]: <https://www.mediawiki.org/wiki/GitLab/Migration_status>
[1]: <https://phabricator.wikimedia.org/project/profile/5552/>
[2]: <https://www.mediawiki.org/wiki/GitLab/Migration_status/FAQ>