Replace always working with always releasable. To me it means the same thing.
> On Oct 14, 2015, at 8:46 AM, Benson Margulies <[email protected]> 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. >> >> 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 <[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). >>> >>> 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: [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] >> > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
