Re: Does anybody have release plans for current roundup devel?

Hi Thomas:

I really need to read all my email before replying to any of it 8-).

In message <[email protected]>,
Thomas Arendsen Hein writes:
>* Joseph Myers <[email protected]> [20190220 04:49]:
>> On Tue, 19 Feb 2019, John P. Rouillard wrote:
>> 
>> > There is at least one patch:
>> > 
>> >   https://issues.roundup-tracker.org/issue2551023
>> > 
>> > that could go into a 1.6.1 release. Thomas Hein do you have a cheat
>> > sheet for creating a 1.6 release branch and tagging a 1.6.1 release?
>> 
>> I've previously suggested that my fix for issue2550994 (breakage caused by 
>> configparser backports; fix is 0cdf19b82354) ought to be added to the 1.6 
>> branch (which already exists) if such a release is to be made.
>
>This would be:
>
>hg co maint-1.6
>hg graft -r 0cdf19b82354
># resolve merge conflict in CHANGES.txt by removing everything new
># except the entry for fixing issue2550994

I just did that myself and it looks like I got it right on my last
reply.

>While looking at this I noticed that "hg log -b maint-1.6" shows
>things that are not mentioned in CHANGES.txt. I don't know if this
>was to make merging it into default easier (no conflicts), or to
>avoid extra work, or if it has just been forgotten :)

The patches were all doc patches. I have added the following to CHANGES.txt
on the maint-1.6 branch.

  doc updates. Link rot fixed and some grammar changes.
  'Provisional User' config example fixed. Issue tracker is
  now https. (John Rouillard) 

That covers the existing entries that are already on default line as
well as another commit to default for the
https://issues.roundup-tracker.org change.
 
>> (Though 
>> I'm more interested in having a 2.0.0 release from current trunk, with 
>> successive 2.0.1, 2.0.2 etc. following reasonably quickly should issues be 
>> found with the changes in 2.0.)
>
>I'd like to see a maintained 1.6 branch for some time, e.g. the gpg
>problems in the default branch would be problematic for us. Or does
>it work and just the tests fail?

Ralf believes the failing gpg is a problem with an older version of
gpg in debian stable. I am not sure if that should be considered a
regression. At the very least it probably requires an update to the
docs.

I agree with Ralf that it would be better to get a 2.x release
out. That would need to include the requirements change to get gpg to
work. I am not sure when the 2.x release would be good to go or what
state it's in.

Given the bug with wsgi CSRF headers checks, I think a 1.6.1 release
would be good and take less testing/preparation than a full major
release.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.