On Wed, Oct 14, 2015 at 8:31 AM, Jason van Zyl <ja...@takari.io> 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 <bimargul...@gmail.com> 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
