<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Thomas De Schampheleire <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> schrieb am Mo., 12. März 2018 um 20:37 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-03-12 18:54 GMT+01:00 Dominik Ruf <<a href="mailto:dominikruf@gmail.com" target="_blank">dominikruf@gmail.com</a>>:<br>
> Hi all,<br>
><br>
> we discussed in the past that we are long over due to release a new version.<br>
> We also agreed that we should strongly push towards a 1.0 release.<br>
> Since this may attract new users, I think we should carefully think about<br>
> what should be included in this release. There is only one chance for a<br>
> first impression.<br>
><br>
> These are the things, I believe, the users will expect and therefore should<br>
> be included in the 1.0 release.<br>
><br>
> 1. attractive UI<br>
> We are not there yet, but close(r)<br>
> 2. ssh support<br>
> There is an old PR for this. I made some fixes and started to and some<br>
> tests. I'll create a PR soon.<br>
<br>
I have also thought that this is something that users will expect. On<br>
the other hand, since this is a big item, this means that 1.0 will<br>
take some time after 0.9 before being ready.<br></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other approach is to already do 1.0 without ssh support and<br>
announcing that SSH support is coming in a next release.<br>
<br>
<br>
> 3. manage hooks (incl. custom hooks) on a repository and repository group<br>
> bases<br>
> I have an old PR about this as well.<br>
<br>
More generally, allowing certain settings per repository and per<br>
repository group.<br></blockquote><div>My PR allows general repository settings, but I think the most important one is the hooks. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I need to think what else we definitely would need...<br>
<br>
><br>
> P.S.: Like I mentioned before, I think we should use a proper project<br>
> management tool, to keep track of things like this. Since you guys don't<br>
> like JIRA, because it is not open source, does somebody know<br>
> <a href="https://www.openproject.org" rel="noreferrer" target="_blank">https://www.openproject.org</a>? @andrew maybe you know it?<br>
<br>
Previously I thought you already played with some other tool, Redmine,<br>
no? Could you refresh my mind, and why it was not good?<br></blockquote><div>(That is why I don't like (mailman) mailing lists, there is no way to search the archive.)</div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I only know openproject from the time it was still an app, some years ago.<br>
If the focus is on real timelines, then I don't think it is needed to<br>
have this kind of tools. What we'd need IMHO is to be able to define<br>
the upcoming release(s) and their scope. A tool like trac can do that,<br>
e.g.<br>
<a href="https://trac.edgewall.org/roadmap" rel="noreferrer" target="_blank">https://trac.edgewall.org/roadmap</a><br>
Trac also has a wiki and issue system, so would mean that together<br>
with OOK we could move away from bitbucket.<br></blockquote><div>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.</div><div><br></div><div>That said, I think redmine or trac would still be an improvement to what we have now.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There is also Taiga.io (<a href="https://taiga.io/" rel="noreferrer" target="_blank">https://taiga.io/</a>). I think I recall Andrew<br>
playing with that one. I watched the video and looks possible useful<br>
to us too.<br></blockquote><div>I also played with <a href="http://taiga.io">taiga.io</a>. I can't point the finger at it, but I didn't like its design and generally didn't like to work with it. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If the tool needs to be hosted by ourselves, I prefer it being on a<br>
Conservancy server tied to the Kallithe project, rather than on a<br>
server of one individual. I also think we should discuss officializing<br>
the Jenkins jobs you are running in such a way.<br></blockquote><div>Yes, it definitely should be hosted on a Conservancy server.</div><div>I'd be happy if we would run a jenkins on a Conservancy server.</div></div></div>