Re: Add JIRA ticket# to `TODO`s in comments

[Adam Avilla]

On Mon, Nov 9, 2015 at 4:29 AM, Bernd Mathiske  wrote:

>  +1 on converting lots of TODOs into JIRAs with links to them in the TODOs.
>

Totally agree with pulling TODOs out to something more visible / trackable
/ scheduleable.


> Questions with opinions:
> - Do we need to create extra tickets like “Edit TODO to mention ticket
> MESOS-XXX”? I suppose not.
>

I think that would be noisy.


> - Do we even need an RR for updating a TODO? I suppose yes.
>

Can be helpful because you can get feedback with making sure the ticket
created is quantifiable, detailed, and attainable.


> - Every TODO *CAN* be a ticket - how’s that for starters? I’d also go
> along with MUST if there is consensus on that.
>

A cursory look shows:

$ git rev-parse HEAD ; git grep TODO | grep -Evc MESOS-[0-9]+
73deb1cd10d9eee16643e646f2f7545cfc22f4b0
1313

Was the suggestion to create different tickets for every TODO, group them
into higher level tickets, or both?

-- 
/adam

Re: Mesos .26 failing on centos7

[Jan Schlicht]

There were some build errors due to some reverts in `registry_puller.cpp`.
Your error logs hints that it may be related to this. They should be fixed
now (with `cee4958`).

On Mon, Nov 9, 2015 at 3:23 PM, haosdent  wrote:

> Could you show more details about error log? I could build current master
> branch in CentOS 7.
>
> On Mon, Nov 9, 2015 at 10:00 PM, Pradeep Kiruvale <
> pradeepkiruv...@gmail.com> wrote:
>
>> Hi All,
>>
>> I am trying to compile mesos on Centos7, but its failing. Please let me
>> know what is the reason.
>>
>> Find the logs below.
>>
>> Regards,
>> Pradeep
>>
>> make[2]: ***
>> [slave/containerizer/mesos/provisioner/docker/libmesos_no_3rdparty_la-registry_puller.lo]
>> Error 1
>> make[2]: *** Waiting for unfinished jobs
>> mv -f
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Tpo
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Plo
>> mv -f master/.deps/libmesos_no_3rdparty_la-master.Tpo
>> master/.deps/libmesos_no_3rdparty_la-master.Plo
>> mv -f java/jni/.deps/libjava_la-convert.Tpo
>> java/jni/.deps/libjava_la-convert.Plo
>> mv -f examples/.deps/libexamplemodule_la-example_module_impl.Tpo
>> examples/.deps/libexamplemodule_la-example_module_impl.Plo
>> mv -f
>> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Tpo
>> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Plo
>> mv -f
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Tpo
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Plo
>> mv -f
>> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Tpo
>> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Plo
>> mv -f
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Tpo
>> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Plo
>> mv -f linux/.deps/libmesos_no_3rdparty_la-perf.Tpo
>> linux/.deps/libmesos_no_3rdparty_la-perf.Plo
>> mv -f
>> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Tpo
>> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Plo
>> mv -f log/.deps/liblog_la-replica.Tpo log/.deps/liblog_la-replica.Plo
>> mv -f slave/.deps/libmesos_no_3rdparty_la-slave.Tpo
>> slave/.deps/libmesos_no_3rdparty_la-slave.Plo
>> mv -f
>> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Tpo
>> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Plo
>> mv -f
>> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Tpo
>> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Plo
>> mv -f
>> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Tpo
>> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Plo
>> mv -f log/.deps/liblog_la-coordinator.Tpo
>> log/.deps/liblog_la-coordinator.Plo
>> mv -f log/.deps/liblog_la-recover.Tpo log/.deps/liblog_la-recover.Plo
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
*Jan Schlicht*
Distributed Systems Engineer, Mesosphere

Re: Add JIRA ticket# to `TODO`s in comments

[Bernd Mathiske]

 +1 on converting lots of TODOs into JIRAs with links to them in the TODOs.

Questions with opinions:
- Do we need to create extra tickets like “Edit TODO to mention ticket 
MESOS-XXX”? I suppose not.
- Do we even need an RR for updating a TODO? I suppose yes.
- Can we do several TODO updates at once across several/many files/topics in 
one RR? I propose: no limits, except stout/libprocess boundaries.
- Every TODO *CAN* be a ticket - how’s that for starters? I’d also go along 
with MUST if there is consensus on that.

Opinions "without question":
- The assignee MUST be left open until the ticket is in a sprint.
- Typically, the reporter should be the person now mentioned in the TODO. 
Alternatively, if there is significant extra information in the ticket,the 
person making the effort to write the ticket can be the Reporter, if leaving a 
comment giving some credit to the original TODO author.

Bernd

> On Nov 9, 2015, at 11:54 AM, Till Toenshoff  wrote:
> 
> +1 in general for this proposal.
> 
> Using JIRA for tracking TODO’s is great, especially for things like 
> deprecation over/at releases. I am however unsure if *all* TODOs need to have 
> a ticket assigned, so that is a detail we may want to discuss as well?
> 
>> On Nov 9, 2015, at 9:55 AM, Alex Clemmer  wrote:
>> 
>> I like this proposal a lot, as I often end up making a point to
>> mention the MESOS- number in the comment anyway. I would rather
>> have the format `TODO(MESOS-XXX)` though, because (1) the JIRA should
>> capture the reporter as well as the assignee, and (2) it's not
>> immediately clear from the structure that the name should be the
>> reporter and not, say, the assignee.
>> 
>> On Sat, Nov 7, 2015 at 8:50 PM, Kapil Arya  wrote:
>>> Folks,
>>> 
>>> I wanted to bring up a style issue related to the TODO tag in comments. I
>>> have filed a Jira ticket (https://issues.apache.org/jira/browse/MESOS-3850)
>>> with the following description:
>>> 
>>> Currently, we have a TODO() tags to note stuff
>>> has "should be"/"has to be" done in future. While this provides us with
>>> some notion of accounting, it's not enough.
>>> 
>>> The author listed in the TODO comment should be considered the "Reporter",
>>> but not necessarily the "Assignee". Further, since the stuff "should
>>> be"/"has to be" done, why not have a Jira issue tracking it?
>>> 
>>> We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or something
>>> similar. Finally, we might wan to consider adding this to the style guide
>>> to make it a soft/hard requirement.
>>> 
>>> 
>>> Are there any opinions/suggestions on this one?
>>> 
>>> Best,
>>> Kapil
>> 
>> 
>> 
>> --
>> Alex
>> 
>> Theory is the first term in the Taylor series of practice. -- Thomas M
>> Cover (1992)
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: More Project Structure in JIRA

[Bernd Mathiske]

All,

thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do this 
from now on!

Bernd

> On Oct 28, 2015, at 2:52 AM, Klaus Ma  wrote:
> 
> +1
> 
> On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin  wrote:
> 
>> +1
>> 
>> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:
>> 
>>> +1
>>> 
>>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
>>> 
 +1 Yes please!
 
 2015-10-19 16:09 GMT+08:00 Alexander Rojas :
 
> +1 Yes please!
> 
>> On 15 Oct 2015, at 10:11, Bernd Mathiske 
>>> wrote:
>> 
>> Proposal: in extension of today’s limited two-level (epic, task)
> approach, make full use of expressive power already available in JIRA
>>> to
> provide more structure for larger projects to facilitate planning,
> tracking, and reporting. This will facilitate dynamically planning of
> sub-projects, which will make us more agile.
>> 
>> The general idea is to use links between epics to provide a
>> recursive
> hierarchical structure, with which one can span trees or DAGs of
> arbitrarily large projects. This does not mean that we want to plan
> everything in minute detail before starting to work. On the contrary.
>> 
>> You can start anywhere in the eventual tree and express part of the
> overall effort, maybe say a short epic with a few task tickets. Then
>>> you
> can LATER make this epic a dependency for a larger effort.
>> 
>> Conversely, you can subdivide a task in the epic into subtasks.
 However,
> this does not mean that you have to literally use the feature
>> “subtask”
 in
> JIRA for this. Instead, staying recursive in our JIRA grammar, so to
 speak,
> convert the task to an epic and then create ordinary tasks in it to
> represent subtasks.
>> 
>> Now the task cannot be a task in its parent epic anymore. We fix
>> this
 by
> putting in a link of type "blocks" to the parent. When you then look
>> at
 the
> parent, it still holds a number of tasks, and it has one dependency
>> on
>>> an
> epic (to which you can add more).
>> 
>> Thus our dependency tree can grow in all directions. You can also
> rearrange and update it in any shape or form if necessary.
>> 
>> Overall, we only use two JIRA elements: epics and tasks (of
>> different
> flavors such as bugs, improvements, etc.). Tasks are the leaves,
 everything
> else is an epic. Review requests only ever happen for tasks.
>> 
>> The epics are there to provide a high level view and to allow
>> dynamic
> (“more agilish”, non-waterfall) planning. Granted, you’d also use a
>>> tree
 if
> you did waterfall. The difference is that you’d spec it all out at
>>> once.
 My
> observation is that not too few of us do exactly this - outside JIRA
>> -
 and
> then try to remember what tickets are where in their tree. Let’s make
 this
> part of JIRA!
>> 
>> Why not use labels? Because they are in a flat name space and we
>> want
 to
> represent tree structure. How would you know that a label denotes a
> subproject of another label? By memorizing or by depicting a tree
>>> outside
> JIRA. Why not use components? Same problem as with labels: flat name
 space.
> We can use labels and components these for many other purposes.
>>> Separate
> discussion.
>> 
>> Aren’t we doing this already? Probably. I have not checked
>>> thoroughly.
> There may occasionally be epics that link to other epics. If so, I
>>> would
> merely like to encourage us to use this powerful expressive means
>> more
> often.
>> 
>> Bernd
>> 
> 
> 
 
 
 --
 Deshi Xiao
 Twitter: xds2000
 E-mail: xiaods(AT)gmail.com
 
>>> 
>> 
> 
> 
> 
> --
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform Symphony/DCOS Development & Support, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Mesos .26 failing on centos7

[Plotka, Bartlomiej]

I had the same issue (broken build) on Ubuntu 14.04.. Commit “cee4958” helped.

Kind Regards,
Bartek Plotka

From: Jan Schlicht [mailto:j...@mesosphere.io]
Sent: Monday, November 9, 2015 3:27 PM
To: u...@mesos.apache.org
Cc: dev 
Subject: Re: Mesos .26 failing on centos7

There were some build errors due to some reverts in `registry_puller.cpp`. Your 
error logs hints that it may be related to this. They should be fixed now (with 
`cee4958`).

On Mon, Nov 9, 2015 at 3:23 PM, haosdent 
> wrote:
Could you show more details about error log? I could build current master 
branch in CentOS 7.

On Mon, Nov 9, 2015 at 10:00 PM, Pradeep Kiruvale 
> wrote:
Hi All,

I am trying to compile mesos on Centos7, but its failing. Please let me know 
what is the reason.

Find the logs below.

Regards,
Pradeep

make[2]: *** 
[slave/containerizer/mesos/provisioner/docker/libmesos_no_3rdparty_la-registry_puller.lo]
 Error 1
make[2]: *** Waiting for unfinished jobs
mv -f 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Tpo
 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Plo
mv -f master/.deps/libmesos_no_3rdparty_la-master.Tpo 
master/.deps/libmesos_no_3rdparty_la-master.Plo
mv -f java/jni/.deps/libjava_la-convert.Tpo 
java/jni/.deps/libjava_la-convert.Plo
mv -f examples/.deps/libexamplemodule_la-example_module_impl.Tpo 
examples/.deps/libexamplemodule_la-example_module_impl.Plo
mv -f 
slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Tpo
 
slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Plo
mv -f 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Tpo
 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Plo
mv -f 
slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Tpo
 
slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Plo
mv -f 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Tpo
 
slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Plo
mv -f linux/.deps/libmesos_no_3rdparty_la-perf.Tpo 
linux/.deps/libmesos_no_3rdparty_la-perf.Plo
mv -f 
slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Tpo 
slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Plo
mv -f log/.deps/liblog_la-replica.Tpo log/.deps/liblog_la-replica.Plo
mv -f slave/.deps/libmesos_no_3rdparty_la-slave.Tpo 
slave/.deps/libmesos_no_3rdparty_la-slave.Plo
mv -f slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Tpo 
slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Plo
mv -f slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Tpo 
slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Plo
mv -f 
slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Tpo
 
slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Plo
mv -f log/.deps/liblog_la-coordinator.Tpo log/.deps/liblog_la-coordinator.Plo
mv -f log/.deps/liblog_la-recover.Tpo log/.deps/liblog_la-recover.Plo




--
Best Regards,
Haosdent Huang



--
Jan Schlicht
Distributed Systems Engineer, Mesosphere


Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

Re: More Project Structure in JIRA

[Adam Avilla]

This is great! I am not one of the devs, but the more transparency and ease
of use there is in our tools, the easier it is to focus on the actual work,
and not the process. I really like Martin Fowler's quote from
http://martinfowler.com/articles/newMethodology.html:

"Agile methods are people-oriented rather than process-oriented. The goal
of engineering methods is to define a process that will work well whoever
happens to be using it. Agile methods assert that no process will ever make
up the skill of the development team, so the role of a process is to
support the development team in their work."

On Mon, Nov 9, 2015 at 4:51 AM, Bernd Mathiske  wrote:

> All,
>
> thanks for upvoting this. AFAICT, we have consensus to go ahead. Let’s do
> this from now on!
>
> Bernd
>
> > On Oct 28, 2015, at 2:52 AM, Klaus Ma  wrote:
> >
> > +1
> >
> > On Sun, Oct 25, 2015 at 11:57 PM, Shuai Lin 
> wrote:
> >
> >> +1
> >>
> >> On Wed, Oct 21, 2015 at 12:55 AM, Greg Mann  wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, Oct 20, 2015 at 9:50 AM, tommy xiao  wrote:
> >>>
>  +1 Yes please!
> 
>  2015-10-19 16:09 GMT+08:00 Alexander Rojas :
> 
> > +1 Yes please!
> >
> >> On 15 Oct 2015, at 10:11, Bernd Mathiske 
> >>> wrote:
> >>
> >> Proposal: in extension of today’s limited two-level (epic, task)
> > approach, make full use of expressive power already available in JIRA
> >>> to
> > provide more structure for larger projects to facilitate planning,
> > tracking, and reporting. This will facilitate dynamically planning of
> > sub-projects, which will make us more agile.
> >>
> >> The general idea is to use links between epics to provide a
> >> recursive
> > hierarchical structure, with which one can span trees or DAGs of
> > arbitrarily large projects. This does not mean that we want to plan
> > everything in minute detail before starting to work. On the contrary.
> >>
> >> You can start anywhere in the eventual tree and express part of the
> > overall effort, maybe say a short epic with a few task tickets. Then
> >>> you
> > can LATER make this epic a dependency for a larger effort.
> >>
> >> Conversely, you can subdivide a task in the epic into subtasks.
>  However,
> > this does not mean that you have to literally use the feature
> >> “subtask”
>  in
> > JIRA for this. Instead, staying recursive in our JIRA grammar, so to
>  speak,
> > convert the task to an epic and then create ordinary tasks in it to
> > represent subtasks.
> >>
> >> Now the task cannot be a task in its parent epic anymore. We fix
> >> this
>  by
> > putting in a link of type "blocks" to the parent. When you then look
> >> at
>  the
> > parent, it still holds a number of tasks, and it has one dependency
> >> on
> >>> an
> > epic (to which you can add more).
> >>
> >> Thus our dependency tree can grow in all directions. You can also
> > rearrange and update it in any shape or form if necessary.
> >>
> >> Overall, we only use two JIRA elements: epics and tasks (of
> >> different
> > flavors such as bugs, improvements, etc.). Tasks are the leaves,
>  everything
> > else is an epic. Review requests only ever happen for tasks.
> >>
> >> The epics are there to provide a high level view and to allow
> >> dynamic
> > (“more agilish”, non-waterfall) planning. Granted, you’d also use a
> >>> tree
>  if
> > you did waterfall. The difference is that you’d spec it all out at
> >>> once.
>  My
> > observation is that not too few of us do exactly this - outside JIRA
> >> -
>  and
> > then try to remember what tickets are where in their tree. Let’s make
>  this
> > part of JIRA!
> >>
> >> Why not use labels? Because they are in a flat name space and we
> >> want
>  to
> > represent tree structure. How would you know that a label denotes a
> > subproject of another label? By memorizing or by depicting a tree
> >>> outside
> > JIRA. Why not use components? Same problem as with labels: flat name
>  space.
> > We can use labels and components these for many other purposes.
> >>> Separate
> > discussion.
> >>
> >> Aren’t we doing this already? Probably. I have not checked
> >>> thoroughly.
> > There may occasionally be epics that link to other epics. If so, I
> >>> would
> > merely like to encourage us to use this powerful expressive means
> >> more
> > often.
> >>
> >> Bernd
> >>
> >
> >
> 
> 
>  --
>  Deshi Xiao
>  Twitter: xds2000
>  E-mail: xiaods(AT)gmail.com
> 
> >>>
> >>
> >
> >
> >
> > --
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform Symphony/DCOS Development & Support, 

Re: Mesos .26 failing on centos7

[haosdent]

Could you show more details about error log? I could build current master
branch in CentOS 7.

On Mon, Nov 9, 2015 at 10:00 PM, Pradeep Kiruvale  wrote:

> Hi All,
>
> I am trying to compile mesos on Centos7, but its failing. Please let me
> know what is the reason.
>
> Find the logs below.
>
> Regards,
> Pradeep
>
> make[2]: ***
> [slave/containerizer/mesos/provisioner/docker/libmesos_no_3rdparty_la-registry_puller.lo]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> mv -f
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Tpo
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Plo
> mv -f master/.deps/libmesos_no_3rdparty_la-master.Tpo
> master/.deps/libmesos_no_3rdparty_la-master.Plo
> mv -f java/jni/.deps/libjava_la-convert.Tpo
> java/jni/.deps/libjava_la-convert.Plo
> mv -f examples/.deps/libexamplemodule_la-example_module_impl.Tpo
> examples/.deps/libexamplemodule_la-example_module_impl.Plo
> mv -f
> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Tpo
> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Plo
> mv -f
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Tpo
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Plo
> mv -f
> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Tpo
> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Plo
> mv -f
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Tpo
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Plo
> mv -f linux/.deps/libmesos_no_3rdparty_la-perf.Tpo
> linux/.deps/libmesos_no_3rdparty_la-perf.Plo
> mv -f
> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Tpo
> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Plo
> mv -f log/.deps/liblog_la-replica.Tpo log/.deps/liblog_la-replica.Plo
> mv -f slave/.deps/libmesos_no_3rdparty_la-slave.Tpo
> slave/.deps/libmesos_no_3rdparty_la-slave.Plo
> mv -f
> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Tpo
> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Plo
> mv -f
> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Tpo
> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Plo
> mv -f
> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Tpo
> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Plo
> mv -f log/.deps/liblog_la-coordinator.Tpo
> log/.deps/liblog_la-coordinator.Plo
> mv -f log/.deps/liblog_la-recover.Tpo log/.deps/liblog_la-recover.Plo
>
>


-- 
Best Regards,
Haosdent Huang

Re: Mesos Style Guideline Adjustments

[Bernd Mathiske]

IMHO jaggedness is a secondary concern.
I’d rather have subsentences on the same line
than try to meet some page boundary on the right consistently.
I see no value in that.

Of course, a maximum line width of 80 columns is necessary
due to anachronistic limitations of our tools.
Here is the above paragraph without jaggedness, with 80 columns
(which the email system will probably mess up before you get to see it):

IMHO jaggedness is a secondary concern. I’d rather have subsentences on the
same line  than try to meet some page boundary on the right consistently. I
see no value in that.

Here it is with 70 columns:

IMHO jaggedness is a secondary concern. I’d rather have subsentences
on the same line than try to meet some page boundary on the right
consistently. I see no value in that.

Maybe for some of us, avoiding jaggedness increases readability.
For me personally, it decreases it.

Bernd

> On Nov 6, 2015, at 8:36 PM, Kapil Arya  wrote:
> 
> As far as setting a soft limit goes, I think there are several different
> style guides and it basically boils down to personal preferences as well.
> The Linux `fmt` command wraps by 75 columns by default; others use 72 or as
> extreme as 60 columns.
> 
> Having said that, it's nice to have tools that enforce some
> check. Jaggedness isn't pretty and one can always use their judgement to
> reformat the comments to make it look nicer and more readable.
> 
> My 2 cents.
> 
> On Fri, Nov 6, 2015 at 2:26 PM, Joris Van Remoortere 
> wrote:
> 
>> @ben Is "jaggedness" the only *formatting* influence on the readability of
>> the comments? If so, would it be possible to make a simple github.io page
>> where we can paste comments, and they get formatted for minimal jaggedness
>> based on some simple math? This would help provide consistency between
>> contributions, and likely better results than humans trying to optimize the
>> jaggedness equation.
>> 
>> This way we can focus on the content of the comments when reviewing, rather
>> than the format. Later one we might even be able to incorporate this in
>> more intelligent editor friendly formatting tools.
>> 
>> If there is more than some simple math involved, this may not be a viable
>> solution.
>> 
>> Joris
>> 
>> —
>> *Joris Van Remoortere*
>> Mesosphere
>> 
>> On Fri, Nov 6, 2015 at 11:10 AM, Benjamin Mahler <
>> benjamin.mah...@gmail.com>
>> wrote:
>> 
>>> I raise this because there is a ton of value in keeping our codebase as
>>> readable as possible. Having had to navigate and maintain the code base
>> for
>>> the past few years, this _is_ a "real issue" that deserves the
>> contributors
>>> spending their mental resources on. I realize this seems very subtle, but
>>> it is of critical importance for the maintainability of the project that
>>> folks are paying attention to how their code and comments will be read by
>>> others.
>>> 
>>> I think about this as follows: we'll always have "soft" rules that cannot
>>> be enforced by these style checkers but require mentorship to communicate
>>> as we grow the community. These tools cannot tell you how to structure
>> your
>>> code in a simple form. They also can't tell you how to write a comment
>> in a
>>> way that is clear to others.
>>> 
>>> To Alex's example, two comments:
>>> 
>>> (1) The second comment is poorly written, did no one even notice this??
>>> That's a "real issue" :(
>>> (2) It's important not to isolate the comments from the code. The
>> comments
>>> live with the code and a major reason why long line length paragraphs are
>>> irregular is because the majority of code lines do not approach 80
>>> characters.
>>> (3) We tend to separate "multiple logical parts" of a comment with an
>> empty
>>> // line, which helps readability.
>>> (4) I'm not saying wrap at 70 or at 80, but (a) write and wrap to reduce
>>> "jaggedness" (or to increase "regularity") and (b) long line lengths (80)
>>> for large paragraphs are harder to read.
>>> 
>>> I just don't want the formatter to become a crutch that causes folks to
>>> think less about the implications of how they write their comments. Do
>> the
>>> soft rules in (a) and (b) seem reasonable? We already need to be diligent
>>> in reviews to ensure that comments are well-written.
>>> 
>>> On Fri, Nov 6, 2015 at 8:44 AM, Benjamin Bannier <
>>> benjamin.bann...@mesosphere.io> wrote:
>>> 
 Hi,
 
 just to echo Alexander’s point, for newbies like me being able to
>>> delegate
 formatting decisions to tools as much as possible frees up a lot of
>>> mental
 resources for tackling the real issues.
 
 
 Cheers,
 
 Benjamin
 
 ps. Also looking forward to an updated and expanded clang-format
>> config.
 
 
> On Nov 6, 2015, at 1:44 PM, Alexander Rojas >> 
 wrote:
> 
> I think one of the main reasons we move to having 80 as the limit for
 both code and comments is the ability it gives 

Re: Mesos .26 failing on centos7

[Timothy Chen]

My commits that caused the trouble are reverted now.

And also 0.26 will not be based on master, it typically are cherry picked 
commits to specific tag.

Tim

> On Nov 9, 2015, at 6:37 AM, Plotka, Bartlomiej  
> wrote:
> 
> I had the same issue (broken build) on Ubuntu 14.04.. Commit “cee4958” helped.
> 
> Kind Regards,
> Bartek Plotka
> 
> From: Jan Schlicht [mailto:j...@mesosphere.io]
> Sent: Monday, November 9, 2015 3:27 PM
> To: u...@mesos.apache.org
> Cc: dev 
> Subject: Re: Mesos .26 failing on centos7
> 
> There were some build errors due to some reverts in `registry_puller.cpp`. 
> Your error logs hints that it may be related to this. They should be fixed 
> now (with `cee4958`).
> 
> On Mon, Nov 9, 2015 at 3:23 PM, haosdent 
> > wrote:
> Could you show more details about error log? I could build current master 
> branch in CentOS 7.
> 
> On Mon, Nov 9, 2015 at 10:00 PM, Pradeep Kiruvale 
> > wrote:
> Hi All,
> 
> I am trying to compile mesos on Centos7, but its failing. Please let me know 
> what is the reason.
> 
> Find the logs below.
> 
> Regards,
> Pradeep
> 
> make[2]: *** 
> [slave/containerizer/mesos/provisioner/docker/libmesos_no_3rdparty_la-registry_puller.lo]
>  Error 1
> make[2]: *** Waiting for unfinished jobs
> mv -f 
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Tpo
>  
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-cpushare.Plo
> mv -f master/.deps/libmesos_no_3rdparty_la-master.Tpo 
> master/.deps/libmesos_no_3rdparty_la-master.Plo
> mv -f java/jni/.deps/libjava_la-convert.Tpo 
> java/jni/.deps/libjava_la-convert.Plo
> mv -f examples/.deps/libexamplemodule_la-example_module_impl.Tpo 
> examples/.deps/libexamplemodule_la-example_module_impl.Plo
> mv -f 
> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Tpo
>  
> slave/containerizer/mesos/isolators/namespaces/.deps/libmesos_no_3rdparty_la-pid.Plo
> mv -f 
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Tpo
>  
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-perf_event.Plo
> mv -f 
> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Tpo
>  
> slave/containerizer/mesos/provisioner/backends/.deps/libmesos_no_3rdparty_la-bind.Plo
> mv -f 
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Tpo
>  
> slave/containerizer/mesos/isolators/cgroups/.deps/libmesos_no_3rdparty_la-mem.Plo
> mv -f linux/.deps/libmesos_no_3rdparty_la-perf.Tpo 
> linux/.deps/libmesos_no_3rdparty_la-perf.Plo
> mv -f 
> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Tpo 
> slave/containerizer/.deps/libmesos_no_3rdparty_la-external_containerizer.Plo
> mv -f log/.deps/liblog_la-replica.Tpo log/.deps/liblog_la-replica.Plo
> mv -f slave/.deps/libmesos_no_3rdparty_la-slave.Tpo 
> slave/.deps/libmesos_no_3rdparty_la-slave.Plo
> mv -f 
> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Tpo 
> slave/containerizer/mesos/.deps/libmesos_no_3rdparty_la-containerizer.Plo
> mv -f 
> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Tpo 
> slave/resource_estimators/.deps/libfixed_resource_estimator_la-fixed.Plo
> mv -f 
> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Tpo
>  
> slave/containerizer/mesos/isolators/filesystem/.deps/libmesos_no_3rdparty_la-linux.Plo
> mv -f log/.deps/liblog_la-coordinator.Tpo log/.deps/liblog_la-coordinator.Plo
> mv -f log/.deps/liblog_la-recover.Tpo log/.deps/liblog_la-recover.Plo
> 
> 
> 
> 
> --
> Best Regards,
> Haosdent Huang
> 
> 
> 
> --
> Jan Schlicht
> Distributed Systems Engineer, Mesosphere
> 
> 
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII 
> Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 
> 957-07-52-316 | Kapital zakladowy 200.000 PLN.
> 
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
> moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
> wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
> jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the 
> sole use of the intended recipient(s). If you are not the intended recipient, 
> please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.

Re: JSON::Protobuf => JSON::protobuf

[Marco Massenzio]

Awesome!

Thanks, Klaus Ma and Michael!

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Sat, Nov 7, 2015 at 10:13 PM, Michael Park  wrote:

> Hello,
>
> This is an announcement that we have changed *JSON::Protobuf* to
> *JSON::protobuf*. Previously, we had a *JSON::Protobuf* class which had an
> implicit conversion operator to *JSON::Object*. We now have
> *JSON::protobuf* which
> is an overloaded function which converts *google::protobuf::Message *to
> *JSON::Object*, and *google::protobuf::RepeatedPtrField* to
> *JSON::Array*
> .
>
> Thanks to *Klaus Ma* for following through with these patches!
>
> MPark.
>

Re: Add JIRA ticket# to `TODO`s in comments

[Till Toenshoff]

+1 in general for this proposal.

Using JIRA for tracking TODO’s is great, especially for things like deprecation 
over/at releases. I am however unsure if *all* TODOs need to have a ticket 
assigned, so that is a detail we may want to discuss as well?

> On Nov 9, 2015, at 9:55 AM, Alex Clemmer  wrote:
> 
> I like this proposal a lot, as I often end up making a point to
> mention the MESOS- number in the comment anyway. I would rather
> have the format `TODO(MESOS-XXX)` though, because (1) the JIRA should
> capture the reporter as well as the assignee, and (2) it's not
> immediately clear from the structure that the name should be the
> reporter and not, say, the assignee.
> 
> On Sat, Nov 7, 2015 at 8:50 PM, Kapil Arya  wrote:
>> Folks,
>> 
>> I wanted to bring up a style issue related to the TODO tag in comments. I
>> have filed a Jira ticket (https://issues.apache.org/jira/browse/MESOS-3850)
>> with the following description:
>> 
>> Currently, we have a TODO() tags to note stuff
>> has "should be"/"has to be" done in future. While this provides us with
>> some notion of accounting, it's not enough.
>> 
>> The author listed in the TODO comment should be considered the "Reporter",
>> but not necessarily the "Assignee". Further, since the stuff "should
>> be"/"has to be" done, why not have a Jira issue tracking it?
>> 
>> We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or something
>> similar. Finally, we might wan to consider adding this to the style guide
>> to make it a soft/hard requirement.
>> 
>> 
>> Are there any opinions/suggestions on this one?
>> 
>> Best,
>> Kapil
> 
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Jan Schlicht]

+1 (non-binding) for an all-at-once change to #pragmas.

On Fri, Nov 6, 2015 at 2:30 AM, Joris Van Remoortere 
wrote:

> +1 with all-at-once
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Thu, Nov 5, 2015 at 9:37 AM, Kapil Arya  wrote:
>
> > +1.
> >
> > I think we should do it all at once as Artem mentioned. This doesn't
> really
> > affect the history (git-blame, etc.) because we are not touching code per
> > se.
> >
> > On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan 
> > wrote:
> >
> > > Hi Alex,
> > >
> > > While I agree with the idea in general, I strongly believe that we
> should
> > > either leave it as it is or fix everything in one go (i.e. three
> > > consecutive commits). Having both #include guards and #pragmas in the
> > > codebase will be confusing and untidy. We have done code sweeps like
> this
> > > in the past when we had to introduce changes to the style guide, so if
> > > folks agree you just need to find a shepherd and do it :).
> > >
> > > Cheers,
> > > Artem.
> > >
> > > On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <
> > clemmer.alexan...@gmail.com>
> > > wrote:
> > >
> > > > Hey folks.
> > > >
> > > > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > > > brought up the issue of moving away from #include guards and towards
> > > > `#pragma once`.
> > > >
> > > > As this has been brought up before, I will be brief: we think it's
> > > > revisiting because the primary objection in previous threads appears
> > > > to be that, though `#pragma once` is a cleaner solution to the
> > > > multiple-include problem, it's not so much better that it's worth the
> > > > code churn. However, the ongoing Windows integration work means we
> > > > have to touch these files anyway, so if we agree this is cleaner and
> > > > desirable, then this is an opportunity to obtain that additional code
> > > > clarity, without the cost of the churn.
> > > >
> > > > For the remainder of the email, I will summarize the history of our
> > > > discussion of this issue, who will do the work, and what the next
> > > > steps are.
> > > >
> > > > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > > > #include guards; for existing files, we propose that you change
> > > > #include guards when you touch them.
> > > >
> > > > HISTORY: This has been discussed before, most recently a year ago on
> > > > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > > > review[4] that changes style guide's recommendation on the matter.
> > > >
> > > > SUMMARIZED OBJECTIONS:
> > > > 1. The Google style guide explicitly forbids `#pragma once`.
> > > > 2. This results in a lot of code churn, but is only marginally
> better.
> > > > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > > > doesn't support it.
> > > > 4. Popular projects like Chrome don't do `#pragma once` because of
> > > > history clutter.
> > > > 5. Intermediate state of inconsistency as we transition to `#pragma
> > > > once` from #include guards.
> > > >
> > > > OUR RESPONSE:
> > > > Objections (1), (2), and (4) are essentially the same -- Dominic
> Hamon
> > > > points out in a previous thread that the Google style guide was
> > > > canonized when `#pragma once` was Windows-only, and the guidance has
> > > > not changed since because of the history churn problem. As noted
> > > > above, we think the history churn problem is minimized by the fact
> > > > that it can be wrapped up into the Windows integration work.
> > > >
> > > > For objection (3), the consensus seems to be that the vast majority
> of
> > > > compilers we care about (in particular, the ones supporting C++ 11)
> do
> > > > support it.
> > > >
> > > > For objection (5) we believe the inconsistent state is likely to not
> > > > be long lived, as long as we commit to wrapping this work up into the
> > > > Windows integration work.
> > > >
> > > > SUMMARIZED ADVANTAGES:
> > > > * Basically fool-proof. Communicates simply what its function is (you
> > > > include this file once). Semantically it is "the right tool for the
> > > > job".
> > > > * No need for namespacing conventions for #include guards.
> > > > * No conflicts with reserved identifiers[5].
> > > > * No internal conflicts between include guards in Stout, Process
> > > > library, and Mesos (this is one reason we need the namespacing
> > > > conventions)
> > > > * Reduces preprocessor definition clutter (we should rely on #define
> > > > as little as humanly possible).
> > > > * Optimized to be easy to read and reason about.
> > > >
> > > > NEXT STEPS:
> > > > If we agree that this is the right thing to do, committers would ask
> > > > people to use `#pragma once` for new code when presented in code
> > > > reviews. For files that exist, I will take point on transitioning as
> > > > we complete the Windows integration work. I expect this work to
> > > > completely land before the new year.
> > > >
> > > >

Re: Add JIRA ticket# to `TODO`s in comments

[Alex Clemmer]

I like this proposal a lot, as I often end up making a point to
mention the MESOS- number in the comment anyway. I would rather
have the format `TODO(MESOS-XXX)` though, because (1) the JIRA should
capture the reporter as well as the assignee, and (2) it's not
immediately clear from the structure that the name should be the
reporter and not, say, the assignee.

On Sat, Nov 7, 2015 at 8:50 PM, Kapil Arya  wrote:
> Folks,
>
> I wanted to bring up a style issue related to the TODO tag in comments. I
> have filed a Jira ticket (https://issues.apache.org/jira/browse/MESOS-3850)
> with the following description:
>
> Currently, we have a TODO() tags to note stuff
> has "should be"/"has to be" done in future. While this provides us with
> some notion of accounting, it's not enough.
>
> The author listed in the TODO comment should be considered the "Reporter",
> but not necessarily the "Assignee". Further, since the stuff "should
> be"/"has to be" done, why not have a Jira issue tracking it?
>
> We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or something
> similar. Finally, we might wan to consider adding this to the style guide
> to make it a soft/hard requirement.
>
>
> Are there any opinions/suggestions on this one?
>
> Best,
> Kapil



-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)