subject:"Re\: Releasable by default\?"

Re: Releasable by default?

2015-10-14 Thread Karl Heinz Marbaise

Hi,

On 10/14/15 2:46 PM, Benson Margulies wrote:

On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl  wrote:

I don’t think we need a policy for this, it’s just common sense not to break 
master.

Agreed..

If someone inadvertently makes master not work properly then provide a

> reason and put that change on a branch.

If you missed it is no problem to undone a change if it really hurts...

>  The developer who did it might not have time at
>  the point someone else finds the issue so anyone can
>  correct the issue with a reasonable explanation.

All our projects should work on master. But I’m not going to try and force 
someone to fix the issue by policy if they happen to make a mistake. Just fix 
it and carry on.

'Always working' is not the same as 'always releasable'. From an
English language standpoint, collection of working, interdependent
snapshots is a 'working' state. Your use of the term 'break' is
important here; no one 'broke' anything AFAIK in the sense checking in
grossly broken code; rather, various people rendered various things
unreleasable due to snapshot dependencies, or due to code that is
working, but in their view not ready to release.

I don't think people are making mistakes. I think that they don't
honestly all or always  see 'always releasable' as a guiding
principle.

To be concrete: maven-release-plugin was left unreleasable due to a
snapshot dependency on SCM. SCM is perhaps unreleasable due to several
1/2-cooked JIRAs. A whole raft of plugins are unreleasable due to the
'Maven 3 baseline' project.

My simple answer to this would be: Just fix maven-release-plugin by 
using the last release state of scm...

If you need to fix something on a particular maven plugin simply create 
a branch from the latest release and fix the problem and release 
it...That's it..So i don't see any problem here...

The trunk at the momement represents the current state of development 
and at the moment we are working to get 3.0.0 state working...which does 
not mean the plugins are unreleasable

>
Maybe this one isn't a fair Axiom Scheme

of examples, because I think there was a general consensus to do this
stuff on trunk -- but it is talking quite a long time.

Sure does it takes time cause it's a quite large change and apart from 
that  are all doing this in our spare time...

If the term 'policy' disturbs you due to the implications of coercion,
  then let's not call it a policy. Let's call it a working principle.

To be honest this results in the end to nothing different than a coercion...

I'm not trying to coerce anyone; the Apache veto/revert mechanism for
CTR is perfectly sufficient, as per your remark about 'fix it and move
on.' I perceive a presumption of 'leave it to the person who wants to
make a release to make a branch'. I'd like to move the presumption in
the other direction.

Sometimes it happens someone is working on something...has to do 
something more imporant (private/businees/job) whatever...so the 
priority changes and that's it...we are an open source project

On Oct 14, 2015, at 8:14 AM, Benson Margulies  wrote:

I'd like to open a discussion of a possible policy.

The policy would look something like the following:

___

All of the projects managed by the Maven PMC are maintained in a
releasable condition. If a developer wants to make a change that will
result in an a component being unreleasable for any significant period
of time, that developer is responsible for setting up a branch
structure that preserved the releasability of the component for the
duration. They might do their work on a sandbox branch, or they might
set up a maintenance branch for the current state of the code.
___

I see several advantages to this policy:

1: The work to fix a small problem or add a small feature is
proportionate.  You can't suddenly find yourself needing to release
four components and / or make a branch and do merges to get a fix out
to the users (including yourself).

This does not solve your problem...I have found several times that 
trying to fix a simple thing on the first glance...and the result was 
releases of several parts (shared/etc.)...and in the end a plugin...This 
"policy" will not change the sligthest thing on that...

2: If we ever have to deal with a security fix, we will find it much
less painful.

As already mentioned if we are really in this situation...there is no 
problem to create a separate branch from the last release (plugin, core 
etc.) and fix the problem and release it...

3: We recognize the reality that we're all volunteers, and that good
intentions don't always lead to timely activity.

It seems to me that this is in the general territory of 'CD' which is
pretty popular in the world at large.

for 'CD' we need to make the releases via a Single-Button in Jenkins 
which we don't have at the moment...

Kind regards
Karl Heinz Marbaise

What do people think?

Re: Releasable by default?

2015-10-14 Thread Jason van Zyl

Replace always working with always releasable. To me it means the same thing.

> On Oct 14, 2015, at 8:46 AM, Benson Margulies  wrote:
> 
> On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl  wrote:
>> I don’t think we need a policy for this, it’s just common sense not to break 
>> master.
>> 
>> If someone inadvertently makes master not work properly then provide a 
>> reason and put that change on a branch. The developer who did it might not 
>> have time at the point someone else finds the issue so anyone can correct 
>> the issue with a reasonable explanation.
> 
> 
>> 
>> All our projects should work on master. But I’m not going to try and force 
>> someone to fix the issue by policy if they happen to make a mistake. Just 
>> fix it and carry on.
> 
> 'Always working' is not the same as 'always releasable'. From an
> English language standpoint, collection of working, interdependent
> snapshots is a 'working' state. Your use of the term 'break' is
> important here; no one 'broke' anything AFAIK in the sense checking in
> grossly broken code; rather, various people rendered various things
> unreleasable due to snapshot dependencies, or due to code that is
> working, but in their view not ready to release.
> 
> I don't think people are making mistakes. I think that they don't
> honestly all or always  see 'always releasable' as a guiding
> principle.
> 
> To be concrete: maven-release-plugin was left unreleasable due to a
> snapshot dependency on SCM. SCM is perhaps unreleasable due to several
> 1/2-cooked JIRAs. A whole raft of plugins are unreleasable due to the
> 'Maven 3 baseline' project. Maybe this one isn't a fair Axiom Scheme
> of examples, because I think there was a general consensus to do this
> stuff on trunk -- but it is talking quite a long time.
> 
> If the term 'policy' disturbs you due to the implications of coercion,
> then let's not call it a policy. Let's call it a working principle.
> I'm not trying to coerce anyone; the Apache veto/revert mechanism for
> CTR is perfectly sufficient, as per your remark about 'fix it and move
> on.' I perceive a presumption of 'leave it to the person who wants to
> make a release to make a branch'. I'd like to move the presumption in
> the other direction.
> 
> 
> 
>> 
>>> On Oct 14, 2015, at 8:14 AM, Benson Margulies  wrote:
>>> 
>>> I'd like to open a discussion of a possible policy.
>>> 
>>> The policy would look something like the following:
>>> 
>>> ___
>>> 
>>> All of the projects managed by the Maven PMC are maintained in a
>>> releasable condition. If a developer wants to make a change that will
>>> result in an a component being unreleasable for any significant period
>>> of time, that developer is responsible for setting up a branch
>>> structure that preserved the releasability of the component for the
>>> duration. They might do their work on a sandbox branch, or they might
>>> set up a maintenance branch for the current state of the code.
>>> ___
>>> 
>>> 
>>> I see several advantages to this policy:
>>> 
>>> 1: The work to fix a small problem or add a small feature is
>>> proportionate.  You can't suddenly find yourself needing to release
>>> four components and / or make a branch and do merges to get a fix out
>>> to the users (including yourself).
>>> 
>>> 2: If we ever have to deal with a security fix, we will find it much
>>> less painful.
>>> 
>>> 3: We recognize the reality that we're all volunteers, and that good
>>> intentions don't always lead to timely activity.
>>> 
>>> It seems to me that this is in the general territory of 'CD' which is
>>> pretty popular in the world at large.
>>> 
>>> What do people think?
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> --
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> -
>> 
>> What matters is not ideas, but the people who have them. Good people can fix 
>> bad ideas, but good ideas can't save bad people.
>> 
>> -- Paul Graham
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io

Re: Releasable by default?

2015-10-14 Thread Jason van Zyl

I don’t think we need a policy for this, it’s just common sense not to break 
master.

If someone inadvertently makes master not work properly then provide a reason 
and put that change on a branch. The developer who did it might not have time 
at the point someone else finds the issue so anyone can correct the issue with 
a reasonable explanation. 

All our projects should work on master. But I’m not going to try and force 
someone to fix the issue by policy if they happen to make a mistake. Just fix 
it and carry on.

> On Oct 14, 2015, at 8:14 AM, Benson Margulies  wrote:
> 
> I'd like to open a discussion of a possible policy.
> 
> The policy would look something like the following:
> 
> ___
> 
> All of the projects managed by the Maven PMC are maintained in a
> releasable condition. If a developer wants to make a change that will
> result in an a component being unreleasable for any significant period
> of time, that developer is responsible for setting up a branch
> structure that preserved the releasability of the component for the
> duration. They might do their work on a sandbox branch, or they might
> set up a maintenance branch for the current state of the code.
> ___
> 
> 
> I see several advantages to this policy:
> 
> 1: The work to fix a small problem or add a small feature is
> proportionate.  You can't suddenly find yourself needing to release
> four components and / or make a branch and do merges to get a fix out
> to the users (including yourself).
> 
> 2: If we ever have to deal with a security fix, we will find it much
> less painful.
> 
> 3: We recognize the reality that we're all volunteers, and that good
> intentions don't always lead to timely activity.
> 
> It seems to me that this is in the general territory of 'CD' which is
> pretty popular in the world at large.
> 
> What do people think?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

What matters is not ideas, but the people who have them. Good people can fix 
bad ideas, but good ideas can't save bad people. 

 -- Paul Graham













-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Releasable by default?

2015-10-14 Thread Benson Margulies

On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl  wrote:
> I don’t think we need a policy for this, it’s just common sense not to break 
> master.
>
> If someone inadvertently makes master not work properly then provide a reason 
> and put that change on a branch. The developer who did it might not have time 
> at the point someone else finds the issue so anyone can correct the issue 
> with a reasonable explanation.

>
> All our projects should work on master. But I’m not going to try and force 
> someone to fix the issue by policy if they happen to make a mistake. Just fix 
> it and carry on.

'Always working' is not the same as 'always releasable'. From an
English language standpoint, collection of working, interdependent
snapshots is a 'working' state. Your use of the term 'break' is
important here; no one 'broke' anything AFAIK in the sense checking in
grossly broken code; rather, various people rendered various things
unreleasable due to snapshot dependencies, or due to code that is
working, but in their view not ready to release.

I don't think people are making mistakes. I think that they don't
honestly all or always  see 'always releasable' as a guiding
principle.

To be concrete: maven-release-plugin was left unreleasable due to a
snapshot dependency on SCM. SCM is perhaps unreleasable due to several
1/2-cooked JIRAs. A whole raft of plugins are unreleasable due to the
'Maven 3 baseline' project. Maybe this one isn't a fair Axiom Scheme
of examples, because I think there was a general consensus to do this
stuff on trunk -- but it is talking quite a long time.

If the term 'policy' disturbs you due to the implications of coercion,
 then let's not call it a policy. Let's call it a working principle.
I'm not trying to coerce anyone; the Apache veto/revert mechanism for
CTR is perfectly sufficient, as per your remark about 'fix it and move
on.' I perceive a presumption of 'leave it to the person who wants to
make a release to make a branch'. I'd like to move the presumption in
the other direction.

>
>> On Oct 14, 2015, at 8:14 AM, Benson Margulies  wrote:
>>
>> I'd like to open a discussion of a possible policy.
>>
>> The policy would look something like the following:
>>
>> ___
>>
>> All of the projects managed by the Maven PMC are maintained in a
>> releasable condition. If a developer wants to make a change that will
>> result in an a component being unreleasable for any significant period
>> of time, that developer is responsible for setting up a branch
>> structure that preserved the releasability of the component for the
>> duration. They might do their work on a sandbox branch, or they might
>> set up a maintenance branch for the current state of the code.
>> ___
>>
>>
>> I see several advantages to this policy:
>>
>> 1: The work to fix a small problem or add a small feature is
>> proportionate.  You can't suddenly find yourself needing to release
>> four components and / or make a branch and do merges to get a fix out
>> to the users (including yourself).
>>
>> 2: If we ever have to deal with a security fix, we will find it much
>> less painful.
>>
>> 3: We recognize the reality that we're all volunteers, and that good
>> intentions don't always lead to timely activity.
>>
>> It seems to me that this is in the general territory of 'CD' which is
>> pretty popular in the world at large.
>>
>> What do people think?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> What matters is not ideas, but the people who have them. Good people can fix 
> bad ideas, but good ideas can't save bad people.
>
>  -- Paul Graham
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Releasable by default?

Re: Releasable by default?

Re: Releasable by default?

Re: Releasable by default?

4 matches

Site Navigation

Mail list logo

Footer information