GitLab beplan om in September veranderinge aan die diens se reëls aan te bring, waarvolgens projekte wat gratis op GitLab.com aangebied word, outomaties uitgevee sal word as hul bewaarplekke vir 12 maande onaktief bly. Die reëlveranderings is nog nie amptelik aangekondig nie en is in die interne beplanningstadium.
Die verandering is daarop gemik om die koste van die instandhouding van gasheer te verminder deur hulpbronne vry te maak vir die stoor en verwerking van verlate projekte en nie-ontwikkelende vurke. Daar word beraam dat die instandhouding van infrastruktuur vir verlate projekte tot 'n kwart van alle GitLab.com-gasheerkoste uitmaak, en die outomatiese skoonmaak van sulke projekte sal tot 'n miljoen dollar per jaar bespaar.
Voor die werklike skrapping sal kennisgewings binne 'n paar weke of maande aan die eienaars van die bewaarplekke gestuur word wat om skrapping aansoek doen, wat hulle waarsku om die relevansie van die projek te bevestig. Slegs verlate projekte word beplan om uitgevee te word, waarvan die skrywers nie op waarskuwings reageer nie; geen veranderinge is gedurende die jaar in die bewaarplek opgemerk nie, geen nuwe uitgawes is gepubliseer nie en geen kommentaar is gestuur nie.
Sommige gemeenskapslede beskou die voorgestelde verwydering egter as 'n slegte praktyk, aangesien kode van onaktiewe bewaarplekke gebruik kan word as 'n afhanklikheid in ander projekte wat aktief bly. Daar word ook opgemerk dat konstante veranderinge nie die doel van sommige skrywers is nie, wat goed kan oorweeg dat die huidige stand van hul projek 'n optimale vlak bereik het en die kode goed genoeg is en nie verbetering vereis nie, of aanvanklik oop gereedgemaakte werk wat nie beplan word om ontwikkel te word nie, maar wat nuttig kan wees vir ander.
Daarbenewens kan kode van onaktiewe projekte ekstern verwys word en die verwydering daarvan sal lei tot die verlies van 'n bekragtigde verwysingskopie (nie-amptelike kopieë word nie gewaarborg om vry van kwaadwillige aktiwiteite te wees nie), dus in plaas daarvan om dit uit te vee, sal dit waarskynlik meer optimaal wees om dit na 'n geargiveerde toestand te skuif terwyl die vermoë om toegang tot die kode in leesalleenmodus te behou, behou word. Om skyfspasie te bespaar wanneer vullisvurke gestoor word, kan jy meer doeltreffende metodes gebruik vir die verwerking van duplikate, byvoorbeeld GitHub, om dataduplisering te vermy, stoor saam alle voorwerpe van die hoofbewaarplek en gepaardgaande vurke, wat die eienaarskap van commits logies skei.
Bron: opennet.ru