Large changes on the codebase due to MESOS-1872

[Till Toenshoff <to...@me.com>]

Hey Everyone,

I would like to reach out to the developer community for making sure that we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872 <https://issues.apache.org/jira/browse/MESOS-1872> and other, entire code-base affecting changes.

Evelina has bravely proposed three review requests (mesos/libprocess/stout) for covering the ticket. There is however some greater risk involved and I wanted to be sure that we are all aware of the pro’s and con's of such big cleanups.

+ we may need to do cleanups - even major ones at some point, hence I think we need a consensus once and for all regarding tickets of the above nature
- almost all existing RRs will possibly get invalid and everyone with work in flight needs to rebase (possibly rather tedious task in particular case).

There may be more.

The only way I can currently see this happening with minimal friction is finding a certain date and even time for doing this on a very quick, propose/review/commit.

What do you think?

cheers!
Till

 

Re: Large changes on the codebase due to MESOS-1872

[Benjamin Mahler <be...@gmail.com>]

> - almost all existing RRs will possibly get invalid

Why is that Till? Are you thinking of merge conflicts?

>If you work in a function that can get cleaned up, clean it up.
>Maybe clean up the entire file if you're making changes to multiple
functions.

But please separate the patches. :)

> git blame history which can be invaluable when working in a file and
trying to ask for some help.

Till, does 'git blame -w' ignore this particular change, since she's only
removing whitespace?

On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman <be...@eecs.berkeley.edu>
wrote:

> My $0.02: Let's make the cleanups as we go. If you work in a function that
> can get cleaned up, clean it up. Maybe clean up the entire file if you're
> making changes to multiple functions. Doing this iteratively not only keeps
> folks from having to do tedious rebases but it also preserves, for the most
> part, the git blame history which can be invaluable when working in a file
> and trying to ask for some help.
>
> On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff <to...@me.com> wrote:
>
> > Hey Everyone,
> >
> > I would like to reach out to the developer community for making sure that
> > we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
> <
> > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > code-base affecting changes.
> >
> > Evelina has bravely proposed three review requests
> > (mesos/libprocess/stout) for covering the ticket. There is however some
> > greater risk involved and I wanted to be sure that we are all aware of
> the
> > pro’s and con's of such big cleanups.
> >
> > + we may need to do cleanups - even major ones at some point, hence I
> > think we need a consensus once and for all regarding tickets of the above
> > nature
> > - almost all existing RRs will possibly get invalid and everyone with
> work
> > in flight needs to rebase (possibly rather tedious task in particular
> case).
> >
> > There may be more.
> >
> > The only way I can currently see this happening with minimal friction is
> > finding a certain date and even time for doing this on a very quick,
> > propose/review/commit.
> >
> > What do you think?
> >
> > cheers!
> > Till
> >
> >
>

Re: Large changes on the codebase due to MESOS-1872

[Cody Maloney <co...@mesosphere.io>]

I think in this case there isn't a lot of value added relative to the cost.
It is an invasive change that doesn't change how easy the code is to work
with, and will periodically break things like '\' aligned to the right for
continuing macros.

For some things like migrating the mesos codebase style to one which can be
as mechanically enforced as possible or resolving. I also potentially see
some things like directory moving happening in the future (making it so
there isn't a 3rdparty embedded in a 3rdparty).

Practically if we are making sweeping changes which will effect everything
dramatically, it is a lot cleaner to have one commit which makes the
switch, even though it acts as a synchronization point for development,
because then it is one commit which gets encountered in a 'git blame' (And
you can then do another blame starting at that one commit).

On Wed, Oct 15, 2014 at 12:49 PM, Dominic Hamon <dh...@twopensource.com>
wrote:

> +1
>
> until we get to the point where the out-of-compliance files are minimal,
> doing them as we go should be sufficient. It moves the code-base forward to
> compliance without being disruptive.
>
> it does make RRs more complex as there are changes that are not geared
> towards the main aim of the patch, but this is still less burden on the
> community as a whole.
>
> On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman <benh@eecs.berkeley.edu
> >
> wrote:
>
> > My $0.02: Let's make the cleanups as we go. If you work in a function
> that
> > can get cleaned up, clean it up. Maybe clean up the entire file if you're
> > making changes to multiple functions. Doing this iteratively not only
> keeps
> > folks from having to do tedious rebases but it also preserves, for the
> most
> > part, the git blame history which can be invaluable when working in a
> file
> > and trying to ask for some help.
> >
> > On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff <to...@me.com>
> wrote:
> >
> > > Hey Everyone,
> > >
> > > I would like to reach out to the developer community for making sure
> that
> > > we find a consensus on
> https://issues.apache.org/jira/browse/MESOS-1872
> > <
> > > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > > code-base affecting changes.
> > >
> > > Evelina has bravely proposed three review requests
> > > (mesos/libprocess/stout) for covering the ticket. There is however some
> > > greater risk involved and I wanted to be sure that we are all aware of
> > the
> > > pro’s and con's of such big cleanups.
> > >
> > > + we may need to do cleanups - even major ones at some point, hence I
> > > think we need a consensus once and for all regarding tickets of the
> above
> > > nature
> > > - almost all existing RRs will possibly get invalid and everyone with
> > work
> > > in flight needs to rebase (possibly rather tedious task in particular
> > case).
> > >
> > > There may be more.
> > >
> > > The only way I can currently see this happening with minimal friction
> is
> > > finding a certain date and even time for doing this on a very quick,
> > > propose/review/commit.
> > >
> > > What do you think?
> > >
> > > cheers!
> > > Till
> > >
> > >
> >
>
>
>
> --
> Dominic Hamon | @mrdo | Twitter
> *There are no bad ideas; only good ideas that go horribly wrong.*
>

Re: Large changes on the codebase due to MESOS-1872

[Dominic Hamon <dh...@twopensource.com>]

+1

until we get to the point where the out-of-compliance files are minimal,
doing them as we go should be sufficient. It moves the code-base forward to
compliance without being disruptive.

it does make RRs more complex as there are changes that are not geared
towards the main aim of the patch, but this is still less burden on the
community as a whole.

On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman <be...@eecs.berkeley.edu>
wrote:

> My $0.02: Let's make the cleanups as we go. If you work in a function that
> can get cleaned up, clean it up. Maybe clean up the entire file if you're
> making changes to multiple functions. Doing this iteratively not only keeps
> folks from having to do tedious rebases but it also preserves, for the most
> part, the git blame history which can be invaluable when working in a file
> and trying to ask for some help.
>
> On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff <to...@me.com> wrote:
>
> > Hey Everyone,
> >
> > I would like to reach out to the developer community for making sure that
> > we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
> <
> > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > code-base affecting changes.
> >
> > Evelina has bravely proposed three review requests
> > (mesos/libprocess/stout) for covering the ticket. There is however some
> > greater risk involved and I wanted to be sure that we are all aware of
> the
> > pro’s and con's of such big cleanups.
> >
> > + we may need to do cleanups - even major ones at some point, hence I
> > think we need a consensus once and for all regarding tickets of the above
> > nature
> > - almost all existing RRs will possibly get invalid and everyone with
> work
> > in flight needs to rebase (possibly rather tedious task in particular
> case).
> >
> > There may be more.
> >
> > The only way I can currently see this happening with minimal friction is
> > finding a certain date and even time for doing this on a very quick,
> > propose/review/commit.
> >
> > What do you think?
> >
> > cheers!
> > Till
> >
> >
>



-- 
Dominic Hamon | @mrdo | Twitter
*There are no bad ideas; only good ideas that go horribly wrong.*

Re: Large changes on the codebase due to MESOS-1872

[Benjamin Hindman <be...@eecs.berkeley.edu>]

My $0.02: Let's make the cleanups as we go. If you work in a function that
can get cleaned up, clean it up. Maybe clean up the entire file if you're
making changes to multiple functions. Doing this iteratively not only keeps
folks from having to do tedious rebases but it also preserves, for the most
part, the git blame history which can be invaluable when working in a file
and trying to ask for some help.

On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff <to...@me.com> wrote:

> Hey Everyone,
>
> I would like to reach out to the developer community for making sure that
> we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872 <
> https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> code-base affecting changes.
>
> Evelina has bravely proposed three review requests
> (mesos/libprocess/stout) for covering the ticket. There is however some
> greater risk involved and I wanted to be sure that we are all aware of the
> pro’s and con's of such big cleanups.
>
> + we may need to do cleanups - even major ones at some point, hence I
> think we need a consensus once and for all regarding tickets of the above
> nature
> - almost all existing RRs will possibly get invalid and everyone with work
> in flight needs to rebase (possibly rather tedious task in particular case).
>
> There may be more.
>
> The only way I can currently see this happening with minimal friction is
> finding a certain date and even time for doing this on a very quick,
> propose/review/commit.
>
> What do you think?
>
> cheers!
> Till
>
>

Re: Large changes on the codebase due to MESOS-1872

[Tim St Clair <ts...@redhat.com>]

It would be nice is we had a place where it is ok to make such changes, and a place for stable incremental changes.  

-stable 
-unstable 

In absence of that, I agree with the consensus.

Cheers,
Tim 


----- Original Message -----
> From: "Till Toenshoff" <to...@me.com>
> To: "mesos" <de...@mesos.apache.org>
> Sent: Wednesday, October 15, 2014 2:13:12 PM
> Subject: Large changes on the codebase due to MESOS-1872
> 
> Hey Everyone,
> 
> I would like to reach out to the developer community for making sure that we
> find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
> <https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> code-base affecting changes.
> 
> Evelina has bravely proposed three review requests (mesos/libprocess/stout)
> for covering the ticket. There is however some greater risk involved and I
> wanted to be sure that we are all aware of the pro’s and con's of such big
> cleanups.
> 
> + we may need to do cleanups - even major ones at some point, hence I think
> we need a consensus once and for all regarding tickets of the above nature
> - almost all existing RRs will possibly get invalid and everyone with work in
> flight needs to rebase (possibly rather tedious task in particular case).
> 
> There may be more.
> 
> The only way I can currently see this happening with minimal friction is
> finding a certain date and even time for doing this on a very quick,
> propose/review/commit.
> 
> What do you think?
> 
> cheers!
> Till
> 
> 

-- 
Cheers,
Timothy St. Clair
Red Hat Inc.