Allow setting of "Merged in" box on Trac

[kcrisman]

I think it would be easy to add a spot in attributes for this.

def close_ticket(self, ticket):
comment = ''
attributes = {
'_ts': ticket.timestamp,
'status': 'closed',
'resolution': 'fixed',
}
notify = True
if len(ticket.commit) > 0:
attributes['branch'] = ticket.commit
return self.trac.authenticated_proxy.ticket.update(
ticket.number, comment, attributes, notify)

But not so easy to guess what the number of the release will be. There are tools to find the previous stable or unstable release in git_trac/git_repository.py but I don't see any support for adding the release version to git_trac/releasemgr/cmdline.py One could do something with

parser_close.add_argument('--version', ...

and similarly for parser_merge if --close was given, but maybe this is more invasive than desired?

[vbraun]

Yes we only know for sure the name of the next release when we release.

[kcrisman]

Would you be averse to stuff like

parser_close.add_argument('--version', ...

in the event I could figure out how to do it properly?

[vbraun]

I also can't know the name of the next release for sure. It would have to be an extra step after the release. This could also replace branch names with commits etc...

[kcrisman]

I also can't know the name of the next release for sure.

? Do you mean that it could be 6.4.beta5 but then turn into 7.0.beta5 ? I'm not sure what you mean.

It would have to be an extra step after the release. This could also replace branch names with commits etc...

Again, I'm not sure why; it would only require naming a release in the fashion above. After all, when you close it it replaces branch names anyway, as far as I can tell. And it is annoying when that happens now, because one doesn't even know exactly where something closed appears until you send out the email to sage-release.

Alternately, would it be possible to have a separate parser option parser_merged_in or something just to do this thing?

On a related note, I was wondering what happens with dup/invalid tickets nowadays - presumably they don't appear at all in the git history, but it's important for them to be noted somewhere; I presume Jeroen's script still finds them, or maybe not?

[vbraun]

Im mean it could be 6.5.beta7 or 6.5.rc0, say.

The replacing of branch names is currently done in a trac plugin.

[vbraun]

There is a "git releasemgr release x,y.z" subcommand to actually make the release, that would be the right place to do it.

[kcrisman]

Ah, I didn't scroll that far, since I was thinking of the closing process. Okay, that is a good place for me to start. Would something along the following lines work?

def release(self, version, check=True):
    from .make_release import update_version, create_tarball, check_tarball, check_upgrade
    ...
    for ticket in self.find_tickets_for_this_version(version):
        self.trac.authenticated_proxy.ticket.update(ticket.number, '', {'Merged in': version}, True)

    def find_tickets_for_this_version(version):
        assert version == self.repo.current_version()
        prev = self.repo.previous_version()
        ticket_list = []
        # now steal code from self.repo.find_release_merge_of_ticket,
        # or probably write a new method, where the log only goes to 
        # the previous version prev
        # and appends the ticket number to this list

and then in the repo, define the obvious previous_version not just previous_stable_version.

This wouldn't be the most efficient way to do it, but it seems like it would be robust.