Hi,
On 10/14/15 2:46 PM, Benson Margulies wrote:
On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl <[email protected]> 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 <[email protected]> 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
