On Tuesday, February 21, 2017 02:43:26 PM Ian Clarke wrote:
> I'm also curious as to the value of much of the data in Mantis, I mean, are
> most of the issues in there still relevant?  Are they ever likely to be
> fixed or will they just gather dust indefinitely? 

I've moved this quote to the top since I've answered this statement of yours 
like 5 times already and you keep acting as if that never happened, which is 
frankly very thoroughly frustrating.

Thus let please me answer it in a manner which is much more explicitly worded 
than what I have previously said, and to compensate for that also includes 
more numbers:

The data in the bugtracker is so important that if the project really decides 
to delete it as has been suggested sometimes, then I will:

- run a copy of it elsewhere (which may be poor because it'll be from
  archive.org or whatever).

- assume the project has been compromised by an intelligence agency because
  deleting the bugtracker is equal to deleting a random half of the codebase
  as documentation and code belong together - and if a project starts to
  delete its own codebase of 11 years of work, then it is compromised for
  sure.

- fork the project because it is compromised, and also because the code must  
  be in sync with the bugtracker.

- in the name of the fork do a press release which states that the main
  Freenet project has likely been compromised by an intelligence agency and
  people shouldn't touch it with a ten foot pole.

Given that we're down to a handful of active contributors, a fork is the VERY 
VERY VERY VERY LEAST THING which I want and which we as the project should 
want
- but it needs to be said because you keep repeating the very dangerous 
statement of claiming that a MAJOR part of our codebase is not valuable.
I'm also not the only one who has been thinking that a fork may become 
necessary if the current approach of management continues.

Here's numbers about the quality of the tracker:

- 3571 of the 6899 issues are *closed* already, that is 51%.
  Also, the main issue balance for the past 365 days is negative, i.e. more
  were closed than opened.

  So we DO fix the stuff.

- As a result of your complaints about the tracker's freshness, I have
  recently spent like a dozen hours on searching for outdated issues and  
  closing them, search the IRC logs for "https://bugs.freenetproject.org";.

  I had already been doing this every once in a while for years, I've closed
  1010 issues in total.

  It now usually takes me like 20 minutes to even FIND an issue which is  
  obsolete. So really most of the stuff *is* valid nowadays.

- 56% of the issues have been filed by:
  * toad: 2211 issues
  * me: 1129 issues
  * nextgens: 513 issues.
  Thus:
  * You could realize that if I dealt with over thousand issues you could
    finally start putting some trust into what I say about the tracker ;)
  * it is mostly run by developers and thus high quality.

> What is the process by which we prioritize the issues in there and fix them?

There is a "severity" and "priority" field for every issue.
Severity is how much an issue breaks something, priority is how soon it should 
be fixed. You can sort on both in combination.

GitHub doesn't have those fields.

> On Tue, Feb 21, 2017 8:15 AM, x...@freenetproject.org wrote:
> > I've looked at GitHub issues for bugtracking, they are not an option:
> > 
> > The most simple issue with it would be that it would require us to ask
> > every pre-existing bug reporter to allow us acccess to their GitHub
> > account so we can link their issues against their account.  We have 1158
> > user accounts, so this isn't going to happen.
>
> We wouldn't have to do that, we could add a note/tag to each issue with the
> original reporter and those that are still active in the project can change
> the ownership of their issues to themselves.

We cannot put the email addresses of 1158 people on the public web, they will 
kill us.

> Also, your argument could be used to prevent us from ever moving away from
> Mantis as our bugtracker.

Yes. And?
Are we going to move away from Java by throwing away all of our 16 years of 
work?
Some things about a project cannot be changed because they are too deeply 
rooted in the system.

And in the case of bugtrackers, the thing to move to hasn't even be invented 
yet [1]:
Distributed bugtracking on top of Git. A distributed system would resolve the 
hosting question for ever.
And it absolutely IS the logical step for bugtracker evoluation to end at: 
Bugs are part of the codebase, they should be stored inside it.

I would be very happy to switch to such a system!
But I would strongly recommend we stay with Mantis until it exists so we only 
have to migrate once and for ever.
Migrating to a proprietary system now will only make this much more difficult 
in the future.

> Looking at Google Trends, Mantis has been
> steadily declining in popularity for at least the last 5 years.

We're developing software, not skateboards for hipsters.

If the tool does the job properly, the duty of an engineer is to use it, no 
matter how old or ugly it is.
We're supposed to be rational scientists, not emotional slaves of fads.

If some new developer is incapable of understanding how to use Mantis just 
because it looks old, they're too incompetent to file good bugs or even write 
code anyway, and we shouldn't WANT them to dump their noise into our 
bugtracker.

> Our dependence on it will become more and more of a headache with time, even
> if we find a free hosted solution for it.

I don't see any headache. It just works fine and does everything I need.

The hosting issue is completely invalidated by the fact that we didn't even 
try to find a managed Mantis hosting company.

> > It also is very unlikely that GitHub can provide a 1:1 mapping of the
> > datamodel of Mantis, so we would lose lots of critical information.
>
> Such as?

- There is no "private" flag, so our security issues would suddenly be public.
Isn't that enough already on a security-focused project?

- The user account issue which we talked about before is impossible to resolve 
because of the email addresses and the lack of a private flag. That alone will 
block everything. We cannot expect GitHub to allow us to create user 1158 
accounts, we cannot put the email addresses anywhere because there is no 
private space, and we cannot lose who filed bugs because we need to be able to 
ask questions.

Beyond that:

- GitHub has the following fields on an issue:
* ID
* Title
* Description
* Date
* Labels
* Milestone
* Assignee
* Comments
* Notification subscriptions
* Reaction Smileys (yay!)

Mantis has these:
* ID
* Project
* Category
* View Status
* Date Submitted
* Last update 
* Reporter
* Assignee
* Priority
* Severity
* Reproducibility
* Status
* Resolution
* Platform
* OS
* OS Version
* Product version
* Target version
* Fixed in version
* Summary
* Description
* Tags
* File attachments
* Relationships
* Users monitoring it
* Comments
* Edit history of the issue fields
* Edit history of comments

So Mantis can store a lot more.
What do we do with all of that?
It may be possible to map, or it may not.
Even if it is, it still won't be searchable on all the fields like Mantis is, 
which is very inconvenient.

And who does the job of looking at the existing bugtracker database for dozens 
of hours and figuring out which fields are frequently used and which not?

So why do you need to mix up the job of migrating the server elsewhere with 
switching the software?
We have enough unfinished work already.

> We should quit trying to pretend we have the resources to manage our own
> server

I just offered you to deal with it and pay for it.

> The most critical feature it's lacking is that someone else administers the
> server it runs on. 

I also told you that if you want to have a company manage it, Mantis hosting 
companies exist.

> Even if you can completely replace what Florent has been doing, being solely
> dependent on one person is concerning, particularly when it is entirely
> unnecessary for us to manage our own server when everything we do can be
> handled by widely-used, hosted, and free third-party services.

Fine, then please ask on the mailing list for who else wants to help with 
maintenance, and wait for some weeks, not just an hour :)

Or switch to a Mantis hosting provider, I am 100% OK with that.
Just don't get rid of Mantis please.

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to