In D25011#370, @avivey wrote:

@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.

@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.

In D25011#365, @chris wrote:

Doesn't CircleCI have some API contract that we can stub out? If the requests + payloads Harbormaster is sending out to CircleCI endpoints pre- and post- this patch are unchanged, and those conform to CircleCI's published API spec, then like, (1) that's all testable, and (2) that's a good assurance that nothing's breaking as a function of this patch that wasn't already broken prior to it. Saying something can't be tested because it calls to an external system feels like a little bit of a cop-out. We can't control what CircleCI does with a request Harbormaster sends, and that's a totally fair point, but we can control what Harbormaster sends to it and when, and ensure that what we're doing conforms to their published documentation.

In D25011#366, @avivey wrote:

One point that you raised and I disagree with: we do have lots of users right now. We (I) consider all the installs of Phabricator to be Phorge installs in-waiting; we want to keep compatibility there, for a while yet - to ease their transition.

And in addition, there's a limited amount of attention we all can allocate to the project; if we spend time reviewing this change, we take that time away from the bootstrap process.

In D25011#365, @chris wrote:

In D25011#358, @deadalnix wrote:

Slowing things down is rarely a good idea ever - at least for the reasons external to the patch in question, rejecting a patches because it's not good if obviously just fine. I reject that point outright.

How is IP assigned currently? We have no CLA, no legal entity stewarding the project. Are we inviting something like the SCO-Linux dispute (obv a worst-case scenario)? What happens if one of our employers takes an interest and attempts to assert ownership of any IP we've individually contributed? Are we at risk of infringing on Phacility trademarks by actively developing, extending, and offering as our own something that, to an end user, ostensibly still calls itself "Phabricator" in 1500-odd user-facing places across the entire application? Do we even know?

100% IANAL, I have no subject matter expertise in any of this. I fully admit I could just be catastrophizing. If the answer to all this is, "Yup, everythong's a-ok, carry on", then that's awesome. But I don't think we have any answers yet, and that feels like it could potentially become problematic down the road. The cost of doing our due diligence here is a couple weeks' delay on some active development; the potential cost of not doing it is we have to rip out functional parts of the codebase and rewrite them because we messed up on IP assignment and licensing.

One point that you raised and I disagree with: we do have lots of users right now. We (I) consider all the installs of Phabricator to be Phorge installs in-waiting; we want to keep compatibility there, for a while yet - to ease their transition.

In D25011#358, @deadalnix wrote:

Slowing things down is rarely a good idea ever - at least for the reasons external to the patch in question, rejecting a patches because it's not good if obviously just fine. I reject that point outright.

Do lint and fix error raised by the linter

A few things on here.

+1 for holding any product change until we're officially "up".

I am in agreement with @Ekubischta’s comments regarding these functional changes staying on hold until we get the branding and quality procedures in place

I feel we should revert this change from master and back into a revision

I have a lot of concerns about what is happening with these Harbormaster updates. I believe them to be good strategy, and should be welcomed, however..............

I think we should check with the community to find someone using CircleCI who is able to check that this doesn’t break backwards compatibility.

I would like to note that France has what the local law calls association loi 1901, which is very advantageous for a open source projects. In short it is an entity that can own stuff, accept donation, but cannot do for profit operations. Projects such as VLC and ffmpeg are using this. The requirement are very lax (you basically need to have an address somewhere in France for administrative bullshit) and have at least 3 founders. They don't need to be French or live in France, in fact, last time I checked, you could even do one as an illegal emigrant, which I found funny. I had a long chat with Jena Baptiste Kempf who created VLC about this for the last big open source project, but we ended up going for a structure in HK because we had Chinese users and donors and that was easier administratively this way. Chinese special case excluded, this was by far the best option we had.

This change looks solid but I am a little concerned about pushing up feature/functional changes prior to getting all the branding work done for T15006: Re-brand Phorge. I haven't been able to spend as much time on that recently as I'd like and would appreciate any assistance on it. I'll update the task to clarify the strategy/approaches that I think we need to address.

This ties into T15009: Evaluate legal organization format ("Foundation") - the majority of foundations for open source will support retaining assets like trademarks/copyrights. It would also be useful if they assist in acquiring them in the first place.

In T15004#585, @Ekubischta wrote:

T15011 discusses some of this...

@willson556 built a container that works awesome - Just a few small things to work out - https://github.com/willson556/phorge-devcontainer

This container was easy enough for me to get up and running in like 4 steps (see the README)

I think once some of those issues are resolved, we should host the source for this container here at we.phorge.it

For the development environment this would probably be best in a diviner book/document instead of a wiki.

T15011 discusses some of this...

@chris Option 3: when upgrading an existing instance, and *IF* the storage.default-namespace is not set explicitly, prompt the user.

In T15004#100, @speck wrote:

On the topic of increasing community involvement we will also want to produce documentation for setting up development environments as well as the steps to submit changes upstream (like a quality checklist). To make development environments even easier we might want to consider supporting something like a vagrantfile so people can get started with very few steps.

Is this change necessary?

Question: while we figure out how/if we host the site itself with phorge, should we also start working on the content?

hi, i'm the owner of a little sw Company based in Italy. I based it on phab and i would like to contribute to Phorge also with my employees.
If someone of admins is interested please contact me via email or in conpherence
Thank you everybody for your work, i hope the Phorge has a great future ahead

I think that for the time-being, we should just continue the stable/master approach, because we have a lot of other things to do.
We can always open this later if we feel a need.

In T15014#495, @Ekubischta wrote:

In T15014#446, @speck wrote:

I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.

Can you give me access to see that document?

There might be a way to explicitly define it as generated, which (used to) exclude it from lint.

Can I please have access to Release Process ?

I see that this has been added to the changelog already here: https://we.phorge.it/w/changelog/2021.25/ . Fantastic!

I landed the code, but leaving the task open because we need to add a release note whenever we know where they go.

rebase

I'm going to land this one as to not wait on things that are not sorted out, with the obvious note that a release note would be advantageous.

I think this is complete.

I'm going to call this done, since we have a stable dashboard set up now.

Looks good to me!

Looks good to me.

Address code review comments

In D25009#285, @20after4 wrote:

Shouldn't we also think about changing the name of arcanist or does it make sense to have a fork with the same name?

We should probably exclude the package-lock.json from linting rules, because it is auto generated.

fwiw the old upstream workflow has been very easy to follow as a downstream fork maintainer so I like keeping it mostly unchanged.

Shouldn't we also think about changing the name of arcanist or does it make sense to have a fork with the same name?

In T15014#446, @speck wrote:

I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change.

Both revisions are landed. We just need a pull on the upstream install to regenerate the documentation. @chris could you do the pull so I don’t break anything?

Alternatively, we could include a one-time migration step that sets the default storage namespace to the database as part of the storage upgrade step… this would ideally be silent.

One other option, if we're going to provide a migration guide, par of that could be setting the storage namespace... Brain fart and forgot that'll be something we do. But that'd let existing installs continue to use their Phab namespace and new ones the Phorge one

One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time

Fix a link that will break once we regenerate the documentation.

Confirmed this does indeed break existing installs relying on the default. What options do we have to work around this? Couple that come to mind might be:

• Add a new SQL patch that runs RENAME TABLE old_db.table_name TO new_db.table_name for every Phorge DB and table.
  • Con of this is that it may require a new GRANT ALL PRIVILEGES ON [...] statement based on how each install originally set things up (e.g., granting ON *.* versus ON phabricator%.*)
• Add a line in the release notes telling users to ./bin/config set storage.default-namespace phabricator if they're using the default namespace
  • Con of this is it's an out-of-band upgrade step that relies on instance maintainers reading the release notes and not setting and forgetting an upgrade script in a crontab on the assumption that stable generally is pretty stable
• Leave the default storage namespace as phabricator