Framagit will close

hEARt PhoniX via Zotlabs|Hubzilla Development

somewhere between the lines, Sun, 29 Sep 2019 20:23:20 +0000

!Zotlabs|Hubzilla Development

@RockyIII has just posted a very important article that will have an effect on our projects: FramaGit will announce it's closure in 2020. There is no fixed date as of yet. I cannot share the original post, but we need to thank @RockyIII .

This brings the old question back: what service do we want to use, would a Zot embedded solution be possible, wanted, should we run our own gitlabs.zotlabs.org ... Everything has it's pro and contra. Luckily this is a very early heads-up, which means we can find a solution that will suit us and do not need to find a new solution Head Over Heels.
https://framablog.org/2019/09/26/lets-de-frama-tify-the-internet/

Image/photo

show all 23 Comments

Herbert Thielen

Sun, 29 Sep 2019 21:07:58 +0000

Uh oh. Thanks for sharing this, that's important news.

Mario Vavti

Mon, 30 Sep 2019 06:31:56 +0000

Thanks for the headsup.

El Dorado

Mon, 30 Sep 2019 06:52:04 +0000

Some folks are working on "ForgeFed", which is a decentralised ActivityPub based git repository management system. I don't know if this will be useable by the time the Framasoft folks pull the plug, but it's worth keeping an eye on their progress. I keep a backup Zap repository on gitlab.com/macgirvin/zap just because. I don't always push to it hourly, but I do push to it often.

I remember when gitlab.com crashed and a lot of work was lost for a lot of projects, so I kind of like redundancy, and I figure with such a high profile incident they are probably going to be the most reliable git repo on earth at least for a little while.

Mon, 30 Sep 2019 06:52:09 +0000

Is there any work being done on decentralizing git?

Mon, 30 Sep 2019 06:56:44 +0000

@Mike Macgirvin Ok, I guess this crossed in the mail

muppeth

Mon, 30 Sep 2019 07:23:18 +0000

Yeah it sad and franky quite suprising they also decided to cut git since it was/is home for quite many projects.
How about gitea, small, fast and easy to maintain if going selfhost route. Or, zot based version control 😃

Tue, 01 Oct 2019 02:17:39 +0000

Interesting....

I don't have an answer for the version control system side of things although really the only thing needed in my view is to add some method of permissioning for a GIT repo into Hubzilla/Zap.  I don't think it's "trivial,' but I don't think it should be super hard, either.

But I am working on a more formal announcement of something really exiting which may help with some of the other functionality provided by Gitlabs/Framagit/etc.

I ran across this note just as I was cleaning up my own repositories a bit and preparing to announce the availability of a distributed (though not FULLY decentralized) WORKFLOW (issue tracker) addon I created.

It requires the DEV branch of Hubzilla - there will also be a port to ZAP (awaiting a merge of a few updates, and it should be good to go!).

The addon creates a new permission "workflow_user" and allows the channel owner to grant that permission to connections.  Each workflow item (think "issue") is essentially a "meta" record pulling together information related to the issue (links to conversations, links to web pages, current issue status, priority, etc.).

A user who has been granted the "workflow_user" permission will be sent revised copies of the meta record when changes are made.  The "meta" information is contained in ICONFIG - which allows selective sharing with item recipients.

If a user with the "workflow user" permission has the workflow addon installed, they will have a "dashboard" including all the issues for the workflows for which they have been granted the "workflow_user" permission (some basic filters are already available).  If they do not have the addon installed, the item will appear as a "note" in their stream (with comments disabled).  "Updates" are simply edits to the item and so will not provide additional notifications.  There are plans to send out separate "Notes" when relevant updates occur.

When the addon is installed, an additional item is added to the pull-down menu of each item on your stream on your home hub.  This allows you to "Create a Workflow Item" linked to the item in your stream.  When you click on this pull-down option, you then select which workflow-enabled-channel to create a new issue on.  When the "issue" is created, only a link to the original item/conversation is attached (along with user entered data describing the issue). It's important to note that only those who already have permission to participate in that original conversation/view the original link will be able to see the contents of that link.  It may be necessary to create a separate conversation (attached to the issue) for workflow users to share information.  Each linked conversation/item "attached" to the issue has a place for a separate title and description/summary to explain why the link is there.

The "issue" itself also has a title and a description also to serve as a summary.  The issue can be assigned a "status".  Each status is assigned a numeric priority for sorting.  The issue can also be "assigned" to channels/users that have the "workflow_user" permission on the channel hosting the workflow.  This "assignment" currently only affects filtering/searching.  As of now, anyone with the "workflow_user" permission can see and modify the meta data of any issue on a channel where they have the "workflow_user" permission.  Basic functionality was the goal for initial release.

It's important to note -- a user does not need the "workflow_user" permission to participate in conversations about the issue or item.  Those are just regular conversations with standard security parameters.  Those conversations are simply "linked" to the issue meta-record.  (In the planning stage is some form of notification for users with the workflow addon installed on their channel that indicates that a given conversation is attached to a workflow item in a workflow-channel on which they have the "workflow_user" permission.)

On the back-end, the system relies on OWA, AJAX and IFRAMES to do some magic and provide a fairly integrated view so you aren't bouncing around to all kinds of different tabs/pages (unless you want to).

At the present time, the system is PARTIALLY nomadically aware - but we aren't yet using nomadic content addressing - so if the hub on which the original item was created is down, the item cannot be edited.  This on reason I say it is "distributed" but not fully "decentralized".  The other reason is that item edits take place directly on a server that hosts the workflow channel itself.  A "workflow_user" simply has a dashboard/report that consolidates all the workflow items from all their workflows into one place.

If all that sounds confusing - I'm not surprised.  It's REALLY hard to wrap your head around because it takes a completely different view of task/issue systems.

There are many improvements on the drawing board, but the first step is done - and it's functional for a lot of different uses even with the limitations.  The "bones" are also there to make it extensible.  I know there are a few more places to add hooks, but many hooks already exist to make it possible to create related addons to add functionality in a modular way rather than needing to have it merged into the existing addon.

So - long story short - Hubzilla has a basic "distributed" (not fully decentralized) issue tracking system.

There should be a Merge Request for the Hubzilla Addons soon.

El Dorado

Tue, 01 Oct 2019 02:31:09 +0000

@M. Dent Send me a DM if you put in a Zap pull request or are waiting for more than a day or two. I'm not ignoring them, I'm just not expecting anything and gitlab isn't always telling me about them, even with global notifications enabled.

Tue, 01 Oct 2019 02:45:32 +0000 last edited: Tue, 01 Oct 2019 02:42:31 +0000

@Mike Macgirvin - will do. Looking at the recent list of work you've been doing, I just figured you had your head down.

hEARt PhoniX

Tue, 01 Oct 2019 05:32:58 +0000

@M. Dent Sounds a lot like a ticket system?

Harald Klimach

Tue, 01 Oct 2019 06:01:13 +0000

I recently moved our public mirrors to OSDN, as Bitbucket announced its ceasing of Mercurial support. It provides a rich feature set:

We offer SVN/Git/Mercurial/Bazaar/CVS repository, mailing list, bug tracking system, bulletin board and forum, web site hosting, release file download service, permanent file archive, complete backup, shell environment and environment that allows easy and integral projects management of these services run on web.

Though, the interface feels a little dated. In any case, I believe it would at least also be a stable option for a mirror to keep the code-base around.

hEARt PhoniX

Tue, 01 Oct 2019 07:30:29 +0000

Maybe a combination would be useful, as @Mike Macgirvin has hinted at: use / create our own resources but also maintain a public mirror.

Mario Vavti

Tue, 01 Oct 2019 08:22:20 +0000

I think i'll create a mirror for now at gitlab.com

Where we will officially host/move the code still needs to be discussed. I would not like to miss gitlabs CI though. Not sure if any of the "easier" to maintain git frontends provide something like that...

Tue, 01 Oct 2019 11:45:07 +0000

@Mario Vavti

I would not like to miss gitlabs CI though

Yes, this is the main Gitlab 'pro' vs other Git-based systems.

Tue, 01 Oct 2019 11:48:32 +0000

@h.ear.t - It is a ticket system - or, rather - it's a slightly abstracted tracking system that can easily be adapted for use as a ticket system - but a ticket system is probably one of the most familiar uses.

hEARt PhoniX

Tue, 01 Oct 2019 15:39:52 +0000

@M. Dent that may be great for direct project use. Give me a heads up, I will give it a try.

Tue, 01 Oct 2019 16:42:28 +0000 last edited: Tue, 01 Oct 2019 16:39:27 +0000

I moved the merge request to the addon repository into "WorkInProgress" temporarily because I found one issue overnight. I have it fixed, but don't have time to add the commit to the merge request right now. Once that's done, it should be ready to play with on the DEV branch.

Also - I took a look at the ForgeFed stuff just a little bit - set my mind thinking on future improvements. But what's there is a good start - and the changes made to both HZ and ZAP to make this possible, give us a HUGE "head start" on something along the lines of "ForgeFed"

Wed, 24 Jun 2020 18:42:21 +0000

Wanted to "bump" this since we are half way through 2020 and I was just reminded of the closure announcement. I haven't heard anything new from Framasoft, but figured with all the other chaos of 2020, this may have left other people's radar like it had mine.

hEARt PhoniX

Wed, 24 Jun 2020 19:32:35 +0000

I had installed a local gitlab on my other notebook to ave a look. But yes, you are right.

Wed, 24 Jun 2020 22:15:38 +0000

GitLab is a monster to host, performance-wise. For my own purposes, I've watched Gitea for a while, but never installed an instance. A system to handle CI would have to be installed separately, but they have plugins for a number of systems.

El Dorado

Thu, 25 Jun 2020 02:21:38 +0000

This gave me a reason to create yet another backup repository on https://codeberg.org/zot/zap . This is based on gitea so doesn't have CI (integrated testing) but gitea seems to be the only git "community" project which isn't tainted in some way by corporate involvement. I'll keep things on framagit for now - as I still require a framagit account to work on Hubzilla issues. But I can swap it out at most any time, so if framagit vanishes suddenly it won't catch us unprepared. I think the take home message is to work on our testing infrastructure so we can easily separate it from the code repository (and of course improve test coverage). That gives us a lot more freedom in our choice of repository providers.

hEARt PhoniX

Fri, 26 Jun 2020 00:12:50 +0000

@Giac El Vecio Yes. That email is used for password resets or status mails if you want them. It can be changed in the account settings. (Speaking for Hubzilla.)

El Dorado

Fri, 26 Jun 2020 00:25:11 +0000

You can't use the old one at that point so yes.