+1 on what we should do. On Mon, Aug 13, 2018 at 3:06 PM, Tom Graves <tgraves...@yahoo.com.invalid> wrote:
> > > I mean, what are concrete steps beyond saying this is a problem? That's > the important thing to discuss. > > Sorry I'm a bit confused by your statement but also think I agree. I > started this thread for this reason. I pointed out that I thought it was a > problem and also brought up things I thought we could do to help fix it. > > Maybe I wasn't clear in the first email, the list of things I had were > proposals on what we do for a jira that is for a correctness/data loss > issue. Its the committers and developers that are involved in this though > so if people don't agree or aren't going to do them, then it doesn't work. > > Just to restate what I think we should do: > > - label any correctness/data loss jira with "correctness" > - jira should be marked as a blocker by default if someone suspects a > corruption/loss issue > - Make sure the description is clear about when it occurs and impact to > the user. > - ensure its back ported to all active branches > - See if we can have a separate section in the release notes for these > > The last one I guess is more a one time thing that i can file a jira for. > The first 4 would be done for each jira filed. > > I'm proposing we do these things and as such if people agree we would also > document those things in the committers or developers guide and send email > to the list. > > > > Tom > On Monday, August 13, 2018, 11:17:22 AM CDT, Sean Owen <sro...@apache.org> > wrote: > > > Generally: if someone thinks correctness fix X should be backported > further, I'd say just do it, if it's to an active release branch (see > below). Anything that important has to outweigh most any other concern, > like behavior changes. > > > On Mon, Aug 13, 2018 at 11:08 AM Tom Graves <tgraves...@yahoo.com> wrote: > > I'm not really sure what you mean by this, this proposal is to introduce a > process for this type of issue so its at least brought to peoples > attention. We can't do anything to make people work on certain things. If > they aren't raised as important issues then its really easy to miss these > things. If its a blocker we should also not be doing any new releases > without a fix for it which may motivate people to look at it. > > > I mean, what are concrete steps beyond saying this is a problem? That's > the important thing to discuss. > > There's a good one here: let's say anything that's likely to be a > correctness or data loss issue should automatically be labeled > 'correctness' as such and set to Blocker. > > That can go into the how-to-contribute manual in the docs and in a note to > dev@. > > > > I agree it would be good for us to make it more official about which > branches are being maintained. I think at this point its still 2.1.x, > 2.2.x, and 2.3.x since we recently did releases of all of these. Since 2.4 > will be coming out we should definitely think about stop maintaining > 2.1.x. Perhaps we need a table on our release page about this. But this > should be a separate thread. > > > I propose writing something like this in the 'versioning' doc page, to at > least establish a policy: > > Minor release branches will, generally, be maintained with bug fixes > releases for a period of 18 months. For example, branch 2.1.x is no longer > considered maintained as of July 2018, 18 months after the release of 2.1.0 > in December 2106. > > This gives us -- and more importantly users -- some understanding of what > to expect for backporting and fixes. > > > I am going to revive the thread about adding PMC / committers as it's > overdue. That may not do much, but, more hands to do more work ought to > possibly free up people to focus on deeper harder issues. >
