Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Emmanuel Bourg-3
Le 31/05/2016 à 03:37, [hidden email] a écrit :
> Repository: commons-math
> Updated Branches:
>   refs/heads/master ffc1caada -> 598edc127
>
>
> Reverting changes on "master" as per Commons Math policy.
>
> The corresponding changes have been ported into branch "develop".

Hi all,

The repository policy for [math] is a bit confusing in my opinion.
People are used to work on the master/trunk branch, and if we want to
make the collaboration on our components as easy as possible I think we
should stick to the common expectation. Otherwise contributors sending
pull requests from GitHub are likely to base their work against the
wrong branch, inducing extra work for the committers to rebase the
changes against the real development trunk. Also I think it would be
preferable for all Apache Commons components to follow the same
repository layout.

Having a stable branch isn't a bad idea (I've never felt the need for it
on my projects though, and this adds some steps to the release process
that we vowed to simplify), but this can be achieved with a separate
'releases' branch.

So for Commons Math I'd suggest renaming the branches as follow:
  master  -> releases (or just drop it)
  develop -> master

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Gilles Sadowski
On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:

> Le 31/05/2016 à 03:37, [hidden email] a écrit :
>> Repository: commons-math
>> Updated Branches:
>>   refs/heads/master ffc1caada -> 598edc127
>>
>>
>> Reverting changes on "master" as per Commons Math policy.
>>
>> The corresponding changes have been ported into branch "develop".
>
> Hi all,
>
> The repository policy for [math] is a bit confusing in my opinion.

It causes confusion indeed but not because it is confusing.
Rather because of years of svn usage which git vows to change IIUC.

> People are used to work on the master/trunk branch,

This is a wrong expectation for git workflow.
For anything (except perhaps trivial changes), people are expected
to work on a dedicated branch.
Cf. rationale in the document here:
   http://nvie.com/posts/a-successful-git-branching-model/

Discussion (and agreement) here:
   http://markmail.org/message/7lnus64entdwj4vo

> and if we want to
> make the collaboration on our components as easy as possible I think
> we
> should stick to the common expectation. Otherwise contributors
> sending
> pull requests from GitHub are likely to base their work against the
> wrong branch, inducing extra work for the committers to rebase the
> changes against the real development trunk. Also I think it would be
> preferable for all Apache Commons components to follow the same
> repository layout.
>
> Having a stable branch isn't a bad idea (I've never felt the need for
> it
> on my projects though, and this adds some steps to the release
> process
> that we vowed to simplify), but this can be achieved with a separate
> 'releases' branch.
>
> So for Commons Math I'd suggest renaming the branches as follow:
>   master  -> releases (or just drop it)
>   develop -> master

I agree that a workflow that includes Github must be clarified.
An issue was opened:
   https://issues.apache.org/jira/browse/MATH-1357

Unfortunately I'm not familiar with Github in order to figure out
the right way to interface its expectations (e.g. Do all projects
exported to Github use only one branch?) with our new development
model (that requires creating a "feature branch" for each feature
rather than modify "master" or "develop" directly).

This especially true for one-off contributors: we _don't_ want
"master" to be modified by code of yet unknown quality.

Regards,
Gilles

>
> Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Emmanuel Bourg-3
Le 31/05/2016 à 10:58, Gilles a écrit :

> It causes confusion indeed but not because it is confusing.
> Rather because of years of svn usage which git vows to change IIUC.

It's confusing because it's unexpected. If you look at the GitHub
projects the majority don't use this so called "git workflow" (that
should actually be named "Vincent Driessen's Git workflow", its name
make it sound like it's the one true way to use Git, but it isn't).

Using feature branches is fine, but I'd advocate merging to 'master'
instead of 'develop'. If you switch the branch names as I suggested you
can keep the same workflow *and* make it less confusing for newcomers.
Best of both worlds.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Gilles Sadowski
On Tue, 31 May 2016 11:33:19 +0200, Emmanuel Bourg wrote:
> Le 31/05/2016 à 10:58, Gilles a écrit :
>
>> It causes confusion indeed but not because it is confusing.
>> Rather because of years of svn usage which git vows to change IIUC.
>
> It's confusing because it's unexpected. If you look at the GitHub
> projects the majority don't use this so called "git workflow" (that
> should actually be named "Vincent Driessen's Git workflow", its name
> make it sound like it's the one true way to use Git, but it isn't).

I pointed to the reference of the discussion that took place on
this very ML.

It didn't take into account what people do on Github, because nobody
raised it.

> Using feature branches is fine, but I'd advocate merging to 'master'
> instead of 'develop'. If you switch the branch names as I suggested
> you
> can keep the same workflow *and* make it less confusing for
> newcomers.
> Best of both worlds.

Are you positive that people will not continue updating "master"?

That is the key point, and not that the official (reviewed/accepted
by a committer) code is in a branch named "master" or "develop".

The nice thing with the current "Vincent Driessen's Git workflow" is
that it is _documented_.  Once people are informed how to
contribute[1],
it is not a minor detail to be able to point them to a simple,
self-contained description of a way to use git, rather than having
to figure it out by themselves.

Or are we going to assume that all future contributors will come
through Github?  That would change the perspective, I agree.
But it would require to subsume more of our processes to the Github
workflow than just changing a name.
People (not me) advocated going in that direction, such as using
the Github forum tools rather than this ML to discuss issues.

Singularly, I find this issue not the most urgent to deal with
as far as Commons Math is concerned!
[Especially when not only consensus was reached on this workflow
but unanimity!]

Gilles

[1] As you pointed out, there isn't a single workflow that can be
     assumed for every project.
     I proposed to select one where there were several, making it
     confusing to argue with newcomers as to what to do.

>
> Emmanuel Bourg
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Emmanuel Bourg-3
Le 31/05/2016 à 12:41, Gilles a écrit :

> Are you positive that people will not continue updating "master"?

Well that depends on the modification pushed:
- for trivial changes like updating the version of a maven plugin there
is no point creating a feature branch, it can be committed directly on
the trunk/master.
- for simple fixes that don't change the API and come with a good test
case, here again a direct commit on master is easier.
- for more complex changes involving design decisions, a feature branch
is a good idea (unless a clear consensus was reached first on the
mailing list).

Note that GitHub pull requests are implicitly feature branches, even if
they are committed on the master branch of the cloned repository. So my
view of what can be committed directly to the master branch really
applies to the Apache Commons committers.


> Or are we going to assume that all future contributors will come
> through Github?  That would change the perspective, I agree.

GitHub has normalized the contribution process to open source projects,
so I wouldn't be surprised if an increasing share of contributions come
from GitHub in the future.


> People (not me) advocated going in that direction, such as using
> the Github forum tools rather than this ML to discuss issues.

I'm not advocating that though, and GitHub doesn't offer forums or
mailing lists anyway.


> Singularly, I find this issue not the most urgent to deal with
> as far as Commons Math is concerned!
> [Especially when not only consensus was reached on this workflow
> but unanimity!]

I agree this isn't urgent, I was just reacting to the commit reversal.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Gilles Sadowski
On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote:

> Le 31/05/2016 à 12:41, Gilles a écrit :
>
>> Are you positive that people will not continue updating "master"?
>
> Well that depends on the modification pushed:
> - for trivial changes like updating the version of a maven plugin
> there
> is no point creating a feature branch, it can be committed directly
> on
> the trunk/master.

Generally yes.
But then mileage start to vary, as to what is trivial for one and
not so for another.

Hence I tend to limit "trivial" to Javadoc changes, unuse "import"
statements, or a commit that is required to fix a broken build.

For all the rest, I've been taught here (by you know who) that the
smaller the changeset the better.

> - for simple fixes that don't change the API and come with a good
> test
> case, here again a direct commit on master is easier.

The point which people make about git is that it is no less easy
to create a temporary branch.
E.g. you pull code from an unknown person and run "mvn site" so
you can verify that CheckStyle and FindBugs are happy, and if
not you know that something must be fixed with that contribution;
but it does not prevent you to easily check that your own work
(in another branch then) is clean.

> - for more complex changes involving design decisions, a feature
> branch
> is a good idea (unless a clear consensus was reached first on the
> mailing list).

The devil is in the details.  You shouldn't want to have non reviewed
code on the branch shared by everybody.

That's why I create remote feature branches and call for review
(through JIRA) in order to increase the likelihood that clean code
code is merge into the shared branch.

>
> Note that GitHub pull requests are implicitly feature branches, even
> if
> they are committed on the master branch of the cloned repository.

I'm not following.
Sorry I have zero experience with Github.

> So my
> view of what can be committed directly to the master branch really
> applies to the Apache Commons committers.

Then I don't understand; committers should know how to contribute...
We'll probably make mistakes (e.g. I committed some changes twice,
because of a "rebase" I think) but the excuse should not be that
on some other platform, they do it that way.

The problem I had with Eric (no offense ;-) is that some part of
the process for contributing through Github was not working.
[I still don't know what the problem was.]

Certainly it would help if that situation could be avoided in the
future.

>> Or are we going to assume that all future contributors will come
>> through Github?  That would change the perspective, I agree.
>
> GitHub has normalized the contribution process to open source
> projects,
> so I wouldn't be surprised if an increasing share of contributions
> come
> from GitHub in the future.

All the more then for a global solution (Commons level? Apache level?)

Currently, we are still wondering which component to migrate to
git and when to do it...

>> People (not me) advocated going in that direction, such as using
>> the Github forum tools rather than this ML to discuss issues.
>
> I'm not advocating that though, and GitHub doesn't offer forums or
> mailing lists anyway.

Again, I'm not a Github user, but I seem to recall that someone
mentioned how easier it was to collaborate on Github...

>> Singularly, I find this issue not the most urgent to deal with
>> as far as Commons Math is concerned!
>> [Especially when not only consensus was reached on this workflow
>> but unanimity!]
>
> I agree this isn't urgent,

Thanks.

> I was just reacting to the commit reversal.

As it happened, the additional burden was for me.  But I'm OK to
do that (once in a while) in order to stick with a transparent
policy (and the same for everyone for a given component).
Even if an expert knows what he is doing, it is equally important
that non-experts and newcomers also understand what is happening
and even learn from it.
The Apache environment is not very successful at educating the
newcomers[1] despite the problem being known for a long time. :-(

Gilles

>
> Emmanuel Bourg

[1] And that includes me who obviously (?) did not get it after 10
     years.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Matt Sicker
In reply to this post by Gilles Sadowski
Why not just rename master to something like stable, then rename develop to
master? Less confusing to people who don't know about git-flow.

On 31 May 2016 at 03:58, Gilles <[hidden email]> wrote:

> On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:
>
>> Le 31/05/2016 à 03:37, [hidden email] a écrit :
>>
>>> Repository: commons-math
>>> Updated Branches:
>>>   refs/heads/master ffc1caada -> 598edc127
>>>
>>>
>>> Reverting changes on "master" as per Commons Math policy.
>>>
>>> The corresponding changes have been ported into branch "develop".
>>>
>>
>> Hi all,
>>
>> The repository policy for [math] is a bit confusing in my opinion.
>>
>
> It causes confusion indeed but not because it is confusing.
> Rather because of years of svn usage which git vows to change IIUC.
>
> People are used to work on the master/trunk branch,
>>
>
> This is a wrong expectation for git workflow.
> For anything (except perhaps trivial changes), people are expected
> to work on a dedicated branch.
> Cf. rationale in the document here:
>   http://nvie.com/posts/a-successful-git-branching-model/
>
> Discussion (and agreement) here:
>   http://markmail.org/message/7lnus64entdwj4vo
>
> and if we want to
>> make the collaboration on our components as easy as possible I think we
>> should stick to the common expectation. Otherwise contributors sending
>> pull requests from GitHub are likely to base their work against the
>> wrong branch, inducing extra work for the committers to rebase the
>> changes against the real development trunk. Also I think it would be
>> preferable for all Apache Commons components to follow the same
>> repository layout.
>>
>> Having a stable branch isn't a bad idea (I've never felt the need for it
>> on my projects though, and this adds some steps to the release process
>> that we vowed to simplify), but this can be achieved with a separate
>> 'releases' branch.
>>
>> So for Commons Math I'd suggest renaming the branches as follow:
>>   master  -> releases (or just drop it)
>>   develop -> master
>>
>
> I agree that a workflow that includes Github must be clarified.
> An issue was opened:
>   https://issues.apache.org/jira/browse/MATH-1357
>
> Unfortunately I'm not familiar with Github in order to figure out
> the right way to interface its expectations (e.g. Do all projects
> exported to Github use only one branch?) with our new development
> model (that requires creating a "feature branch" for each feature
> rather than modify "master" or "develop" directly).
>
> This especially true for one-off contributors: we _don't_ want
> "master" to be modified by code of yet unknown quality.
>
> Regards,
> Gilles
>
>
>
>> Emmanuel Bourg
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Rob Tompkins
On May 31, 2016, at 10:21 AM, Matt Sicker <[hidden email]> wrote:
>
> Why not just rename master to something like stable, then rename develop to
> master? Less confusing to people who don't know about git-flow.

Generally when I think about an arbitrary github project I would think that the “master” branch reflects the latest released code, and the “develop” branch should reflect the inflight development. Assuming that the history of the branches is properly maintained, a topic branch based in master should be able to be worked on and then PR’d into develop (assuming that the individual doing the work has accommodated for the merge conflicts in migrating it to develop).

If the project is mirrored in git, then I would argue that the semantics of the version control system should be used as opposed to using our own semantics because then the arbitrary developer coming from another git project can quickly figure out how to work with the codebase.

All the best,
-Rob

>
> On 31 May 2016 at 03:58, Gilles <[hidden email]> wrote:
>
>> On Tue, 31 May 2016 09:34:25 +0200, Emmanuel Bourg wrote:
>>
>>> Le 31/05/2016 à 03:37, [hidden email] a écrit :
>>>
>>>> Repository: commons-math
>>>> Updated Branches:
>>>>  refs/heads/master ffc1caada -> 598edc127
>>>>
>>>>
>>>> Reverting changes on "master" as per Commons Math policy.
>>>>
>>>> The corresponding changes have been ported into branch "develop".
>>>>
>>>
>>> Hi all,
>>>
>>> The repository policy for [math] is a bit confusing in my opinion.
>>>
>>
>> It causes confusion indeed but not because it is confusing.
>> Rather because of years of svn usage which git vows to change IIUC.
>>
>> People are used to work on the master/trunk branch,
>>>
>>
>> This is a wrong expectation for git workflow.
>> For anything (except perhaps trivial changes), people are expected
>> to work on a dedicated branch.
>> Cf. rationale in the document here:
>>  http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Discussion (and agreement) here:
>>  http://markmail.org/message/7lnus64entdwj4vo
>>
>> and if we want to
>>> make the collaboration on our components as easy as possible I think we
>>> should stick to the common expectation. Otherwise contributors sending
>>> pull requests from GitHub are likely to base their work against the
>>> wrong branch, inducing extra work for the committers to rebase the
>>> changes against the real development trunk. Also I think it would be
>>> preferable for all Apache Commons components to follow the same
>>> repository layout.
>>>
>>> Having a stable branch isn't a bad idea (I've never felt the need for it
>>> on my projects though, and this adds some steps to the release process
>>> that we vowed to simplify), but this can be achieved with a separate
>>> 'releases' branch.
>>>
>>> So for Commons Math I'd suggest renaming the branches as follow:
>>>  master  -> releases (or just drop it)
>>>  develop -> master
>>>
>>
>> I agree that a workflow that includes Github must be clarified.
>> An issue was opened:
>>  https://issues.apache.org/jira/browse/MATH-1357
>>
>> Unfortunately I'm not familiar with Github in order to figure out
>> the right way to interface its expectations (e.g. Do all projects
>> exported to Github use only one branch?) with our new development
>> model (that requires creating a "feature branch" for each feature
>> rather than modify "master" or "develop" directly).
>>
>> This especially true for one-off contributors: we _don't_ want
>> "master" to be modified by code of yet unknown quality.
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Emmanuel Bourg
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

dbrosIus
In reply to this post by Emmanuel Bourg-3
Most servers allow you to specify a  default branch so that when you clone a repository you are on that branch.  I'm used to that from github, and didn't think twice about it,  which caused the last problem.  If this is possible here,  it would probably fix most cases. 

-------- Original message --------
From: Gilles <[hidden email]>
Date: 05/31/2016  9:26 AM  (GMT-05:00)
To: [hidden email]
Subject: Re: [math] Repository Policy

On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote:

> Le 31/05/2016 à 12:41, Gilles a écrit :
>
>> Are you positive that people will not continue updating "master"?
>
> Well that depends on the modification pushed:
> - for trivial changes like updating the version of a maven plugin
> there
> is no point creating a feature branch, it can be committed directly
> on
> the trunk/master.

Generally yes.
But then mileage start to vary, as to what is trivial for one and
not so for another.

Hence I tend to limit "trivial" to Javadoc changes, unuse "import"
statements, or a commit that is required to fix a broken build.

For all the rest, I've been taught here (by you know who) that the
smaller the changeset the better.

> - for simple fixes that don't change the API and come with a good
> test
> case, here again a direct commit on master is easier.

The point which people make about git is that it is no less easy
to create a temporary branch.
E.g. you pull code from an unknown person and run "mvn site" so
you can verify that CheckStyle and FindBugs are happy, and if
not you know that something must be fixed with that contribution;
but it does not prevent you to easily check that your own work
(in another branch then) is clean.

> - for more complex changes involving design decisions, a feature
> branch
> is a good idea (unless a clear consensus was reached first on the
> mailing list).

The devil is in the details.  You shouldn't want to have non reviewed
code on the branch shared by everybody.

That's why I create remote feature branches and call for review
(through JIRA) in order to increase the likelihood that clean code
code is merge into the shared branch.

>
> Note that GitHub pull requests are implicitly feature branches, even
> if
> they are committed on the master branch of the cloned repository.

I'm not following.
Sorry I have zero experience with Github.

> So my
> view of what can be committed directly to the master branch really
> applies to the Apache Commons committers.

Then I don't understand; committers should know how to contribute...
We'll probably make mistakes (e.g. I committed some changes twice,
because of a "rebase" I think) but the excuse should not be that
on some other platform, they do it that way.

The problem I had with Eric (no offense ;-) is that some part of
the process for contributing through Github was not working.
[I still don't know what the problem was.]

Certainly it would help if that situation could be avoided in the
future.

>> Or are we going to assume that all future contributors will come
>> through Github?  That would change the perspective, I agree.
>
> GitHub has normalized the contribution process to open source
> projects,
> so I wouldn't be surprised if an increasing share of contributions
> come
> from GitHub in the future.

All the more then for a global solution (Commons level? Apache level?)

Currently, we are still wondering which component to migrate to
git and when to do it...

>> People (not me) advocated going in that direction, such as using
>> the Github forum tools rather than this ML to discuss issues.
>
> I'm not advocating that though, and GitHub doesn't offer forums or
> mailing lists anyway.

Again, I'm not a Github user, but I seem to recall that someone
mentioned how easier it was to collaborate on Github...

>> Singularly, I find this issue not the most urgent to deal with
>> as far as Commons Math is concerned!
>> [Especially when not only consensus was reached on this workflow
>> but unanimity!]
>
> I agree this isn't urgent,

Thanks.

> I was just reacting to the commit reversal.

As it happened, the additional burden was for me.  But I'm OK to
do that (once in a while) in order to stick with a transparent
policy (and the same for everyone for a given component).
Even if an expert knows what he is doing, it is equally important
that non-experts and newcomers also understand what is happening
and even learn from it.
The Apache environment is not very successful at educating the
newcomers[1] despite the problem being known for a long time. :-(

Gilles

>
> Emmanuel Bourg

[1] And that includes me who obviously (?) did not get it after 10
     years.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy (was: Reverting changes on "master" as per Commons Math policy)

Artem Barger
In reply to this post by Rob Tompkins
On Tue, May 31, 2016 at 5:43 PM, Rob Tompkins <[hidden email]> wrote:

> On May 31, 2016, at 10:21 AM, Matt Sicker <[hidden email]> wrote:
> >
> > Why not just rename master to something like stable, then rename develop
> to
> > master? Less confusing to people who don't know about git-flow.
>
> Generally when I think about an arbitrary github project I would think
> that the “master” branch reflects the latest released code, and the
> “develop” branch should reflect the inflight development. Assuming that the
> history of the branches is properly maintained, a topic branch based in
> master should be able to be worked on and then PR’d into develop (assuming
> that the individual doing the work has accommodated for the merge conflicts
> in migrating it to develop).
>
> If the project is mirrored in git, then I would argue that the semantics
> of the version control system should be used as opposed to using our own
> semantics because then the arbitrary developer coming from another git
> project can quickly figure out how to work with the codebase.
> ​
>

​Well, IMO an average GutHub project usually uses a master branch as
ongoing branch for development and has "release" branch or even several
branches​ in case there are a couple of versions for release. Of course
working w/ feature branch for separate tasks merging/rebasing them later
into the master. But I think this is a matter of project policies and
agreements, important branches usually protected from accepting direct
commits into them.

BR,
- Artem.
Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Stian Soiland-Reyes
In reply to this post by dbrosIus
To reduce complexity and confusion, I would generally hope for
"master" to be where development happens, rather than an additional
"develop" - as that means we now have three levels of "releases" to
deal with:

* tagged/voted/published releases
* a supposedly stable "master" that is somewhere between last release
and develop, in a "releasable state"
* a probably unstable "develop" which merges feature branches but
might take lots of extra effort before it can be released

The problem is that people will still end up making feature branches
and pull requests from "master"  - changing the default branch in
GitHub does a lot to mitigate that, but perhaps better if we end up
agreeing to this model for a component, then we can avoid "master"
altogether and rather call it "stable"?

(Note: "master" is also special in git.apache.org as it does not allow
removing commits)


On 31 May 2016 at 15:52, dbrosIus <[hidden email]> wrote:

> Most servers allow you to specify a  default branch so that when you clone a repository you are on that branch.  I'm used to that from github, and didn't think twice about it,  which caused the last problem.  If this is possible here,  it would probably fix most cases.
>
> -------- Original message --------
> From: Gilles <[hidden email]>
> Date: 05/31/2016  9:26 AM  (GMT-05:00)
> To: [hidden email]
> Subject: Re: [math] Repository Policy
>
> On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote:
>> Le 31/05/2016 à 12:41, Gilles a écrit :
>>
>>> Are you positive that people will not continue updating "master"?
>>
>> Well that depends on the modification pushed:
>> - for trivial changes like updating the version of a maven plugin
>> there
>> is no point creating a feature branch, it can be committed directly
>> on
>> the trunk/master.
>
> Generally yes.
> But then mileage start to vary, as to what is trivial for one and
> not so for another.
>
> Hence I tend to limit "trivial" to Javadoc changes, unuse "import"
> statements, or a commit that is required to fix a broken build.
>
> For all the rest, I've been taught here (by you know who) that the
> smaller the changeset the better.
>
>> - for simple fixes that don't change the API and come with a good
>> test
>> case, here again a direct commit on master is easier.
>
> The point which people make about git is that it is no less easy
> to create a temporary branch.
> E.g. you pull code from an unknown person and run "mvn site" so
> you can verify that CheckStyle and FindBugs are happy, and if
> not you know that something must be fixed with that contribution;
> but it does not prevent you to easily check that your own work
> (in another branch then) is clean.
>
>> - for more complex changes involving design decisions, a feature
>> branch
>> is a good idea (unless a clear consensus was reached first on the
>> mailing list).
>
> The devil is in the details.  You shouldn't want to have non reviewed
> code on the branch shared by everybody.
>
> That's why I create remote feature branches and call for review
> (through JIRA) in order to increase the likelihood that clean code
> code is merge into the shared branch.
>
>>
>> Note that GitHub pull requests are implicitly feature branches, even
>> if
>> they are committed on the master branch of the cloned repository.
>
> I'm not following.
> Sorry I have zero experience with Github.
>
>> So my
>> view of what can be committed directly to the master branch really
>> applies to the Apache Commons committers.
>
> Then I don't understand; committers should know how to contribute...
> We'll probably make mistakes (e.g. I committed some changes twice,
> because of a "rebase" I think) but the excuse should not be that
> on some other platform, they do it that way.
>
> The problem I had with Eric (no offense ;-) is that some part of
> the process for contributing through Github was not working.
> [I still don't know what the problem was.]
>
> Certainly it would help if that situation could be avoided in the
> future.
>
>>> Or are we going to assume that all future contributors will come
>>> through Github?  That would change the perspective, I agree.
>>
>> GitHub has normalized the contribution process to open source
>> projects,
>> so I wouldn't be surprised if an increasing share of contributions
>> come
>> from GitHub in the future.
>
> All the more then for a global solution (Commons level? Apache level?)
>
> Currently, we are still wondering which component to migrate to
> git and when to do it...
>
>>> People (not me) advocated going in that direction, such as using
>>> the Github forum tools rather than this ML to discuss issues.
>>
>> I'm not advocating that though, and GitHub doesn't offer forums or
>> mailing lists anyway.
>
> Again, I'm not a Github user, but I seem to recall that someone
> mentioned how easier it was to collaborate on Github...
>
>>> Singularly, I find this issue not the most urgent to deal with
>>> as far as Commons Math is concerned!
>>> [Especially when not only consensus was reached on this workflow
>>> but unanimity!]
>>
>> I agree this isn't urgent,
>
> Thanks.
>
>> I was just reacting to the commit reversal.
>
> As it happened, the additional burden was for me.  But I'm OK to
> do that (once in a while) in order to stick with a transparent
> policy (and the same for everyone for a given component).
> Even if an expert knows what he is doing, it is equally important
> that non-experts and newcomers also understand what is happening
> and even learn from it.
> The Apache environment is not very successful at educating the
> newcomers[1] despite the problem being known for a long time. :-(
>
> Gilles
>
>>
>> Emmanuel Bourg
>
> [1] And that includes me who obviously (?) did not get it after 10
>      years.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [math] Repository Policy

Rob Tompkins
That seems reasonable based upon the other git based commons repos.

-Rob

> On May 31, 2016, at 12:08 PM, Stian Soiland-Reyes <[hidden email]> wrote:
>
> To reduce complexity and confusion, I would generally hope for
> "master" to be where development happens, rather than an additional
> "develop" - as that means we now have three levels of "releases" to
> deal with:
>
> * tagged/voted/published releases
> * a supposedly stable "master" that is somewhere between last release
> and develop, in a "releasable state"
> * a probably unstable "develop" which merges feature branches but
> might take lots of extra effort before it can be released
>
> The problem is that people will still end up making feature branches
> and pull requests from "master"  - changing the default branch in
> GitHub does a lot to mitigate that, but perhaps better if we end up
> agreeing to this model for a component, then we can avoid "master"
> altogether and rather call it "stable"?
>
> (Note: "master" is also special in git.apache.org as it does not allow
> removing commits)
>
>
>> On 31 May 2016 at 15:52, dbrosIus <[hidden email]> wrote:
>> Most servers allow you to specify a  default branch so that when you clone a repository you are on that branch.  I'm used to that from github, and didn't think twice about it,  which caused the last problem.  If this is possible here,  it would probably fix most cases.
>>
>> -------- Original message --------
>> From: Gilles <[hidden email]>
>> Date: 05/31/2016  9:26 AM  (GMT-05:00)
>> To: [hidden email]
>> Subject: Re: [math] Repository Policy
>>
>>> On Tue, 31 May 2016 13:22:10 +0200, Emmanuel Bourg wrote:
>>>> Le 31/05/2016 à 12:41, Gilles a écrit :
>>>>
>>>> Are you positive that people will not continue updating "master"?
>>>
>>> Well that depends on the modification pushed:
>>> - for trivial changes like updating the version of a maven plugin
>>> there
>>> is no point creating a feature branch, it can be committed directly
>>> on
>>> the trunk/master.
>>
>> Generally yes.
>> But then mileage start to vary, as to what is trivial for one and
>> not so for another.
>>
>> Hence I tend to limit "trivial" to Javadoc changes, unuse "import"
>> statements, or a commit that is required to fix a broken build.
>>
>> For all the rest, I've been taught here (by you know who) that the
>> smaller the changeset the better.
>>
>>> - for simple fixes that don't change the API and come with a good
>>> test
>>> case, here again a direct commit on master is easier.
>>
>> The point which people make about git is that it is no less easy
>> to create a temporary branch.
>> E.g. you pull code from an unknown person and run "mvn site" so
>> you can verify that CheckStyle and FindBugs are happy, and if
>> not you know that something must be fixed with that contribution;
>> but it does not prevent you to easily check that your own work
>> (in another branch then) is clean.
>>
>>> - for more complex changes involving design decisions, a feature
>>> branch
>>> is a good idea (unless a clear consensus was reached first on the
>>> mailing list).
>>
>> The devil is in the details.  You shouldn't want to have non reviewed
>> code on the branch shared by everybody.
>>
>> That's why I create remote feature branches and call for review
>> (through JIRA) in order to increase the likelihood that clean code
>> code is merge into the shared branch.
>>
>>>
>>> Note that GitHub pull requests are implicitly feature branches, even
>>> if
>>> they are committed on the master branch of the cloned repository.
>>
>> I'm not following.
>> Sorry I have zero experience with Github.
>>
>>> So my
>>> view of what can be committed directly to the master branch really
>>> applies to the Apache Commons committers.
>>
>> Then I don't understand; committers should know how to contribute...
>> We'll probably make mistakes (e.g. I committed some changes twice,
>> because of a "rebase" I think) but the excuse should not be that
>> on some other platform, they do it that way.
>>
>> The problem I had with Eric (no offense ;-) is that some part of
>> the process for contributing through Github was not working.
>> [I still don't know what the problem was.]
>>
>> Certainly it would help if that situation could be avoided in the
>> future.
>>
>>>> Or are we going to assume that all future contributors will come
>>>> through Github?  That would change the perspective, I agree.
>>>
>>> GitHub has normalized the contribution process to open source
>>> projects,
>>> so I wouldn't be surprised if an increasing share of contributions
>>> come
>>> from GitHub in the future.
>>
>> All the more then for a global solution (Commons level? Apache level?)
>>
>> Currently, we are still wondering which component to migrate to
>> git and when to do it...
>>
>>>> People (not me) advocated going in that direction, such as using
>>>> the Github forum tools rather than this ML to discuss issues.
>>>
>>> I'm not advocating that though, and GitHub doesn't offer forums or
>>> mailing lists anyway.
>>
>> Again, I'm not a Github user, but I seem to recall that someone
>> mentioned how easier it was to collaborate on Github...
>>
>>>> Singularly, I find this issue not the most urgent to deal with
>>>> as far as Commons Math is concerned!
>>>> [Especially when not only consensus was reached on this workflow
>>>> but unanimity!]
>>>
>>> I agree this isn't urgent,
>>
>> Thanks.
>>
>>> I was just reacting to the commit reversal.
>>
>> As it happened, the additional burden was for me.  But I'm OK to
>> do that (once in a while) in order to stick with a transparent
>> policy (and the same for everyone for a given component).
>> Even if an expert knows what he is doing, it is equally important
>> that non-experts and newcomers also understand what is happening
>> and even learn from it.
>> The Apache environment is not very successful at educating the
>> newcomers[1] despite the problem being known for a long time. :-(
>>
>> Gilles
>>
>>>
>>> Emmanuel Bourg
>>
>> [1] And that includes me who obviously (?) did not get it after 10
>>     years.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons
> http://orcid.org/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]