djowel
commented
6 years ago Very good points!
Closed octopus-prime closed 6 years ago
djowel
commented
6 years ago Very good points!
Kojoley
commented
6 years ago Mike, these are strong word and I support them, but I do not see redundant work, about a month ago Spirit was in semi-abandoned state and had several major problems that now fixed. What about merges without review, I also consider them bad, but on the projects where are a lot of active members. From my experience on matplotlib, where we have ~5-10 active people, it is hard to acquire even a single review so some PRs dangle for months.
octopus-prime
commented
6 years ago I like open source and i like spirit very much... But I think I should leave this team until you get teamwork running again.
I remember the good old days, where discussions in issues and PRs were normal.
See #169, #170, #175 ...
There was good teamwork - fertile and productive.
Good luck, Nikita
djowel
commented
6 years ago @octopus-prime, @Kojoley, I re-opened this because I think this is important. I value discussion and I want to have Spirit back on track. I also value @Kojoley's and @octopus-prime's work. Those are steps in the right direction. But I agree with @octopus-prime that we should discuss more before we merge, especially bigger issues. On the other hand, I do not wish to be too bureaucratic so I allowed small, simple fixes to go through quickly. Small issues, such as warning suppressions, for example. I guess it was not clear how "small" is defined. Please, let us discuss.
BTW, @octopus-prime, I'd like to give you write permission.
Kojoley
commented
6 years ago @djowel I want really to hear what I did wrong. If I understand Mike right, he went to his 'bye' post because I have merged the #291. To be clear, as you remember, I gave my agree to become a maintainer to setup all the CI system, and made all the fixed to done it. I may just spend my time on the other project if Mike want to jump in and continue or if you think I merged something that I should not have been.
djowel
commented
6 years ago @Kojoley, As I said, we need consensus on anything beyond simple PRs. What constitutes "simple" is vague, I guess and we need to have clear rules for that and so I think this is the main point of this issue. There has to be a balance in between. I would like to build a team, but OTOH, I don't want to be too bureaucratic.
djowel
commented
6 years ago Gentlemen, I value your contributions very much. This thread may a bit too blunt, @octopus-prime, but I want to look beyond that. We need to find the right balance to make this work.
Kojoley
commented
6 years ago I feel guilty and pressure. I still do not understand was I am not right to self-merge #291. What about consensus, there are already 20+ PRs without it and counting.
djowel
commented
6 years ago @Kojoley, yes there are. I am not sure what's with #291 to be honest. @octopus-prime, could you please kindly elaborate? If I am not mistaken, there were comments that were left unanswered? It's easy to miss, it seems.
Kojoley
commented
6 years ago See how it looks from my perspective: I spend more than a month fixing the things to get tests work and setup the CI, in the very end I got abused by talking that I am doing the things wrong without actually clarifying what exactly.
djowel
commented
6 years ago I understand, @Kojoley. That said, however blunt, I think it's directed towards the team as a whole, not a single individual. And I am to blame if the team is not meshing well. I hope we can be constructive and work this out.
djowel
commented
6 years ago BTW, on a constructive note, we (Boost) uses the Trac system for tickets. Perhaps we can look into the current status of that.
octopus-prime
commented
6 years ago I feel guilty and pressure
That was not my purpose.
I may just spend my time on the other project if Mike want to jump in and continue
Nope. Joel want a team. I want a team. So we want you!
there are already 20+ PRs without it and counting
boost says "peer reviewed". i want to make "peer reviewed" great again. Are reviews evil? Is communication evil? In my opinion the reviews are good. They lead to better understanding of the team and better solutions.
I gave my agree to become a maintainer to setup all the CI system
Where people can know from? Let's have a look at #251. No assignee. No WIP. So other people start to work at same story - redundant and useless.
There are some other missed tests. I did not catch up all of them, it is a part of the other PR.
I don't understand why to kick tests? No explanation. So I asked:
Which other PR? Is there a ticket for adding kicked tests again - containing a list of kicked test to add later again? Big chance to forget/miss some of the kicked tests...
No reply.
Nikita did work alone for some time. Now we could have a team. This brings change.
The question is: Are all willing to work as team - or should one do all the stuff alone.
djowel
commented
6 years ago The question is: Are all willing to work as team - or should one do all the stuff alone.
Let us work as a team. Let's do it right.
octopus-prime
commented
6 years ago I would like to know about
One wasted weekend for me (working on CI integration) should be enough.
Kojoley
commented
6 years ago Mike, look, you jumped out on me demanding things. I have not been asked am I agree or not to play in the sandbox by your rules.
So other people start to work at same story - redundant and useless.
Best things were invented twice or even more times. You bring the solution, time decides which one is the best.
I don't understand why to kick tests?
I did not kick the tests, I have reapplied previous PR, this test was missed. But you have made the show out of it.
No explanation. So I asked: Which other PR?
Was it so hard to open a PR with the test added? No, but you did not, just got your rant on me. Escalating to this discussion, spending time the participants time in it.
One wasted weekend for me (working on CI integration) should be enough.
You saw my PR (it was actually done a year ago, but you have not read the discussion, once again), then you spend the weekend doing something that makes only a small subset of it, now you blame me. Nice job.
octopus-prime
commented
6 years ago You bring the solution, time decides which one is the best.
Nope. Your write access and self-merge technique decided which one is the "best". In my opinion a mixture of both would be the best. But you ignored my PR...
I did not kick the tests, I have reapplied previous PR, this test was missed. But you have made the show out of it.
Why we can discuss now - after escalation? We should discuss in review...
Was it so hard to open a PR with the test added? No, but you did not, just got your rant on me.
I did one PR and wasted time... I don't know your plans. Do YOU want to add the missing tests again, or not?! How can I know? There is no communication/coordination.
You saw my PR
Nope - I would not start if i see that others are working on it... The wasted time hurts - but is not the major point. There were two solutions - one was ignored. No cherry pick - no discussion - only kicking tests....
djowel
commented
6 years ago OK, I think this is just a big misunderstanding. And so we need proper communication alright. It seems Github does not help in this case. I too sometimes miss relevant items. It's too easy to miss. Perhaps the mailing list is still the best way to have discussions that everyone can see.
djowel
commented
6 years ago I will make myself active again in the Spirit mailing list. I think it is the proper venue (still!) for collaborative work and discussion (https://sourceforge.net/projects/spirit/lists/spirit-general). There is actually a spirit-devel list, but I think it is best to have it all in only one list.
Please join the Spirit mailing list, if you haven't done so yet.
octopus-prime
commented
6 years ago In my opinion it's not the question of tools. Even mailing lists can be silent without communication. github provides issues/tickets like jira - so it's a good tool for overview, discussion and planning. for a good example of how to work with this issue system have a look at vinnie's issues (https://github.com/boostorg/beast/issues) All things to do are in the list. Discussions are in the issues and reviews.
djowel
commented
6 years ago @octopus-prime, TRAC is the ticketing system for Boost, not github. My problem is that there's a plethora of online "tools" available that it gets confusing. Honestly, I am confused with all the messages coming from everywhere. The mailing list has worked in the past and I do not see why it should not work again. You are correct to say that we need some rules and guidelines. The mailing list is the best way (still) for such conversations. That includes commit policies, for example. All devs should know what's happening.
Oh, and BTW, the ticketing system is orthogonal to the mailing list.
djowel
commented
6 years ago Update: @mjcaisse noted that several boost projects have moved to github issues. So, I'd agree we should move to that. TBH, I hated TRAC.
Anyway, that's still orthogonal to the mailing list.
djowel
commented
6 years ago 
fhein
commented
6 years ago I am not sure that it is appropriate to contribute to this discussion. The only thing I actually did was the ridiculous expect directive for qi. Anyway, here are my 5 cent:
More than a year ago I wanted to step in. I supplied said directive and suggested a ternary operator. I also pointed out, that the Spirit tests did not pass without errors for at least five years. And now: Open tickets in TRAC. Surprise!
My impression that time (2016 or 2015?) was that efforts going into x3 were appreciated, qi and karma seemed to be more or less a burdon from the past. No new features there, please.
This has dramatically changed since @Kojoley recently became a maintainer. Spirit's future at all seems to be vital and important again. As a massive user I highly appreciate that. As soon as @Kojolev entered the stage @octopus-prime followed. Appreciated as well. Those two seem to be the team (currently).
@Kojoley currently is on the fast track. Doing things on his own. Leaving the team behind, maybe, but (!) he is getting things done. Getting things done is important for me. I highly appreciate what he does. He get's things done for good, but he is taking a lot of risk on his own. @octopus-prime complains. He's right to some degree, I think.
Team work is important. Peer review is important. But from my experience as a company leader for the last 20 years I think it is not enough just to ask for team work. Someone, @djowel would be the choice at hand, should define what teamwork in this context particularily means. Someone should actively lead this team.
1) Who does what? (Self targeting?, Assigned? (by whom?)) Estimation when it will be done. 2) Who is to be informed? About what? What can one decide on his/her one, what not? What needs team leader attention, what needs team attention? Deadline important. Can one (@Kojoley) merge on his/her own, if team communication does not happen within x hours/days/weeks? 3) Who is going to review (test) a proposed solution? Assignment. Schedule. 4) Who is going to approve (and merge)? Who's taking responsibility? Assignment. Schedule.
It's very difficult to act as a team, if nobody takes responsibility to explain what in particular that means. Somebody, the team leader, HAS TO define policies, procedures, standards and guidelines. That's work and that needs time to spend.
I believe, @djowel would be the best choice because of his deep knowledge and tight connection to the project and it's intents. I hope, he has the time to be the backbone the team needs. But if not, I'd recommend to discuss who's taking over team leadership actively.
New Boost releases promise enhanced maturity, stability, blah ... to the user. The last five years or so the new releases of Boost meant nothing regarding Spirit. That's sad. And it says something about Boost QA (regarding Spirit at least). Without further explains the message is: I'm just a number, I don't mean anything. Nobody did anything. Good luck! I think, that's not enough. Boost's formalized QA is vulnerable. Lazyness is enough to out-lever the release regarding all those properties promised.
Ad hoc, l'd recommend: @octopus-prime gets write permission, @Kojoley and @octopus-prime negotiate what to do, involve each other for review, together decide on merge. If no consensus, @djowel gets involved. His decision is binding for both.
Regarding my business: I am in 'Good luck' mode mentioned above. As far as they pass my tests and I understand what's going on, I go with the latest merges. Boost Releases don't mean anything to Spirit (currently).
My deep respect for and recognition of the enthusiasm, heart, time and genius both @Kojoley and @octopus-prime put into Spirit currently. Please continue the way you do. There are people out there watching, awaiting, hoping and trusting in what you do. What you do actually helps in real life. Please don't stop.
Again, just my five cents. I sincerely apologize if not appropriate.
Please find an agreement how to organize team work so that things can continue to happen.
Frank
djowel
commented
6 years ago Very much appreciated, @fhein! We'll figure something out. I'll be giving it further thought in the coming days. For now, please keep it coming! I hope we can put this big misunderstanding behind us.
fhein
commented
6 years ago Open Source is an ongoing thing. Comes from the past and extends to the future (hopefully). Please do everything necessary to get this team on track and keep it on track. @Kojoley and @octopus-prime are a light in the darkness and a hint to the future of Spirit.
octopus-prime
commented
6 years ago Ad hoc, l'd recommend: @octopus-prime gets write permission, @Kojoley and @octopus-prime negotiate what to do, involve each other for review, together decide on merge. If no consensus, @djowel gets involved. His decision is binding for both.
Sounds like a really good plan.
djowel
commented
6 years ago write permission invitation on its way to @octopus-prime
octopus-prime
commented
6 years ago Thanks, Joel!
Kojoley
commented
6 years ago @fhein Thanks for comments, but @octopus-prime contribution is not that big https://github.com/boostorg/spirit/graphs/contributors. I still did not get the response what was wrong with the PR all this hell comes from. I am sorry but I do not bother with someone who does not read and demands me to explain the things already explained on the same or linked page, or whose comments so useful like "this yml file is a lot of boilerplate", or copy-pastes without understanding what he is doing, but rather haunts and insults me.
octopus-prime
commented
6 years ago In my opinion in this yml file is a lot of boilerplate to execute build jobs (e.g. sed into user-config.jam). Could be much easier?
Is something different than
this yml file is a lot of boilerplate
Who does not read?
octopus-prime
commented
6 years ago @jeking3 suggested to use tools/boostdep in my PR.
Something you never read, because you ignored my PR.
Who does not read?
Kojoley
commented
6 years ago Enough from me, I will not continue this discussion. I think you have got what you and this little holy war was your target. There is not point for me to waste my time arguing with you.
octopus-prime
commented
6 years ago But it's easy @Kojoley ... You wan't to work alone? You don't want to bother with me?! Take it!! Since my
contribution is not that big
hkaiser
commented
6 years ago Guys - open source isn't about figuring out who has the bigger one. You both want to contribute - so do it. There is no need for you to fight over a misunderstanding. Any contribution to a project is great, even if it's just a small one. Please don't get angry without reason - let's move on.
As a side note: in my experience, the github ticket system works very well and is much superior to trac. We use it for HPX on a daily (hourly) basis with excellent results. Things that can't be solved there are usually discussed on IRC and/or the mailing list.
So let's try to move the trac tickets over to github (I think I have a script somewhere that can be used for this) and try to put rivalries and bad blood behind.
Another thing I would like to suggest is to adopt a policy of behavior (some people call it code of conduct). Originally I thought that such a document is just silly because it mainly puts into words what's normally considered common sense. But I see now that it might help (see here for HPX's CoC: https://github.com/STEllAR-GROUP/hpx/blob/master/.github/CODE_OF_CONDUCT.md).
jeking3
commented
6 years ago @octopus-prime perhaps take a look at the work you did on travis as educational - my guess is you learned a thing or two along the way. Getting travis to work on a project takes time. It's obvious to me that @Kojoley was working on this for quite some time and quite frankly once I reviewed the new .travis.yml file I learned some new tricks myself, and would have (if I had a say) voted for that one because it is so easy to understand.
It would have been a good idea to know that this was being worked on, so that there was no duplication of effort. I think that's really how things started off badly. When a project does get into this state where the backlog is huge, sometimes you need to make things move along quickly. In order to drain the backlog one needs a proper CI environment and the priority on getting this done first, and appveyor second, and then requiring everyone to rebase thir pull requests to make sure they pass is a good path forward.
As for my comment, there's nothing wrong with checking out everything as the current .travis.yml is doing, however I think it would be easier (and more aligned to all the other project's use of travis) if we let travis pull the spirit repo, and then used an install script like the one in Boost.Uuid to make the dependency management automatic. The solution here is fine though - all the code will always be there. I think the current solution might take longer than what's used in other projects where only recursive dependencies are cloned local.
djowel
commented
6 years ago Gentlemen, if you can't resolve this misunderstanding, then it is NOT a good sign of things to come and this is probably NOT the team that Spirit needs. More contentious issues took place in the past and they were resolved with respect, kindness and understanding, true to the Spirit of Spirit. @octopus-prime, there is no place for harsh, blunt words here, but looking beyond the blunt words , you do have very good points and I was hoping that @Kojoley wouldn't just shrug everything off and take the message as a whole as an insult. Please do not let me choose between either of you. You both have done remarkable work and as @hkaiser said, it's not about figuring out who the bigger contributor is.
octopus-prime
commented
6 years ago I would like to apologise for my harsh and blunt words here. These words were inappropriate, careless and emotional.
I think Nikita is doing a great job. I am glad to see all the progress now. He provides some really impressing solutions.
So I want to say sorry and thank you, Nikita
djowel
commented
6 years ago Thank you, @octopus-prime. That is a welcome start. I'll reiterate what @hkaiser said: "You both want to contribute - so do it."
djowel
commented
6 years ago @octopus-prime it would be nice to migrate spirit's Trac issues over to Github Issues. @hkaiser says he has some scripts. Would you be interested to take care of that?
djowel
commented
6 years ago @octopus-prime Also, I will be closing this issue and replace it with something more productive, where we can list down actual steps :)
octopus-prime
commented
6 years ago Would you be interested to take care of that?
Yes, I can take care of that.
Also, I will be closing this issue ...
:+1:
hkaiser
commented
6 years ago Here is what we've been using for migrating our stuff to github: https://github.com/STEllAR-GROUP/github-migrate-trac-tickets.
octopus-prime
commented
6 years ago Thanks @hkaiser
octopus-prime
commented
6 years ago Created issue for migrating task: #309
Currently team work is bullshit:
So I want to strongly suggest working together - AS TEAM:
So communication is most important. And there should be rules, e.g. no merge without review...