Send hpx-devel mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."
Today's Topics:
1. Re: Shaping a scalable development model (Thomas Heller)
2. Re: Shaping a scalable development model (Agust?n K-ballo Berg?)
3. Re: Shaping a scalable development model (Andreas Sch?fer)
4. Re: Shaping a scalable development model (Agust?n K-ballo Berg?)
5. Push to master test case (Biddiscombe, John A.)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Jun 2015 20:37:39 +0200
From: Thomas Heller <[email protected]>
Subject: Re: [hpx-devel] Shaping a scalable development model
To: [email protected]
Message-ID:
<CAJcxAexMrVz_9TFDeACobdPh8bi1z4+HkR=m5--m-9peqtc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Agust?n,
Thanks for raising those issues, this is very valuable input. While I
understand that a broken master is frustrating, I just have to ask two
questions:
- Are we that bad?
- Do you know of a similar project than ours that solved those problems
which we can use as role models?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20150608/bf95075b/attachment-0001.html
------------------------------
Message: 2
Date: Mon, 8 Jun 2015 15:50:31 -0300
From: Agust?n K-ballo Berg? <[email protected]>
Subject: Re: [hpx-devel] Shaping a scalable development model
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format=flowed
On 6/8/2015 3:37 PM, Thomas Heller wrote:
> Agust?n,
>
> Thanks for raising those issues, this is very valuable input. While I
> understand that a broken master is frustrating, I just have to ask two
> questions:
Please go back and re-read my message, as you seem to have missed the
point. Also, please go back and re-read my reply here
https://github.com/STEllAR-GROUP/hpx/issues/1587#issuecomment-110061735
where I state that a broken master is not a problem but a symptom.
Regards,
--
Agust?n K-ballo Berg?.-
http://talesofcpp.fusionfenix.com
------------------------------
Message: 3
Date: Mon, 8 Jun 2015 21:57:25 +0200
From: Andreas Sch?fer <[email protected]>
Subject: Re: [hpx-devel] Shaping a scalable development model
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On 14:51 Fri 05 Jun , Agust?n K-ballo Berg? wrote:
> This is a meta thread. It is not the intention of this thread to start
> debate on each point from the above list, in fact the points I've
> included are those for which I have already participated in a debate in
> some form of another. The intention of this thread is to show the
> futility of those past debates. After all the time spent on them, very
> little of it is formally documented, contributors are unlikely to be
> aware of most of them (specially new members), few of them are actually
> followed/enforced and when they are it's often done in ways that defeats
> their purpose.
>
> I am not proposing nor will I be proposing any particular policy, please
> keep any discussion about those in separate threads.
So you're saying that we should not discuss the individual issues you
raised, but lead a meta discussion on their very existence? Honest
question, I'm just trying to make sure I got you correctly. If yes:
The way I see it, any project of a non-trivial size will always have
issues: there will always be new contributors who contribute code and
are unaware of the project's style/workflow etc. There will always be
seasoned developers stepping on each others toe. Documentation will
always be lacking, at least for new code. Most of the issues could be
solved by slowing down development: run more CI tests, get more
detailed reviews on PRs, greenlight PRs only if all points have been
addressed etc.
But let's not forget: HPX is still a research project. As long as it's
moving this fast, we'll see such issues. Yes, as someone who's rolling
code downstream of HPX, I'd be the first to cheer for an HPX 1.0.
Coping with a rapidly changing upstream can be frustrating. The plus
side is though that we can get awesome new stuff into trunk rapidly.
Research is a competitive domain, speed is an asset.
Cheers
-Andi
--
==========================================================
Andreas Sch?fer
HPC and Grid Computing
Department of Computer Science 3
Friedrich-Alexander-Universit?t Erlangen-N?rnberg, Germany
+49 9131 85-27910
PGP/GPG key via keyserver
http://www.libgeodecomp.org
==========================================================
(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
Url :
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20150608/23003eaa/attachment-0001.bin
------------------------------
Message: 4
Date: Mon, 8 Jun 2015 18:01:47 -0300
From: Agust?n K-ballo Berg? <[email protected]>
Subject: Re: [hpx-devel] Shaping a scalable development model
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; format=flowed
On 6/8/2015 4:57 PM, Andreas Sch?fer wrote:
> On 14:51 Fri 05 Jun , Agust?n K-ballo Berg? wrote:
>> This is a meta thread. It is not the intention of this thread to start
>> debate on each point from the above list, in fact the points I've
>> included are those for which I have already participated in a debate in
>> some form of another. The intention of this thread is to show the
>> futility of those past debates. After all the time spent on them, very
>> little of it is formally documented, contributors are unlikely to be
>> aware of most of them (specially new members), few of them are actually
>> followed/enforced and when they are it's often done in ways that defeats
>> their purpose.
>>
>> I am not proposing nor will I be proposing any particular policy, please
>> keep any discussion about those in separate threads.
>
> So you're saying that we should not discuss the individual issues you
> raised, but lead a meta discussion on their very existence? Honest
> question, I'm just trying to make sure I got you correctly.
I'm not trying to start any kind of debate, not about the individual
issues nor about their existence. I am merely stating what I perceive to
be a problem with the development model, one that is at least partially
known and for which attempts to addressed it have failed in the past. I
do see a lot of wasted time and efforts due to it, and I hope for some
constructive outcome but I do not intend to shape it in any way.
> But let's not forget: HPX is still a research project. As long as it's
> moving this fast, we'll see such issues. Yes, as someone who's rolling
> code downstream of HPX, I'd be the first to cheer for an HPX 1.0.
> Coping with a rapidly changing upstream can be frustrating. The plus
> side is though that we can get awesome new stuff into trunk rapidly.
> Research is a competitive domain, speed is an asset.
That is precisely while I'm not proposing anything in particular, for me
HPX is not work nor research.
Regards,
--
Agust?n K-ballo Berg?.-
http://talesofcpp.fusionfenix.com
------------------------------
Message: 5
Date: Tue, 9 Jun 2015 06:50:53 +0000
From: "Biddiscombe, John A." <[email protected]>
Subject: [hpx-devel] Push to master test case
To: "[email protected]" <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
I see today #1590, that a binary dir containing "/path/with/c++/in/it" breaks
our cmake and the fix is a trivial string replace to escape the control chars
before the regex test.
Since this is IMHO a trivial fix, I am making an 'executive decision' to commit
directly to master and am willing to suffer the consequences and public shaming
should my decision prove to be a bad one.
Since there is (rightly) a debate about the procedure I am invoking the new
rule which I'm now writing which reads as follows and I hope can be added to
the contributing to hpx
doc to get us started on the 'correct procedures'.
Please add/amend/approve as appropriate this text ...
Trivial Fixes
-------------
When a developer who is a member of the Ste||ar group makes a small fix or
improvement which in his/her considered opinion
* has a very low probability of causing build or test failures or
warnings on any of the supported platforms and compilers
* does not significantly affect topics/branches or outstanding issues
that others might be working on
* is unlikely to be considered controversial by other members of the
development team and will not therefore require a review process
* does not break any public API or cause other backward
incompatibilities
* can be easily reverted in future should the need arise, as it is
atomic in nature and touches a very small number of files.
Then the fix may be applied directly to the master branch. If the fix does not
comply with all of the above, or there is any doubt in the developer's mind,
then it must be applied to a branch with an accompanying Pull Request and is
subject to a review process. See section <$$$>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20150609/fdb2abd1/attachment.html
------------------------------
_______________________________________________
hpx-devel mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
End of hpx-devel Digest, Vol 21, Issue 5
****************************************
