After seeing bugzilla tasks scattered around and one of the main goals of removing Bugzilla being thought about, here's a tracking task so everything that is needed for removing Bugzilla from production use is done and nothing is left behind.
Description
Details
Event Timeline
As explained in T95266#1242451, T95266 does not block T95184, hence removed from blockers list.
(Re-added a blocking task.) There is no hurry to kill bugzilla, please stop boycotting public discussion of the matter (namely, nominations of show-stoppers).
It's pretty clear that there are few persons wishing to kill bugzilla at all costs and few other persons who do not like the idea. The solution is not a Phabricator edit-war nor a might makes right outcome. The solution is to call more people to express their opinions, how they use old-bugzilla etc.
@Nemo_bis removing a bug tracker that is not used for actual development anymore - or did I miss something? - from production means reducing the attack surface of our infrastructure and leaves us with one less unuseful thing to maintain.
So as far as ops are concerned, killing bugzilla is pretty important, and there is some hurry - if there is no hurry no one will ever act to kill it, in my experience.
@Nemo_bis: See T95184#1244757 - if you think this is a blocker, explain why you think so by replying to my explanation why I do not see it as a blocker.
You are free to call more people to express their opinions.
T95266 - i don't know if anyone actually still wants to mail users who have not migrated so i did not close it as rejected, but i did remove it as a blocker for this.
T95267 - removed as a blocker because the dump exists now which makes it possible to build one without needing old-bz
You are free to call more people to express their opinions.
I'm not the one who proposed this action and I don't intend to do the proposal work in the proposers' and supporters' stead. I think that removing a service without consulting the stakeholders for it, *and* in direct contradiction of promises formerly made to the stakeholders in question during a public consultation, is an extremely bad practice.
The above tasking is getting annoying with the unless debates. As has been said, old-Bugzilla is not required for this as all data can be claimed within Phabricator once the email registers. The data is all transferred and all data is migrated, all that is missing is an account with the emails which we can't dictate as we can't force people to sign up if a) they don't want to b) they don't participate in Wikimedia anyway more or c) the email is lost.
All data *is* migrated just the account doesn't exist. If we have this as a blocker hen we are going into a too social area for a technical objective. Please do not add the blocker again. It is not s blocker as there is 0% relation now unless I have misunderstood the communications from those who worked in a migration. Pinging @Aklapper and @Qgil to comment on the technical accuracy.
@Nemo_bis could you please stop adding the blocker if you are not going to provide a rationale on how that is a technical block for the project? All data is migrated all that is missing is an account on phabricator for the data to be assigned to. This means this is instead a social blocker which can not be dealt with adequately and should not block the technical implementation of something done based on security reasons.
Unless you provide a rationale that clearly states why this requires Bugzilla to be online, could you please stop doing this in a disruptive way in order to make a point. If you continue, restrictions may be out in place to prevent editing of this task.
@greg I figured the next step is sending an announcement mail and committing to a date.
@JohnLewis
Pretty much. I vote for a like a three week window so I'm proposing June 22nd? For a good time frame, after the ops meeting (1900 UTC seems the usual end)?
Great great work. Timing sounds good to me.
Anyone planning to draft that announcement email?
I'm happy to help (or even draft it, just want to understand who plans to do the next step).
I believe Daniel's workload is mixed at the minute so if you want to draft an email @Aklapper that'll be extremely helpful.
Change 220691 had a related patch set uploaded (by Dzahn):
bugzilla: backup dump and static files
Change 220818 had a related patch set uploaded (by Dzahn):
bugzilla_static: include role::backup::host