What should be included in 1.0

[Dominik Ruf]

Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Mo., 12.
März 2018 um 20:37 Uhr:

> 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 heavy lifting is already done and if we put our minds to it, I truly
believe we could deliver ssh support in less then a month.

>
> 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.
>
My PR allows general repository settings, but I think the most important
one is the hooks.

>
> 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?
>
(That is why I don't like (mailman) mailing lists, there is no way to
search the archive.)
I only took a quick look at Redmine. I did like its UI (I think
its anachronistic) and some plugins I'd like to use were commercial.


> 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.
>
I haven't looked a trac in a long time, but I though its UI is
anachronistic as well and its functionality is very basic.

That said, I think redmine or trac would still be an improvement to what we
have now.

>
> 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.
>
I also played with taiga.io. I can't point the finger at it, but I didn't
like its design and generally didn't like to work with it.

>
> 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.
>
Yes, it definitely should be hosted on a Conservancy server.
I'd be happy if we would run a jenkins on a Conservancy server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20180313/16bdecf7/attachment.html>