What should be included in 1.0

[Thomas De Schampheleire]

2018-03-12 18:54 GMT+01:00 Dominik Ruf <dominikruf at gmail.com>:
> Hi all,
>
> we discussed in the past that we are long over due to release a new version.
> We also agreed that we should strongly push towards a 1.0 release.
> Since this may attract new users, I think we should carefully think about
> what should be included in this release. There is only one chance for a
> first impression.
>
> These are the things, I believe, the users will expect and therefore should
> be included in the 1.0 release.
>
> 1. attractive UI
> We are not there yet, but close(r)
> 2. ssh support
> There is an old PR for this. I made some fixes and started to and some
> tests. I'll create a PR soon.

I have also thought that this is something that users will expect. On
the other hand, since this is a big item, this means that 1.0 will
take some time after 0.9 before being ready.

The other approach is to already do 1.0 without ssh support and
announcing that SSH support is coming in a next release.


> 3. manage hooks (incl. custom hooks) on a repository and repository group
> bases
> I have an old PR about this as well.

More generally, allowing certain settings per repository and per
repository group.

I need to think what else we definitely would need...

>
> P.S.: Like I mentioned before, I think we should use a proper project
> management tool, to keep track of things like this. Since you guys don't
> like JIRA, because it is not open source, does somebody know
> https://www.openproject.org? @andrew maybe you know it?

Previously I thought you already played with some other tool, Redmine,
no? Could you refresh my mind, and why it was not good?

I only know openproject from the time it was still an app, some years ago.
If the focus is on real timelines, then I don't think it is needed to
have this kind of tools. What we'd need IMHO is to be able to define
the upcoming release(s) and their scope. A tool like trac can do that,
e.g.
https://trac.edgewall.org/roadmap
Trac also has a wiki and issue system, so would mean that together
with OOK we could move away from bitbucket.

There is also Taiga.io (https://taiga.io/). I think I recall Andrew
playing with that one. I watched the video and looks possible useful
to us too.

If the tool needs to be hosted by ourselves, I prefer it being on a
Conservancy server tied to the Kallithe project, rather than on a
server of one individual. I also think we should discuss officializing
the Jenkins jobs you are running in such a way.