BlackBox Framework Center

Posted: **Sat Apr 30, 2016 7:23 am**

Since we are approaching a release, I started to think about how to generate a change list for 1.7.
The simplest and most consistent approach would be to start with the Redmine issues and
transform them into a file that lists all issues that are:
1. closed
2. belong to Target Version 1.7
3. either Bug, Feature or Documentation.

With a little BlackBox tool based on Xmlcore I was able to convert the
Redmine issues into a BB file that lists all such issues and provides a link
to the corresponding Redmine Issue. In Redmine you can then see the various
commits with the changed files.

Posted: **Tue May 03, 2016 3:21 pm**

any comments on the change list?

Posted: **Wed May 04, 2016 7:01 am**

Josef Templ wrote:any comments on the change list?

Looks good. And nice that this process can be automated.
Many issues can be described better, however I do not know the aim of this file, so it is difficult to decide what to do...
Will we attach this file to the distribution or place in some web-page?

Josef, it is better to attach StdCoded file than post in the text... as moderator I fixed this readability issue this time.

Posted: **Wed May 04, 2016 8:38 pm**

Why is issue-#49 (fixes in SqlOdbc) not in this list?

Posted: **Thu May 05, 2016 5:48 am**

Zinn wrote:Why is issue-#49 (fixes in SqlOdbc) not in this list?

At the time of generating the change list #49 was not marked as closed
because we had to apply a late fix.
It is closed now.

Posted: **Thu May 05, 2016 6:40 am**

Ivan Denisov wrote: Looks good. And nice that this process can be automated.
Many issues can be described better, however I do not know the aim of this file, so it is difficult to decide what to do...
Will we attach this file to the distribution or place in some web-page?

Some issues contain more than the issue itself. They contain a proposal for a solution and/or a discussion about the solution. This should not be in the issue. As far as I have seen it is only a small number of issues and they could be cleaned up easily.

The fundamental question is really if we want to have a change list at all and, if yes, in which format and at which place it is stored.

One possibility would be to include it in the distribution and put it in the root directory.
Having it in the distribution has the advantage that the distribution and the change list are consistently stored forever.
For the 1.7 release the change list would contain the changes from 1.6 to 1.7.
For the 1.8 release the change list would contain the changes from 1.7 to 1.8.
Thereby the change list does not grow infinitely.
Having it in the root directory means that a search for Docu would not find it, which seems like an advantage because the change list contains many different terms and would appear in the search result of many docu searches.

Another option is to put it on the web (as .html) and this could also be combined with including it in the distribution.

The process of generating the change list is currently not 100% automated. The xml file needs to be downloaded manually. But in principle, I think, this could also be automated. Then we would have an interesting option: The build engine could integrate change list generation whenever a new master build is performed. The only requirement is to mark the merged issue as Closed in Redmine before the changes are merged to master in Github. Any master build would then contain an up-to-date change list.

Ivan Denisov wrote: it is better to attach StdCoded file than post in the text... as moderator I fixed this readability issue this time.

Then you always have to download a file which, to me, is more work than using copy and paste.
But I don't really care...

- Josef

Posted: **Fri May 06, 2016 1:58 pm**

with only a few lines in the Python build script it would be possible to automate the download of the xml file.
This problem is solved in principle, see below.

Code: Select all

#!/usr/bin/python
# Python 2.x code for downloading the BlackBox issues as an xml file

import urllib2

url = "http://redmine.blackboxframework.org/projects/blackbox/issues.xml?status_id=5&fixed_version_id=2&offset=0&limit=100"
file_name = "issues.xml"

# Download the file from `url` and save it locally under `file_name`:
response = urllib2.urlopen(url)
with open(file_name,'wb') as out_file:
    data = response.read() # a `bytes` object
    out_file.write(data)

Posted: **Sat May 07, 2016 4:09 am**

Josef Templ wrote:with only a few lines in the Python build script it would be possible to automate the download of the xml file.
This problem is solved in principle, see below.

That is good if we want to publish parsed xml as an web page. I can automate this in the web-server. However in that case is better to make parser also with python.

There is an alternative. This XML file can be downloaded directly to BlackBox and proceed with your XML parser after been downloaded.
I am attaching the example of the similar engine. CommHttp downloading the file. Please look at the CommObxHttp and RedInstall as the examples.
This also can be done on the server side.

Posted: **Sun May 08, 2016 1:52 pm**

Ivan Denisov wrote:There is an alternative. This XML file can be downloaded directly to BlackBox and proceed with your XML parser after been downloaded.
I am attaching the example of the similar engine. CommHttp downloading the file. Please look at the CommObxHttp and RedInstall as the examples.
This also can be done on the server side.

I have never heard about CommHttp or CommObxHttp.
Why should we want to introduce a dependency on unknown external modules if we can
avoid it? If they are part of BlackBox it may be an alternative.

- Josef

Posted: **Sun May 08, 2016 2:34 pm**

Josef Templ wrote:I have never heard about CommHttp or CommObxHttp.
Why should we want to introduce a dependency on unknown external modules if we can
avoid it? If they are part of BlackBox it may be an alternative.

They are not a part of BlackBox. I developed them for RedInstall module and other tasks. I think, that we can avoid using python, replacing all to BlackBox where it is possible. So I am suggesting to use this modules to obtain xml file instead of Python.

BlackBox Framework Center

issue-#112 producing a change list from Redmine

issue-#112 producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine

Re: producing a change list from Redmine