Re: The future of this project

[Thomas De Schampheleire]

Hi Dominik, Mads, all,

2017-06-19 8:45 GMT+02:00 Dominik Ruf :
>
>
> Mads Kiilerich  schrieb am Do., 15. Juni 2017 um 03:32
> Uhr:
>>
>> On 06/12/2017 05:41 PM, Dominik Ruf wrote:
>> > Hello everyone,
>> >
>> > this mail is overdue, but I always hoped it would get better. :-/
>> > I know this is a community project and we all have other
>> > responsibilities. So I understand that a request does not get answered
>> > instantly.
>>
>> I understand and see your frustration.
>>
>> Not that it really answer your questions, but for what it's worth, some
>> comments to your examples:
>>
>> > But for example my pull requests about 'repository settings' is now
>> > literally waiting for YEARS.
>>
>> Yes. Also, the latest changesets in the PR still say WIP, suggesting
>> that it not really is considered ready yet. The previous iteration got
>> review feedback 2 weeks ago. I haven't had time to follow up on the
>> latest one, having spent time on ...
>
> Yes I got some feedback from a USER about the UI related (WIP) parts.
> And I'm thankful for that.
> It is WIP because I still got no feedback from any 'developer'.
> For the non-WIP parts I still got no review/feedback. And after 2 years
> 'I haven't had time...' is not longer a proper argument :-(

I think the main problem here is again the amount of active developers
with time to review.
In fact, I actually wanted this feature for a long time as well. I was
assuming too much that it would 'automatically' get in, which is also
wrong on my part.
I hope that in the long run, growing the community would help here.
In the short run, I will try to review your open changes and this way
hopefully help moving it forward.

>>
>>
>> > Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
>> > multiple times for some feedback, but since 2 MONTH I got nothing. I
>> > understand that reviewing takes time, but at least some kind of
>> > comment is not too much to ask.
>>
>> Bootstrap has been very hard to land. Mainly because my initial requests
>> for splitting things up with clean history so they were reviewable were
>> refused or ignored.
>
> And I said I will not do it because I consider it a colossal waist of time.
> You on the other hand never explained that you'll split it up anyway.

It's a sword cutting on two edges. I understand that it feels like a
waste of time. I have felt the same sometimes during the TurboGears2
changes. However, seeing the end result for those changes, I do agree
that it is much better now even though it took longer: the amount of
changes has been reduced because it turned out that some changes were
not actually needed, some things were done differently/simpler/better,
and in general I feel that we (myself, Mads, in general all of us)
understand the changes much better than if we'd just have pushed the
original commit with almost everything in it.

In any case, I do support fully the request that proposed changes are
reviewable. This typically means splitting up the change so that each
commit does one thing, and can be added independently of subsequent
commits.
I understand that in changes as big as bootstrap introduction this is
not trivial, but not impossible either.

>>
>> I have thus spent a lot of time trying to
>> extract/redo and land parts that I could review and so I knew what was
>> changed and why.
>
> And why the hell did you not rebase it properly after that?

I think it is worth having a discussion on this topic, but please
let's keep it civil.

Mads, can you explain your workflow in such case? Do you at some point
have a repo with the rebased version, or do you start from a clean
one, and cherry-pick individual commits from the PR ?
In the former case we could share that result to alleviate the work of
the submitter, but in the latter case it is not necessarily logical to
expect the maintainer to do such rebase.


>>
>> The latest iteration of the Bootstrap PR is much better
>> and we are making progress - thanks!
>>
>> > And some pull request like 'catch MemoryErrors when calling git diff'
>> > are really trivial.
>>
>> Unfortunately, I also have the feeling that the approach in that PR is
>> wrong.
>
> Then why the hell did you not say so?

As I wrote in my earlier mail, I think more explicit communication
will help here.

>>
>> If we push the system so much that we get MemoryErrors, the
>> system might start swapping and other things might fail too. Instead, we
>> should make sure we don't use crazy amounts of memory but fail
>> gracefully.
>
> I don't think that is possible with the way we use git at the moment.
> But that discussion belongs in the PR. So add a comment to the PR already.
>>
>> But I haven't had time to investigate and propose a better
>> solution.
>
> 'A bird in the hand is worth two in the bush.'
> So even though there is a bigger problem we need to solve in the FUTURE,
> why the hell can we not solve a small part of the problem NOW?

Not neglecting 

Re: The future of this project

[Dominik Ruf]

Mads Kiilerich  schrieb am Do., 15. Juni 2017 um
03:32 Uhr:

> On 06/12/2017 05:41 PM, Dominik Ruf wrote:
> > Hello everyone,
> >
> > this mail is overdue, but I always hoped it would get better. :-/
> > I know this is a community project and we all have other
> > responsibilities. So I understand that a request does not get answered
> > instantly.
>
> I understand and see your frustration.
>
> Not that it really answer your questions, but for what it's worth, some
> comments to your examples:
>
> > But for example my pull requests about 'repository settings' is now
> > literally waiting for YEARS.
>
> Yes. Also, the latest changesets in the PR still say WIP, suggesting
> that it not really is considered ready yet. The previous iteration got
> review feedback 2 weeks ago. I haven't had time to follow up on the
> latest one, having spent time on ...
>
Yes I got some feedback from a USER about the UI related (WIP) parts.
And I'm thankful for that.
It is WIP because I still got no feedback from any 'developer'.
For the non-WIP parts I still got no review/feedback. And after 2 years
'I haven't had time...' is not longer a proper argument :-(

>
> > Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
> > multiple times for some feedback, but since 2 MONTH I got nothing. I
> > understand that reviewing takes time, but at least some kind of
> > comment is not too much to ask.
>
> Bootstrap has been very hard to land. Mainly because my initial requests
> for splitting things up with clean history so they were reviewable were
> refused or ignored.

And I said I will not do it because I consider it a colossal waist of time.
You on the other hand never explained that you'll split it up anyway.

> I have thus spent a lot of time trying to
> extract/redo and land parts that I could review and so I knew what was
> changed and why.

And why the hell did you not rebase it properly after that?

> The latest iteration of the Bootstrap PR is much better
> and we are making progress - thanks!
>
> > And some pull request like 'catch MemoryErrors when calling git diff'
> > are really trivial.
>
> Unfortunately, I also have the feeling that the approach in that PR is
> wrong.

Then why the hell did you not say so?

> If we push the system so much that we get MemoryErrors, the
> system might start swapping and other things might fail too. Instead, we
> should make sure we don't use crazy amounts of memory but fail
> gracefully.

I don't think that is possible with the way we use git at the moment.
But that discussion belongs in the PR. So add a comment to the PR already.

> But I haven't had time to investigate and propose a better
> solution.
>
'A bird in the hand is worth two in the bush.

'
So even though there is a bigger problem we need to solve in the FUTURE,
why the hell can we not solve a small part of the problem NOW?

>
> > This can not continue in this way. This project is now almost 3 years
> > old and we have very little to show for ourselves. In fact there were
> > questions if this project is actually alive (can't find the link right
> > now). And I can't blame anybody to think so. Kallithea has improved
> > very little. Version 0.3 is 20 month ago.
> >
> > So my questions to you guys is this:
> > What are your future plans for this project?
>
> My plan is to keep improving it, as contributions, time and priorities
> allow it.
>
> > Are there any chances that this project will start moving more quickly?
>
> Yes, if more people help by adding more resources and by helping us
> utilize resources better.
>
> Contributors can help reviewing, testing and improving contributions
> from others to the point where they are willing to put it in production
> right away and support it long term.
>
> Code contributors can also help by following the contributor guidelines
> and structure the code changes in such a way that they are easy to
> review and maintain.
>
> /Mads
>
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Thomas De Schampheleire]

Hi all,

2017-06-15 3:32 GMT+02:00 Mads Kiilerich :
> On 06/12/2017 05:41 PM, Dominik Ruf wrote:
>>
>> Hello everyone,
>>
>> this mail is overdue, but I always hoped it would get better. :-/
>> I know this is a community project and we all have other responsibilities.
>> So I understand that a request does not get answered instantly.
>
>
> I understand and see your frustration.
>
> Not that it really answer your questions, but for what it's worth, some
> comments to your examples:
>
>> But for example my pull requests about 'repository settings' is now
>> literally waiting for YEARS.
>
>
> Yes. Also, the latest changesets in the PR still say WIP, suggesting that it
> not really is considered ready yet. The previous iteration got review
> feedback 2 weeks ago. I haven't had time to follow up on the latest one,
> having spent time on ...
>
>> Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
>> multiple times for some feedback, but since 2 MONTH I got nothing. I
>> understand that reviewing takes time, but at least some kind of comment is
>> not too much to ask.
>
>
> Bootstrap has been very hard to land. Mainly because my initial requests for
> splitting things up with clean history so they were reviewable were refused
> or ignored. I have thus spent a lot of time trying to extract/redo and land
> parts that I could review and so I knew what was changed and why. The latest
> iteration of the Bootstrap PR is much better and we are making progress -
> thanks!
>
>> And some pull request like 'catch MemoryErrors when calling git diff' are
>> really trivial.
>
>
> Unfortunately, I also have the feeling that the approach in that PR is
> wrong. If we push the system so much that we get MemoryErrors, the system
> might start swapping and other things might fail too. Instead, we should
> make sure we don't use crazy amounts of memory but fail gracefully. But I
> haven't had time to investigate and propose a better solution.
>
>> This can not continue in this way. This project is now almost 3 years old
>> and we have very little to show for ourselves. In fact there were questions
>> if this project is actually alive (can't find the link right now). And I
>> can't blame anybody to think so. Kallithea has improved very little. Version
>> 0.3 is 20 month ago.
>>
>> So my questions to you guys is this:
>> What are your future plans for this project?
>
>
> My plan is to keep improving it, as contributions, time and priorities allow
> it.
>
>> Are there any chances that this project will start moving more quickly?
>
>
> Yes, if more people help by adding more resources and by helping us utilize
> resources better.
>
> Contributors can help reviewing, testing and improving contributions from
> others to the point where they are willing to put it in production right
> away and support it long term.
>
> Code contributors can also help by following the contributor guidelines and
> structure the code changes in such a way that they are easy to review and
> maintain.

Mads,
Thanks for sharing your view.
I think one 'quick win' would be if you could communicate more
explicitly on some matters. For example, if someone sent changes and
you are looking at them, possible reworking things, or testing it out,
then it would be helpful if you'd just reply with that fact. Then the
submitter is aware of it, and is not left in the blue.
Also, if you do not agree with a certain change or an entire PR, and
think it needs to be reworked in such or such way, or you're expecting
this or that before it can be merged, explicit (always polite of
course :-) ) communication could perhaps reduce some frustration about
seemingly 'ignored' changes.

Dominik,
Again thanks for bringing up this topic. I think we need to talk about
this and try to improve.
I hope it's not too late and we can still convince you to continue
contributing in this community.
As I said, I really value your contribution in the different areas you
attacked, be it testing, styling, bug fixes, functionality ... Due to
lack of time, I have not reviewed most of your changes, although I
realize that such peer review could help the changes moving forward.



A recurring factor in the discussion is the benefit of growing the
community: more developers means more mutual review and more bandwidth
to add new features or fix bugs. While there is no magic to do that,
there are definitely things that we could do.
For example:
- expanding the user base will eventually lead to more developers, as
users really are just potential developers. To do that:
  a. we should focus on adding important features (like SSH support)
above other improvements
  b. we should consider promoting Kallithea in a more active manner on
selected channels
  c. we should make frequent releases and use 1.0+ release numbers to
indicate the project is mature and active

- marking/tagging certain issues/features as 'easy' or 'for newcomers'
helps onboard new developers
- ...
There are 

Re: The future of this project

[Mads Kiilerich]

You consistently fail to mention that your project isn't a real open 
source project, but (in best case) a commercial company that just makes 
a part of your product available under a "open source" license. But you 
also sell a non-AGPL edition, meaning that all contributors must sign a 
CLA that grant your company a license to use all contributions under the 
MIT license, without giving contributors the option of using their own 
contribution under the same MIT license (or even GPL). The AGPL license 
is often problematic to use in companies, so contributors might need a 
commercial license to use their own contribution. So, you basically want 
us to work for you for free ... and pay for it. That could perhaps be OK 
if you were honest about it, but now it just looks like we still can't 
trust you.


Also, knowing the history of your product, I wouldn't dare to be 
associated with (or use) your GPL-incompatible product. AFAIK, you 
stripped development history from all the public repositories, so we 
can't know if you really own or have permission from all copyright 
holders to use their contributions under the GPL-incompatible license. I 
understand your architecture has a separate GPL server process to work 
around the incompatibility between GPL Mercurial and your 
GPL-incompatible product. The validity of that approach is also highly 
questionable. I suggest all users of the GPL-incompatible product do 
thorough investigation and consult a lawyer.


If you say that close sourcing was a big mistake and you learned 
anything, then you totally have the option of undoing it by dropping the 
CLA and taking the product back to GPL. That would re-enable the 
co-operation with the GPL community that you broke. If not, it just 
sounds like marketing BS to please this audience.


But sure, a free and open community project around an AGPL non-CLA fork 
of your codebase could also work ... assuming you really have a full 
product available under AGPL. Anybody could do that ... and they could 
continue to take changes from your AGPL version, while you couldn't take 
anything back to the GPL-incompatible version. That would also test 
whether you still will send DMCA takedown notices to forks, as you have 
done in the past. That is however not something I want to get involved 
in. Also because I find AGPL very problematic and uninteresting in general.


Finally, I find it very rude and clueless that you post your marketing 
blurb here on this list, and again try to recruit users and contributors 
from our community to your company. Do you want us to do the same?


/Mads
Kallithea contributor,
not a lawyer,
not talking for anyone


On 06/13/2017 10:04 AM, Marcin Kuźmiński wrote:

Hi All,

Given the opportunity of this email thread, i'd like to pitch in the 
open-source version of RhodeCode CE again.


- A fully functional, free AGPL v3.0 software
- based on a modern web framework - Pyramid
- we had almost 20 releases in last 12 months
- introduced major features like Git LFS, Mercurial Evolve
- per repo settings
- web mergeable pull requests
- integration framework
- and many more
- a quickly growing community use base we currently have over 170 
people on our community slack channel.


As a part of Management team i must admit that close sourcing the 
project was a big mistake, however, we learned our lesson, and bet on 
the new business model that is based on OpenSource Core and RhodeCode 
will have a CE free edition.


We talked a bit about some co-operation, and i believe it's a good 
time to re-think this. I'll be blunt, i think that it doesn't look 
like there a sense of two such similar open-source projects to exist.


I highly valued contribution from this community that was done into 
the RhodeCode codebase, i invite everyone again to join and have an 
influence on the tool you or your company is using regularly.


Happy to chat about any options again, if someone is interested.

Best,


___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Mads Kiilerich]

On 06/12/2017 05:41 PM, Dominik Ruf wrote:

Hello everyone,

this mail is overdue, but I always hoped it would get better. :-/
I know this is a community project and we all have other 
responsibilities. So I understand that a request does not get answered 
instantly.


I understand and see your frustration.

Not that it really answer your questions, but for what it's worth, some 
comments to your examples:


But for example my pull requests about 'repository settings' is now 
literally waiting for YEARS.


Yes. Also, the latest changesets in the PR still say WIP, suggesting 
that it not really is considered ready yet. The previous iteration got 
review feedback 2 weeks ago. I haven't had time to follow up on the 
latest one, having spent time on ...


Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked 
multiple times for some feedback, but since 2 MONTH I got nothing. I 
understand that reviewing takes time, but at least some kind of 
comment is not too much to ask.


Bootstrap has been very hard to land. Mainly because my initial requests 
for splitting things up with clean history so they were reviewable were 
refused or ignored. I have thus spent a lot of time trying to 
extract/redo and land parts that I could review and so I knew what was 
changed and why. The latest iteration of the Bootstrap PR is much better 
and we are making progress - thanks!


And some pull request like 'catch MemoryErrors when calling git diff' 
are really trivial.


Unfortunately, I also have the feeling that the approach in that PR is 
wrong. If we push the system so much that we get MemoryErrors, the 
system might start swapping and other things might fail too. Instead, we 
should make sure we don't use crazy amounts of memory but fail 
gracefully. But I haven't had time to investigate and propose a better 
solution.


This can not continue in this way. This project is now almost 3 years 
old and we have very little to show for ourselves. In fact there were 
questions if this project is actually alive (can't find the link right 
now). And I can't blame anybody to think so. Kallithea has improved 
very little. Version 0.3 is 20 month ago.


So my questions to you guys is this:
What are your future plans for this project?


My plan is to keep improving it, as contributions, time and priorities 
allow it.



Are there any chances that this project will start moving more quickly?


Yes, if more people help by adding more resources and by helping us 
utilize resources better.


Contributors can help reviewing, testing and improving contributions 
from others to the point where they are willing to put it in production 
right away and support it long term.


Code contributors can also help by following the contributor guidelines 
and structure the code changes in such a way that they are easy to 
review and maintain.


/Mads

___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Marcin Kuźmiński]

Hi Andrew,

There have been many efforts to create this project. However, because it's
a RhodeCode based project I'm following
it closely. I must say that for me this project looks quite dead. We have
more and more users moving from Kallithea to RhodeCode, strictly because
really no new relevant features are developed.
And I understand it, RhodeCode had so much legacy stuff cleaning things up
took us many many months...
No company will bet on Kallithea seeing such stale state. There are lots of
FOSS project now doing source code management and they are very active.

For me personally contributing to open source projects is something more
than helping the maintainers to move the project forward. We have the
capacity inside the company to produce regular releases, however
community driven contributions often improve things around the project. One
of the goals of a project such as RhodeCode is to help Mercurial be
relevant because of great tooling around that project.

No one can guarantee that OpenSource project will stay, because a lot of
things can happen.
Currently, there's AGPL version, one can fork it and move it forward if
you're unhappy about people behind it. Just look what happened with
Gogs/Gitea.

>From my perspecitve, there's close to 0% chance for RhodeCode beeing merged
with Kallithea, because of our Brand, and simply at this point those are
two VERY different projects
written in two incompatible web frameworks. We provide infrastructure and
installer for RhodeCode cannot imagine re-implementing it for another
project (just too much effort)

I'm absolutely open to discussing RhodeCode to join and help the community,
however the state of Kallithea as community project doesn't look promising.
And honestly, from my observation the main driver behind developing new
feature of it were from one very big commercial company :)

If someone has better alternative we're open for discussion, i think we
want to have the BEST possible project that support Mercurial.

Best,


On 13 June 2017 at 12:30, Andrew Shadura  wrote:

> On 13/06/17 10:04, Marcin Kuźmiński wrote:
> > Hi All,
> >
> > Given the opportunity of this email thread, i'd like to pitch in the
> > open-source version of RhodeCode CE again.
> >
> > - A fully functional, free AGPL v3.0 software
> > - based on a modern web framework - Pyramid
> > - we had almost 20 releases in last 12 months
> > - introduced major features like Git LFS, Mercurial Evolve
> > - per repo settings
> > - web mergeable pull requests
> > - integration framework
> > - and many more
> > - a quickly growing community use base we currently have over 170 people
> > on our community slack channel.
> >
> > As a part of Management team i must admit that close sourcing the
> > project was a big mistake, however, we learned our lesson, and bet on
> > the new business model that is based on OpenSource Core and RhodeCode
> > will have a CE free edition.
> >
> > We talked a bit about some co-operation, and i believe it's a good time
> > to re-think this. I'll be blunt, i think that it doesn't look like there
> > a sense of two such similar open-source projects to exist.
> >
> > I highly valued contribution from this community that was done into the
> > RhodeCode codebase, i invite everyone again to join and have an
> > influence on the tool you or your company is using regularly.
> >
> > Happy to chat about any options again, if someone is interested.
>
> This is very nice of you Marcin, but honestly I'm struggling to imagine
> how is going to work. Are you suggesting we abandon Kallithea and all
> hard work we’ve done and just go help develop RhodeCode? Yes, there
> seems to be a lot of development in RhodeCode, but is there really a big
> community around it? From the Mercurial log it looks more like a single
> person project (while certainly you do a lot of work!). What if
> something happens to the company again?
>
> I understand how you feel about the project you started, but I don't
> think it is the best idea to join to projects by abandoning one
> developed by the community. It would be much better if the company could
> become a member of the community instead.
>
> I'm not saying "no, we don't want to work with you", not at all. What
> I'm saying if we want to work together, we need a better plan.
>
> --
> Cheers,
>   Andrew
> ___
> kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Dominik Ruf]

Andrew Shadura  schrieb am Di., 13. Juni 2017 um
12:30 Uhr:

> On 13/06/17 10:04, Marcin Kuźmiński wrote:
> > Hi All,
> >
> > Given the opportunity of this email thread, i'd like to pitch in the
> > open-source version of RhodeCode CE again.
> >
> > - A fully functional, free AGPL v3.0 software
> > - based on a modern web framework - Pyramid
> > - we had almost 20 releases in last 12 months
> > - introduced major features like Git LFS, Mercurial Evolve
> > - per repo settings
> > - web mergeable pull requests
> > - integration framework
> > - and many more
> > - a quickly growing community use base we currently have over 170 people
> > on our community slack channel.
> >
> > As a part of Management team i must admit that close sourcing the
> > project was a big mistake, however, we learned our lesson, and bet on
> > the new business model that is based on OpenSource Core and RhodeCode
> > will have a CE free edition.
> >
> > We talked a bit about some co-operation, and i believe it's a good time
> > to re-think this. I'll be blunt, i think that it doesn't look like there
> > a sense of two such similar open-source projects to exist.
> >
> > I highly valued contribution from this community that was done into the
> > RhodeCode codebase, i invite everyone again to join and have an
> > influence on the tool you or your company is using regularly.
> >
> > Happy to chat about any options again, if someone is interested.
>
> This is very nice of you Marcin, but honestly I'm struggling to imagine
> how is going to work. Are you suggesting we abandon Kallithea and all
> hard work we’ve done and just go help develop RhodeCode? Yes, there
> seems to be a lot of development in RhodeCode, but is there really a big
> community around it? From the Mercurial log it looks more like a single
> person project (while certainly you do a lot of work!). What if
> something happens to the company again?
>
I for one am actually considering going back to RhodeCode. I already
thought about this before Marcin answered to the mail. But it is a big step
and I have not made up my mind yet. I'll have to take a closer look a the
current state of the RhodeCode project.

Sure it hurts to give up all the work, but like I already said I done feel
like we have accomplished that much. So there is not that much that will
actually be lost (except my pride).

>
> I understand how you feel about the project you started, but I don't
> think it is the best idea to join to projects by abandoning one
> developed by the community. It would be much better if the company could
> become a member of the community instead.
>
> I'm not saying "no, we don't want to work with you", not at all. What
> I'm saying if we want to work together, we need a better plan.
>
> --
> Cheers,
>   Andrew
> ___
> kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Andrew Shadura]

On 13/06/17 10:04, Marcin Kuźmiński wrote:
> Hi All,
> 
> Given the opportunity of this email thread, i'd like to pitch in the
> open-source version of RhodeCode CE again.
> 
> - A fully functional, free AGPL v3.0 software
> - based on a modern web framework - Pyramid
> - we had almost 20 releases in last 12 months
> - introduced major features like Git LFS, Mercurial Evolve
> - per repo settings
> - web mergeable pull requests
> - integration framework
> - and many more
> - a quickly growing community use base we currently have over 170 people
> on our community slack channel.
> 
> As a part of Management team i must admit that close sourcing the
> project was a big mistake, however, we learned our lesson, and bet on
> the new business model that is based on OpenSource Core and RhodeCode
> will have a CE free edition. 
> 
> We talked a bit about some co-operation, and i believe it's a good time
> to re-think this. I'll be blunt, i think that it doesn't look like there
> a sense of two such similar open-source projects to exist.
> 
> I highly valued contribution from this community that was done into the
> RhodeCode codebase, i invite everyone again to join and have an
> influence on the tool you or your company is using regularly.
> 
> Happy to chat about any options again, if someone is interested.

This is very nice of you Marcin, but honestly I'm struggling to imagine
how is going to work. Are you suggesting we abandon Kallithea and all
hard work we’ve done and just go help develop RhodeCode? Yes, there
seems to be a lot of development in RhodeCode, but is there really a big
community around it? From the Mercurial log it looks more like a single
person project (while certainly you do a lot of work!). What if
something happens to the company again?

I understand how you feel about the project you started, but I don't
think it is the best idea to join to projects by abandoning one
developed by the community. It would be much better if the company could
become a member of the community instead.

I'm not saying "no, we don't want to work with you", not at all. What
I'm saying if we want to work together, we need a better plan.

-- 
Cheers,
  Andrew
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Marcin Kuźmiński]

Hi All,

Given the opportunity of this email thread, i'd like to pitch in the
open-source version of RhodeCode CE again.

- A fully functional, free AGPL v3.0 software
- based on a modern web framework - Pyramid
- we had almost 20 releases in last 12 months
- introduced major features like Git LFS, Mercurial Evolve
- per repo settings
- web mergeable pull requests
- integration framework
- and many more
- a quickly growing community use base we currently have over 170 people on
our community slack channel.

As a part of Management team i must admit that close sourcing the project
was a big mistake, however, we learned our lesson, and bet on the new
business model that is based on OpenSource Core and RhodeCode will have a
CE free edition.

We talked a bit about some co-operation, and i believe it's a good time to
re-think this. I'll be blunt, i think that it doesn't look like there a
sense of two such similar open-source projects to exist.

I highly valued contribution from this community that was done into the
RhodeCode codebase, i invite everyone again to join and have an influence
on the tool you or your company is using regularly.

Happy to chat about any options again, if someone is interested.

Best,

On 12 June 2017 at 17:41, Dominik Ruf  wrote:

> Hello everyone,
>
> this mail is overdue, but I always hoped it would get better. :-/
> I know this is a community project and we all have other responsibilities.
> So I understand that a request does not get answered instantly.
> But for example my pull requests about 'repository settings' is now
> literally waiting for YEARS.
> Or lately my 'Port Kallithea theme to Bootstrap' pull request. I asked
> multiple times for some feedback, but since 2 MONTH I got nothing. I
> understand that reviewing takes time, but at least some kind of comment is
> not too much to ask. And some pull request like 'catch MemoryErrors when
> calling git diff' are really trivial.
> This can not continue in this way. This project is now almost 3 years old
> and we have very little to show for ourselves. In fact there were questions
> if this project is actually alive (can't find the link right now). And I
> can't blame anybody to think so. Kallithea has improved very little.
> Version 0.3 is 20 month ago.
>
> So my questions to you guys is this:
> What are your future plans for this project?
> Are there any chances that this project will start moving more quickly?
> If not, I believe it has no real future. :-(
> Which would be a shame. I have quite a few ideas for it and think it
> really has potential.
>
> cheers
> Dominik
>
> ___
> kallithea-general mailing list
> kallithea-general@sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
>
___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general

Re: The future of this project

[Long Vu]

On Mon, Jun 12, 2017 at 4:21 PM, Andrew Shadura  wrote:
> Hi Dominik,
>
> Thanks for this mail. This is something I've been thinking about too.
>
> On 12/06/17 17:41, Dominik Ruf wrote:
>
> Debian is now looking for a replacement for Alioth, which currently runs
> FusionForge. The replacement has to support SSH, which — with us not
> having merged the SSH support — immediately makes us worse than the
> alternatives, even though we have a benefit of also supporting Mercurial
> and having nice review tools. It's a shame, as being used by Debian
> could bring new contributors and breath new life into the project.
>

There is a PR for SSH support
https://bitbucket.org/conservancy/kallithea/pull-requests/311/ssh-v8/diff

I also would like ssh support.

>> This can not continue in this way. This project is now almost 3 years
>> old and we have very little to show for ourselves. In fact there were
>> questions if this project is actually alive (can't find the link right
>> now). And I can't blame anybody to think so. Kallithea has improved very
>> little. Version 0.3 is 20 month ago.
>
>> So my questions to you guys is this:
>> What are your future plans for this project?
>> Are there any chances that this project will start moving more quickly?
>> If not, I believe it has no real future. :-(
>> Which would be a shame. I have quite a few ideas for it and think it
>> really has potential.

With, git, there's gitlab that can be self-hosted.  With mercurial ...
Kallithea is the only choice (am I wrong)?

So Kallithea has great potential.  gitlab has no mercurial support
while Kallithea does !  Another bonus right here.

I've tried submitting PR before but due to my unfamiliarity with the
code, it's slow for me to incorporate review feedback (I have 1 PR
waiting for me to incorporate feedback ... since more than a year).

But I can volunteer to test.


-- 
Long Vu | Build Controller | Intelerad | +1-514-931-6222 ext. 7743

-- 

This email or any attachments may contain confidential or legally 
privileged information intended for the sole use of the addressees. Any 
use, redistribution, disclosure, or reproduction of this information, 
except as intended, is prohibited. If you received this email in error, 
please notify the sender and remove all copies of the message, including 
any attachments.

___
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general